mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 1/3 v2] net: introduce phylib
Date: Tue, 11 Sep 2012 11:09:06 +0200	[thread overview]
Message-ID: <20120911090906.GQ18243@pengutronix.de> (raw)
In-Reply-To: <20120910130800.GB31207@game.jcrosoft.org>

On Mon, Sep 10, 2012 at 03:08:00PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 09:14 Mon 10 Sep     , Sascha Hauer wrote:
> > On Sun, Sep 09, 2012 at 05:44:00PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > +
> > > +	drv->config_init(dev);
> > 
> > Call _dev->driver->probe instead? A phy driver would have to convert the
> > device argument to a phy_device using to_phy_device(), but this would be
> > the same as other subsystems do it currently.
> 
> the phy probe is the for the driver which I did not add but I could 
> here the config_init is correct

I have assumed that phy drivers would need the opportunity to allocate
memory, and hence also to free it on remove. Appearantly this is not
the case, even in Linux. So ok, let's keep it this way.

> > 
> > > +
> > > +static void phy_remove(struct device_d *dev)
> > > +{
> > > +}
> > > +
> > > +struct bus_type phy_bustype = {
> > > +	.name = "phy",
> > > +	.match = phy_match,
> > > +	.probe = phy_probe,
> > > +	.remove = phy_remove,
> > 
> > Then you could just remove the .remove callback which has the effect
> > that a phy drivers .remove function would be called.
> the generic code make the remove mandatory

Indeed, I thought the generic code bahaves differently here.

Sascha

> 
> > 
> > > +};
> > > +
> > > +int phy_driver_register(struct phy_driver *phydrv)
> > > +{
> > > +	if (!phydrv)
> > > +		return -1;
> > 
> > Drop this check. A stack dump contains more information than an error
> > code that nobody checks. EPERM would be the wrong error code anyway.

Would you mind dropping this? Then we are free to go.

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:[~2012-09-11  9:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-09 15:44 Jean-Christophe PLAGNIOL-VILLARD
2012-09-09 15:44 ` [PATCH 2/3] net: catch error on eth_send Jean-Christophe PLAGNIOL-VILLARD
2012-09-09 15:44 ` [PATCH 3/3] net: move the eth_dev status detection at driver level Jean-Christophe PLAGNIOL-VILLARD
2012-09-10  7:14 ` [PATCH 1/3 v2] net: introduce phylib Sascha Hauer
2012-09-10 13:08   ` Jean-Christophe PLAGNIOL-VILLARD
2012-09-11  9:09     ` Sascha Hauer [this message]

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=20120911090906.GQ18243@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=plagnioj@jcrosoft.com \
    /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