linux-kernel - Re: UIO device tree bindings.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 2 Apr 2013 08:43:33 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Pavel Machek <pavel@...x.de>
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.

On Tue, Apr 02, 2013 at 03:46:45PM +0200, Pavel Machek wrote:
> 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.

Anyway, after sleeping over it, I think I understand the concern better.
"ns16550" describes some HW compatible to a specific chip with well defined
functionality, and "generic-uio" doesn't. Maybe it would have to be something
like "generic-uio-hw" instead.

> 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,
Guenter

> 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/