public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Jamie Iles <jamie@jamieiles.com>,
	linux-kernel@vger.kernel.org, vapier@gentoo.org
Subject: Re: [RFC PATCHv2 1/4] drivers/otp: add initial support for OTP memory
Date: Fri, 25 Mar 2011 16:28:47 -0700	[thread overview]
Message-ID: <20110325232847.GA5551@suse.de> (raw)
In-Reply-To: <201103252301.56718.arnd@arndb.de>

On Fri, Mar 25, 2011 at 11:01:56PM +0100, Arnd Bergmann wrote:
> On Friday 25 March 2011 22:12:46 Greg KH wrote:
> > > Why is this a bus? You don't have any device matching code or similar,
> > > and the devices typically are on an existing bus_type (e.g. platform_bus).
> > > I think it would make more sense to do this as a class.
> > 
> > No, for new things, we want to use busses instead of classes please.
> > Especially as this does create devices, which are best put on a bus
> > somewhere.
> 
> I don't understand. Isn't that rather inconsistent?
> 
> I realize the same thing came up with the IIO subsystem, where I also
> didn't understand it.
> 
> In my mental model of Linux drivers, a bus is something that physically
> connects devices and the bus code matches devices with drivers, while a
> class groups logical devices that get created by the driver itself.

Yes, that is how it used to be, but then it turns out that both of them
are really just "subsystems" as far as it all goes.  They are just ways
that devices are bound to drivers in a logical manner.  We have patches
floating around that get rid of both busses and classes to merge them
together, which is the end goal here.  I know Kay has posted detailed
reasons for why this all is on lkml in the past, and had working code
about 5 years ago, it's just been slow going...

So we recommend all new subsystems use the bus code, it's simple and
works well.

thanks,

greg k-h

  reply	other threads:[~2011-03-25 23:31 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-24 15:21 [RFC PATCHv2 0/4] Support for OTP memory Jamie Iles
2011-03-24 15:21 ` [RFC PATCHv2 1/4] drivers/otp: add initial support " Jamie Iles
2011-03-24 18:32   ` Mike Frysinger
2011-03-24 20:35     ` Jamie Iles
2011-03-24 21:33       ` Mike Frysinger
2011-03-25 10:08         ` Jamie Iles
2011-03-25 21:32           ` Mike Frysinger
2011-03-25 22:27             ` Jamie Iles
2011-03-25 22:36               ` Mike Frysinger
2011-03-24 19:20   ` Greg KH
2011-03-24 20:49     ` Jamie Iles
2011-03-25 20:12   ` Arnd Bergmann
2011-03-25 21:12     ` Greg KH
2011-03-25 22:01       ` Arnd Bergmann
2011-03-25 23:28         ` Greg KH [this message]
2011-03-26 11:25           ` Arnd Bergmann
2011-03-26 15:10             ` Greg KH
2011-03-28 13:11               ` Arnd Bergmann
2011-03-25 22:23     ` Jamie Iles
2011-03-25 22:35       ` Arnd Bergmann
2011-03-25 22:38         ` Mike Frysinger
2011-03-25 22:52           ` Jamie Iles
2011-03-25 23:02             ` Arnd Bergmann
2011-03-26  0:21               ` Jamie Iles
2011-03-26  2:16                 ` Mike Frysinger
2011-03-26  2:40                   ` Jamie Iles
2011-03-26 10:54                   ` Arnd Bergmann
2011-03-26 17:55                     ` Mike Frysinger
2011-03-26 20:51                       ` Arnd Bergmann
2011-03-27  3:52                         ` Mike Frysinger
2011-03-27 11:18                           ` Arnd Bergmann
2011-03-25 22:53           ` Arnd Bergmann
2011-03-24 15:21 ` [RFC PATCHv2 2/4] drivers/otp: add support for Picoxcell PC3X3 OTP Jamie Iles
2011-03-24 18:50   ` Mike Frysinger
2011-03-24 20:59     ` Jamie Iles
2011-03-24 21:40       ` Mike Frysinger
2011-03-24 15:21 ` [RFC PATCHv2 3/4] drivers/otp: allow an ioctl to be specified Jamie Iles
2011-03-24 18:35   ` Mike Frysinger
2011-03-24 20:36     ` Jamie Iles
2011-03-24 15:21 ` [RFC PATCHv2 4/4] drivers/otp: convert bfin otp to generic OTP Jamie Iles
2011-03-24 18:52   ` Mike Frysinger
2011-03-24 20:40     ` Jamie Iles
2011-03-24 17:39 ` [RFC PATCHv2 0/4] Support for OTP memory Mike Frysinger
2011-03-24 17:47   ` Jamie Iles
2011-03-24 17:56     ` Mike Frysinger
2011-03-24 18:32       ` Jamie Iles
2011-03-24 18:36         ` Mike Frysinger
2011-03-24 20:38           ` Jamie Iles
2011-03-25  0:12         ` Mark Brown

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=20110325232847.GA5551@suse.de \
    --to=gregkh@suse.de \
    --cc=arnd@arndb.de \
    --cc=jamie@jamieiles.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vapier@gentoo.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