All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: German Rivera <German.Rivera@freescale.com>
Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	stuart.yoder@freescale.com, linuxppc-release@linux.freescale.net
Subject: Re: [RFC PATCH 2/4] drivers/bus: Freescale Management Complex (fsl-mc) bus driver
Date: Thu, 21 Aug 2014 13:30:20 +0200	[thread overview]
Message-ID: <201408211330.20869.arnd@arndb.de> (raw)
In-Reply-To: <53F3B8EA.6070609@freescale.com>

On Tuesday 19 August 2014, German Rivera wrote:
> >> + * @dev_node: Node in the container's child list
> >
> > Same here: just use the device model's list management instead if you can,
> > or explain why this is needed.
> >
> We still need to keep a per-bus list of child devices (devices contained 
> in a given DPRC object). Unless I'm missing something,
> I think the device model's list management links together all the 
> devices of the same bus type. We are trying to follow a similar approach 
> to the pci_dev/pci_bus structs.

There are multiple lists in the device handling. device_for_each_child()
should iterate over the children of a particular device using the
klist_children member.

> >> +/**
> >> + * struct fsl_mc_dprc - Data Path Resource Container (DPRC) object
> >> + * @magic: marker to verify identity of this structure
> >> + * @mc_dev: pointer to MC object device object for this DPRC
> >> + * @mutex: mutex to serialize access to the container.
> >> + * @child_device_count: have the count of devices in this DPRC
> >> + * @child_list:     anchor node of list of child devices on this DPRC
> >> + */
> >> +struct fsl_mc_dprc {
> >> +#   define FSL_MC_DPRC_MAGIC   FSL_MC_MAGIC('D', 'P', 'R', 'C')
> >> +    uint32_t magic;
> >> +    struct fsl_mc_device *mc_dev;
> >> +    struct mutex mutex;     /* serializes access to fields below */
> >> +    uint16_t child_device_count;    /* Count of devices in this DPRC */
> >> +    struct list_head child_list;
> >> +};
> >
> > It's not clear what this represents to me. mc_dev presumably already
> > has a list of children, so why not just use a pointer to mc_dev
> > and remove this structure entirely?
> >
> This structure represents the per-bus (per DPRC object) information.
> It is kind of the equivalent to 'struct pci_bus' in the PCI world.
> I have renamed this struct to 'struct fsl_mc_bus'.

Ok, I'll look at the new version when I get back to Germany. I still think
that can remove all members of the current structure and just use the
same structure for fsl_mc_bus and fsl_mc_device. If you really need
a small number of extra members beyond what is in the device, you have
two other choices:

a) put the members into the device structure as well but not use them
   for a device that is not a bus

b) embed the device structure within the bus structure like

	struct fsl_mc_bus {
		int something;
		struct fsl_mc_device;
	};

and then use container_of() to go from the device to the bus where needed
rather than having two objects that are allocated separately. This is
what a lot of other subsystems (not PCI) do. See for instance
platform_device, which often has child devices as well.

	Arnd

  reply	other threads:[~2014-08-21 12:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-15 22:13 [RFC PATCH 0/4] drivers/bus: Freescale Management Complex bus driver patch series J. German Rivera
2014-08-15 22:13 ` [RFC PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs J. German Rivera
2014-08-15 22:13 ` [RFC PATCH 2/4] drivers/bus: Freescale Management Complex (fsl-mc) bus driver J. German Rivera
2014-08-16 11:09   ` Arnd Bergmann
2014-08-16 14:12   ` Arnd Bergmann
2014-08-19 20:51     ` German Rivera
2014-08-21 11:30       ` Arnd Bergmann [this message]
2014-08-23  4:26         ` German Rivera
2014-08-15 22:13 ` [RFC PATCH 3/4] drivers/bus: Device driver for FSL-MC DPRC devices J. German Rivera
2014-08-15 22:13 ` [RFC PATCH 4/4] Update MAINTAINERS file J. German Rivera
  -- strict thread matches above, loose matches on Subject: below --
2014-08-15 22:09 [RFC PATCH 0/4] drivers/bus: Freescale Management Complex bus driver patch series J. German Rivera
2014-08-15 22:09 ` [RFC PATCH 2/4] drivers/bus: Freescale Management Complex (fsl-mc) bus driver J. German Rivera

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=201408211330.20869.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=German.Rivera@freescale.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-release@linux.freescale.net \
    --cc=stuart.yoder@freescale.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.