Hello,
On Sun, Apr 30, 2017 at 12:34:40AM +0100, André Przywara wrote:
> >> If this is a valid use case, we can change devm to repeat till empty
> >> but it's a weird thing to do to allocate from a release function.
> >>
> >> So, something like this. Only compile tested.
>
> I was wondering if u
On 29/04/17 22:28, Adam Borowski wrote:
> On Fri, Apr 28, 2017 at 06:03:14PM -0400, Tejun Heo wrote:
>> On Tue, Apr 18, 2017 at 10:12:16AM +0100, Andre Przywara wrote:
>>> Yeah, so I stack-dumped on the zero allocations and indeed they are
>>> called from cleanup functions:
>>> drivers/pinctrl/pinm
On Fri, Apr 28, 2017 at 06:03:14PM -0400, Tejun Heo wrote:
> On Tue, Apr 18, 2017 at 10:12:16AM +0100, Andre Przywara wrote:
> > Yeah, so I stack-dumped on the zero allocations and indeed they are
> > called from cleanup functions:
> > drivers/pinctrl/pinmux.c:pinmux_generic_free_functions():
> >
Hello,
On Tue, Apr 18, 2017 at 10:12:16AM +0100, Andre Przywara wrote:
> Yeah, so I stack-dumped on the zero allocations and indeed they are
> called from cleanup functions:
> drivers/pinctrl/pinmux.c:pinmux_generic_free_functions():
> devm_kzalloc(sizeof(*indices) * pctldev->num_functions,
于 2017年4月18日 GMT+08:00 下午3:25:05, Tejun Heo 写到:
>Hello,
>
>On Mon, Apr 03, 2017 at 12:48:16AM +0100, André Przywara wrote:
>> So I see this problem easily now - on every boot - with an unpatched
>> 4.11-rc3 kernel and the (arm64) defconfig on a Pine64 or BananaPi
>M64.
>> I enabled devres.log an
Hi,
On 18/04/17 08:25, Tejun Heo wrote:
> Hello,
>
> On Mon, Apr 03, 2017 at 12:48:16AM +0100, André Przywara wrote:
>> So I see this problem easily now - on every boot - with an unpatched
>> 4.11-rc3 kernel and the (arm64) defconfig on a Pine64 or BananaPi M64.
>> I enabled devres.log and see th
Hello,
On Mon, Apr 03, 2017 at 12:48:16AM +0100, André Przywara wrote:
> So I see this problem easily now - on every boot - with an unpatched
> 4.11-rc3 kernel and the (arm64) defconfig on a Pine64 or BananaPi M64.
> I enabled devres.log and see that pinctrl probes early, but apparently
> gets def
Hi,
On 17/03/17 14:44, Tejun Heo wrote:
> On Fri, Mar 17, 2017 at 10:28:34PM +0800, Icenowy Zheng wrote:
>>> It's warning that the device has resources associated with it on
>>> probe. There gotta be something fishy going on with the probing
>>> sequence. How reproducible is the problem?
>>
>> Do
On Fri, Mar 17, 2017 at 10:44:22AM -0400, Tejun Heo wrote:
> On Fri, Mar 17, 2017 at 10:28:34PM +0800, Icenowy Zheng wrote:
> > > It's warning that the device has resources associated with it on
> > > probe. There gotta be something fishy going on with the probing
> > > sequence. How reproducible i
On Fri, Mar 17, 2017 at 10:28:34PM +0800, Icenowy Zheng wrote:
> > It's warning that the device has resources associated with it on
> > probe. There gotta be something fishy going on with the probing
> > sequence. How reproducible is the problem?
>
> Do you mean in the first probing trial the driv
Hello,
On Thu, Mar 16, 2017 at 10:06:15AM +0900, Greg Kroah-Hartman wrote:
> > > [ 2.895375] platform 1c20800.pinctrl: Retrying from deferred list
> > > [ 2.901945] bus: 'platform': driver_probe_device: matched device
> > > 1c20800.pinctrl with driver sun50i-a64-pinctrl
> > > [ 2.912660] bus: 'pl
On Thu, Mar 16, 2017 at 12:24:38AM +0800, Icenowy Zheng wrote:
>
>
> 16.03.2017, 00:14, "Adam Borowski" :
> > Hi!
> > On Pine64, since mid-February's -next, I get the following non-fatal
> > warning:
>
> I don't think this is from any bug in sun50i-a64-pinctrl driver, as the PC
> even
> didn't
12 matches
Mail list logo