[PATCH 0/5] Minor fixes for Marvell Armada 38x SoC.

[PATCH 0/5] Minor fixes for Marvell Armada 38x SoC.

[Thomas Petazzoni]

Dear Marcin Wojtas,

On Thu, 13 Nov 2014 00:39:55 +0100, Marcin Wojtas wrote:
> This patchset adds minor fixes for Armada 38x SoC around SDHCI interface. It
> also enables usage of I2C char-device and adjusts ethernet aliases for
> bootloader's needs. Any feedback is welcome.
> 
> Marcin Wojtas (5):
>   ARM: mvebu: re-enable SDHCI driver for Armada 38x SoC in v7 defconfig
>   ARM: mvebu: enable no-1-8-v flag for Armada 385 DB SDHCI interface
>   ARM: mvebu: remove clock-frequency from Armada 38x SDHCI Device Tree
>     node
>   ARM: mvebu: adjust ethernet aliases according to U-Boot requirements
>     for A38x
>   ARM: mvebu: enable i2c device in mvebu_v7_defconfig

On the entire series, you forgot to Cc some of the mvebu maintainers,
namely Andrew Lunn and Sebastian Hesselbarth. I've added them in Cc of
the cover letter, so that they get notified about this patch series.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 0/5] Minor fixes for Marvell Armada 38x SoC.

[Andrew Lunn]

On Thu, Nov 13, 2014 at 09:02:49AM +0100, Thomas Petazzoni wrote:
> Dear Marcin Wojtas,
> 
> On Thu, 13 Nov 2014 00:39:55 +0100, Marcin Wojtas wrote:
> > This patchset adds minor fixes for Armada 38x SoC around SDHCI interface. It
> > also enables usage of I2C char-device and adjusts ethernet aliases for
> > bootloader's needs. Any feedback is welcome.
> > 
> > Marcin Wojtas (5):
> >   ARM: mvebu: re-enable SDHCI driver for Armada 38x SoC in v7 defconfig
> >   ARM: mvebu: enable no-1-8-v flag for Armada 385 DB SDHCI interface
> >   ARM: mvebu: remove clock-frequency from Armada 38x SDHCI Device Tree
> >     node
> >   ARM: mvebu: adjust ethernet aliases according to U-Boot requirements
> >     for A38x
> >   ARM: mvebu: enable i2c device in mvebu_v7_defconfig
> 
> On the entire series, you forgot to Cc some of the mvebu maintainers,
> namely Andrew Lunn and Sebastian Hesselbarth. I've added them in Cc of
> the cover letter, so that they get notified about this patch series.

Hi Marcin

I don't think the patches made it to linux-arm-kernel. And i cannot
find them with google.

You might need to repost them before i can review them.

    Andrew

[PATCH 1/5] ARM: mvebu: re-enable SDHCI driver for Armada 38x SoC in v7 defconfig

[Thomas Petazzoni]

Dear Marcin Wojtas,

On Thu, 13 Nov 2014 00:39:56 +0100, Marcin Wojtas wrote:
> In the recent update of mvebu_v7_defconfig a config that enables sdhci-pxav3
> driver, that supports SDHCI interface of Armada 38x SoC, disappeared.
> 
> This commit enables CONFIG_MMC_SDHCI_PXAV3 back.
> 
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Fixes fc9fa8714a75 ("ARM: mvebu: update v7 defconfig with useful options")

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 2/5] ARM: mvebu: enable no-1-8-v flag for Armada 385 DB SDHCI interface

[Thomas Petazzoni]

Dear Marcin Wojtas,

On Thu, 13 Nov 2014 00:39:57 +0100, Marcin Wojtas wrote:
> The Marvell Armada 38x SoC's SDHCI interface is capable of using 1.8v voltage,
> needed for driving "UHS-I" SD cards at their full speed. It is not, however,
> possible on the DB board. Due to physical connectivity connector supply is tied
> to 3v and any attempt of changing voltage in order to operate in the fastest UHS
> modes fails.
> 
> This patch enables equivalent SDHCI quirk in order to adjust controller
> operation to system capabilities.
> 
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 5/5] ARM: mvebu: enable i2c device in mvebu_v7_defconfig

