linux-kernel - Re: [PATCH 3/4] usb: ehci: Add new EHCI driver for Broadcom STB SoC's

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]

Message-ID: <20200313150850.GV1922688@smile.fi.intel.com>
Date:   Fri, 13 Mar 2020 17:08:50 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Al Cooper <alcooperx@...il.com>
Cc:     linux-kernel@...r.kernel.org,
        Alan Stern <stern@...land.harvard.edu>,
        Arnd Bergmann <arnd@...db.de>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        bcm-kernel-feedback-list@...adcom.com,
        "David S. Miller" <davem@...emloft.net>,
        devicetree@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Johan Hovold <johan@...nel.org>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        linux-usb@...r.kernel.org, Mark Rutland <mark.rutland@....com>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, Rob Herring <robh@...nel.org>
Subject: Re: [PATCH 3/4] usb: ehci: Add new EHCI driver for Broadcom STB SoC's

On Fri, Mar 13, 2020 at 10:15:44AM -0400, Al Cooper wrote:
> Add a new EHCI driver for Broadcom STB SoC's. A new EHCI driver
> was created instead of adding support to the existing ehci platform
> driver because of the code required to workaround bugs in the EHCI
> controller.

I'm not sure this is the best approach, but I leave it to maintainers.

By the way, can you list what exactly the difference to the (generic)
ehci driver?

...

> +#include <linux/acpi.h>
> +#include <linux/clk.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/err.h>
> +#include <linux/kernel.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>

...

> +/* ehci_brcm_wait_for_sof
> + * Wait for start of next microframe, then wait extra delay microseconds
> + */

Style is inconsistent even inside this file.

> +static inline void ehci_brcm_wait_for_sof(struct ehci_hcd *ehci, u32 delay)
> +{
> +	int frame_idx = ehci_readl(ehci, &ehci->regs->frame_index);

This is not needed if you use do {} while approach.

> +

> +	while (frame_idx == ehci_readl(ehci, &ehci->regs->frame_index))
> +		;

Busy loop without even power management taking into consideration?

Infinite loop?

> +	udelay(delay);
> +}

...

> +static const struct ehci_driver_overrides brcm_overrides __initconst = {
> +

> +	.reset =	ehci_brcm_reset,

Indentation issue.

> +	.extra_priv_size = sizeof(struct brcm_priv),
> +};

...

> +static int ehci_brcm_probe(struct platform_device *pdev)
> +{

> +	irq = platform_get_irq(pdev, 0);
> +	if (irq < 0) {

> +		dev_err(&pdev->dev, "no irq provided");

Duplicate with core message.

> +		return irq;
> +	}

> +	/* initialize hcd */
> +	hcd = usb_create_hcd(&ehci_brcm_hc_driver,
> +			&pdev->dev, dev_name(&pdev->dev));

At least this one will look much better (and fit one line) when you introduce

	struct device *dev = &pdev->dev;

in the definition block above.

> +	if (!hcd)
> +		return -ENOMEM;

> +	return err;
> +}

...

> +static struct platform_driver ehci_brcm_driver = {
> +	.probe		= ehci_brcm_probe,
> +	.remove		= ehci_brcm_remove,
> +	.shutdown	= usb_hcd_platform_shutdown,
> +	.driver		= {

> +		.owner	= THIS_MODULE,

Do we need this?

> +		.name	= "ehci-brcm",
> +		.pm	= &ehci_brcm_pm_ops,
> +		.of_match_table = brcm_ehci_of_match,
> +	}
> +};

-- 
With Best Regards,
Andy Shevchenko