All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Rob Herring <robh+dt@kernel.org>
Cc: Sekhar Nori <nsekhar@ti.com>, Kevin Hilman <khilman@kernel.org>,
	David Lechner <david@lechnology.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Peter Rosin <peda@axentia.se>, Jiri Slaby <jslaby@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Magnus Damm <magnus.damm@gmail.com>,
	Johan Hovold <johan@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	"open list:GENERIC INCLUDE/ASM HEADER FILES"
	<linux-arch@vger.kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH 10/12] platform/early: implement support for early platform drivers
Date: Tue, 15 May 2018 16:06:15 +0200	[thread overview]
Message-ID: <CAMRc=MdsDWb0Ve29_d=30nc1F0aVhTrG74GX=sv0iB5WycWwLw@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqJw8UXktcLK8ADUfo1P+1un+omJ31sGcq7GFbNwJMsHKg@mail.gmail.com>

2018-05-14 15:37 GMT+02:00 Rob Herring <robh+dt@kernel.org>:
> On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> This introduces the core part of support for early platform drivers
>> and devices.
>>
>
> It looks like most of your prep patches are to separate the alloc and
> init of platform devices because you are essentially making early
> devices/drivers a sub-class. Maybe you could avoid doing that and
> simplify things a bit. Comments below based on doing that...
>

My aim was to change as little as possible for everybody else while
fixing our problem. These changes are already controversial enough
without risky reusing of existing fields in common structures. I was
just afraid that there are too many intricacies for it to be safe.

