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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox