On 20 February 2014 16:29, Russell King - ARM Linux
<linux@xxxxxxxxxxxxxxxx> wrote:
> I'll send a few patches in a moment. First through, I've just found this
> gem:
Yeah, 'gem' is the real word for this precious code :)
> static int sdhci_probe(struct platform_device *pdev)
> {
> ...
> sdhci = devm_kzalloc(&pdev->dev, sizeof(*sdhci), GFP_KERNEL);
> ...
> if (np) {
> ...
> } else {
> sdhci->data = dev_get_platdata(&pdev->dev);
> }
>
> pdev->dev.platform_data = sdhci;
> ...
> ... some paths which can cause probe to return an error code ...
> ...
> static int sdhci_remove(struct platform_device *pdev)
> {
> struct sdhci_host *host = platform_get_drvdata(pdev);
> struct spear_sdhci *sdhci = dev_get_platdata(&pdev->dev);
> ...
> clk_disable_unprepare(sdhci->clk);
> clk_put(sdhci->clk);
>
> So, what happens if we hit an error such as -EPROBEDEFER after that
> assignment to pdev->dev.platform_data, and then re-probe the driver
> later?
BANG BANG!! :)
> This is just horribly broken.
>
> What's wrong with using the facilities in sdhci to allow you to have
> your own private data after the sdhci_host structure?
Nothing wrong in that, only right.. Do you want me to float a patch for
this or you can get that done along with your series?
Thanks again..
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
