linux-kernel - Re: [PATCH] spidev: add platform driver support

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:   Mon, 21 Jun 2021 15:57:02 +0200
From:   Christian Gmeiner <christian.gmeiner@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>, linux-spi@...r.kernel.org
Subject: Re: [PATCH] spidev: add platform driver support

Hi Mark,

Am Mi., 16. Juni 2021 um 21:44 Uhr schrieb Mark Brown <broonie@...nel.org>:
>
> On Wed, Jun 16, 2021 at 09:16:44PM +0200, Christian Gmeiner wrote:
>
> > ping
>
> I replied to your mail some time ago...
>

It did not land in my in-box and I do not see your mail here:
https://patches.linaro.org/patch/449250/
In the end I found it only here:
https://lore.kernel.org/lkml/YK9wDd%2F+c1uAjwk7@sirena.org.uk/

This makes it basically quite hard to answer your question. So will do it here:

> > This makes it possible to use spidev in combination with the
> > MFD subsystem. The MFD subsystem add platform_driver devices.

> This is a really strange thing to want to do so it needs a
> changelog which explains what the goal is and why this is a good
> way of accomplishing that goal.

I am currently working on a system controller that is connected via
SPI. The system controller
provides a handful of LEDs, a hex switch and some GPIOs. All of this
can be modeled quite easily
with the MFD subsystem but the e.g. LED subsystem.

The biggest pain point is that this system controller or the used FPGA
can be updated via SPI. And
I see no suitable subsystem to handle this update case.

That's why I have chosen to expose the SPI device also via spidev.

>
> Also:
>
> Please don't send content free pings and please allow a reasonable time
> for review.  People get busy, go on holiday, attend conferences and so
> on so unless there is some reason for urgency (like critical bug fixes)
> please allow at least a couple of weeks for review.  If there have been
> review comments then people may be waiting for those to be addressed.
>

I am aware of the rules.. but as I told you I got nothing in my in-box
for 2 weeks.

> Sending content free pings adds to the mail volume (if they are seen at
> all) which is often the problem and since they can't be reviewed
> directly if something has gone wrong you'll have to resend the patches
> anyway, so sending again is generally a better approach though there are
> some other maintainers who like them - if in doubt look at how patches
> for the subsystem are normally handled.
>
> Please don't top post, reply in line with needed context.  This allows
> readers to readily follow the flow of conversation and understand what
> you are talking about and also helps ensure that everything in the
> discussion is being addressed.

Yeah.. I should never ever send a mail from my smartphone.


--
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info/privacypolicy