All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <paul.mundt@nokia.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] SuperHyway bus support
Date: Fri, 7 Jan 2005 11:41:04 +0200	[thread overview]
Message-ID: <20050107094103.GA7408@pointless.research.nokia.com> (raw)
In-Reply-To: <20050107072222.GB24441@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 4081 bytes --]

On Thu, Jan 06, 2005 at 11:22:22PM -0800, Greg KH wrote:
> So it looks like you are just adding a fake "bus" driver and then
> manually adding the bus devices to the root device.  Why not just
> complete the conversion and register the real devices properly?
> 
Can you elaborate on what you mean by registering the "real devices properly"?

> We are depreciating device lists within the kernel.  The PCI device list
> will be going away sometime in the future, and we shouldn't be adding
> new ones.  Can't this just be determined from userspace instead like
> 'lspci' and 'lsusb' do?
> 
Yes, this can be done in userspace, so that stuff can be dropped.

> > +void superhyway_create_sysfs_files(struct superhyway_device *s)
> > +{
> > +	struct device *dev = &s->dev;
> > +
> > +	device_create_file(dev, &dev_attr_perr_flags);
> > +	device_create_file(dev, &dev_attr_merr_flags);
> > +	device_create_file(dev, &dev_attr_mod_vers);
> > +	device_create_file(dev, &dev_attr_mod_id);
> > +	device_create_file(dev, &dev_attr_bot_mb);
> > +	device_create_file(dev, &dev_attr_top_mb);
> > +	device_create_file(dev, &dev_attr_resource);
> 
> Can you use a default attribute list instead of manually creating the
> files individually?  Also, I don't see the code that removes these
> attributes.  Please don't rely on the sysfs function of automatically
> cleaning up the attributes when the device is removed, that might not
> work in the future.
> 
Yes, I can use the dev_attrs for this. Thanks for pointing that out.

> > +static struct superhyway_bus superhyway_bus = {
> > +	.name	= "SuperHyway bus",
> > +};
> 
> Please don't add sysfs directories that have spaces in them.  How about
> "superhyway_bus" instead?
> 
Ok.

> > +	pr_info("    0x%04x (%s) control block at 0x%08lx\n",
> > +		dev->id.id, dev->pretty_name, dev->resource.start);
> 
> Shouldn't this be a debug message?
> 
Yes, probably. Though with the devlist in userspace I suppose it's not overly
useful to have here anyways.

> > +static void __exit superhyway_bus_exit(void)
> > +{
> > +	struct superhyway_device *dev;
> > +
> > +	list_for_each_entry(dev, &superhyway_bus.devices, node) {
> > +		device_unregister(&dev->dev);
> > +		kfree(dev);
> > +	}
> 
> Ick, not good, userspace could still have a reference on the device
> through sysfs.  Don't kfree it here, do it in the release function
> (which you need to do.)
> 
Ok.

> Also, why have a local list of devices and not just use the list the
> driver core provides for you?
> 
Probably because I wasn't aware that the driver core provided one. Now that I
see the bus_for_each_xxx() stuff I'll drop the list and use that instead.

> > +struct superhyway_device {
> > +	struct list_head node;
> > +
> > +	char name[32];
> > +	char pretty_name[64];
> 
> Do you need the name and pretty_name?
> 
No, the pretty_name was only added for the devlist. I'll clean that up.

> > +struct superhyway_bus {
> > +	struct list_head devices;
> > +	struct device dev;
> > +	char name[16];
> > +};
> 
> Is the name really necessary?
> 
Probably not. With that and the list gone I can drop this struct entirely and
just have the root device as a struct device.

> > +/* drivers/sh/superhyway/superhyway-sysfs.c */
> > +#ifdef CONFIG_SYSFS
> > +void superhyway_create_sysfs_files(struct superhyway_device *);
> > +#else
> > +void superhyway_create_sysfs_files(struct superhyway_device *s)
> > +{
> > +	/* Nothing to do */
> > +}
> > +#endif
> 
> Why ifdef this function?  That should not be needed.
> 
superhyway_add_device() calls this. We don't want to assume that CONFIG_SYSFS
will always be enabled. I can move the ifdef in to superhyway_add_device() if
you think it would be cleaner. (And this is needed as we happen to have
superhyway_create_sysfs_files() defined in superhyway-sysfs.c which is only
compiled in when CONFIG_SYSFS is set, and I would rather not link this in
unconditionally).

Thanks for looking at this, I'll post a cleaned up version shortly.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2005-01-07  9:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-27  7:52 [PATCH] SuperHyway bus support Paul Mundt
2005-01-07  7:22 ` Greg KH
2005-01-07  9:41   ` Paul Mundt [this message]
2005-01-07 16:29     ` Paul Mundt
2005-01-12  8:17       ` Greg KH
2005-01-12 12:48         ` Paul Mundt
2005-01-25 14:08           ` Paul Mundt
2005-01-25 20:30             ` Greg KH
2005-02-01 22:05           ` Greg KH
2005-02-01 22:23             ` Sam Ravnborg
2005-02-01 22:30               ` Greg KH
2005-02-02  7:04                 ` Paul Mundt
2005-02-02  7:10             ` Paul Mundt
2005-02-02 22:19               ` Greg KH

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=20050107094103.GA7408@pointless.research.nokia.com \
    --to=paul.mundt@nokia.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.