I like the interface. It's just Greg that needs to comment on whether
using the kobj.parent for this purpose is actually sane. That was his
argument from the beginning.
On 13/02/17 01:47 PM, Dan Williams wrote:
On Sat, Feb 11, 2017 at 9:42 PM, Logan Gunthorpe
> On 11/02/17 11:58 AM, Dan Williams wrote:
>> Also when using an embedded cdev how would you recommend avoiding this problem?
> I don't know. Hopefully, Greg has a good idea. But it sounds like a
> general problem that a lot of cdev's actually suffer from without
> realizing. Perhaps we need a more general solution. Some way for the
> cdev to reference its containing structure in a way that it's designed
> for such that anyone writing a driver will do the right thing without
> needing to dive into the kobjects.
How about something like the below? I.e. hide the details with a new
helper api so that all driver writers need to worry about is the
parent device and cdev_del(). This is similar to the device_add_disk()
and del_gendisk() pairing that we have for block-device drivers.
diff --git a/fs/char_dev.c b/fs/char_dev.c
index 3bc97002c86f..4c5d51cdd353 100644
@@ -471,6 +471,12 @@ int cdev_add(struct cdev *p, dev_t dev, unsigned count)
+int device_add_cdev(struct device *dev, struct cdev *p)
+ p->kobj.parent = &dev->kobj;
+ return cdev_add(p, dev->devt, 1);
static void cdev_unmap(dev_t dev, unsigned count)
kobj_unmap(cdev_map, dev, count);
diff --git a/include/linux/cdev.h b/include/linux/cdev.h
index f8763615a5f2..043168df1d8f 100644
@@ -25,6 +25,7 @@ struct cdev *cdev_alloc(void);
void cdev_put(struct cdev *p);
int cdev_add(struct cdev *, dev_t, unsigned);
+int device_add_cdev(struct device *dev, struct cdev *);
void cdev_del(struct cdev *);