From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Mon, 29 Feb 2016 14:34:41 +0100 Subject: [U-Boot] [PATCH 05/17] drivers: usb: musb: adopt musb backend driver to driver model In-Reply-To: <56D44716.2090705@ti.com> References: <1456717460-3132-1-git-send-email-mugunthanvnm@ti.com> <1456717460-3132-6-git-send-email-mugunthanvnm@ti.com> <56D433BB.7000101@denx.de> <56D44716.2090705@ti.com> Message-ID: <56D448F1.4030009@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 02/29/2016 02:26 PM, Mugunthan V N wrote: > On Monday 29 February 2016 05:34 PM, Marek Vasut wrote: >> On 02/29/2016 04:44 AM, Mugunthan V N wrote: >>> Currently all backend driver ops uses hard coded physical >>> address, so to adopt the driver to DM, add device pointer to ops >>> call backs so that drivers that drivers can get physical >>> addresses from the usb driver priv/plat data. >>> >>> Signed-off-by: Mugunthan V N >>> --- >> >> [...] >> >>> @@ -704,8 +719,13 @@ static int dsps_resume(struct device *dev) >>> struct omap_musb_board_data *data = plat->board_data; >>> >>> /* Start the on-chip PHY and its PLL. */ >>> +#ifndef CONFIG_DM_USB >>> if (data->set_phy_power) >>> data->set_phy_power(1); >>> +#else >>> + if (data->set_phy_power) >>> + data->set_phy_power(data->dev, 1); >> >> Would it be possible to avoid adding this sea of ifdefs into the driver? >> > > May be introducing a void pointer and pass it back in ops callback can > avoid ifdefs. For non DM mode, it will be holding NULL pointer and for > DM mode it will be holding a dev pointer. If its ok, I can fix in v2. That looks a bit more sensible, yes. I am worried about problems with dereferencing the data->dev pointer though. But let's see. -- Best regards, Marek Vasut