linux-kernel - Re: [PATCH v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Sep 2014 12:43:10 -0500
From:	Felipe Balbi <balbi@...com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	<balbi@...com>, Antoine Tenart <antoine.tenart@...e-electrons.com>,
	<linux-arm-kernel@...ts.infradead.org>,
	<sebastian.hesselbarth@...il.com>, <Peter.Chen@...escale.com>,
	<p.zabel@...gutronix.de>, <thomas.petazzoni@...e-electrons.com>,
	<zmxu@...vell.com>, <devicetree@...r.kernel.org>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<alexandre.belloni@...e-electrons.com>, <jszhang@...vell.com>
Subject: Re: [PATCH v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx

Hi,

On Tue, Sep 23, 2014 at 07:37:25PM +0200, Arnd Bergmann wrote:
> On Tuesday 23 September 2014 11:55:15 Felipe Balbi wrote:
> > On Tue, Sep 23, 2014 at 06:44:40PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 23 September 2014 15:36:45 Antoine Tenart wrote:
> > > > On Tue, Sep 23, 2014 at 12:39:04PM +0200, Arnd Bergmann wrote:
> > > > > On Tuesday 23 September 2014 12:28:03 Antoine Tenart wrote:
> > > > > > +       if (dev->of_node) {
> > > > > > +               ret = ci_hdrc_usb2_dt_probe(dev, ci_pdata);
> > > > > > +               if (ret)
> > > > > > +                       goto clk_err;
> > > > > > +       } else {
> > > > > > +               ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> > > > > > +               if (ret)
> > > > > > +                       goto clk_err;
> > > > > > +       }
> > > > > > 
> > > > > 
> > > > > Why do you care about the non-DT case here? I think it would be nicer to
> > > > > open-code the ci_hdrc_usb2_dt_probe() function in here and remove
> > > > > the dma_set_mask_and_coherent(), which should not even be necessary for
> > > > > the case where you have a hardwired platform device.
> > > > > 
> > > > 
> > > > I thought we agreed to call dma_set_mask_and_coherent():
> > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/273335.html
> > > > 
> > > > I do not have a strong opinion on this as I only use the dt case for my
> > > > usage.
> > > 
> > > The question is more about who actually wants the non-DT case.
> > > 
> > > Since this is a new driver, I suspect that the answer is "nobody",
> > > as the existing board files are all for legacy platforms that we
> > > are not going to adapt for this driver.
> > 
> > wait a minute... will the legacy platforms be adapted to DT and, thus,
> > to this driver in the future ? I really don't want to keep several
> > copies of chipidea driver just because there are still some legacy
> > platforms still using them. I have said in the past and will say again,
> > everybody should move to the generic chipidea driver at the earliest
> > opportunity so we avoid duplication of work.
> > 
> 
> Sorry, my mistake. The intention that this new driver is meant to
> replace the existing ones wasn't clear to me from the changelog, and
> if I'd been involved in the discussion before, then I've forgotten
> about it.
> 
> It absolutely makes sense to migrate to a common driver, and in that
> case we should keep the platform_data handling and
> dma_set_mask_and_coherent() call in there, so we can do the two
> conversions (migrating from platform specific frontends to the generic
> one, and migrating from platform_data to DT) on independent schedules.

makes sense to me.

> Eventually I'd like all of the existing users of the platform_data
> path to move to DT, but that should not hold up the other cleanup if
> it takes longer.

yeah, certainly.

> There is however still my point that we shouldn't have an extra
> platform device that is not attached to the device node. I think the
> generic driver should just be part of the common code, without an
> extra framework.  Something like the (entirely untested) patch below.

yeah, that's what I did on dwc3 at least. We support platform_data and
DT on the core driver. As for glue layers, we have ST, Qcom, PCI, OMAP,
Exynos and Keystone.

The only difference is that core dwc3 still doesn't know about clocks,
but that's not an issue right now because we're not yet supporting
pm_runtime.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)