>> +/**
>> + * struct early_platform_driver
>> + *
>> + * @pdrv: real platform driver associated with this early platform driver
>> + * @list: list head for the list of early platform drivers
>> + * @early_probe: early probe callback
>> + */
>> +struct early_platform_driver {
>> +       struct platform_driver pdrv;
>> +       struct list_head list;
>
> Couldn't you use an existing list in driver_private until you move
> over to the normal bus infra.
>

This is something that the previous implementation did. It was quite
unreadable, so I decided to go with a separate list.

>> +       int (*early_probe)(struct platform_device *);
>
> Just add this to platform_driver.
>

This would extend the structure for everybody else while there'll be
very few such devices and not all systems would even require it.

>> +};
>> +
>> +/**
>> + * struct early_platform_device
>> + *
>> + * @pdev: real platform device associated with this early platform device
>> + * @list: list head for the list of early platform devices
>> + * @deferred: true if this device's early probe was deferred
>> + * @deferred_drv: early platform driver with which this device was matched
>> + */
>> +struct early_platform_device {
>> +       struct platform_device pdev;
>> +       struct list_head list;
>
> Use a list in device_private?
>
>> +       bool deferred;
>> +       struct early_platform_driver *deferred_drv;
>
> Can't you use the existing deferred probe list?
>

I thought about it, but I was afraid there could be some timing issues
with that and decided against it. The early deferral also doesn't work
in a workque, but is synchronous instead.

Best regards,
Bartosz Golaszewski

WARNING: multiple messages have this Message-ID (diff)
From: Bartosz Golaszewski <brgl@bgdev.pl>
To: Rob Herring <robh+dt@kernel.org>
Cc: Sekhar Nori <nsekhar@ti.com>, Kevin Hilman <khilman@kernel.org>,
	David Lechner <david@lechnology.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Peter Rosin <peda@axentia.se>, Jiri Slaby <jslaby@suse.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Magnus Damm <magnus.damm@gmail.com>,
	Johan Hovold <johan@kernel.org>
Subject: Re: [PATCH 10/12] platform/early: implement support for early platform drivers
Date: Tue, 15 May 2018 16:06:15 +0200	[thread overview]
Message-ID: <CAMRc=MdsDWb0Ve29_d=30nc1F0aVhTrG74GX=sv0iB5WycWwLw@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqJw8UXktcLK8ADUfo1P+1un+omJ31sGcq7GFbNwJMsHKg@mail.gmail.com>

2018-05-14 15:37 GMT+02:00 Rob Herring <robh+dt@kernel.org>:
> On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> This introduces the core part of support for early platform drivers
>> and devices.
>>
>
> It looks like most of your prep patches are to separate the alloc and
> init of platform devices because you are essentially making early
> devices/drivers a sub-class. Maybe you could avoid doing that and
> simplify things a bit. Comments below based on doing that...
>

My aim was to change as little as possible for everybody else while
fixing our problem. These changes are already controversial enough
without risky reusing of existing fields in common structures. I was
just afraid that there are too many intricacies for it to be safe.

>> +/**
>> + * struct early_platform_driver
>> + *
>> + * @pdrv: real platform driver associated with this early platform driver
>> + * @list: list head for the list of early platform drivers
>> + * @early_probe: early probe callback
>> + */
>> +struct early_platform_driver {
>> +       struct platform_driver pdrv;
>> +       struct list_head list;
>
> Couldn't you use an existing list in driver_private until you move
> over to the normal bus infra.
>

This is something that the previous implementation did. It was quite
unreadable, so I decided to go with a separate list.

>> +       int (*early_probe)(struct platform_device *);
>
> Just add this to platform_driver.
>

This would extend the structure for everybody else while there'll be
very few such devices and not all systems would even require it.

>> +};
>> +
>> +/**
>> + * struct early_platform_device
>> + *
>> + * @pdev: real platform device associated with this early platform device
>> + * @list: list head for the list of early platform devices
>> + * @deferred: true if this device's early probe was deferred
>> + * @deferred_drv: early platform driver with which this device was matched
>> + */
>> +struct early_platform_device {
>> +       struct platform_device pdev;
>> +       struct list_head list;
>
> Use a list in device_private?
>
>> +       bool deferred;
>> +       struct early_platform_driver *deferred_drv;
>
> Can't you use the existing deferred probe list?
>

I thought about it, but I was afraid there could be some timing issues
with that and decided against it. The early deferral also doesn't work
in a workque, but is synchronous instead.

Best regards,
Bartosz Golaszewski

WARNING: multiple messages have this Message-ID (diff)
From: brgl@bgdev.pl (Bartosz Golaszewski)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 10/12] platform/early: implement support for early platform drivers
Date: Tue, 15 May 2018 16:06:15 +0200	[thread overview]
Message-ID: <CAMRc=MdsDWb0Ve29_d=30nc1F0aVhTrG74GX=sv0iB5WycWwLw@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqJw8UXktcLK8ADUfo1P+1un+omJ31sGcq7GFbNwJMsHKg@mail.gmail.com>

2018-05-14 15:37 GMT+02:00 Rob Herring <robh+dt@kernel.org>:
> On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> This introduces the core part of support for early platform drivers
>> and devices.
>>
>
> It looks like most of your prep patches are to separate the alloc and
> init of platform devices because you are essentially making early
> devices/drivers a sub-class. Maybe you could avoid doing that and
> simplify things a bit. Comments below based on doing that...
>

My aim was to change as little as possible for everybody else while
fixing our problem. These changes are already controversial enough
without risky reusing of existing fields in common structures. I was
just afraid that there are too many intricacies for it to be safe.

>> +/**
>> + * struct early_platform_driver
>> + *
>> + * @pdrv: real platform driver associated with this early platform driver
>> + * @list: list head for the list of early platform drivers
>> + * @early_probe: early probe callback
>> + */
>> +struct early_platform_driver {
>> +       struct platform_driver pdrv;
>> +       struct list_head list;
>
> Couldn't you use an existing list in driver_private until you move
> over to the normal bus infra.
>

This is something that the previous implementation did. It was quite
unreadable, so I decided to go with a separate list.

>> +       int (*early_probe)(struct platform_device *);
>
> Just add this to platform_driver.
>

This would extend the structure for everybody else while there'll be
very few such devices and not all systems would even require it.

>> +};
>> +
>> +/**
>> + * struct early_platform_device
>> + *
>> + * @pdev: real platform device associated with this early platform device
>> + * @list: list head for the list of early platform devices
>> + * @deferred: true if this device's early probe was deferred
>> + * @deferred_drv: early platform driver with which this device was matched
>> + */
>> +struct early_platform_device {
>> +       struct platform_device pdev;
>> +       struct list_head list;
>
> Use a list in device_private?
>
>> +       bool deferred;
>> +       struct early_platform_driver *deferred_drv;
>
> Can't you use the existing deferred probe list?
>

I thought about it, but I was afraid there could be some timing issues
with that and decided against it. The early deferral also doesn't work
in a workque, but is synchronous instead.

Best regards,
Bartosz Golaszewski

  reply	other threads:[~2018-05-15 14:06 UTC|newest]

Thread overview: 106+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-11 16:20 [PATCH 00/12] introduce support for early platform drivers Bartosz Golaszewski
2018-05-11 16:20 ` Bartosz Golaszewski
2018-05-11 16:20 ` Bartosz Golaszewski
2018-05-11 16:20 ` [PATCH 01/12] platform/early: add a new field to struct device Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-14 21:24   ` Geert Uytterhoeven
2018-05-14 21:24     ` Geert Uytterhoeven
2018-05-14 21:24     ` Geert Uytterhoeven
2018-05-11 16:20 ` [PATCH 02/12] platform/early: don't WARN() on non-empty devres list for early devices Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-14 21:24   ` Geert Uytterhoeven
2018-05-14 21:24     ` Geert Uytterhoeven
2018-05-14 21:24     ` Geert Uytterhoeven
2018-05-11 16:20 ` [PATCH 03/12] platform/early: export platform_match() locally Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-14 21:25   ` Geert Uytterhoeven
2018-05-14 21:25     ` Geert Uytterhoeven
2018-05-14 21:25     ` Geert Uytterhoeven
2018-05-11 16:20 ` [PATCH 04/12] platform: provide a separate function for initializing platform devices Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-14 21:25   ` Geert Uytterhoeven
2018-05-14 21:25     ` Geert Uytterhoeven
2018-05-14 21:25     ` Geert Uytterhoeven
2018-05-11 16:20 ` [PATCH 05/12] platform: export platform_device_release() locally Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-14 21:25   ` Geert Uytterhoeven
2018-05-14 21:25     ` Geert Uytterhoeven
2018-05-14 21:25     ` Geert Uytterhoeven
2018-05-11 16:20 ` [PATCH 06/12] of: add a new flag for OF device nodes Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-14 21:25   ` Geert Uytterhoeven
2018-05-14 21:25     ` Geert Uytterhoeven
2018-05-14 21:25     ` Geert Uytterhoeven
2018-05-11 16:20 ` [PATCH 07/12] of/platform: provide a separate routine for setting up device resources Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-14 21:26   ` Geert Uytterhoeven
2018-05-14 21:26     ` Geert Uytterhoeven
2018-05-14 21:26     ` Geert Uytterhoeven
2018-05-11 16:20 ` [PATCH 08/12] of/platform: provide a separate routine for device initialization Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-14 21:26   ` Geert Uytterhoeven
2018-05-14 21:26     ` Geert Uytterhoeven
2018-05-14 21:26     ` Geert Uytterhoeven
2018-05-11 16:20 ` [PATCH 09/12] platform/early: add an init section for early driver data Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-14 21:29   ` Geert Uytterhoeven
2018-05-14 21:29     ` Geert Uytterhoeven
2018-05-14 21:29     ` Geert Uytterhoeven
2018-05-15  8:41     ` Bartosz Golaszewski
2018-05-15  8:41       ` Bartosz Golaszewski
2018-05-15  8:41       ` Bartosz Golaszewski
2018-05-11 16:20 ` [PATCH 10/12] platform/early: implement support for early platform drivers Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-14 13:37   ` Rob Herring
2018-05-14 13:37     ` Rob Herring
2018-05-14 13:37     ` Rob Herring
2018-05-15 14:06     ` Bartosz Golaszewski [this message]
2018-05-15 14:06       ` Bartosz Golaszewski
2018-05-15 14:06       ` Bartosz Golaszewski
2018-05-16  1:06       ` Rob Herring
2018-05-16  1:06         ` Rob Herring
2018-05-16  1:06         ` Rob Herring
2018-05-11 16:20 ` [PATCH 11/12] misc: implement a dummy early platform driver Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-11 16:20 ` [PATCH 12/12] of/platform: make the OF code aware of early platform drivers Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-11 16:20   ` Bartosz Golaszewski
2018-05-14 21:32   ` Geert Uytterhoeven
2018-05-14 21:32     ` Geert Uytterhoeven
2018-05-14 21:32     ` Geert Uytterhoeven
2018-05-11 20:13 ` [PATCH 00/12] introduce support for " Rob Herring
2018-05-11 20:13   ` Rob Herring
2018-05-11 20:13   ` Rob Herring
2018-05-14 11:38   ` Bartosz Golaszewski
2018-05-14 11:38     ` Bartosz Golaszewski
2018-05-14 11:38     ` Bartosz Golaszewski
2018-05-14 13:20     ` Rob Herring
2018-05-14 13:20       ` Rob Herring
2018-05-14 13:20       ` Rob Herring
2018-05-30 19:40       ` Michael Turquette
2018-05-30 19:40         ` Michael Turquette
2018-05-30 19:40         ` Michael Turquette
2018-05-30 22:36         ` Rob Herring
2018-05-30 22:36           ` Rob Herring
2018-05-30 22:36           ` Rob Herring
2018-05-31  6:42           ` Geert Uytterhoeven
2018-05-31  6:42             ` Geert Uytterhoeven
2018-05-31  6:42             ` Geert Uytterhoeven
2018-05-31 14:16             ` Tony Lindgren
2018-05-31 14:16               ` Tony Lindgren
2018-05-31 14:16               ` Tony Lindgren
2018-10-19 12:08 ` Bartosz Golaszewski
2018-10-19 12:08   ` Bartosz Golaszewski
2018-10-19 12:08   ` Bartosz Golaszewski
2018-10-19 12:08   ` Bartosz Golaszewski

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='CAMRc=MdsDWb0Ve29_d=30nc1F0aVhTrG74GX=sv0iB5WycWwLw@mail.gmail.com' \
    --to=brgl@bgdev.pl \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=bgolaszewski@baylibre.com \
    --cc=dalias@libc.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=david@lechnology.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan@kernel.org \
    --cc=jslaby@suse.com \
    --cc=khilman@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@baylibre.com \
    --cc=nsekhar@ti.com \
    --cc=peda@axentia.se \
    --cc=rafael.j.wysocki@intel.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=ysato@users.sourceforge.jp \
    /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.