Stuck creating sysfs hooks for a driver..

Stuck creating sysfs hooks for a driver..

[Kaiwan N Billimoria]

Hello All,

I am in the process of porting a 2.4 temperature sensor device driver (the National 
Semiconductor LM70CILD-3 temperature sensor eval board) to the 2.6 Linux kernel 
(specifically to v 2.6.15.3 <http://2.6.15.3>), with the intention of submitting it for inclusion. 
All ok, except this: am stuck on inserting an entry in /sys instead of /proc for the
driver (as that is suggested as the new "correct" interface to userspace).

I have read some documentation on sysfs and Rubini's lddbus example in
the LDD3 book; however, i am still a little confused: do we really need
to create a new /sys/bus/<driver_name> for each device inserted into
the lernel at runtime? if (probably) not, where _exactly_ do i create
my entry, and of course, _how _ exactly?

FYI, my driver is a char driver and does not require a major/minor pair as the UI is via proc, 
and hopefully now, sysfs.
(For those interested, pl find the source here: http://www.designergraphix.com/kaiwan/projects/lm70CILD3.c )

So i guess what i'm also trying to say is this: as i don't require a major/minor pair, i'm abviously
not using register_chrdev() or the cdev() interface..hence i don't have a kobject and auto-inclusion in
the sysfs tree (isn't that right?). So... how exactly do i get my sysfs hooks in - as the 
device_create_file() API requires struct device and struct device_attribute parameters.

Have any of you come across sample code/howto/tutorial out there that demonstrates just this (creating 
arbitrary sysfs hooks)? Request your help as i'm stuck here...(i also looked through
Documentation/filesystems/sysfs.txt but was unable to properly map it to code...  ). 

Perhaps, as the usual googling did not turn up a full-fledged howto on this topic, it's time for a 
knowledgeable person(s) out there to write one? I feel this would be v useful in the Documentation/ branch..
Just a suggestion..

TIA, kaiwan.

Re: Stuck creating sysfs hooks for a driver..

[Seewer Philippe]

On Wed, 15 Feb 2006 13:24:28 +0530, Kaiwan N Billimoria wrote:
> 
> 
>Hello All,
>
>I am in the process of porting a 2.4 temperature sensor device driver (the National 
>Semiconductor LM70CILD-3 temperature sensor eval board) to the 2.6 Linux kernel 
>(specifically to v 2.6.15.3 <http://2.6.15.3>), with the intention of submitting it for inclusion. 
>All ok, except this: am stuck on inserting an entry in /sys instead of /proc for the
>driver (as that is suggested as the new "correct" interface to userspace).
>
>I have read some documentation on sysfs and Rubini's lddbus example in
>the LDD3 book; however, i am still a little confused: do we really need
>to create a new /sys/bus/<driver_name> for each device inserted into
>the lernel at runtime? if (probably) not, where _exactly_ do i create
>my entry, and of course, _how _ exactly?
>
>FYI, my driver is a char driver and does not require a major/minor pair as the UI is via proc, 
>and hopefully now, sysfs.
>(For those interested, pl find the source here: http://www.designergraphix.com/kaiwan/projects/lm70CILD3.c )
>
>So i guess what i'm also trying to say is this: as i don't require a major/minor pair, i'm abviously
>not using register_chrdev() or the cdev() interface..hence i don't have a kobject and auto-inclusion in
>the sysfs tree (isn't that right?). So... how exactly do i get my sysfs hooks in - as the 
>device_create_file() API requires struct device and struct device_attribute parameters.
>
>Have any of you come across sample code/howto/tutorial out there that demonstrates just this (creating 
>arbitrary sysfs hooks)? Request your help as i'm stuck here...(i also looked through
>Documentation/filesystems/sysfs.txt but was unable to properly map it to code...  ). 
>
>Perhaps, as the usual googling did not turn up a full-fledged howto on this topic, it's time for a 
>knowledgeable person(s) out there to write one? I feel this would be v useful in the Documentation/ branch..
>Just a suggestion..
>
>TIA, kaiwan.
> 
> 

Hmmm...

I don't know if this'll really help, but have a look at
drivers/firmware/edd.c

Re: Stuck creating sysfs hooks for a driver..

[Greg KH]

On Wed, Feb 15, 2006 at 01:24:28PM +0530, Kaiwan N Billimoria wrote:
> Hello All,
> 
> I am in the process of porting a 2.4 temperature sensor device driver (the 
> National Semiconductor LM70CILD-3 temperature sensor eval board) to the 2.6 
> Linux kernel (specifically to v 2.6.15.3 <http://2.6.15.3>), with the 
> intention of submitting it for inclusion. All ok, except this: am stuck on 
> inserting an entry in /sys instead of /proc for the
> driver (as that is suggested as the new "correct" interface to userspace).

Have you read Documentation/hwmon/sysfs-interface?  I think that,
combined with using the hwmon class code is what you want to use here.

Hope this helps,

greg k-h

Re: Stuck creating sysfs hooks for a driver..

[Kaiwan N Billimoria]

 >Seewer Philippe wrote:

>Hmmm...
>
>I don't know if this'll really help, but have a look at
>drivers/firmware/edd.c

 >Greg KH wrote:

>Have you read Documentation/hwmon/sysfs-interface?  I think that,
>combined with using the hwmon class code is what you want to use here.
>
>Hope this helps,
>
>greg k-h
>
>  
>
Thanks, yes I shall look up both these..at first glance they do look 
promising.

One thing i'd like to point out though, Greg: the LM70 is an 
SPI/Microwire based system and not i2c; so straight away, the i2c 
interface by itself will not be used...; also, the specific board 
(LM70CILD-3, which i've written the 2.4 driver for & am now porting to 
2.6), comes with a built-in parport interface..so that's what the driver 
takes into account of course..

Also it's a relatively simple temperature sensor - it does not seem to 
support hysteresis temperature, i/p voltages, etc. I'm saying all this 
as the sysfs interface i envision is just a simple read-only hook: the 
o/p value (after a little userspace massaging) is the temperature in 
Celsius correct to 0.25 degrees. So it looks to me that this particular 
driver necessitates a kind-of "custom" entry under /sys/class/hwmon with 
it's own userspace support. Do I move ahead in this direction?

Regards,
kaiwan.

Re: Stuck creating sysfs hooks for a driver..

[Arjan van de Ven]

> Also it's a relatively simple temperature sensor - it does not seem to 
> support hysteresis temperature, i/p voltages, etc. I'm saying all this 
> as the sysfs interface i envision is just a simple read-only hook: the 
> o/p value (after a little userspace massaging) is the temperature in 
> Celsius correct to 0.25 degrees. So it looks to me that this particular 
> driver necessitates a kind-of "custom" entry under /sys/class/hwmon with 
> it's own userspace support. 

try to avoid this!
It is very useful for EVERYONE to only have ONE interface to report such
temperatures. That way *all* applications will just work, and nobody
needs to do 5 to 50 different interfaces in their application.

Please try to see if it's possible to use the existing userspace
interface. Pretty please with sugar on top ;)

Re: Stuck creating sysfs hooks for a driver..

[Greg KH]

On Thu, Feb 16, 2006 at 05:03:45PM +0530, Kaiwan N Billimoria wrote:
> One thing i'd like to point out though, Greg: the LM70 is an 
> SPI/Microwire based system and not i2c; so straight away, the i2c 
> interface by itself will not be used...; also, the specific board 
> (LM70CILD-3, which i've written the 2.4 driver for & am now porting to 
> 2.6), comes with a built-in parport interface..so that's what the driver 
> takes into account of course..

That's fine, you do not have to be a i2c driver to use the hwmon
interface.  There are other drivers in the drivers/hwmon/ directory
today that are not i2c drivers.  It is not a requirement at all.

> Also it's a relatively simple temperature sensor - it does not seem to 
> support hysteresis temperature, i/p voltages, etc. I'm saying all this 
> as the sysfs interface i envision is just a simple read-only hook: the 
> o/p value (after a little userspace massaging) is the temperature in 
> Celsius correct to 0.25 degrees. So it looks to me that this particular 
> driver necessitates a kind-of "custom" entry under /sys/class/hwmon with 
> it's own userspace support. Do I move ahead in this direction?

No.  Use the same names for your files as is described in the document.
If you can't provide all of the different files, that's fine, just
provide what you can.  The userspace tools will handle this properly.

This also keeps you from having to write custom userspace tools for
every individual program that wants to know this information.

thanks,

greg k-h

Re: Stuck creating sysfs hooks for a driver..

[Jean Delvare]

Hi Kaiwan,

> One thing i'd like to point out though, Greg: the LM70 is an 
> SPI/Microwire based system and not i2c; so straight away, the i2c 
> interface by itself will not be used...; also, the specific board 
> (LM70CILD-3, which i've written the 2.4 driver for & am now porting to 
> 2.6), comes with a built-in parport interface..so that's what the driver 
> takes into account of course..

You must stay away from writing a driver for the board itself. What you
must write is in fact two different drivers:

1* A driver for the SPI interface of your board (basically a parallel
port <-> SPI bridge). This driver will expose the device as an SPI bus
to the rest of the kernel. This driver doesn't care about what chip is
plugged on it.

2* A driver for the LM70 temperature sensor chip, which doesn't care
about the chip location. This driver will use generic SPI commands as
offered by the spi kernel interface.

This modular approach makes it possible to then reuse each of the
drivers. If you later have a similar board for a different chip, the
first driver will still work (assuming the new board uses SPI and the
same wiring conventions). If you later have an LM70 chip on a different
physical interface, the second driver will still work.

You should take a look at how this was done for the Analog Devices
ADM1032 evaluation board, as this is really similar, except that the
ADM1032 uses I2C/SMBus instead of SPI.

The board itself is driven by the i2c-parport driver. This driver
exposes the board as a generic i2c interface to the rest of the kernel.
The bit-banging logic is common to various I2C bus driver and can be
found in i2c-algo-bit. The i2c-parport really only defines which bits
must be played with to control the I2C bus lines. SPI has an equivalent
helper driver named spi_bitbang. I've never used it myself but it must
be very similar. So your first driver would be similar to i2c-parport
except that it would use spi_bitbang instead of i2c-algo-bit. There
doesn't seem to be any in-tree user of spi_bitbang right now so you are
walking a relatively new path. Maybe the spi folks will be able to
guide you.

The ADM1032 chip is driven by the lm90 driver (National Semiconductor's
LM90 and Analog Devices' ADM1032 are fully compatible). This driver
uses the generic i2c/smbus interface. Thanks to this, it works with the
chip on the parallel port evaluation board, but also with compatible
chips found in laptops or desktop SMBus. Your lm70 driver would be
similar, except that it would use spi commands instead of i2c/smbus
commands. The sysfs interface should be very similar, except that yours
would be more simple if the LM70 is a single temperature chip.

> Also it's a relatively simple temperature sensor - it does not seem to 
> support hysteresis temperature, i/p voltages, etc. I'm saying all this 
> as the sysfs interface i envision is just a simple read-only hook: the 
> o/p value (after a little userspace massaging) is the temperature in 
> Celsius correct to 0.25 degrees. So it looks to me that this particular 
> driver necessitates a kind-of "custom" entry under /sys/class/hwmon with 
> it's own userspace support. Do I move ahead in this direction?

No, just do what every other hardware monitoring chip does, so that
support can be added for the lm70 chip in libsensors - then you win
instant support in all hardware monitoring application which rely on
libsensors, and even a few which do not.

It's really not a matter of how many features a chip has. Look at the
lm75 or w83l785ts driver, you'll see they have very few features as
well. It's a matter of having a common standard for exporting the
values to user-space, so that the same library or application can
handle all sources with minimum effort.

Thanks,
-- 
Jean Delvare

Re: Stuck creating sysfs hooks for a driver..

[Kaiwan N Billimoria]

Jean Delvare wrote:

>Hi Kaiwan,
>
>You must stay away from writing a driver for the board itself. What you
>must write is in fact two different drivers:
>
>1* A driver for the SPI interface of your board (basically a parallel
>port <-> SPI bridge). This driver will expose the device as an SPI bus
>to the rest of the kernel. This driver doesn't care about what chip is
>plugged on it.
>
>2* A driver for the LM70 temperature sensor chip, which doesn't care
>about the chip location. This driver will use generic SPI commands as
>offered by the spi kernel interface.
>
>  
>
Ok, i see your point..

>It's really not a matter of how many features a chip has. Look at the
>lm75 or w83l785ts driver, you'll see they have very few features as
>well. It's a matter of having a common standard for exporting the
>values to user-space, so that the same library or application can
>handle all sources with minimum effort.
>
>  
>
Yes, again..
I shall start looking into these aspects & workin on it in the coming 
week..am up to my ears in other stuff right now..
though how exactly i don;t know now :) ; will certainly require your 
(and others) help on this..

>Thanks,
>  
>
Thank you, your long reply was very enlightening;
Kaiwan.