All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Alexander Shiyan <shc_work@mail.ru>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 2/5] spi: i.MX: Move to coredevice_initcall
Date: Mon, 19 May 2014 10:47:50 +0200	[thread overview]
Message-ID: <20140519084750.GG5918@pengutronix.de> (raw)
In-Reply-To: <1400090277.899030332@f387.i.mail.ru>

On Wed, May 14, 2014 at 09:57:57PM +0400, Alexander Shiyan wrote:
> > 
> > - put the drivers private data into dev->priv
> > - when returning an error from probe, instead of freeing the data
> >   keep it.
> > - when probing again re-use the data.
> > 
> > With this drivers could be written like:
> > 
> > 	priv = dev->priv;
> > 	if (!priv) {
> > 		priv = xzalloc(sizeof(priv));
> > 		dev->priv = priv;
> > 	}
> > 
> > 	if (!priv->clk) {
> > 		clk = clk_get(dev, NULL);
> > 		if (IS_ERR(clk))
> > 			return PTR_ERR(clk);
> > 		priv->clk = clk;
> > 		clk_enable(priv->clk);
> > 	}
> > 
> > 	if (!priv->regulator) {
> > 		regulator = regulator_get(dev, "vmmc");
> > 		if (IS_ERR(regulator))
> > 			return PTR_ERR(regulator);
> > 		priv->regulator = regulator;
> > 	}
> > 
> > This way drivers could allocate the missing resources as needed without
> > freeing them between different calls to probe().
> 
> The idea is good, but I think that it will not be so easy to do.

Where do you expect problems?

> In addition, we obtain additional incompatibility with the kernel code.

I think this is not a problem in this case. The probe pathes of the
device drivers contain nearly the same elements, but are quite different
in the details anyway.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2014-05-19  8:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-08  7:31 [PATCH] fix i.MX51 babbage ethernet Sascha Hauer
2014-05-08  7:31 ` [PATCH 1/5] mfd: mc13xxx: Allow to set callback for mc13xxx Sascha Hauer
2014-05-18 23:14   ` Marc Reilly
2014-05-19  6:40     ` Sascha Hauer
2014-05-08  7:31 ` [PATCH 2/5] spi: i.MX: Move to coredevice_initcall Sascha Hauer
2014-05-11 18:49   ` Alexander Shiyan
2014-05-12 10:38     ` Sascha Hauer
2014-05-14 17:57       ` Alexander Shiyan
2014-05-19  8:47         ` Sascha Hauer [this message]
2014-05-08  7:31 ` [PATCH 3/5] mfd: mc13xxx: move " Sascha Hauer
2014-05-08  7:31 ` [PATCH 4/5] ARM: i.MX51 babbage: use mc13xxx_register_callback to initialize PMIC Sascha Hauer
2014-05-08  7:31 ` [PATCH 5/5] ARM: dts: i.MX51 babbage: overwrite upstream FEC iomux settings Sascha Hauer

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=20140519084750.GG5918@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=shc_work@mail.ru \
    /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.