[Thomas Petazzoni]

Dear Marcin Wojtas,

On Thu, 13 Nov 2014 00:40:00 +0100, Marcin Wojtas wrote:
> This commit enables user-space access to I2C bus using char device.
> 
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Even though not directly tied to HW capabilities, having userspace
access to I2C devices is quite useful in development-related defconfigs.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 4/5] ARM: mvebu: adjust ethernet aliases according to U-Boot requirements for A38x

[Thomas Petazzoni]

Dear Marcin Wojtas,

On Thu, 13 Nov 2014 00:39:59 +0100, Marcin Wojtas wrote:
> The vendor bootloader provided for Armada 38x boards expects an
> alias for the ethernet nodes, which is used to fixup the MAC address.
> The alias format naming is strict.

I believe this needs a bit more explanation: why would we care about
the "vendor bootloader" ? What are expecting the mainline versions of
popular bootloaders like U-Boot and Barebox ? What are other platforms
supported in the mainline doing ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[PATCH 4/5] ARM: mvebu: adjust ethernet aliases according to U-Boot requirements for A38x

[Marcin Wojtas]

+Andrew Lunn, Sebastian Hesselbarth

Dear Thomas,

2014-11-13 9:14 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Dear Marcin Wojtas,
>
> On Thu, 13 Nov 2014 00:39:59 +0100, Marcin Wojtas wrote:
>> The vendor bootloader provided for Armada 38x boards expects an
>> alias for the ethernet nodes, which is used to fixup the MAC address.
>> The alias format naming is strict.
>
> I believe this needs a bit more explanation: why would we care about
> the "vendor bootloader" ? What are expecting the mainline versions of
> popular bootloaders like U-Boot and Barebox ? What are other platforms
> supported in the mainline doing ?

In order to update MAC address entry in Device Tree both mainline U-Boot
(in function fdt_fixup_ethernet) and Barebox (in function eth_of_fixup)
accept same (and the only one) format of eth aliases, which is 'ethernetX',
where X stands for interface number.
Other platforms in the mainline Linux, that comprise ethernet references in
'/aliases' node (like various flavours of imx or sunXi), follow the naming
scheme described above.
Is this explanation sufficient? Do you think I should extend the commit log?

Best regards,
Marcin Wojtas

[PATCH 4/5] ARM: mvebu: adjust ethernet aliases according to U-Boot requirements for A38x

[Thomas Petazzoni]

Dear Marcin Wojtas,

On Thu, 13 Nov 2014 15:55:31 +0100, Marcin Wojtas wrote:

> 2014-11-13 9:14 GMT+01:00 Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com>:
> > Dear Marcin Wojtas,
> >
> > On Thu, 13 Nov 2014 00:39:59 +0100, Marcin Wojtas wrote:
> >> The vendor bootloader provided for Armada 38x boards expects an
> >> alias for the ethernet nodes, which is used to fixup the MAC address.
> >> The alias format naming is strict.
> >
> > I believe this needs a bit more explanation: why would we care about
> > the "vendor bootloader" ? What are expecting the mainline versions of
> > popular bootloaders like U-Boot and Barebox ? What are other platforms
> > supported in the mainline doing ?
> 
> In order to update MAC address entry in Device Tree both mainline U-Boot
> (in function fdt_fixup_ethernet) and Barebox (in function eth_of_fixup)
> accept same (and the only one) format of eth aliases, which is 'ethernetX',
> where X stands for interface number.

Yes, I know this, I had a look when I saw your patch.

> Other platforms in the mainline Linux, that comprise ethernet references in
> '/aliases' node (like various flavours of imx or sunXi), follow the naming
> scheme described above.
> Is this explanation sufficient? Do you think I should extend the commit log?

Yes, that's what I meant: in the commit log, taking as a justification
for the change a "vendor bootloader" is probably the worst possible
justification. Taking the mainline version of bootloaders and other
platforms supported in the kernel is a much stronger justification for
the change you're proposing.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com