linux-kernel - Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver

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]

Message-ID: <CAOMqctR8mdjzCpfJodHO6MDUEMZubKmnT_eZZs+48xJXQfragA@mail.gmail.com>
Date:	Fri, 1 Jul 2016 20:56:44 +0200
From:	Michal Suchanek <hramrach@...il.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-spi <linux-spi@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] drivers core: allow id match override when
 manually binding driver

On 1 July 2016 at 18:22, Mark Brown <broonie@...nel.org> wrote:
> On Fri, Jul 01, 2016 at 05:37:53PM +0200, Michal Suchanek wrote:
>
>> Can you, please, specify what problems this patch creates for other users
>> and maintainability?
>
> To repeat yet again a major design goal for DT is to describe the
> hardware rather than implementation details of the software you plan to
> run on the system.  Not doing this breaks upgrades or changes in our
> ideas of how we control a given bit of hardware.
>
>> Without stating the problems of this solution clearly or proposing alternate
>> workable solution there is not much that can be done.
>
> You are rejecting out of hand any suggestion that is not the one
> solution you are demanding.

Your only suggestion is that hardware that is not driven by kernel is
described to the kernel. I have written in great detail why this does
not make sense.

So to me it seems that you reject out of hand any suggestion that
is not the one solution you are demanding. You have not raised any
concrete reason against the proposed solution other than it does not
describe the hardware. The hardware cannot be described for practical
usability reasons.

>
> I'm done with this thread, please come back with new code that fits in
> with the device model and device tree designs.

Is there any solution that fits the driver model and allows using spidev with
arbitrary device without describing said device in devicetree?

Thanks

Michal