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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 31 Aug 2018 20:29:29 +0200 From: Arnd Bergmann <arnd@...db.de> To: Sunil Kovvuri <sunil.kovvuri@...il.com> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Olof Johansson <olof@...om.net>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, linux-soc@...r.kernel.org, sgoutham@...vell.com Subject: Re: [PATCH 11/15] soc: octeontx2: Add Marvell OcteonTX2 CGX driver On Fri, Aug 31, 2018 at 6:01 PM Sunil Kovvuri <sunil.kovvuri@...il.com> wrote: > On Fri, Aug 31, 2018 at 7:50 PM Arnd Bergmann <arnd@...db.de> wrote: > > Thanks for the suggestion, that does makes sense. > Actually i did thought about it, but i was skeptical if it would be > acceptable to make > a single module out of drivers registering for two different PCI devices. I don't think it matters much whether there is one module or two (others might have a strong opinion one way or the other). What is important though are these two points: - How to represent the two PCI devices to user space: You should only have one interface to user space I think, and this should be similar to how other drivers manage similar cases (I don't actually know what they do, but I assume you've done some research here) - How you connect find the pair of devices: Generally speaking while the SoC might only have one of each, you shouldn't make that assumption in the code, but instead have a reliable way of having one driver wait for the other driver to finish probing so you can match the pair. > Will wait for few more days for more feedback from anyone and port v2 series. Ok. Arnd
Powered by blists - more mailing lists