From: Arnd Bergmann <arnd@arndb.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
David Brown <davidb@codeaurora.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Nicolas Pitre <nico@fluxnic.net>
Subject: Re: [GIT PATCH] char/misc patches for 3.10-rc1
Date: Mon, 29 Apr 2013 23:22:18 +0200 [thread overview]
Message-ID: <201304292322.18971.arnd@arndb.de> (raw)
In-Reply-To: <CA+55aFzxyB375fKXW37e2JBB57VwMw6UWccRwWSGn_zUa0J7SA@mail.gmail.com>
On Monday 29 April 2013, Linus Torvalds wrote:
> On Mon, Apr 29, 2013 at 1:50 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > Fair enough. Of course the distinction here is not based on what it
> > does, but how it gets used.
>
> Even technically, a "bus" generally has a topology. It has addresses,
> and it has a protocol.
>
> i2c is a bus. PCI is a bus. And something like SSB is a bus. There is
> a protocol, there's device with identity on the bus, there's stuff
> going on.
Right. I was looking at it from the linux driver model perspective,
where we already call a lot of things a bus that are not at all one in
the engineering sense.
> The SBBI driver has neither addresses nor a protocol. It's literally
> just an embedded on-chip serial device as far as I can tell. There's
> nothing "bus" about it. It's just a hose.
>
> Yeah, yeah, at some point you can call "anything" a bus. I could call
> my little two-seater car a "school bus", because it has wheels, it's
> even yellow exactly like the school buses around here. And I can put a
> child in it. So my little yellow two-seater must be a bus too. It's
> all just how you define your words.
>
> But it's a damn big reach. I didn't use to call the serial line
> connecting my computer to the modem a "bus". Even if it connected two
> devices.
It seems I looked too briefly. As you point out and David already
confirmed, there is only one device on the other side, which is indeed
a major difference to e.g. SPI, which seems rather similar otherwise
but can use chip-select pins to multiplex between different endpoints.
Certainly this hardware could do the same, but you are right that it's
not relevant because it doesn't do that in practice.
Arnd
next prev parent reply other threads:[~2013-04-29 21:22 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-29 16:21 [GIT PATCH] char/misc patches for 3.10-rc1 Greg KH
2013-04-29 18:28 ` Linus Torvalds
2013-04-29 18:38 ` Greg KH
2013-04-29 18:55 ` Linus Torvalds
2013-04-29 19:02 ` Linus Torvalds
2013-04-29 19:15 ` Linus Torvalds
2013-04-29 19:54 ` Arnd Bergmann
2013-04-29 20:12 ` Linus Torvalds
2013-04-29 20:50 ` Arnd Bergmann
2013-04-29 21:13 ` Linus Torvalds
2013-04-29 21:22 ` Arnd Bergmann [this message]
2013-05-01 16:12 ` Mark Brown
2013-04-29 21:08 ` David Brown
2013-04-29 21:16 ` Arnd Bergmann
2013-05-01 16:13 ` Mark Brown
2013-05-02 20:53 ` David Brown
2013-05-03 8:06 ` Mark Brown
2013-04-29 21:18 ` Linus Torvalds
2013-04-29 21:29 ` Arnd Bergmann
2013-04-29 22:00 ` MFD: move ssbi driver into drivers/mfd Arnd Bergmann
2013-04-29 22:10 ` Greg KH
2013-04-29 22:48 ` Nicolas Pitre
2013-04-30 0:00 ` David Brown
2013-04-30 10:18 ` Samuel Ortiz
2013-04-30 10:26 ` Arnd Bergmann
2013-05-16 9:49 ` Samuel Ortiz
2013-04-29 20:45 ` [GIT PATCH] char/misc patches for 3.10-rc1 Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201304292322.18971.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=akpm@linux-foundation.org \
--cc=davidb@codeaurora.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nico@fluxnic.net \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox