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, 18 Dec 2020 13:46:03 +0000 From: Lee Jones <lee.jones@...aro.org> To: Mark Brown <broonie@...nel.org> Cc: Greg KH <gregkh@...uxfoundation.org>, Alexandre Belloni <alexandre.belloni@...tlin.com>, Dan Williams <dan.j.williams@...el.com>, Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>, alsa-devel@...a-project.org, Kiran Patil <kiran.patil@...el.com>, linux-rdma <linux-rdma@...r.kernel.org>, Shiraz Saleem <shiraz.saleem@...el.com>, Martin Habets <mhabets@...arflare.com>, Liam Girdwood <lgirdwood@...il.com>, Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>, Fred Oh <fred.oh@...ux.intel.com>, Jason Gunthorpe <jgg@...dia.com>, Dave Ertman <david.m.ertman@...el.com>, Jakub Kicinski <kuba@...nel.org>, Netdev <netdev@...r.kernel.org>, Leon Romanovsky <leonro@...dia.com>, David Miller <davem@...emloft.net>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Parav Pandit <parav@...lanox.com> Subject: Re: [resend/standalone PATCH v4] Add auxiliary bus support On Fri, 18 Dec 2020, Mark Brown wrote: > On Fri, Dec 18, 2020 at 08:10:51AM +0100, Greg KH wrote: > > On Thu, Dec 17, 2020 at 10:19:37PM +0100, Alexandre Belloni wrote: > > > > There is something I don't get from the documentation and it is what is > > > this introducing that couldn't already be done using platform drivers > > > and platform devices? > > > Because platform drivers and devices should ONLY be for actual platform > > devices. Do NOT use that interface to fake up a non-platform device > > (i.e. something that is NOT connected to a cpu through a memory-mapped > > or direct-firmware interface). > > > Do not abuse the platform code anymore than it currently is, it's bad > > enough what has been done to it over time, let's not make it any worse. > > I am not clear on why you're giving direct-firmware devices (which I > assume means things like ARM SCMI where we're talking directly to some > firmware?) a pass here but not for example a GPIO controlled devices. > If this is mainly about improving abstractions it seems like the > boundary here isn't great. Or perhaps I'm just missing what > direct-firmware is supposed to mean? > > In any case, to be clear part of what you're saying here is that all > I2C and SPI MFDs should be rewritten to use this new bus - I've just > copied Lee in again since he keeps getting missed from these threads. > As previously discussed this will need the auxilliary bus extending to > support at least interrupts and possibly also general resources. Thanks Mark. Not entirely sure why this needed an entirely new subsystem to handle non-MMIO Multi-Functional Devices (MFD). Or why I was not approached by any of the developers during the process. Having 2 entirely separate subsystems where MFDs can now be registered sounds confusing and convoluted at best. Why not simply extend actual MFD to be capable of registering non-pure platform devices via other means? By doing so you keep things bound to a central location resulting in less chance of misuse. I turn away MFD implementation abuses all the time. Seeing as the 2 subsystems are totally disjoint, this just unwittingly opened up another back-channel opportunity for those abuses to make it into the mainline kernel. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Powered by blists - more mailing lists