* Mark Brown [171130 16:56]:
> On Thu, Nov 30, 2017 at 10:37:22AM -0600, Andrew F. Davis wrote:
> > On 11/30/2017 10:33 AM, Mark Brown wrote:
>
> > > It might make sense to pull in the relevant branches from ASoC first
> > > however IIRC the reset GPIO code currently does
* Mark Brown [171130 16:56]:
> On Thu, Nov 30, 2017 at 10:37:22AM -0600, Andrew F. Davis wrote:
> > On 11/30/2017 10:33 AM, Mark Brown wrote:
>
> > > It might make sense to pull in the relevant branches from ASoC first
> > > however IIRC the reset GPIO code currently does nothing useful anyway
On Thu, Nov 30, 2017 at 10:37:22AM -0600, Andrew F. Davis wrote:
> On 11/30/2017 10:33 AM, Mark Brown wrote:
> > It might make sense to pull in the relevant branches from ASoC first
> > however IIRC the reset GPIO code currently does nothing useful anyway so
> > it won't have any impact on
On Thu, Nov 30, 2017 at 10:37:22AM -0600, Andrew F. Davis wrote:
> On 11/30/2017 10:33 AM, Mark Brown wrote:
> > It might make sense to pull in the relevant branches from ASoC first
> > however IIRC the reset GPIO code currently does nothing useful anyway so
> > it won't have any impact on
On 11/30/2017 10:33 AM, Mark Brown wrote:
> On Thu, Nov 30, 2017 at 08:18:26AM -0800, Tony Lindgren wrote:
>
>> So it seems this and patch 8/8 are safe for me to pick separately?
>
> It might make sense to pull in the relevant branches from ASoC first
> however IIRC the reset GPIO code currently
On 11/30/2017 10:33 AM, Mark Brown wrote:
> On Thu, Nov 30, 2017 at 08:18:26AM -0800, Tony Lindgren wrote:
>
>> So it seems this and patch 8/8 are safe for me to pick separately?
>
> It might make sense to pull in the relevant branches from ASoC first
> however IIRC the reset GPIO code currently
On Thu, Nov 30, 2017 at 08:18:26AM -0800, Tony Lindgren wrote:
> So it seems this and patch 8/8 are safe for me to pick separately?
It might make sense to pull in the relevant branches from ASoC first
however IIRC the reset GPIO code currently does nothing useful anyway so
it won't have any
On Thu, Nov 30, 2017 at 08:18:26AM -0800, Tony Lindgren wrote:
> So it seems this and patch 8/8 are safe for me to pick separately?
It might make sense to pull in the relevant branches from ASoC first
however IIRC the reset GPIO code currently does nothing useful anyway so
it won't have any
* Andrew F. Davis [171129 17:16]:
> The correct DT property for specifying a GPIO used for reset
> is "reset-gpios", fix this here.
>
> Fixes: 4341881d0562 ("ARM: dts: Add devicetree for Gumstix Pepper board")
So it seems this and patch 8/8 are safe for me to pick separately?
* Andrew F. Davis [171129 17:16]:
> The correct DT property for specifying a GPIO used for reset
> is "reset-gpios", fix this here.
>
> Fixes: 4341881d0562 ("ARM: dts: Add devicetree for Gumstix Pepper board")
So it seems this and patch 8/8 are safe for me to pick separately?
Regards,
Tony
>
The correct DT property for specifying a GPIO used for reset
is "reset-gpios", fix this here.
Fixes: 4341881d0562 ("ARM: dts: Add devicetree for Gumstix Pepper board")
Signed-off-by: Andrew F. Davis
---
arch/arm/boot/dts/am335x-pepper.dts | 2 +-
1 file changed, 1 insertion(+), 1
The correct DT property for specifying a GPIO used for reset
is "reset-gpios", fix this here.
Fixes: 4341881d0562 ("ARM: dts: Add devicetree for Gumstix Pepper board")
Signed-off-by: Andrew F. Davis
---
arch/arm/boot/dts/am335x-pepper.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
12 matches
Mail list logo