On Thu, Mar 07, 2019 at 09:53:50PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 07.03.19 21:18, Wolfram Sang wrote:
> >
> >> It's been almost a year later, and several Linux revisions, and this
> >> still seems stuck somewhere/somehow.
> >
> > I wanted to respin this series once rc1 is re
On 07.03.19 21:18, Wolfram Sang wrote:
>
>> It's been almost a year later, and several Linux revisions, and this
>> still seems stuck somewhere/somehow.
>
> I wanted to respin this series once rc1 is released.
>
Maybe just rebase and repost ?
--mtx
--
Enrico Weigelt, metux IT consult
Free so
> It's been almost a year later, and several Linux revisions, and this
> still seems stuck somewhere/somehow.
I wanted to respin this series once rc1 is released.
signature.asc
Description: PGP signature
On Mon, Apr 30, 2018 at 4:30 AM Thierry Reding wrote:
>
> On Mon, Apr 30, 2018 at 11:03:25AM +0200, Linus Walleij wrote:
> > On Thu, Apr 19, 2018 at 5:14 PM, Grygorii Strashko
> > wrote:
> > > On 04/19/2018 09:05 AM, Wolfram Sang wrote:
> > >>
> > >> We should get drvdata from struct device direc
On Mon, Apr 30, 2018 at 11:03:25AM +0200, Linus Walleij wrote:
> On Thu, Apr 19, 2018 at 5:14 PM, Grygorii Strashko
> wrote:
> > On 04/19/2018 09:05 AM, Wolfram Sang wrote:
> >>
> >> We should get drvdata from struct device directly. Going via
> >> platform_device is an unneeded step back and fort
> Wolfram: if I don't find it, poke me with something sharp so I get to apply
> it.
I just bounced it again. Otherwise, it is here, too, downloadable as
mbox: https://patchwork.kernel.org/patch/10350759/
signature.asc
Description: PGP signature
On Thu, Apr 19, 2018 at 5:14 PM, Grygorii Strashko
wrote:
> On 04/19/2018 09:05 AM, Wolfram Sang wrote:
>>
>> We should get drvdata from struct device directly. Going via
>> platform_device is an unneeded step back and forth.
>>
>> Signed-off-by: Wolfram Sang
>> ---
>>
>> Build tested only. build
Hi Wolfram,
On 21.4.2018 18:23, Wolfram Sang wrote:
> Hi Michal,
>
> Thanks for the reviews!
>
>> There are two more occurences in this gpio-zynq driver.
>> zynq_gpio_resume, zynq_gpio_suspend. It wasn't detected because these
>> two lines are not together. But the same change can be applied for
Hi Michal,
Thanks for the reviews!
> There are two more occurences in this gpio-zynq driver.
> zynq_gpio_resume, zynq_gpio_suspend. It wasn't detected because these
> two lines are not together. But the same change can be applied for them too.
Not really. The rule would have matched if there was
Hi Wolfram,
On 19.4.2018 16:05, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
>
> Build tested only. buildbot is happy. Please apply individually.
>
> drivers/gpio/
On 04/19/2018 09:05 AM, Wolfram Sang wrote:
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
for gpio-omap.c:
Reviewed-by: Grygor
11 matches
Mail list logo