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 <[email protected]>
Subject: hid: struct device - replace bus_id with dev_name(), dev_set_name()
CC: Jiri Kosina <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-Off-By: Kay Sievers <[email protected]>
---
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 721a36d..73ccc37 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1573,9 +1573,8 @@ int hid_add_device(struct hid_device *hdev)
if (hid_ignore(hdev))
return -ENODEV;
- /* XXX hack, any other cleaner solution < 20 bus_id bytes? */
- sprintf(hdev->dev.bus_id, "%04X:%04X:%04X.%04X", hdev->bus,
- hdev->vendor, hdev->product, atomic_inc_return(&id));
+ dev_set_name(&hdev->dev, "%04X:%04X:%04X.%04X", hdev->bus,
+ hdev->vendor, hdev->product, atomic_inc_return(&id));
ret = device_add(&hdev->dev);
if (!ret)
Kay Sievers napsal(a):
> switch over to the new api, which will remove the 20 bytes array
> and does no longer have a size limitation.
Cool!
> From: Kay Sievers <[email protected]>
> Subject: hid: struct device - replace bus_id with dev_name(), dev_set_name()
>
> CC: Jiri Kosina <[email protected]>
> Acked-by: Greg Kroah-Hartman <[email protected]>
> Signed-Off-By: Kay Sievers <[email protected]>
> ---
>
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 721a36d..73ccc37 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1573,9 +1573,8 @@ int hid_add_device(struct hid_device *hdev)
> if (hid_ignore(hdev))
> return -ENODEV;
>
> - /* XXX hack, any other cleaner solution < 20 bus_id bytes? */
> - sprintf(hdev->dev.bus_id, "%04X:%04X:%04X.%04X", hdev->bus,
> - hdev->vendor, hdev->product, atomic_inc_return(&id));
> + dev_set_name(&hdev->dev, "%04X:%04X:%04X.%04X", hdev->bus,
> + hdev->vendor, hdev->product, atomic_inc_return(&id));
Could you left the comment above to remind us about removing this ugly hack
later when the new non-limited api will be used?
On Thu, 2008-10-30 at 20:25 +0100, Jiri Slaby wrote:
> Kay Sievers napsal(a):
> > switch over to the new api, which will remove the 20 bytes array
> > and does no longer have a size limitation.
>
> Cool!
> Could you left the comment above to remind us about removing this ugly hack
> later when the new non-limited api will be used?
Sure!
Thanks,
Kay
From: Kay Sievers <[email protected]>
Subject: hid: struct device - replace bus_id with dev_name(), dev_set_name()
CC: Jiri Kosina <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-Off-By: Kay Sievers <[email protected]>
---
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 1903e75..27f1e16 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1613,9 +1613,10 @@ int hid_add_device(struct hid_device *hdev)
if (hid_ignore(hdev))
return -ENODEV;
- /* XXX hack, any other cleaner solution < 20 bus_id bytes? */
- sprintf(hdev->dev.bus_id, "%04X:%04X:%04X.%04X", hdev->bus,
- hdev->vendor, hdev->product, atomic_inc_return(&id));
+ /* XXX hack, any other cleaner solution after the driver core
+ * is converted to allow more than 20 bytes as the device name? */
+ dev_set_name(&hdev->dev, "%04X:%04X:%04X.%04X", hdev->bus,
+ hdev->vendor, hdev->product, atomic_inc_return(&id));
ret = device_add(&hdev->dev);
if (!ret)
On Thu, 30 Oct 2008, Kay Sievers wrote:
> > > switch over to the new api, which will remove the 20 bytes array
> > > and does no longer have a size limitation.
> > Cool!
> > Could you left the comment above to remind us about removing this ugly hack
> > later when the new non-limited api will be used?
> Sure!
> From: Kay Sievers <[email protected]>
> Subject: hid: struct device - replace bus_id with dev_name(), dev_set_name()
Hi Kay,
thanks for this cleanup. What is the timeframe the bus_id will be removed
from struct device?
--
Jiri Kosina
SUSE Labs
On Fri, Oct 31, 2008 at 00:10, Jiri Kosina <[email protected]> wrote:
> On Thu, 30 Oct 2008, Kay Sievers wrote:
>
>> > > switch over to the new api, which will remove the 20 bytes array
>> > > and does no longer have a size limitation.
>> > Cool!
>> > Could you left the comment above to remind us about removing this ugly hack
>> > later when the new non-limited api will be used?
>> Sure!
>> From: Kay Sievers <[email protected]>
>> Subject: hid: struct device - replace bus_id with dev_name(), dev_set_name()
>
> Hi Kay,
>
> thanks for this cleanup. What is the timeframe the bus_id will be removed
> from struct device?
Hmm, not sure. We will put the remaining pieces into Greg's tree, wait
for -next to carry most of it, and convert the rest. Maybe we can do
it for the next kernel, but we might get sidetracked again, and it
might take longer.
Thanks,
Kay
On Fri, 31 Oct 2008, Kay Sievers wrote:
> >> Subject: hid: struct device - replace bus_id with dev_name(), dev_set_name()
> > thanks for this cleanup. What is the timeframe the bus_id will be removed
> > from struct device?
> Hmm, not sure. We will put the remaining pieces into Greg's tree, wait
> for -next to carry most of it, and convert the rest. Maybe we can do
> it for the next kernel, but we might get sidetracked again, and it
> might take longer.
OK, thanks. I just wanted to know how much hurry do you expect from
subsystem maintainers with this change.
I have queued it for 2.6.29 now in my tree, thanks.
--
Jiri Kosina
SUSE Labs