[PATCH] hwmon class driver registration with a device number

[PATCH] hwmon class driver registration with a device number

[Himanshu Chauhan]

This patch adds a way to register a hwmon class driver
with a device number rather than the default MK_DEV(0,0).
This would help in creating required "dev" file under
sysfs which in turn can be used in populating /dev tree
during bootup (helpful to driver which want to show up
a char interface along with sysfs).

Signed-off-by: Himanshu Chauhan <hschauhan@nulltrace.org>
---
 drivers/hwmon/hwmon.c |   28 ++++++++++++++++++++++------
 include/linux/hwmon.h |    1 +
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index a61e781..36961c5 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -31,15 +31,17 @@ static DEFINE_IDR(hwmon_idr);
 static DEFINE_SPINLOCK(idr_lock);
 
 /**
- * hwmon_device_register - register w/ hwmon
- * @dev: the device to register
+ * hwmon_device_register_numbered - register hwmon class dev
+ * with specific device number.
+ * @dev: Device to register.
+ * @dev_id: device number to register.
  *
- * hwmon_device_unregister() must be called when the device is no
- * longer needed.
+ * hwmon_device_unregister() must be called when the device
+ * is no longer needed.
  *
  * Returns the pointer to the new device.
  */
-struct device *hwmon_device_register(struct device *dev)
+struct device* hwmon_device_register_numbered(struct device *dev, dev_t dev_id)
 {
 	struct device *hwdev;
 	int id, err;
@@ -58,7 +60,7 @@ again:
 		return ERR_PTR(err);
 
 	id = id & MAX_ID_MASK;
-	hwdev = device_create(hwmon_class, dev, MKDEV(0, 0), NULL,
+	hwdev = device_create(hwmon_class, dev, dev_id, NULL,
 			      HWMON_ID_FORMAT, id);
 
 	if (IS_ERR(hwdev)) {
@@ -71,6 +73,20 @@ again:
 }
 
 /**
+ * hwmon_device_register - register w/ hwmon
+ * @dev: the device to register
+ *
+ * hwmon_device_unregister() must be called when the device is no
+ * longer needed.
+ *
+ * Returns the pointer to the new device.
+ */
+struct device *hwmon_device_register(struct device *dev)
+{
+	return hwmon_device_register_numbered(dev, MK_DEV(0,0));
+}
+
+/**
  * hwmon_device_unregister - removes the previously registered class device
  *
  * @dev: the class device to destroy
diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
index 6b6ee70..d816cbe 100644
--- a/include/linux/hwmon.h
+++ b/include/linux/hwmon.h
@@ -16,6 +16,7 @@
 
 #include <linux/device.h>
 
+struct device *hwmon_device_register_numbered(struct device *dev, dev_t dev_id);
 struct device *hwmon_device_register(struct device *dev);
 
 void hwmon_device_unregister(struct device *dev);
-- 
1.7.4.1

[PATCH] hwmon class driver registration with a device number

[Greg KH]

On Wed, Oct 05, 2011 at 10:43:11PM +0530, Himanshu Chauhan wrote:
> This patch adds a way to register a hwmon class driver
> with a device number rather than the default MK_DEV(0,0).
> This would help in creating required "dev" file under
> sysfs which in turn can be used in populating /dev tree
> during bootup (helpful to driver which want to show up
> a char interface along with sysfs).

How do you later remove a device created with this new interface?  As it
is, I think the existing calls will fail, right?

greg k-h

[PATCH] hwmon class driver registration with a device number

[Himanshu Chauhan]

Hi Greg,

> 
> How do you later remove a device created with this new interface?  As it
> is, I think the existing calls will fail, right?
> 
If I have not missed out anything from hwmon_device_unregister(), it shouldn't
fail. Why did you point that out?

-Himanshu

[PATCH] hwmon class driver registration with a device number

[Greg KH]

On Thu, Oct 06, 2011 at 09:40:11AM +0530, Himanshu Chauhan wrote:
> Hi Greg,
> 
> > 
> > How do you later remove a device created with this new interface?  As it
> > is, I think the existing calls will fail, right?
> > 
> If I have not missed out anything from hwmon_device_unregister(), it shouldn't
> fail. Why did you point that out?

If you create a device with a call to device_create() with a dev_t set,
it is usually cleaned up with a call to device_destroy(), but you are
right, a simple call to device_unregister() will still work properly.

So nevermind, sorry for the noise.

What you do need to determine is if this is a device node you really
want to be creating in this manner, as it is a new user/kernel API,
right?

greg k-h

[lm-sensors] [PATCH] hwmon class driver registration with a device number

[Himanshu Chauhan]

On Thu, Oct 06, 2011 at 12:07:52PM -0700, Guenter Roeck wrote:
> And why, and what for.

The initial idea of posting to kernelnewbies was to get a hint on how
the patch would be taken as. I wanted to know if developers will like
the idea behind it or not. I guess, Guenter is not convinced with
any of my reasoning. I am willing to clean it up further only if
I get a positive hint. But it doesn't seem to be going anywhere.

Thanks Guenter, Alan, and Greg for taking your time and reviewing it.

Greg: To answer your last question, if this was taken positively, I
was thinking of having functionality similar to misc device registration.

-Himanshu

[lm-sensors] [PATCH] hwmon class driver registration with a device number

[Greg KH]

On Fri, Oct 07, 2011 at 12:12:40PM +0530, Himanshu Chauhan wrote:
> On Thu, Oct 06, 2011 at 12:07:52PM -0700, Guenter Roeck wrote:
> > And why, and what for.
> 
> The initial idea of posting to kernelnewbies was to get a hint on how
> the patch would be taken as. I wanted to know if developers will like
> the idea behind it or not. I guess, Guenter is not convinced with
> any of my reasoning. I am willing to clean it up further only if
> I get a positive hint. But it doesn't seem to be going anywhere.
> 
> Thanks Guenter, Alan, and Greg for taking your time and reviewing it.
> 
> Greg: To answer your last question, if this was taken positively, I
> was thinking of having functionality similar to misc device registration.

But why?  What is that device node going to be used for?  Who would be
using it in userspace and where would it be tied into in the kernel?

still confused,

greg k-h

[lm-sensors] [PATCH] hwmon class driver registration with a device number

[Himanshu Chauhan]

On Thu, Oct 06, 2011 at 11:52:37PM -0700, Greg KH wrote:
> On Fri, Oct 07, 2011 at 12:12:40PM +0530, Himanshu Chauhan wrote:
> > On Thu, Oct 06, 2011 at 12:07:52PM -0700, Guenter Roeck wrote:
> > > And why, and what for.
> > 
> > The initial idea of posting to kernelnewbies was to get a hint on how
> > the patch would be taken as. I wanted to know if developers will like
> > the idea behind it or not. I guess, Guenter is not convinced with
> > any of my reasoning. I am willing to clean it up further only if
> > I get a positive hint. But it doesn't seem to be going anywhere.
> > 
> > Thanks Guenter, Alan, and Greg for taking your time and reviewing it.
> > 
> > Greg: To answer your last question, if this was taken positively, I
> > was thinking of having functionality similar to misc device registration.
> 
> But why?  What is that device node going to be used for?  Who would be
> using it in userspace and where would it be tied into in the kernel?
> 
The device node, as I said earlier, can be used for doing IOCTLS. In user space,
applications that manage and monitor system environment will need to use this
interface for querying the sensor's location, for example. In side the kernel,
the driver that is driving the particular hardware sensor can register a char
interface for all this and then register with hwmon with the same major/minor
for usual sysfs export of data.

-Himanshu

[lm-sensors] [PATCH] hwmon class driver registration with a device number

[Greg KH]

On Fri, Oct 07, 2011 at 03:26:21PM +0530, Himanshu Chauhan wrote:
> On Thu, Oct 06, 2011 at 11:52:37PM -0700, Greg KH wrote:
> > On Fri, Oct 07, 2011 at 12:12:40PM +0530, Himanshu Chauhan wrote:
> > > On Thu, Oct 06, 2011 at 12:07:52PM -0700, Guenter Roeck wrote:
> > > > And why, and what for.
> > > 
> > > The initial idea of posting to kernelnewbies was to get a hint on how
> > > the patch would be taken as. I wanted to know if developers will like
> > > the idea behind it or not. I guess, Guenter is not convinced with
> > > any of my reasoning. I am willing to clean it up further only if
> > > I get a positive hint. But it doesn't seem to be going anywhere.
> > > 
> > > Thanks Guenter, Alan, and Greg for taking your time and reviewing it.
> > > 
> > > Greg: To answer your last question, if this was taken positively, I
> > > was thinking of having functionality similar to misc device registration.
> > 
> > But why?  What is that device node going to be used for?  Who would be
> > using it in userspace and where would it be tied into in the kernel?
> > 
> The device node, as I said earlier, can be used for doing IOCTLS.

It can?  Which ones?  New ones you want to propose?  If so, why use an
ioctl?

> In user space, applications that manage and monitor system environment
> will need to use this interface for querying the sensor's location,
> for example. In side the kernel, the driver that is driving the
> particular hardware sensor can register a char interface for all this
> and then register with hwmon with the same major/minor for usual sysfs
> export of data.

So you are creating a new user/kernel api here, right?  If so, you need
to document it in Documentation/API and we need to be able to approve
that BEFORE we could ever accept the creation of new device nodes like
this, that at the moment, do not do anything.

In other words, you need to prove you need a new ioctl interface before
you can get a patch accepted that implements this.

greg k-h

[PATCH] hwmon class driver registration with a device number

[Himanshu Chauhan]

Hi,

> I can not comment on the merits of your patch. Unless I am missing
> something, which may well be since I only spent a couple of minutes on
> it, other device classes don't seem to provide a similar API, so I don't
> know if or why it would make sense for hwmon. Maybe a driver which wants
> to register a character device interface should do so independently of
> hwmon.
> 

The idea here is to sit in the same class directory as of hwmon. Devices
registered with this interface will have "dev" under, for example,
/sys/class/hwmon/hwmon0/dev. To do the same inside the driver will be
a bit more involved than a call.

In my opinion other classes should also have similar interfaces.

> On the technical side, EXPORT_SYMBOL is missing.
> 
I will take care of that.

Regards
Himanshu