From: Alex Chiang <achiang@hp.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: lenb@kernel.org, shaohua.li@intel.com,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH v3 1/6] ACPI: dock: convert sysfs attributes to an attribute_group
Date: Mon, 19 Oct 2009 11:21:38 -0600 [thread overview]
Message-ID: <20091019172138.GB23948@ldl.fc.hp.com> (raw)
In-Reply-To: <20091018071630.GC3935@core.coreip.homeip.net>
Hi Dmitry,
* Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> On Fri, Oct 16, 2009 at 03:14:59PM -0600, Alex Chiang wrote:
> > As suggested by Dmitry Torokhov, convert the individual sysfs
> > attributes into an attribute group.
> >
> > This change eliminates quite a bit of copy/paste code in the
> > error handling paths.
> >
>
> Looks much better, one more suggestion though:
>
> > +err_unregister:
> > + printk(KERN_ERR "%s encountered error %d\n", __func__, ret);
>
> If you want to print error this it should probably go down, right before
> "return ret".
This is true for this patch, 1/6... but by the end of the series,
the problem has resolved itself.
I agree that it's sloppy to have this bit of inconsistency in the
middle of the patch series, but I'm reluctant to spin the entire
series again, for sake of a printk.
> > + sysfs_remove_group(&dock_device->dev.kobj, &dock_attribute_group);
>
> It begs another label right here. There are cases when yo0u already
> registered the platform device but haven't added the sysfs group, right?
This isn't quite true. In this patch, 1/6, our sequence goes:
platform_device_register_simple()
platform_device_add_data()
/* twiddle some state in the platform device, no error paths though */
sysfs_create_group()
Arguably, the platform_device_add_data() call could fail with
-ENOMEM, but the code today doesn't deal with that error
condition, and I didn't touch the platform_device_add_data()
line.
So really, there are no other exit paths between registering the
platform device and adding the sysfs group.
By the end of the patch series, I combine the _register_simple()
call with the _add_data() call and the final sequence looks like
this:
if (platform_device_register_data() == error)
return error;
/* twiddle local state in platform device */
if (sysfs_create_group())
goto err_unregister;
/* other stuff */
err_unregister:
printk(KERN_ERR "%s encountered error %d\n", __func__, ret);
sysfs_remove_group(&dd->dev.kobj, &dock_attribute_group);
platform_device_unregister(dd);
return ret;
Checking other callsites of sysfs_remove_group(), it seems to be
valid to call that API even if the creation step failed.
Basically, I don't see the necessity of adding another label.
Below is the final end state of dock_add(). Hopefully the code is
a lot clearer than before. If there are still semantic issues,
please let me know and I'll happily respin.
Thanks.
/ac
static int dock_add(acpi_handle handle)
{
int ret, id;
struct dock_station ds, *dock_station;
struct platform_device *dd;
id = dock_station_count;
dd = platform_device_register_data(NULL, "dock", id, &ds, sizeof(ds));
if (IS_ERR(dd))
return PTR_ERR(dd);
dock_station = dd->dev.platform_data;
dock_station->handle = handle;
dock_station->dock_device = dd;
dock_station->last_dock_time = jiffies - HZ;
mutex_init(&dock_station->hp_lock);
spin_lock_init(&dock_station->dd_lock);
INIT_LIST_HEAD(&dock_station->sibling);
INIT_LIST_HEAD(&dock_station->hotplug_devices);
ATOMIC_INIT_NOTIFIER_HEAD(&dock_notifier_list);
INIT_LIST_HEAD(&dock_station->dependent_devices);
/* we want the dock device to send uevents */
dev_set_uevent_suppress(&dd->dev, 0);
if (is_dock(handle))
dock_station->flags |= DOCK_IS_DOCK;
if (is_ata(handle))
dock_station->flags |= DOCK_IS_ATA;
if (is_battery(handle))
dock_station->flags |= DOCK_IS_BAT;
ret = sysfs_create_group(&dd->dev.kobj, &dock_attribute_group);
if (ret)
goto err_unregister;
/* Find dependent devices */
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT, ACPI_UINT32_MAX,
find_dock_devices, dock_station, NULL);
/* add the dock station as a device dependent on itself */
ret = add_dock_dependent_device(dock_station, handle);
if (ret)
goto err_unregister;
dock_station_count++;
list_add(&dock_station->sibling, &dock_stations);
return 0;
err_unregister:
printk(KERN_ERR "%s encountered error %d\n", __func__, ret);
sysfs_remove_group(&dd->dev.kobj, &dock_attribute_group);
platform_device_unregister(dd);
return ret;
}
next prev parent reply other threads:[~2009-10-19 17:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-16 21:14 [PATCH v3 0/6] ACPI: dock: code hygiene Alex Chiang
2009-10-16 21:14 ` [PATCH v3 1/6] ACPI: dock: convert sysfs attributes to an attribute_group Alex Chiang
2009-10-18 7:16 ` Dmitry Torokhov
2009-10-19 17:21 ` Alex Chiang [this message]
2009-10-19 17:56 ` Dmitry Torokhov
2009-10-19 19:36 ` Alex Chiang
2009-10-16 21:15 ` [PATCH v3 2/6] ACPI: dock: combine add|alloc_dock_dependent_device Alex Chiang
2009-10-16 21:15 ` [PATCH v3 3/6] ACPI: dock: remove global 'dock_device_name' Alex Chiang
2009-10-16 21:15 ` [PATCH v3 4/6] ACPI: dock: dock_add - hoist up platform_device_register_simple() Alex Chiang
2009-10-16 21:15 ` [PATCH v3 5/6] ACPI: dock: add struct dock_station * directly to platform device data Alex Chiang
2009-10-16 21:15 ` [PATCH v3 6/6] ACPI: dock: minor whitespace and style cleanups Alex Chiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091019172138.GB23948@ldl.fc.hp.com \
--to=achiang@hp.com \
--cc=dmitry.torokhov@gmail.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shaohua.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.