From: Greg KH <greg@kroah.com>
To: Nicolas Schichan <nschichan@freebox.fr>
Cc: Jeff Garzik <jgarzik@pobox.com>,
linux-ide@vger.kernel.org, Maxime Bizon <mbizon@freebox.fr>
Subject: Re: [RFC] add port information for ATA devices in sysfs
Date: Tue, 27 Apr 2010 22:50:13 -0700 [thread overview]
Message-ID: <20100428055013.GA14913@kroah.com> (raw)
In-Reply-To: <201004271518.13611.nschichan@freebox.fr>
On Tue, Apr 27, 2010 at 03:18:13PM +0200, Nicolas Schichan wrote:
> On Tuesday 27 April 2010 05:42:10 am Greg KH wrote:
> > On Mon, Apr 26, 2010 at 06:29:04PM +0200, Nicolas Schichan wrote:
>
> > > diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> > > index 91fed3c..179abad 100644
> > > --- a/drivers/ata/libata-core.c
> > > +++ b/drivers/ata/libata-core.c
> > > @@ -5660,6 +5660,10 @@ int sata_link_init_spd(struct ata_link *link)
> > > return 0;
> > > }
> > >
> > > +static void ata_port_dev_release(struct device *dev)
> > > +{
> > > +}
> >
> > {sigh}
> >
> > By doing the above, you have guaranteed that I will make fun of this
> > code. Consider this the ridicule it deserves.
> >
> > (hint, read the kobject documentation for why I get to make fun of
> > it...)
> >
> > Think about why you created an empty release function, to try to get the
> > kernel to stop spitting out a message to you.
>
> That's right, shame on me for not reading the documentation.
>
> > Didn't you think that the
> > message was there for a reason, and it was not to be worked around?
>
> Well after reading the kobject documentation, I understand why it is
> bad thing to have this function empty. Since someone may still hold a
> reference on the device when I call device_unregister(), I guess the
> only safe place where to kfree the struct ata_port is in the release
> callback of the device.
>
> Please find an updated patch addressing your comments below:
Looks better, thanks.
As for the whole idea of the extra device (which it doesn't look like
you ever initialize anywhere), it's not good to have one sitting in the
middle of the device chain that isn't owned by a bus somehow. That just
looks wierd and can cause problems with udev rules.
why is this really needed at all? Can't you just export the port number
in the device as an attribute instead?
thanks,
greg k-h
next prev parent reply other threads:[~2010-04-28 5:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-26 16:29 [RFC] add port information for ATA devices in sysfs Nicolas Schichan
2010-04-27 3:42 ` Greg KH
2010-04-27 13:18 ` Nicolas Schichan
2010-04-28 5:50 ` Greg KH [this message]
2010-04-28 14:57 ` Maxime Bizon
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=20100428055013.GA14913@kroah.com \
--to=greg@kroah.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=mbizon@freebox.fr \
--cc=nschichan@freebox.fr \
/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.