Message-ID: <20130402203519.GA12385@amd.pavel.ucw.cz>
Date:	Tue, 2 Apr 2013 22:35:19 +0200
From:	Pavel Machek <pavel@...x.de>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	sr@...x.de, w.sang@...gutronix.de, magnus.damm@...il.com,
	hjk@...utronix.de, Greg KH <greg@...ah.com>,
	linux-kernel@...r.kernel.org, dzu@...x.de
Subject: Re: UIO device tree bindings.

Hi!

> > > > > Or maybe we can do some magic with module parameter. That should be
> > > > > enough for expected use.
> > > > > 
> > > > I don't think that would make a difference. I mean, just take ns16550 as another
> > > > example. No one has problems declaring some block of hardware addresses to be
> > > > compatible with "ns16550", even though it can be anything including a memory
> > > > block on one of the FPGAs or ASICs we are talking about here, it can be anything
> > > > but a NS16550, and many of the actual "compatible" strings are not defined
> > > > anythere either.
> > > > 
> > > > So there is no problem with "ata-generic" and "ns16550", and no one cares if
> > > > "fsl,mpc8349emitx-pata" or "xlnx,xps-uart16550-2.00.b" is defined or not, but
> > > > "generic-uio" together with "ptx,c64fpga001" is unacceptable.
> > > > 
> > > > I think it has more to do with the uio driver not being an actual driver, but
> > > > the kernel part of a user-space driver, though that is just a wild guess.
> > > 
> > > Well, it turned out that adding module parameter was not that much
> > > work... and yes I believe it is a tiny bit cleaner.
> > > 
> > > Here's updated patch, if you can please test this one.
> > > 
> > > [You can just pass "uio_of_genirq.of_id=generic-uio" to get previous
> > > behaviour. But don't tell anyone :-)]
> > 
> > Actually, looking at it some more, perhaps even solution is possible?
> > (This will need uio_pdrv_genirq.of_id=generic-uio .)
> > 
> Possibly for your case, but not for mine, as I'll have several instances of the
> driver, and the hardware is not always present. Also, I am not sure if the match
> function runs before the module paratemers are initialized or afterwards, but that
> would be a matter of testing.

I tested that much: it works ok.

And... yes, this should work for you. You'll simply put
compatible="generic-uio" into the dts. (Ok, ugly part is that this is
probably not acceptable for upstream.) Then you'll use this patch,
with uio_pdrv_genirq.of_id=generic-uio commandline. It should pick up
all the devices old version of patch picked. (Not sure how you'll
assign right userland drivers to right devices, but that problem was
that even with old patch version, right?)

> > Unfortunately, I don't have easy way to test this :-(. So feedback is
> > essential.
> > 
> I'll try to get it to work, but it will take a bit.

Thanks,
									Pavel

> > Signed-off-by: Pavel Machek <pavel@...x.de>
> > 
> > diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pdrv_genirq.c
> > index 4a50ead..64b6dac 100644
> > --- a/drivers/uio/uio_pdrv_genirq.c
> > +++ b/drivers/uio/uio_pdrv_genirq.c
> > @@ -271,9 +273,13 @@ static const struct dev_pm_ops uio_pdrv_genirq_dev_pm_ops = {
> >  
> >  #ifdef CONFIG_OF
> >  static const struct of_device_id uio_of_genirq_match[] = {
> > -	{ /* empty for now */ },
> > +	{ /* This is filled with module_parm */ },
> > +	{ /* Sentinel */ },
> >  };
> >  MODULE_DEVICE_TABLE(of, uio_of_genirq_match);
> > +
> > +module_param_string(of_id, uio_of_genirq_match[0].compatible, 128, 0);
> > +MODULE_PARM_DESC(of_id, "Openfirmware id of the device to be handled by uio");
> >  #else
> >  # define uio_of_genirq_match NULL
> >  #endif

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists