On Mon, May 22, 2006 at 01:40:57PM -0600, Jim Cromie wrote:
>
> Im trying to update scx200_gpio to properly use the 2.6 api
> (and thus learn it)
> attached patch does following:
> - register chrdev-region for 32 devices, (or alloc-chrdev-region)
> - allocate array of 32 cdevs,
> - initialize each cdev in scx200_gpio_init()
> with gpio_fops, and major, minors
>
> What follows, is a stream-of-conciousness, discover, a bit of fumbling ..
> its a monologue in search of a dialogue ..
>
> One thing missing wrt current best practice is
> the lack of dev_dbg(), etc to control debug messages.
> I cant figure out how to get a dev I can use.
>
> 1st printk()s Id like to lose are in fops write-handler
>
> static ssize_t scx200_gpio_write(struct file *file, const char __user *data,
> size_t len, loff_t *ppos)
> {
> unsigned m = iminor(file->f_dentry->d_inode);
> ...
> case 'O':
> printk(KERN_INFO NAME ": GPIO%d output
> enabled\n", m);
> scx200_gpio_configure(m, ~1, 1);
> break;
>
>
> Oooh, I think the light just went on...
>
> If I set up file->private_data with the right info, then the dev is
> obtainable.
Exactly. Do that on your open() function.
> right now, (in patch 5) I do
> (retrieval, and initialization, in write-handler, and open-handler
> respectively)
> chr-scx200-gpio-vtable-calls:+ struct gpio_access_methods *amp =
> file->private_data;
> chr-scx200-gpio-vtable-calls:+ file->private_data = &scx200_access;
>
> access-methods has .owner, with THIS_MODULE.
> add a struct device *,
> or something that contains one, like:
> platform_device, miscdevice, probably many others.
>
> so, wheres my device ?
Depends on what your driver is, and where it stores it.
> dont I automatically get one, perhaps under the covers ?
Depends on what type of driver you are. If you are an i2c driver, you
get one. A PCI driver, you get one. A USB driver, you get one. A
platform driver, well, you might be on your own, you have to create
yours, using the platform api.
> why isnt/arent there THIS_DRIVER, THIS_PLATFORM, THIS_BUS constructs ?
How would that work?
> THIS_MODULE storage is magically populated
> ( during what? compilation, module-loading, init ?)
compilation time. It's a simple macro.
> couldnt the others be also (if later).
>
> I also found this:
> **Subject: Driver model ISA bus**
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114678055902797&w=2
> It looks interesting - anything that simplifies stuff is -
> but alas - theres no empty-isa-driver.c for me to start from.
It's getting there, hasn't made it into any kernel trees yet...
thanks,
greg k-h
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
