mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: linux-kernel@vger.kernel.org, kernel@pengutronix.de
Subject: Re: [RFC PATCH 1/3] siox: new driver/bus framework for Eckelmann SIOX
Date: Sat, 12 Mar 2016 19:42:26 -0800	[thread overview]
Message-ID: <20160313034226.GB12613@kroah.com> (raw)
In-Reply-To: <20160312134321.GG1781@pengutronix.de>

On Sat, Mar 12, 2016 at 02:43:21PM +0100, Uwe Kleine-König wrote:
> Hello Greg,
> 
> On Fri, Mar 11, 2016 at 02:20:39PM -0800, Greg Kroah-Hartman wrote:
> > On Fri, Mar 11, 2016 at 10:52:12PM +0100, Uwe Kleine-König wrote:
> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > ---
> > >  drivers/Kconfig          |   2 +
> > >  drivers/Makefile         |   1 +
> > >  drivers/siox/Kconfig     |   2 +
> > >  drivers/siox/Makefile    |   1 +
> > >  drivers/siox/siox-core.c | 572 +++++++++++++++++++++++++++++++++++++++++++++++
> > >  drivers/siox/siox.h      |  48 ++++
> > >  include/linux/siox.h     |  53 +++++
> > >  7 files changed, 679 insertions(+)
> > >  create mode 100644 drivers/siox/Kconfig
> > >  create mode 100644 drivers/siox/Makefile
> > >  create mode 100644 drivers/siox/siox-core.c
> > >  create mode 100644 drivers/siox/siox.h
> > >  create mode 100644 include/linux/siox.h
> > 
> > What's the relationship between your "master" and "regular" devices
> > here?  I think that's getting things confused, you are unregistering
> > your 'master' yet the children it controls don't go away because you
> > never unregister them.  You need to fix this heirachy up a bit, and
> > maybe just drop the 'master' logic?
> 
> A master is the bus controller (i.e. it drives DOUT, DCLK and DLD). A
> device is a consumer and provides DIN to the master.
> 
> The topology looks as follows:
> 
>       ,------->--DCLK-->---------------+----------------------.
>       ^                                v                      v
>  ,--------.                ,----------------------.       ,------
>  |        |                |   ,--------------.   |       |
>  |        |--->--DOUT-->---|->-|shift register|->-|--->---|
>  |        |                |   `--------------'   |       |
>  | master |                |        device        |       |  device
>  |        |                |   ,--------------.   |       |
>  |        |---<--DIN---<---|-<-|shift register|-<-|---<---|
>  |        |                |   `--------------'   |       |
>  `--------'                `----------------------'       `------
>       v                                ^                      ^
>       `----------DLD-------------------+----------------------'
> 
> So there are two chains of shift registers, one for letting the master
> write to the devices, and the other to let the master read from the
> devices. DCLK is the clock to shift both chains by a single bit. An edge
> on DLD is used to make the devices load the inputs and sample the
> outputs.
> 
> I think I need the following:
> 
> 	void siox_unregister_master(struct siox_master *smaster)
> 	{
> 		for (each siox_device d of smaster)
> 			siox_device_remove(d);
> 
> 		device_unregister(&smaster->dev);
> 	}

Yes, you have to do this, as that's how USB and other busses do it when
their "controllers" go away.

> But the locking scheme that is necessary isn't obvious for me. For
> example I must prevent that after the for loop is done a new device is
> registered. Do I need to prevent this explicitly (e.g. by doing
> something like:
> 
> 	lock(smaster);
> 	smaster->is_going_away = true;
> 	for (each siox_device d of smaster)
> 		siox_device_remove(d);
> 	unlock(smaster);
> 
> 	device_unregister(&smaster->dev);
> 
> and let registering new devices fail if smaster->is_going_away is true?)
> Or is there something that the kobject stuff/driver core can help me
> with?

Look at what happens when you remove a USB host controller with the
locking there, it shouldn't be that hard.

thanks,

greg k-h

  reply	other threads:[~2016-03-13  3:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-11 21:52 [RFC PATCH 0/3] new bus type siox Uwe Kleine-König
2016-03-11 21:52 ` [RFC PATCH 1/3] siox: new driver/bus framework for Eckelmann SIOX Uwe Kleine-König
2016-03-11 22:20   ` Greg Kroah-Hartman
2016-03-12 13:43     ` Uwe Kleine-König
2016-03-13  3:42       ` Greg Kroah-Hartman [this message]
2016-03-11 21:52 ` [RFC PATCH 2/3] siox: add gpio bus driver Uwe Kleine-König
2016-03-11 21:52 ` [RFC PATCH 3/3] gpio: new driver to work with a 8x12 siox Uwe Kleine-König

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=20160313034226.GB12613@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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

all inboxes | Powered by JetHome®