linux-kernel - RE: [PATCH] usb: dwc3: core: modify IO memory resource after deferred probe completes

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 26 Jul 2013 22:02:08 +0000
From:	Paul Zimmerman <Paul.Zimmerman@...opsys.com>
To:	"balbi@...com" <balbi@...com>
CC:	"Ivan T. Ivanov" <iivanov@...sol.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] usb: dwc3: core: modify IO memory resource after
 deferred probe completes

> From: Felipe Balbi [mailto:balbi@...com]
> Sent: Friday, July 26, 2013 1:32 PM
> 
> On Fri, Jul 26, 2013 at 06:44:23PM +0000, Paul Zimmerman wrote:
> > > From: Felipe Balbi [mailto:balbi@...com]
> > > Sent: Friday, July 26, 2013 2:54 AM
> > > > > > Also, this is not *modifying* what was passed, just skipping the xHCI
> > > > > > address space so we don't request_mem_region() an area we won't really
> > > > > > handle and prevent xhci-hcd.ko from probing.
> > > > >
> > > > > Hmm? platform_get_resource() returns a pointer to an entry in the
> > > > > platform_device's resource[] array. And "res->start +=" modifies the
> > > > > entry pointed at. If it didn't, the bug fixed by this patch wouldn't
> > > > > have happened.
> > > > >
> > > > > Are you sure this code will work OK if you build the driver as a module,
> > > > > modprobe it, rmmod it, and then modprobe it again? Seems like it won't,
> > > > > unless the dev->resource[] array gets reinitialized in between somehow.
> > >
> > > gotta try that one... Perhaps the correct way would be to copy the
> > > resource to a private struct resource and modify that one, leaving
> > > pdev->resources untouched.
> >
> > Maybe this is a dumb question, but why can't the driver that is going
> > to use the resource after this just "know" that it has to add
> > DWC3_GLOBALS_REGS_START to the start address? Are there some versions
> > of the core where that is not the case?
> 
> that won't work, because dwc3.ko will already have request_mem_region()
> the entire region and a subsequent request_mem_region() for xHCI space
> only would fail.
> 
> > Or, maybe there should be two sets of resources?
> 
> maybe we should require two sets of resources, yes... but then there's
> no point in having any host initialization whatsoever in dwc3.ko.

Right. For a platform with a DWC3 controller, have DT or whatever set up
a second memory resource in the platform device, and have xhci_plat_probe()
look for that one first. If it finds it, it uses that resource instead
of the first one. If it doesn't find the second resource (not a DWC3
platform) then it uses the first one like it does today.

Then you don't need to have dwc3 set up the xhci resource like it does
today. Seems cleaner to me. 'Course it's incompatible with what you have
today, I guess that's the major drawback.

-- 
Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/