Hi Linus,
The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus
for you to fetch changes up to 660e1c2f47f51f5b03ea7f63fa11f000e0240bda:
Merge tag 'omap-for-v3.12/fixes-dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes (2013-09-18 14:01:39 -0700)
----------------------------------------------------------------
ARM: SoC fixes for 3.12-rc
A set of fixes for ARM platforms for 3.12. Among them:
- A fix for build breakage in the MTD subsystem for some PXA devices.
David Woodhouse has this patch in his for-next branch but has not been
responding to our requests to send it up so here it is.
I should have amended the commit message to describe the build failure for
CONFIG_OF=n setups, but forgot and now it's down in the stack of commits.
- Added device-tree for the BeagleBone Black. Turns out people have been
using the older "regualar" bone DT for the newer boards, and there's
risk of damaging hardware that way.
- Misc DT and regular fixes for OMAP.
- Fix to make the ST-Ericsson "snowball" boards boot with
multi_v7_defconfig, and enable one of the ST-E reference boards on the
same config.
- Kconfig cleanup for u300 to hide submenus when the platform isn't
enabled.
- Enable ARM_ATAG_DTB_COMPAT to let firmware override command
line when booting with an appended devicetree on non-DT-enabled
firmware (needed to boot snowball).
----------------------------------------------------------------
Andrea Adami (1):
ARM: sa1100: collie.c: fall back to jedec_probe flash detection
Anoop Thomas Mathew (1):
ARM: OMAP4 SMP: Corrected a typo fucntions to functions
Arnaud Patard (1):
ARM: imx51.dtsi: fix PATA device clock
Enric Balletbo i Serra (1):
ARM: dts: igep00x0: Add pinmux configuration for MCBSP2
Ezequiel Garcia (1):
mtd: nand: pxa3xx: Remove unneeded ifdef CONFIG_OF
Fabio Estevam (2):
ARM: mach-imx: clk-imx51-imx53: Fix 'spdif1_pred' clock registration
ARM: mach-omap2: gpmc: Fix warning when CONFIG_ARM_LPAE=y
Felipe Balbi (2):
ARM: dts: OMAP5: fix reg property size
ARM: dts: OMAP5: fix ocp2scp DTS data
Gwenhael Goavec-Merou (1):
ARM: imx27.dtsi: fix CSPI PER clock id
Huang Shijie (1):
ARM: dts: imx6q: fix the wrong offset of the Pad Mux register
Jason Liu (1):
ARM: imx: i.mx6d/q: disable the double linefill feature of PL310
Jingoo Han (1):
mailbox: remove unnecessary platform_set_drvdata()
Koen Kooi (1):
ARM: dts: am335x-bone*: add DT for BeagleBone Black
Linus Walleij (3):
ARM: ux500: disable outer cache debug
ARM: u300: hide submenus
ARM: multi_v7: add HREFv60 to multi_v7 defconfig
Olof Johansson (4):
ARM: multi_v7_defconfig: enable ARM_ATAG_DTB_COMPAT
Merge tag 'imx-fixes-3.12' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
Merge tag 'omap-for-v3.12/fixes-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes
Merge tag 'omap-for-v3.12/fixes-dt-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes
Phil Carmody (1):
ARM: OMAP2+: mux: fix trivial typo in name
Robert Nelson (1):
ARM: dts: omap3-beagle-xm: fix string error in compatible property
Shawn Guo (1):
ARM: imx: initialize clk_init_data.flags for clk-fixup-mux
Tony Lindgren (4):
ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for blaze
ARM: OMAP4: Fix clock_get error for GPMC during boot
Merge tag 'for_3.12-rc2/dts_signed' of git://git.kernel.org/.../bcousson/linux-omap-dt into omap-for-v3.12/fixes-dt
Vladimir Murzin (1):
ARM: OMAP4: cpuidle: fix: call cpu_cluster_pm_exit conditionally
Wei Yongjun (1):
ARM: OMAP: fix return value check in omap_device_build_from_dt()
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/am335x-bone-common.dtsi | 262 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/am335x-bone.dts | 256 +----------------------------
arch/arm/boot/dts/am335x-boneblack.dts | 17 ++
arch/arm/boot/dts/imx27.dtsi | 6 +-
arch/arm/boot/dts/imx51.dtsi | 2 +-
arch/arm/boot/dts/imx6q-pinfunc.h | 4 +-
arch/arm/boot/dts/omap3-beagle-xm.dts | 2 +-
arch/arm/boot/dts/omap3-igep.dtsi | 14 ++
arch/arm/boot/dts/omap4-panda-common.dtsi | 46 +++++-
arch/arm/boot/dts/omap4-sdp.dts | 39 ++++-
arch/arm/boot/dts/omap5.dtsi | 7 +-
arch/arm/configs/multi_v7_defconfig | 2 +
arch/arm/mach-imx/clk-fixup-mux.c | 1 +
arch/arm/mach-imx/clk-imx51-imx53.c | 2 +-
arch/arm/mach-imx/system.c | 11 ++
arch/arm/mach-omap2/cclock44xx_data.c | 2 +-
arch/arm/mach-omap2/cpuidle44xx.c | 2 +-
arch/arm/mach-omap2/gpmc.c | 4 +-
arch/arm/mach-omap2/mux34xx.c | 2 +-
arch/arm/mach-omap2/omap-smp.c | 2 +-
arch/arm/mach-omap2/omap_device.c | 2 +-
arch/arm/mach-sa1100/collie.c | 2 +-
arch/arm/mach-u300/Kconfig | 10 +-
arch/arm/mach-ux500/cache-l2x0.c | 1 +
drivers/mailbox/mailbox-omap2.c | 1 -
drivers/mtd/nand/pxa3xx_nand.c | 7 -
27 files changed, 418 insertions(+), 289 deletions(-)
create mode 100644 arch/arm/boot/dts/am335x-bone-common.dtsi
create mode 100644 arch/arm/boot/dts/am335x-boneblack.dts
On Thu, 2013-09-19 at 12:47 -0700, Olof Johansson wrote:
>
> - A fix for build breakage in the MTD subsystem for some PXA devices.
> David Woodhouse has this patch in his for-next branch but has not been
> responding to our requests to send it up so here it is.
> I should have amended the commit message to describe the build failure for
> CONFIG_OF=n setups, but forgot and now it's down in the stack of commits.
Thanks for pulling that in. Apologies for the screwup.
We were were working on a better way to fix the litter of #ifdef
CONFIG_OF which wasn't ready for the merge window so I just left this
one out since it *appeared* to be entirely cosmetic.
--
David Woodhouse Open Source Technology Centre
[email protected] Intel Corporation
On Thu, Sep 19, 2013 at 2:39 PM, Woodhouse, David
<[email protected]> wrote:
> On Thu, 2013-09-19 at 12:47 -0700, Olof Johansson wrote:
>>
>> - A fix for build breakage in the MTD subsystem for some PXA devices.
>> David Woodhouse has this patch in his for-next branch but has not been
>> responding to our requests to send it up so here it is.
>> I should have amended the commit message to describe the build failure for
>> CONFIG_OF=n setups, but forgot and now it's down in the stack of commits.
>
> Thanks for pulling that in. Apologies for the screwup.
No worries. You're a busy guy these days.
> We were were working on a better way to fix the litter of #ifdef
> CONFIG_OF which wasn't ready for the merge window so I just left this
> one out since it *appeared* to be entirely cosmetic.
Yeah, the real bug is a missing stub function in the #else case, but
if the ifdef is all going away there's no point in adding it.
The ifdeffery around the match tables is something that Mark Brown
brought up yesterday as well. With ACPI_PTR() and of_match_ptr() we at
least don't need the ifdefs in the struct device, but we do still need
it for the match tables.
-Olof
On Thu, Sep 19, 2013 at 2:39 PM, Woodhouse, David
<[email protected]> wrote:
> On Thu, 2013-09-19 at 12:47 -0700, Olof Johansson wrote:
>>
>> - A fix for build breakage in the MTD subsystem for some PXA devices.
>> David Woodhouse has this patch in his for-next branch but has not been
>> responding to our requests to send it up so here it is.
>> I should have amended the commit message to describe the build failure for
>> CONFIG_OF=n setups, but forgot and now it's down in the stack of commits.
>
> Thanks for pulling that in. Apologies for the screwup.
Speaking of such process issues: there's an outstanding patch for a
(small) memory leak that was introduced in the nand_base.c ONFI code
in 3.12-rc1. Can I expect you to attend to these sort of -rcX (where X
> 1) issues? Or should I send Linus the patch myself? I don't really
want it to wait around until 3.13-rc1 to go to -stable.
It's in l2-mtd.git (will need cherry-picked out of there) and ready
for the next linux-next:
commit b2bdf43fcc1d440d8f4e1d5c8c59bf2ca76204df
Author: Brian Norris <[email protected]>
Date: Mon Sep 16 17:59:20 2013 -0700
mtd: nand: fix memory leak in ONFI extended parameter page
Brian
On Thu, 2013-09-19 at 15:57 -0700, Brian Norris wrote:
> On Thu, Sep 19, 2013 at 2:39 PM, Woodhouse, David
> <[email protected]> wrote:
> > On Thu, 2013-09-19 at 12:47 -0700, Olof Johansson wrote:
> >>
> >> - A fix for build breakage in the MTD subsystem for some PXA devices.
> >> David Woodhouse has this patch in his for-next branch but has not been
> >> responding to our requests to send it up so here it is.
> >> I should have amended the commit message to describe the build failure for
> >> CONFIG_OF=n setups, but forgot and now it's down in the stack of commits.
> >
> > Thanks for pulling that in. Apologies for the screwup.
>
> Speaking of such process issues: there's an outstanding patch for a
> (small) memory leak that was introduced in the nand_base.c ONFI code
> in 3.12-rc1. Can I expect you to attend to these sort of -rcX (where X
> > 1) issues? Or should I send Linus the patch myself? I don't really
> want it to wait around until 3.13-rc1 to go to -stable.
I'm aware of it, and will get to it shortly. Was going to round it up
along with the one that Olof just sent, either some time this week at
Plumbers or when I get home.
If you want to stick it in the linux-mtd.git tree before that and send
Linus a pull request, I have no objection.
Does that m25p80 'fix 4 byte addressing' fix for Micron not also want to
go in?
--
Sent with MeeGo's ActiveSync support.
David Woodhouse Open Source Technology Centre
[email protected] Intel Corporation
On Thu, Sep 19, 2013 at 4:19 PM, Woodhouse, David
<[email protected]> wrote:
> On Thu, 2013-09-19 at 15:57 -0700, Brian Norris wrote:
>> On Thu, Sep 19, 2013 at 2:39 PM, Woodhouse, David
>> <[email protected]> wrote:
>> > On Thu, 2013-09-19 at 12:47 -0700, Olof Johansson wrote:
>> >>
>> >> - A fix for build breakage in the MTD subsystem for some PXA devices.
>> >> David Woodhouse has this patch in his for-next branch but has not been
>> >> responding to our requests to send it up so here it is.
>> >> I should have amended the commit message to describe the build failure for
>> >> CONFIG_OF=n setups, but forgot and now it's down in the stack of commits.
>> >
>> > Thanks for pulling that in. Apologies for the screwup.
>>
>> Speaking of such process issues: there's an outstanding patch for a
>> (small) memory leak that was introduced in the nand_base.c ONFI code
>> in 3.12-rc1. Can I expect you to attend to these sort of -rcX (where X
>> > 1) issues? Or should I send Linus the patch myself? I don't really
>> want it to wait around until 3.13-rc1 to go to -stable.
>
> I'm aware of it, and will get to it shortly. Was going to round it up
> along with the one that Olof just sent, either some time this week at
> Plumbers or when I get home.
>
> If you want to stick it in the linux-mtd.git tree before that and send
> Linus a pull request, I have no objection.
If you're up to it, then you can take it. I'll take it myself if I
feel it's getting too late. The problem is just when I can't
differentiate your quiet awareness from oblivion (or obliviousness?).
> Does that m25p80 'fix 4 byte addressing' fix for Micron not also want to
> go in?
I suppose the m25p80 one can go in as well. It's not so much a bugfix
as augmenting my original patch to support more devices. But it is
safe enough.
Brian
On Thu, 2013-09-19 at 17:44 -0700, Brian Norris wrote:
> > Does that m25p80 'fix 4 byte addressing' fix for Micron not also want to
> > go in?
>
> I suppose the m25p80 one can go in as well. It's not so much a bugfix
> as augmenting my original patch to support more devices. But it is
> safe enough.
You say 'support more devices', but AFAICT the code in -rc1 will already
*attempt* to enable 4-byte addressing on those devices, and fail.
(It looks like set_4byte() can return failure, but its return code isn't
checked, and anyway it's only a SPI write so there's no feedback from
the *chip* if it fails due to lack of WREN; it can only indicate failure
if the SPI connection falls over.)
So I'm inclined to think of it as a bug fix and include it.
--
David Woodhouse Open Source Technology Centre
[email protected] Intel Corporation
On Fri, Sep 27, 2013 at 3:59 AM, Woodhouse, David
<[email protected]> wrote:
> On Thu, 2013-09-19 at 17:44 -0700, Brian Norris wrote:
>> > Does that m25p80 'fix 4 byte addressing' fix for Micron not also want to
>> > go in?
>>
>> I suppose the m25p80 one can go in as well. It's not so much a bugfix
>> as augmenting my original patch to support more devices. But it is
>> safe enough.
>
> You say 'support more devices', but AFAICT the code in -rc1 will already
> *attempt* to enable 4-byte addressing on those devices, and fail.
As will the code in every release since 3.7-rc1 (commit
8da28681eb1430fb6715c7aef67001acfbbbcba5).
> (It looks like set_4byte() can return failure, but its return code isn't
> checked, and anyway it's only a SPI write so there's no feedback from
> the *chip* if it fails due to lack of WREN; it can only indicate failure
> if the SPI connection falls over.)
>
> So I'm inclined to think of it as a bug fix and include it.
Sure, it's a bug fix. Just a long-standing bug. We were sending
invalid commands to Micron devices, so no n25q256a devices could have
possibly been supported properly before the 3.12-rc cycle [*]. I'm not
sure who actually tested these flash way back in 3.7. I still would
qualify them as "new devices" for 3.12, but that's just semantics now.
Please, do include it.
Brian
[*] Under special circumstances they could have been supported. For
instance, some n25q256a packages defaulted to 4-byte addressing mode.
(Trimming CC list)
Hi David,
On Thu, Sep 19, 2013 at 4:19 PM, Woodhouse, David
<[email protected]> wrote:
> On Thu, 2013-09-19 at 15:57 -0700, Brian Norris wrote:
>> Speaking of such process issues: there's an outstanding patch for a
>> (small) memory leak that was introduced in the nand_base.c ONFI code
>> in 3.12-rc1. Can I expect you to attend to these sort of -rcX (where X
>> > 1) issues? Or should I send Linus the patch myself? I don't really
>> want it to wait around until 3.13-rc1 to go to -stable.
>
> I'm aware of it, and will get to it shortly. Was going to round it up
> along with the one that Olof just sent, either some time this week at
> Plumbers or when I get home.
I see that you have queued up some 3.12-rc patches in linux-mtd.git.
This is a reminder to send a pull request...
> If you want to stick it in the linux-mtd.git tree before that and send
> Linus a pull request, I have no objection.
...or else I will just send them myself within a week.
Thanks,
Brian