linux-kernel - Re: [PATCH v2 4/7] usb: dwc3: core: Expose core driver as library

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: <ZsO1wbXSpaMk4ZMB@hu-bjorande-lv.qualcomm.com>
Date: Mon, 19 Aug 2024 14:14:41 -0700
From: Bjorn Andersson <quic_bjorande@...cinc.com>
To: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
CC: Bjorn Andersson <andersson@...nel.org>,
        Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>,
        Rob Herring <robh@...nel.org>,
        "Krzysztof
 Kozlowski" <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, "Felipe
 Balbi" <balbi@...nel.org>,
        Wesley Cheng <quic_wcheng@...cinc.com>,
        "Saravana
 Kannan" <saravanak@...gle.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "Konrad Dybcio" <konrad.dybcio@...aro.org>,
        "linux-usb@...r.kernel.org"
	<linux-usb@...r.kernel.org>,
        "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "linux-arm-msm@...r.kernel.org"
	<linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v2 4/7] usb: dwc3: core: Expose core driver as library

On Wed, Aug 14, 2024 at 12:56:44AM +0000, Thinh Nguyen wrote:
> On Sun, Aug 11, 2024, Bjorn Andersson wrote:
> > From: Bjorn Andersson <quic_bjorande@...cinc.com>
> > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
[..]
> > @@ -2076,10 +2077,11 @@ static int dwc3_get_num_ports(struct dwc3 *dwc)
> >  	return 0;
> >  }
> >  
> > -static int dwc3_probe(struct platform_device *pdev)
> > +struct dwc3 *dwc3_probe(struct platform_device *pdev, struct resource *res,
> > +			bool ignore_clocks_and_resets, void *glue)
> 
> Perhaps create a wrapper struct to hold the parameters above. I can see
> we may expand this in the future.
> 

Sounds good.

There are a few cases where e.g. the Qualcomm glue needs to react to
role switching in the core, so we already know that we want to add some
callbacks here.

> >  {
> >  	struct device		*dev = &pdev->dev;
> > -	struct resource		*res, dwc_res;
> > +	struct resource		dwc_res;
> >  	unsigned int		hw_mode;
> >  	void __iomem		*regs;
> >  	struct dwc3		*dwc;
> > @@ -2087,15 +2089,10 @@ static int dwc3_probe(struct platform_device *pdev)
> >  
> >  	dwc = devm_kzalloc(dev, sizeof(*dwc), GFP_KERNEL);
> >  	if (!dwc)
> > -		return -ENOMEM;
> > +		return ERR_PTR(-ENOMEM);
> >  
> >  	dwc->dev = dev;
> > -
> > -	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > -	if (!res) {
> > -		dev_err(dev, "missing memory resource\n");
> > -		return -ENODEV;
> > -	}
> > +	dwc->glue = glue;
> >  
> >  	dwc->xhci_resources[0].start = res->start;
> >  	dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
> > @@ -2123,7 +2120,7 @@ static int dwc3_probe(struct platform_device *pdev)
> >  
> >  	regs = devm_ioremap_resource(dev, &dwc_res);
> >  	if (IS_ERR(regs))
> > -		return PTR_ERR(regs);
> > +		return ERR_CAST(regs);
> >  
> >  	dwc->regs	= regs;
> >  	dwc->regs_size	= resource_size(&dwc_res);
> > @@ -2132,15 +2129,17 @@ static int dwc3_probe(struct platform_device *pdev)
> >  
> >  	dwc3_get_software_properties(dwc);
> >  
> > -	dwc->reset = devm_reset_control_array_get_optional_shared(dev);
> > -	if (IS_ERR(dwc->reset)) {
> > -		ret = PTR_ERR(dwc->reset);
> > -		goto err_put_psy;
> > -	}
> > +	if (!ignore_clocks_and_resets) {
> 
> This seems to be specific change for your platform. Let's keep this
> change separated from this patch.
> 

The primary need here is that the glue code needs to be able to access
the hardware before the core's resume and after suspend. I'd expect
other glue implementations will have the same need.

But moving this change to a separate change allows us to reason about
that separately, so I like the suggestion.

Thanks,
Bjorn

> Thanks,
> Thinh
>