linux-kernel - Re: [RFC PATCH 0/3] UART slave device bus

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: <23B59EBB-DD4E-4F79-8294-BCE1BE7B9888@goldelico.com>
Date:	Thu, 18 Aug 2016 13:14:08 +0200
From:	"H. Nikolaus Schaller" <hns@...delico.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Pavel Machek <pavel@....cz>, Rob Herring <robh@...nel.org>,
	Marcel Holtmann <marcel@...tmann.org>,
	Jiri Slaby <jslaby@...e.com>,
	Sebastian Reichel <sre@...nel.org>,
	Peter Hurley <peter@...leysoftware.com>,
	NeilBrown <neil@...wn.name>, Arnd Bergmann <arnd@...db.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-bluetooth@...r.kernel.org, linux-serial@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] UART slave device bus

Hi Greg,

> Am 18.08.2016 um 12:57 schrieb Greg Kroah-Hartman <gregkh@...uxfoundation.org>:
> 
> On Thu, Aug 18, 2016 at 12:54:15PM +0200, H. Nikolaus Schaller wrote:
>> Hi Pavel,
>> 
>>> Am 18.08.2016 um 12:47 schrieb Pavel Machek <pavel@....cz>:
>>> 
>>> 
>>>> 
>>>> Thereof 4 files, ~260 changes w/o gps demo and documentation/bindings.
>>> 
>>> So what do you use for the serial devices? platform_device was vetoed
>>> for that purpose by Greg.
>> 
>> device tree?
> 
> No.

? Sorry, but each time Pavel jumps in, he just copies half of a statement and
any reply gets misunderstood.

I did not even mention platform_device, still you disagree to device tree for the
*slave driver*?

> 
> This patchset from Rob is the way I have been saying it should be done
> for years now.  Yes, a "bus" takes up more boilerplate code (blame me
> for that), but overall, it makes the drivers simpler,

Sorry, but I don't see how Rob's approach makes it simpler to write a device driver
than our original proposal, which btw is also sort of a bus and I see only some implementation
differences.

Except that IMHO Rob's approach lacks functions we need (which maybe can added).

> and fits into the
> rest of the kernel driver/device model much better.

BR and thanks,
Nikolaus