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 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.