netdev - Re: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTink7MB8JbSz1cguVLviqkF0OTt=gHMjUi3j0bfB@mail.gmail.com>
Date:	Mon, 16 Aug 2010 23:58:42 +0000
From:	Michał Mirosław <mirqus@...il.com>
To:	Patrick Pannuto <ppannuto@...eaurora.org>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	magnus.damm@...il.com, gregkh@...e.de,
	Kevin Hilman <khilman@...prootsystems.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Magnus Damm <damm@...nsource.se>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Eric Miao <eric.y.miao@...il.com>,
	Dmitry Torokhov <dtor@...l.ru>, netdev@...r.kernel.org
Subject: Re: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses

2010/8/16 Patrick Pannuto <ppannuto@...eaurora.org>:
> On 08/13/2010 03:05 PM, Grant Likely wrote:
>> On Tue, Aug 10, 2010 at 5:49 PM, Patrick Pannuto
[...]
>>> + * @bus: partially complete bus type to register
>>> + *
>>> + * This init will fill in any ommitted fields in @bus, however, it
>>> + * also allocates memory and replaces the pm field in @bus, since
>>> + * pm is const, but some of its pointers may need this one-time
>>> + * initialziation overwrite.
>>> + *
>>> + * @bus's registered this way should be released with
>>> + * pseudo_platform_bus_unregister
>>> + */
>>> +int pseudo_platform_bus_register(struct bus_type *bus)
>>> +{
>>> +       int error;
>>> +       struct dev_pm_ops* heap_pm;
>>> +       heap_pm = kmalloc(sizeof (*heap_pm), GFP_KERNEL);
>>> +
>>> +       if (!heap_pm)
>>> +               return -ENOMEM;
>>> +
>>> +       if (!bus->dev_attrs)
>>> +               bus->dev_attrs = platform_bus_type.dev_attrs;
>>> +       if (!bus->match)
>>> +               bus->match = platform_bus_type.match;
>>> +       if (!bus->uevent)
>>> +               bus->uevent = platform_bus_type.uevent;
>>> +       if (!bus->pm)
>>> +               memcpy(heap_pm, &platform_bus_type.pm, sizeof(*heap_pm));
>>> +       else {
>>> +               heap_pm->prepare = (bus->pm->prepare) ?
>>> +                       bus->pm->prepare : platform_pm_prepare;
>>> +               heap_pm->complete = (bus->pm->complete) ?
>>> +                       bus->pm->complete : platform_pm_complete;
[and so on ...]
>>> +               heap_pm->runtime_idle = (bus->pm->runtime_idle) ?
>>> +                       bus->pm->runtime_idle : platform_pm_runtime_idle;
>>> +       }
>>> +       bus->pm = heap_pm;
>>> +
>>> +       error = bus_register(bus);
>>> +       if (error)
>>> +               kfree(bus->pm);
>>> +
>>> +       return error;
>>> +}
>>> +EXPORT_SYMBOL_GPL(pseudo_platform_bus_register);
>>
>> Ick, this is a nasty list of conditional statements.  :-)  Instead it
>> could have an unconditional initialize function which sets it up just
>> like the platform bus without registering.  Then allow the
>> foo_bus_type initialization code override the ones it cares about, and
>> then register directly.
>>
> No, this won't work. (Unless, every pseudo_bus_type author did this same
> kludge to work around const - better to do once IMHO)

Actually you can do:

const struct dev_pm_ops test = {
    DEFAULT_PLATFORM_PM_OPS,
    .prepare = my_func,
    ...
};

where:

#define DEFAULT_PLATFORM_PM_OPS \
    .prepare = platform_pm_prepare, \
    .complete = platform_pm_complete, \
    ...

In case of repeated field assignments, gcc uses the last value (as per
http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html).

Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html