From: Masahiro Yamada <yamada.m@jp.panasonic.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 12/26] dm: core: Allow uclasses to specific the private data for a device's children
Date: Thu, 22 Jan 2015 19:25:17 +0900 [thread overview]
Message-ID: <20150122192516.199B.AA925319@jp.panasonic.com> (raw)
In-Reply-To: <1421723575-4532-13-git-send-email-sjg@chromium.org>
Hi Simon,
Perhaps a typo in this subject, too
dm: core: Allow uclasses to specific the private data for a device's children
s/to specific/to specify/ ??
On Mon, 19 Jan 2015 20:12:41 -0700
Simon Glass <sjg@chromium.org> wrote:
> In many cases the per-child private data for a device's children is defined
> by the uclass rather than the individual driver. For example, a SPI bus
> needs to store information about each of its children, but all SPI drivers
> store the same information. It makes sense to allow the uclass to define
> this data.
>
> If the driver provides a size value for its per-child private data, then use
> it. Failng that, fall back to that provided by the uclass.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v2: None
>
> drivers/core/device-remove.c | 4 ++++
> drivers/core/device.c | 4 ++++
> include/dm/uclass.h | 4 ++++
> test/dm/bus.c | 31 +++++++++++++++++++++++++++++--
> 4 files changed, 41 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
> index 56c358a..3a5f48d 100644
> --- a/drivers/core/device-remove.c
> +++ b/drivers/core/device-remove.c
> @@ -126,6 +126,10 @@ void device_free(struct udevice *dev)
> }
> if (dev->parent) {
> size = dev->parent->driver->per_child_auto_alloc_size;
> + if (!size) {
> + size = dev->parent->uclass->uc_drv->
> + per_child_auto_alloc_size;
> + }
> if (size) {
> free(dev->parent_priv);
> dev->parent_priv = NULL;
Hmm, do we need to check the per_child_auto_alloc_size?
Is it better and simpler to check dev->parent_priv like this?
if (dev->parent && !dev->parent_priv) {
free(dev->parent_priv);
dev->parent_priv = NULL;
}
Or further more simpily
if (dev->parent) {
free(dev->parent_priv);
dev->parent_priv = NULL;
}
When free() is given with NULL pointer, it returns without doing anything,
I think.
Best Regards
Masahiro Yamada
next prev parent reply other threads:[~2015-01-22 10:25 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 3:12 [U-Boot] [PATCH v2 0/26] dm: Add additional bus functionality Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 01/26] dm: i2c: Provide an offset length parameter where needed Simon Glass
2015-01-20 6:28 ` Heiko Schocher
2015-01-21 10:45 ` Masahiro Yamada
2015-01-21 16:12 ` Simon Glass
2015-01-21 18:34 ` Masahiro YAMADA
2015-01-22 8:03 ` Masahiro Yamada
2015-01-22 15:00 ` Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 02/26] dm: Don't run tests if U-Boot cannot be built Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 03/26] dm: core: Improve comments for uclass_first/next_device() Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 04/26] dm: core: Set device tree node for root device Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 05/26] dm: core: Tidy up error handling in device_bind() Simon Glass
2015-01-22 8:04 ` Masahiro Yamada
2015-01-20 3:12 ` [U-Boot] [PATCH v2 06/26] dm: core: Allocate platform data when binding a device Simon Glass
2015-01-23 9:20 ` Masahiro Yamada
2015-01-23 15:50 ` Simon Glass
2015-01-24 5:04 ` Masahiro YAMADA
2015-01-24 14:23 ` Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 07/26] dm: core: Allow parents to have platform data for their children Simon Glass
2015-01-22 7:45 ` Masahiro Yamada
2015-01-20 3:12 ` [U-Boot] [PATCH v2 08/26] dm: core: Allow uclasses to specific the platdata for a device's children Simon Glass
2015-01-22 10:25 ` Masahiro Yamada
2015-01-20 3:12 ` [U-Boot] [PATCH v2 09/26] dm: core: Add a post_bind method for parents Simon Glass
2015-01-23 12:42 ` Masahiro Yamada
2015-01-20 3:12 ` [U-Boot] [PATCH v2 10/26] dm: core: Add a function to get a device's uclass ID Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 11/26] dm: core: Add a flag to control sequence numbering Simon Glass
2015-01-22 9:50 ` Masahiro Yamada
2015-01-20 3:12 ` [U-Boot] [PATCH v2 12/26] dm: core: Allow uclasses to specific the private data for a device's children Simon Glass
2015-01-22 10:25 ` Masahiro Yamada [this message]
2015-01-22 14:58 ` Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 13/26] dm: spi: Move the per-child data size to the uclass Simon Glass
2015-01-22 10:30 ` Masahiro Yamada
2015-01-20 3:12 ` [U-Boot] [PATCH v2 14/26] dm: core: Allow the uclass to set up a device's child after binding Simon Glass
2015-01-22 11:45 ` Masahiro Yamada
2015-01-20 3:12 ` [U-Boot] [PATCH v2 15/26] dm: sandbox: sf: Tidy up the error handling in sandbox_sf_probe() Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 16/26] dm: core: Allow uclass to set up a device's child before it is probed Simon Glass
2015-01-22 11:45 ` Masahiro Yamada
2015-01-20 3:12 ` [U-Boot] [PATCH v2 17/26] dm: spi: Set up the spi_slave device pointer in child_pre_probe() Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 18/26] dm: spi: Move slave details to child platdata Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 19/26] dm: i2c: " Simon Glass
2015-01-23 12:32 ` Masahiro Yamada
2015-01-23 15:40 ` Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 20/26] dm: tegra: Drop unused COMPAT features for I2C, SPI Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 21/26] dm: exynos: Drop unused COMPAT features for SPI Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 22/26] dm: core: Ignore disabled devices when binding Simon Glass
2015-01-24 4:46 ` Masahiro YAMADA
2015-01-20 3:12 ` [U-Boot] [PATCH v2 23/26] dm: cros_ec: Don't require protocol 3 support Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 24/26] dm: cros_ec: Move cros_ec_i2c over to driver model Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 25/26] dm: cros_ec_spi: Remove old pre-driver-model code Simon Glass
2015-01-20 3:12 ` [U-Boot] [PATCH v2 26/26] dm: Update documentation for new bus features Simon Glass
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=20150122192516.199B.AA925319@jp.panasonic.com \
--to=yamada.m@jp.panasonic.com \
--cc=u-boot@lists.denx.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