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: <201304292250.47699.arnd@arndb.de>
Date:	Mon, 29 Apr 2013 22:50:47 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	David Brown <davidb@...eaurora.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Nicolas Pitre <nico@...xnic.net>
Subject: Re: [GIT PATCH] char/misc patches for 3.10-rc1

On Monday 29 April 2013, Linus Torvalds wrote:
> On Mon, Apr 29, 2013 at 12:54 PM, Arnd Bergmann <arnd@...db.de> wrote:

> There are other things wrong with that whole SSBI driver crap that you
> seem to be ignoring:
> 
>  - it's not a bus, it's just a driver. Just because some people call
> it "serial bus" doesn't make it magically about a "bus". I can call an
> ethernet driver an "ethernet bus driver", and it may be technically
> correct, but it is still bullshit. And ethernet is damn more a real
> bus than that SSBI driver is. That's just a pure serial driver for a
> very specific piece of embedded hardware. Stop calling it a bus.

Fair enough. Of course the distinction here is not based on what it
does, but how it gets used. I've looked at the driver now and it
seems to do exactly the same as i2c and spi, which we certainly need
to treat as buses here. The only difference here is that this hardware
only has a single use in linux-next, which in an MFD driver. If we
had a lot of different ones, it could reasonably be called a bus
and use the bus_type and device_driver infrastructure.

>  - The whole Kconfig thing is complete and utter garbage. There is no
> excuse what-so-ever for ever asking the user about it. Not on x86, not
> on ARM. The drivers that actually use that magical serial line
> driver should just have selected it.

Agreed.

>  - I'm not seeing what commonalities this thing can have with anything
> else. Did anybody look at the code? There's nothing generic there.

It's a simple bus that has addressable registers. We have a generic
infrastructure for these things in drivers/base/regmap, currently
handling I2C, SPI and MMIO based buses, which are often used as
different methods to address the same device endpoints. I think it
would be sensible to add another one-off type here and convert the
user(s) to be based on the regmap interface rather than its own
set of exported symbols.
Alternatively, it could just be moved next to the pm8921 driver
in drivers/mfd, which is currently its only user, but the Qualcomm
people might have a better idea on whether other devices connected
to ssbi follow the same pattern or whether they are going to live
elsewhere outside of drivers/mfd.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