ssb: struct device - replace bus_id with dev_name(), dev_set_name() - Kernel

This is a discussion on ssb: struct device - replace bus_id with dev_name(), dev_set_name() - Kernel ; This patch is part of a larger patch series which will remove the "char bus_id[20]" name string from struct device. The device name is managed in the kobject anyway, and without any size limitation, and just needlessly copied into "struct ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: ssb: struct device - replace bus_id with dev_name(), dev_set_name()

  1. ssb: struct device - replace bus_id with dev_name(), dev_set_name()

    This patch is part of a larger patch series which will remove
    the "char bus_id[20]" name string from struct device. The device
    name is managed in the kobject anyway, and without any size
    limitation, and just needlessly copied into "struct device".

    To set and read the device name dev_name(dev) and dev_set_name(dev)
    must be used. If your code uses static kobjects, which it shouldn't
    do, "const char *init_name" can be used to statically provide the
    name the registered device should have. At registration time, the
    init_name field is cleared, to enforce the use of dev_name(dev) to
    access the device name at a later time.

    We need to get rid of all occurrences of bus_id in the entire tree
    to be able to enable the new interface. Please apply this patch,
    and possibly convert any remaining remaining occurrences of bus_id.

    We want to submit a patch to -next, which will remove bus_id from
    "struct device", to find the remaining pieces to convert, and finally
    switch over to the new api, which will remove the 20 bytes array
    and does no longer have a size limitation.

    Thanks,
    Kay


    From: Kay Sievers
    Subject: ssb: struct device - replace bus_id with dev_name(), dev_set_name()

    CC: Michael Buesch
    Acked-by: Greg Kroah-Hartman
    Signed-Off-By: Kay Sievers
    ---


    diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
    index 0ffabf5..65a1ed9 100644
    --- a/drivers/ssb/main.c
    +++ b/drivers/ssb/main.c
    @@ -226,7 +226,7 @@ int ssb_devices_freeze(struct ssb_bus *bus)
    err = drv->suspend(dev, state);
    if (err) {
    ssb_printk(KERN_ERR PFX "Failed to freeze device %s\n",
    - dev->dev->bus_id);
    + dev_name(dev->dev));
    goto err_unwind;
    }
    }
    @@ -269,7 +269,7 @@ int ssb_devices_thaw(struct ssb_bus *bus)
    err = drv->resume(dev);
    if (err) {
    ssb_printk(KERN_ERR PFX "Failed to thaw device %s\n",
    - dev->dev->bus_id);
    + dev_name(dev->dev));
    }
    }

    @@ -454,8 +454,7 @@ static int ssb_devices_register(struct ssb_bus *bus)

    dev->release = ssb_release_dev;
    dev->bus = &ssb_bustype;
    - snprintf(dev->bus_id, sizeof(dev->bus_id),
    - "ssb%u:%d", bus->busnumber, dev_idx);
    + dev_set_name(dev, "ssb%u:%d", bus->busnumber, dev_idx);

    switch (bus->bustype) {
    case SSB_BUSTYPE_PCI:
    @@ -480,7 +479,7 @@ static int ssb_devices_register(struct ssb_bus *bus)
    if (err) {
    ssb_printk(KERN_ERR PFX
    "Could not register %s\n",
    - dev->bus_id);
    + dev_name(dev));
    /* Set dev to NULL to not unregister
    * dev on error unwinding. */
    sdev->dev = NULL;
    @@ -796,7 +795,7 @@ int ssb_bus_pcibus_register(struct ssb_bus *bus,
    err = ssb_bus_register(bus, ssb_pci_get_invariants, 0);
    if (!err) {
    ssb_printk(KERN_INFO PFX "Sonics Silicon Backplane found on "
    - "PCI device %s\n", host_pci->dev.bus_id);
    + "PCI device %s\n", dev_name(&host_pci->dev));
    }

    return err;
    diff --git a/drivers/ssb/pcihost_wrapper.c b/drivers/ssb/pcihost_wrapper.c
    index e82db4a..26737a0 100644
    --- a/drivers/ssb/pcihost_wrapper.c
    +++ b/drivers/ssb/pcihost_wrapper.c
    @@ -65,7 +65,7 @@ static int ssb_pcihost_probe(struct pci_dev *dev,
    err = pci_enable_device(dev);
    if (err)
    goto err_kfree_ssb;
    - name = dev->dev.bus_id;
    + name = dev_name(&dev->dev);
    if (dev->driver && dev->driver->name)
    name = dev->driver->name;
    err = pci_request_regions(dev, name);


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: ssb: struct device - replace bus_id with dev_name(), dev_set_name()

    On Thursday 30 October 2008 15:51:57 Kay Sievers wrote:
    > This patch is part of a larger patch series which will remove
    > the "char bus_id[20]" name string from struct device. The device
    > name is managed in the kobject anyway, and without any size
    > limitation, and just needlessly copied into "struct device".
    >
    > To set and read the device name dev_name(dev) and dev_set_name(dev)
    > must be used. If your code uses static kobjects, which it shouldn't
    > do, "const char *init_name" can be used to statically provide the
    > name the registered device should have. At registration time, the
    > init_name field is cleared, to enforce the use of dev_name(dev) to
    > access the device name at a later time.
    >
    > We need to get rid of all occurrences of bus_id in the entire tree
    > to be able to enable the new interface. Please apply this patch,
    > and possibly convert any remaining remaining occurrences of bus_id.
    >
    > We want to submit a patch to -next, which will remove bus_id from
    > "struct device", to find the remaining pieces to convert, and finally
    > switch over to the new api, which will remove the 20 bytes array
    > and does no longer have a size limitation.
    >
    > Thanks,
    > Kay
    >
    >
    > From: Kay Sievers
    > Subject: ssb: struct device - replace bus_id with dev_name(), dev_set_name()
    >
    > CC: Michael Buesch
    > Acked-by: Greg Kroah-Hartman
    > Signed-Off-By: Kay Sievers


    ACK

    --
    Greetings Michael.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread