From: Greg KH <greg@kroah.com>
To: Corey Minyard <minyard@acm.org>
Cc: Andrew Morton <akpm@osdl.org>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Add sysfs support to the IPMI driver
Date: Mon, 14 Mar 2005 14:57:16 -0800 [thread overview]
Message-ID: <20050314225716.GA9779@kroah.com> (raw)
In-Reply-To: <4234C5C2.8000109@acm.org>
On Sun, Mar 13, 2005 at 04:59:14PM -0600, Corey Minyard wrote:
> Greg KH wrote:
> >On Sat, Mar 12, 2005 at 10:57:24PM -0600, Corey Minyard wrote:
> >>The IPMI driver has long needed to tie into the device model (and I've
> >>long been hoping someone else would do it). I finally gave up and spent
> >>the time to learn how to do it. I think this is right, it seems to work
> >>on on my system.
> >
> >Looks good. One minor question:
> >
> >>+
> >>+ snprintf(name, sizeof(name), "ipmi%d", if_num);
> >>+ class_simple_device_add(ipmi_class, dev, NULL, name);
> >
> >What do ipmi class devices live on? pci devices? i2c devices?
> >platform devices? Or are they purely virtual things?
> >
> Good question. I struggled with this for a little while and decided the
> class interface was important to have in first and I'd figure out the
> rest later. They live in different places depending on the particular
> low-level interface. Some live on the I2C bus (and will show up there
> in sysfs with the I2C driver). Some live on the ISA bus, some are
> memory-mapped, some are on the PCI bus (though there is not a driver for
> PCI support yet), and some sit on the end of a serial port (driver is in
> the works). I know, it's a mess, but there's not much I can do about
> these crazy hardware manufacturers.
>
> I wasn't sure where to handle all this. The I2C and PCI bus side of
> things should be handled. However, the others probably need to sit
> someplace on a bus, right? That should probably be handled in the
> low-level code that actually knows where the hardware sits.
Well, how about handling the devices that already have a struct device
today (like the i2c and pci devices)? Pass the pointer to that device
into your class_simple_device_add() call. Then, work on figuring out
where your other devices live on some new bus later.
thanks,
greg k-h
prev parent reply other threads:[~2005-03-14 23:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-13 4:57 [PATCH] Add sysfs support to the IPMI driver Corey Minyard
2005-03-13 5:20 ` Greg KH
2005-03-13 22:59 ` Corey Minyard
2005-03-14 22:57 ` Greg KH [this message]
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=20050314225716.GA9779@kroah.com \
--to=greg@kroah.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=minyard@acm.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.