From: hdegoede@redhat.com (Hans de Goede)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 4/8] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
Date: Sat, 22 Feb 2014 12:19:07 +0100 [thread overview]
Message-ID: <530887AB.1030805@redhat.com> (raw)
In-Reply-To: <20140222083128.GH3931@lukather>
Hi,
On 02/22/2014 09:31 AM, Maxime Ripard wrote:
<snip>
>>>>> This should be before the registration. Otherwise, you're racy.
>>>>
>>>> Nope, we only need this to get the data on sunxi_mmc_remove,
>>>> everywhere else the data is found through the mmc-host struct.
>>>
>>> Still, if anyone makes a following patch using the platform_device
>>> for some reason, we will have a race condition, without any way to
>>> notice it.
>>>
>>> Plus, you're doing all the other bits of initialization of your
>>> structures much earlier, why not be consistent and having all of
>>> them at the same place?
>>
>> Most platform drivers I've worked on do platform_set_drvdata as late
>> as possible, so that the drvdata does not get set and never cleared
>> in error paths.
>
> You don't actually have to clear it,
Erm, yes and no, you used to have to manually clear it, so as to not
leave a dangling pointer in there, which may confuse things later.
But since a few kernel releases, the driver core will explicitly
clear it on probe failure, since many many drivers got this wrong.
I know this because I wrote the driver core patch doing the clearing :)
So in drivers which used to get it right, you will see the
platform_set_drvdata call quite late and it being so late
in the sunxi-mmc.c driver is old habits dying hard.
But you're right that this is no longer needed, still I see little
reason to move it up, but if you really want it to be moved up,
I'm fine with that.
> and some frameworks actually require you to call dev_set_drvdata before registration, so that
> statement looks quite odd to me.
And the proper thing to do when using those frameworks was to
manually clear drvdata again on probe failure. Anyways this is
all handled in the driver core now, so this whole discussion
is moot anyways. I was merely trying to explain where my
preference for doing the dev_set_drvdata call as late as
possible comes from.
Regards,
Hans
next prev parent reply other threads:[~2014-02-22 11:19 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-17 10:02 [PATCH v7 0/8] ARM: sunxi: Add driver for SD/MMC hosts found on allwinner sunxi SOCs David Lanzendörfer
2014-02-17 10:02 ` [PATCH v7 1/8] clk: sunxi: factors: automatic reparenting support David Lanzendörfer
2014-02-18 14:05 ` Maxime Ripard
[not found] ` <20140319233945.21989.12073@quantum>
2014-03-20 9:47 ` Maxime Ripard
2014-02-17 10:02 ` [PATCH v7 2/8] clk: sunxi: Implement MMC phase control David Lanzendörfer
2014-02-18 14:15 ` Maxime Ripard
2014-02-19 5:21 ` Mike Turquette
2014-02-19 8:36 ` Maxime Ripard
2014-02-23 20:31 ` Mike Turquette
[not found] ` <20140602213134.10062.14293@quantum>
2014-06-05 16:01 ` Maxime Ripard
2014-02-17 10:02 ` [PATCH v7 3/8] ARM: sunxi: clk: export clk_sunxi_mmc_phase_control David Lanzendörfer
2014-02-18 14:17 ` Maxime Ripard
2014-02-17 10:02 ` [PATCH v7 4/8] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs David Lanzendörfer
2014-02-18 15:37 ` Maxime Ripard
2014-02-18 20:49 ` Hans de Goede
2014-02-19 9:46 ` Maxime Ripard
2014-02-19 12:14 ` Hans de Goede
2014-02-22 8:31 ` Maxime Ripard
2014-02-22 11:19 ` Hans de Goede [this message]
2014-02-17 10:02 ` [PATCH v7 5/8] ARM: dts: sun7i: Add support for mmc David Lanzendörfer
2014-02-18 14:22 ` Maxime Ripard
2014-02-18 15:10 ` Hans de Goede
2014-02-21 18:54 ` Maxime Ripard
2014-02-17 10:02 ` [PATCH v7 6/8] ARM: dts: sun4i: " David Lanzendörfer
2014-02-17 10:02 ` [PATCH v7 7/8] ARM: dts: sun5i: " David Lanzendörfer
2014-02-17 10:03 ` [PATCH v7 8/8] ARM: sunxi: Add documentation for driver for SD/MMC hosts found on Allwinner sunxi SoCs David Lanzendörfer
2014-02-18 15:42 ` Maxime Ripard
2014-02-22 7:32 ` David Lanzendörfer
2014-02-22 8:37 ` Maxime Ripard
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=530887AB.1030805@redhat.com \
--to=hdegoede@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).