Re: rt2x00: Kconfig symbols RALINK_RT288X and RALINK_RT305X

[Jonas Gorski]

On 13 March 2013 09:59, Paul Bolle  wrote:
> 0) Support for rt2800pci (or "the rt2860/rt3090 chipsets") was added in
> v2.6.33 (three years ago). References to the related Kconfig symbols
> RALINK_RT288X and RALINK_RT305X were introduced in that release. So were
> checks for their macros (CONFIG_RALINK_RT288X and CONFIG_RALINK_RT305X).
>
> 1) The Kconfig symbols themselves were never added in mainline. So these
> references and macros appear to be just markers for dead code in
> mainline, as that code will not be built.
>
> 2) This was previously discussed in
> https://lkml.org/lkml/2010/7/14/110 . The patch submitted in that
> message (which would remove all the dead code at the time) did not get
> applied.
>
> 3) What is the current status of the (out of tree) code that adds
> RALINK_RT288X and RALINK_RT305X?

They are now present in 3.9-rc1, see a0b0197c (more specifically
85639910..d3d2b420) :)

The actual accepted Kconfig symbol names are different though, so they
should be changed in rt2x00 to match them (SOC_RT288X and SOC_RT305X).


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rt2x00: Kconfig symbols RALINK_RT288X and RALINK_RT305X

[Jonas Gorski]

On 13 March 2013 11:03, Paul Bolle  wrote:
> On Wed, 2013-03-13 at 10:51 +0100, Jonas Gorski wrote:
>> The actual accepted Kconfig symbol names are different though, so they
>> should be changed in rt2x00 to match them (SOC_RT288X and SOC_RT305X).
>
> Thanks. Note that I could not find an actual Kconfig symbol SOC_RT288X!

Ah, yes, the inital submission only included RT305X support, not
RT288X (and neither of the newer chips). These will come later.

> Anyhow, I guess somebody has the (trivial) patch to convert
> RALINK_RT...X and CONFIG_RALINK_RT...X to their SOC_* equivalents queued
> for inclusion in v3.9-rcX. Is that correct?

Yes, that should be everything. John Crispin, anything missing from that?


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 04/25] MIPS: Netlogic: use ehci-platform driver

[Jonas Gorski]

On 3 October 2012 17:02, Florian Fainelli  wrote:
> Signed-off-by: Florian Fainelli 
> ---
>  arch/mips/netlogic/xlr/platform.c |6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/mips/netlogic/xlr/platform.c 
> b/arch/mips/netlogic/xlr/platform.c
> index 71b44d8..1731dfd 100644
> --- a/arch/mips/netlogic/xlr/platform.c
> +++ b/arch/mips/netlogic/xlr/platform.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -123,6 +124,10 @@ static u64 xls_usb_dmamask = ~(u32)0;
> },  \
> }
>
> +static struct usb_ehci_pdata xls_usb_ehci_pdata = {
> +   .caps_offset= 0,
> +};
> +
>  static struct platform_device xls_usb_ehci_device =
>  USB_PLATFORM_DEV("ehci-xls", 0, PIC_USB_IRQ);

Don't you also need to change this to "ehci-platform"?

>  static struct platform_device xls_usb_ohci_device_0 =
> @@ -172,6 +177,7 @@ int xls_platform_usb_init(void)
> memres = CPHYSADDR((unsigned long)usb_mmio);
> xls_usb_ehci_device.resource[0].start = memres;
> xls_usb_ehci_device.resource[0].end = memres + 0x400 - 1;
> +   xls_usb_ehci_device.dev.platform_data = &xls_usb_ehci_pdata;
>
> memres += 0x400;
> xls_usb_ohci_device_0.resource[0].start = memres;
> --
> 1.7.9.5

Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 20/25] MIPS: Netlogic: convert to use OHCI platform driver

[Jonas Gorski]

On 3 October 2012 17:03, Florian Fainelli  wrote:
> Signed-off-by: Florian Fainelli 
> ---
>  arch/mips/netlogic/xlr/platform.c |5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/mips/netlogic/xlr/platform.c 
> b/arch/mips/netlogic/xlr/platform.c
> index 320b7ef..755ddcc 100644
> --- a/arch/mips/netlogic/xlr/platform.c
> +++ b/arch/mips/netlogic/xlr/platform.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -129,6 +130,8 @@ static struct usb_ehci_pdata xls_usb_ehci_pdata = {
> .need_io_watchdog = 1,
>  };
>
> +static struct usb_ohci_pdata xls_usb_ohci_pdata;
> +
>  static struct platform_device xls_usb_ehci_device =
>  USB_PLATFORM_DEV("ehci-xls", 0, PIC_USB_IRQ);
>  static struct platform_device xls_usb_ohci_device_0 =

And change after the device names of the ohci devices to "ohci-platform"?

> @@ -183,10 +186,12 @@ int xls_platform_usb_init(void)
> memres += 0x400;
> xls_usb_ohci_device_0.resource[0].start = memres;
> xls_usb_ohci_device_0.resource[0].end = memres + 0x400 - 1;
> +   xls_usb_ohci_device_0.dev.platform_data = &xls_usb_ohci_pdata;
>
> memres += 0x400;
> xls_usb_ohci_device_1.resource[0].start = memres;
> xls_usb_ohci_device_1.resource[0].end = memres + 0x400 - 1;
> +   xls_usb_ohci_device_1.dev.platform_data = &xls_usb_ohci_pdata;
>
> return platform_add_devices(xls_platform_devices,
> ARRAY_SIZE(xls_platform_devices));
> --
> 1.7.9.5

Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] spi: make sure all transfer has bits_per_word set

[Jonas Gorski]

Hi,

On 9 November 2012 10:06, Laxman Dewangan  wrote:
> When spi client does the spi transfer and does not sets
> the bits_per_word for each transfer then set it as default
> of spi device in spi core before calling low level transfer.

I like that (not that it counts ... )!

> Removing the similar code from spi-tegra20-slink driver as
> it is not required.

Not sure if this should be part of *this* patch.
Also spi-tegra20-slink isn't the only one fixing up the bits_per_word
for transfers, so it would be nice if you could remove it from the
other drivers, too.

In a future patch, maybe even do the same with speed_hz?

Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] MIPS: BCM63XX: add initial Device Tree support

[Jonas Gorski]

On 12 November 2012 12:18, Maxime Bizon  wrote:
> On Sun, 2012-11-11 at 13:50 +0100, Jonas Gorski wrote:
>
>> This patch series adds initial Device Tree support to BCM63XX by adding
>> bindings for interrupts, GPIOs and clocks to Device Tree. Finally it adds
>> one "real" user, the serial driver, to the device tree boards.
>
>>  51 files changed, 1993 insertions(+), 392 deletions(-)
>
> I've already said what I think privately to you but I will do it again
>
> The bcm63xx code base is IMO quite clean. It does not suffer from code
> duplication, and god it would have taken far less time to write it the
> "bad" way.

The non-DT way of defining boards will not go away soon - see how all
changes are done with keeping "backward" compatibility in mind: I
don't remove the old device registration code, I don't remove any
fields from the board struct, I added compatibility dts for when there
is only a board struct, no board specific dts file.

> We have only *one* register file for all the SOCs, only the different
> bits are visible.
>
> We can even build a single kernel that support all SOCs/boards.

That's not going to change with Device Tree, and I'm trying my best to
keep this.

> So what's the *point* of this ?

Not having to update board_bcm963xx.{c,h} because some vendor decided
to add e.g. a previously unused gpio-bitbanged device. Not having to
modify the kernel but just attach a (externally build) dtb to the
kernel to support a new board. Ideally in the far future even using a
CFE provided dtb. I'm sure there are more reasons.

> You *cannot* abstract hardware, you just can't guess now what the next
> SOC peculiarity will be.

And nobody wants to do that. But - as Kevin already mentioned - it
would be nice if we get similar SoCs we already know about supported
with the same code; or at least , like BCM33xx, BCM68xx or maybe even
BCM7xxx (never looked at them, so I can't tell how viable that is).

>> Quoting your patch "BCM63XX: switch to common clock and Device Tree"
>
> +Required properties:
> +- compatible: one of
> +  a) "brcm,bcm63xx-clock"
> +  Standard BCM63XX clock.
>
> cool a nice abstraction, one register bit = one clock
>
> +  b) "brcm,bcm63xx-sar-clock"
> +  SAR/ATM clock, which requires a reset of the SAR/ATM block.
> +  c) "brcm,bcm63xx-enetsw-clock"
> +  Generic ethernet switch clock, which requires a reset of the block.
> +  d) "brcm,bcm6368-enetsw-clock"
> +  BCM6368 ethernet switch clock, which requires additional clocks to be
> +  enabled during reset.
>
> oops that abstraction did not fly because after enabling this particular
> clock on this SOC you also need to toggle other bits.

These special clocks are so that the original behaviour of the clocks
is kept.  I'd rather argue that the reset code does not belong into
the clock code, and is actually the responsibility of the driver. It
would make the clock code much simpler.

There will be exactly one consumer each for the enetsw/sar clocks; the
drivers themselves. And since the drivers itself aren't upstream yet,
it should be no problem modifying them to reset the cores instead of
relying on the clock code to do that for them. then we can implement
the reset call abstract enough so the entsw just expects a list of
clocks through DT that need to be enabled during reset - without
having to care about which exact clocks these are (and it will be zero
except for two SoCs).


What would you suggest? Please no "don't use Device Tree", as I don't
think we can avoid that. I'm struggling to find something you are fine
with.

> that list is going to get longer and longer and at the end won't mean 
> anything.

BCM681x needs additional special handling, yes, but that's it
currently. Neither BCM6362 nor BCM63168 have/need this. And there is
no problem adding new support code in the kernel as needed. Nobody
expects older kernels to work with newer SoCs. But as stated earlier,
older kernels should work with newer boards.

> and this is supposed to be a *STABLE* API
>
> We don't add syscall everyday, because we have to support them forever.
> Why would it be ok to add such abstractions that prevent further code
> refactoring because they are fixed in stone ?

I wouldn't treat this as stable until we got it into a satisfactory
state with everything supported. Heck, I wouldn't even treat this as
stable until Broadcom ships it in their SDKs to customers with CFEs
providing DTBs to the kernel.

What do you want to do, keep it out of the kernel until everything is
supported, working and "polished up", then posting a big patch bomb? I
don't think this will work well and will just cause pain for everyone.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] MIPS: BCM63XX: add Device Tree glue code for IRQ handling

[Jonas Gorski]

On 13 November 2012 06:00, Stephen Warren  wrote:
> On 11/11/2012 05:50 AM, Jonas Gorski wrote:
>> Register IRQ domains through Device Tree for the internal and external
>> interrupt controllers. Register the same IRQ ranges as previously to
>> provide backward compatibility for non-DT drivers.
>
>> diff --git a/Documentation/devicetree/bindings/mips/bcm63xx/epic.txt 
>> b/Documentation/devicetree/bindings/mips/bcm63xx/epic.txt
>
> Rather than putting binding docs in an arch-specific directory, perhaps
> put them into a device-type-specific directory, such as
> bindings/interrupt-controller/brcm,bcm63xx-epic.txt?

Almost everyone has their interrupt-controller bindings in
$arch/$platform, but if interrupt-controller is the preferred
location, I can certainly move it there; I have no hard preference for
any location.

>
>> +- #interrupt-cells: <2>
>> +  This controller supports level and edge triggered interrupts. The
>> +  first cell is the interrupt number, the second is a 1:1 mapping to
>> +  the linux interrupt flags.
>
> The DT documentation should be self-contained, and not reference
> anything OS-specific. In this case, you could reference
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> for the interrupt flags.

Good Idea, I'll do that for the next iteration.

>> diff --git a/arch/mips/bcm63xx/dts/bcm6328.dtsi 
>> b/arch/mips/bcm63xx/dts/bcm6328.dtsi
>
>>   ranges = <0 0x1000 0x2>;
>>   compatible = "simple-bus";
>> +
>> + interrupt-parent = <&ipic>;
>> +
>> + perf@0 {
>> + epic: interrupt-controller@18 {
>
> Don't you need some reg properties in the perf and interrupt-controller
> nodes so that the register address can be determined?

Since there is no support code for that property yet I did not add it.
I haven't quite finished yet how the final bindings will be (since
there are/were a few things I haven't finished researching yet, e.g.
how this controller works in SMP context, and how interrupt
controllers are supposed to work).

I can add all expected properties now and add support for them later,
but I feel that this might add properties that will then never
supported, and nobody updates the documentation for that, so I'd
rather like to keep the documentation/dts(i) in sync with what the
actual code expects/supports.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] MIPS: BCM63XX: add Device Tree clock definitions

[Jonas Gorski]

On 13 November 2012 06:02, Stephen Warren  wrote:
> On 11/11/2012 05:50 AM, Jonas Gorski wrote:
>> Add definitions for the clocks found and used in all supported SoCs.
>
>> diff --git a/arch/mips/bcm63xx/dts/bcm6328.dtsi 
>> b/arch/mips/bcm63xx/dts/bcm6328.dtsi
>
>> + clocks {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + periph: pll {
>> + compatible = "brcm,bcm63xx-clock";
>> + #clock-cells = <0>;
>> + clock-frequency = <5000>;
>> + clock-output-names = "periph";
>> + };
>
> Here too, it seems like some reg properties would be required.

This is more or less a dummy clock with no real backing for it, but
some of the drivers expect this clock to be present (even just to get
the frequency).


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] MIPS: BCM63XX: switch to common clock and Device Tree

[Jonas Gorski]

On 13 November 2012 06:04, Stephen Warren  wrote:
> On 11/11/2012 05:50 AM, Jonas Gorski wrote:
>> Switch BCM63XX to the common clock framework and use clkdev for
>> providing clock name lookups for non-DT devices.
>>
>> Clocks can have a frequency and gate-bit, or none, in case they
>> are just provided for drivers expecting them to be present.
>
>> diff --git a/Documentation/devicetree/bindings/clock/bcm63xx-clock.txt 
>> b/Documentation/devicetree/bindings/clock/bcm63xx-clock.txt
>
> A very minor nit, but it might be nice to add the DT binding
> documentation before (or as part of) the patches that use them (code
> that parses them, or using the bindings in .dts files)
>
> Of course, I'm relying on my email receive order, to judge this since
> the patch numbering didn't come through, so perhaps the patches are
> already set up this way...

No you are right, the bindings are being added earlier. I move it to
the patch adding the (then still unused) binding to the dts(i) files.
I'd rather not split it up completely, and add it with the binding
usage together so it's easier to spot if I do something with the
bindings that contradicts the documentation or is missing ;-).


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] MIPS: BCM63XX: register GPIO controller through Device Tree

[Jonas Gorski]

On 13 November 2012 06:06, Stephen Warren  wrote:
> On 11/11/2012 05:50 AM, Jonas Gorski wrote:
>> Register the GPIO controller through Device Tree and add the
>> appropriate values in the include files.
>>
>> Since we can't register a platform driver at this early stage move the
>> direct call to bcm63xx_gpio_init from prom_init to an arch initcall.
>
>> diff --git a/Documentation/devicetree/bindings/gpio/bcm63xx-gpio.txt 
>> b/Documentation/devicetree/bindings/gpio/bcm63xx-gpio.txt
>
>> +- #gpio-cells: Must be <2>. The first cell is the GPIO pin, and
>> +  the second one the standard linux flags.
>
> Also here, I think you want to explicitly document the flag values here
> so the bindings don't rely on the Linux kernel code. I don't think
> there's a standard central file which documents them though, although I
> vaguely recall some discussion to create add them to gpio.txt?

I'll add some more description. And yes there isn't, and I can't
comment about that since I just joined devicetree-discuss a few days
ago. It would be nice to have them there. Maybe I'll add a reference
to gpio.txt and see if I can come up with an acceptable description
for the flags.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] MIPS: BCM63XX: add empty Device Trees for all supported boards

[Jonas Gorski]

On 13 November 2012 06:12, Stephen Warren  wrote:
> On 11/11/2012 05:50 AM, Jonas Gorski wrote:
>> Add empty board files for all boards supported by the legacy board
>> support.
>
>> diff --git a/arch/mips/bcm63xx/dts/96328avng.dts 
>> b/arch/mips/bcm63xx/dts/96328avng.dts
>
>> +/ {
>> + model = "96328avng";
>> + compatible = "96328avng";
>
> The board should be compatible with both the board name and the SoC on
> the board. I know that right now the MIPS code is choosing the DT to use
> based on the board name, but I think it's more typical to pass an
> explicit DT to the kernel, and then choose the kernel support to execute
> based on the compatible value (certainly this is the case on ARM and I
> assume other architectures too). That would require the DT content to
> include the SoC name in the compatible property, so that the kernel
> support didn't then need to contain a table of all supported board names.

I'll add the SoC name to the compatible line.

>> + ubus@1000 {
>> +
>> + };
>
> Do you need to include this empty node in each file? I guess it gets
> added to in the next patch so it's not a big deal though.

It's just there so it is already present when adding blocks to it. It
is/was mainly for making reordering patches easier.

>
>> diff --git a/arch/mips/bcm63xx/dts/Kconfig b/arch/mips/bcm63xx/dts/Kconfig
>
>> +config BOARD_96328AVNG
>> + bool "96328avng reference board"
>> + select BCM63XX_CPU_6328
>
> Why not simply compile all DTs whenever the SoC support is enabled? I
> suppose you're trying to avoid packing all the DTs into the kernel
> image. Does it make more sense to amend the MIPS kernel boot process so
> that a single user-/firmware-selected DT is passed to the kernel, rather
> than packing the DTs into the kernel and selecting one?

The plan is to add support for an externally attached DT (but not
present yet), and eventually add support for a bootloader passed DT,
but since I don't know yet how these will work, I didn't want to add
something based on guesses.

My reasoning for allowing (de-)selecting each board is to dampen the
bloat from the dtbs - after these few blocks the combined dtbs are
already four times as large as the old board setup code including all
boards. Especially older devices are constrained to 4 or even 2 MB
flash, so every kB counts there.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] MIPS: BCM63XX: add initial Device Tree support

[Jonas Gorski]

This patch series adds initial Device Tree support to BCM63XX by adding
bindings for interrupts, GPIOs and clocks to Device Tree. Finally it adds
one "real" user, the serial driver, to the device tree boards.

The main intention of this patch series is to make the transition to
device tree as smooth as possible by retaining backward compatibility
with not yet DT enabled drivers. Also to reduce the number of potential
regressions I tried to make the changes as small as possible. The resulting
code has therefore still a lot of room for improvement.

The first patches add support for loading kernel embedded DTBs, and
add generic fallback DTSs for boards not yet having a DTS.

Next the IRQ controllers get registered through device tree.

The next set prepares all bcm63xx drivers using clocks for switching to
the generic clock framework, add bindings for the clocks present, then
replaces the custom implementation with one using the common clock
framework.

Last of the generic controllers the GPIO controller is converted to
Device Tree. This is more of an interim solution, as I plan to replace
the driver with a proper pinctrl driver in the future.

Finally, to have a user for some of this, I added support for
registering the serial console through device tree and added appropriate
board files for all currently supported boards.

These patches have been tested on BCM6348, BCM6358, BCM6368 and BCM6328, but
still need to be tested on BCM6338 and BCM6345.

The next steps after this will be:
 * convert the reminder of the device drivers and PCI(e) and pccard
   controllers to device tree support
 * improve the device tree bindings of currently registered devices
 * replace the GPIO controller driver with a pinctrl implementation

This patch series is based on Ralf's upstream-sfr mips tree. My hope is
that these changes eventually go through Ralf's tree instead of through each
subsystem's tree, to make the switch less slow.

Jonas Gorski (15):
  MIPS: BCM63XX: add support for loading DTB
  MIPS: BCM63XX: add simple Device Tree includes for all SoCs
  MIPS: BCM63XX: add generic fallback device trees
  MIPS: BCM63XX: add Device Tree glue code for IRQ handling
  SPI: spi-bcm63xx: use clk_{prepare_enable,disable_unprepare}
  bcm63xx-rng: use clk_{prepare_enable,disable_unprepare}
  net: ethernet: bcm63xx_enet: use
clk_{prepare_enable,disable_unprepare}
  serial: bcm63xx_uart: remove unnecessary include
  MIPS: BCM63XX: add Device Tree clock definitions
  MIPS: BCM63XX: switch to common clock and Device Tree
  MIPS: BCM63XX: register GPIO controller through Device Tree
  serial: bcm63xx_uart: allow probing through Device Tree
  MIPS: BCM63XX: add serial blocks to Device Tree includes
  MIPS: BCM63XX: add empty Device Trees for all supported boards
  MIPS: BCM63XX: enable serial through Device Tree

 .../devicetree/bindings/clock/bcm63xx-clock.txt|   32 ++
 .../devicetree/bindings/gpio/bcm63xx-gpio.txt  |   24 ++
 .../devicetree/bindings/mips/bcm63xx/epic.txt  |   20 ++
 .../devicetree/bindings/mips/bcm63xx/ipic.txt  |   18 +
 .../bindings/tty/serial/bcm63xx-uart.txt   |   17 +
 arch/mips/Kconfig  |4 +-
 arch/mips/bcm63xx/Kconfig  |2 +
 arch/mips/bcm63xx/Makefile |8 +-
 arch/mips/bcm63xx/boards/board_bcm963xx.c  |   15 -
 arch/mips/bcm63xx/clk.c|  331 
 arch/mips/bcm63xx/dts/96328avng.dts|   25 ++
 arch/mips/bcm63xx/dts/96338gw.dts  |   25 ++
 arch/mips/bcm63xx/dts/96338w.dts   |   25 ++
 arch/mips/bcm63xx/dts/96345gw2.dts |   25 ++
 arch/mips/bcm63xx/dts/96348gw.dts  |   25 ++
 arch/mips/bcm63xx/dts/96348gw_10.dts   |   25 ++
 arch/mips/bcm63xx/dts/96348gw_11.dts   |   25 ++
 arch/mips/bcm63xx/dts/96348gw_a.dts|   25 ++
 arch/mips/bcm63xx/dts/96348r.dts   |   25 ++
 arch/mips/bcm63xx/dts/96358vw.dts  |   25 ++
 arch/mips/bcm63xx/dts/96358vw2.dts |   26 ++
 arch/mips/bcm63xx/dts/Kconfig  |   67 
 arch/mips/bcm63xx/dts/Makefile |   28 ++
 arch/mips/bcm63xx/dts/agpf_s0.dts  |   22 ++
 arch/mips/bcm63xx/dts/bcm6328.dtsi |  158 ++
 arch/mips/bcm63xx/dts/bcm6338.dtsi |  108 +++
 arch/mips/bcm63xx/dts/bcm6345.dtsi |   94 ++
 arch/mips/bcm63xx/dts/bcm6348.dtsi |  115 +++
 arch/mips/bcm63xx/dts/bcm6358.dtsi |  156 +
 arch/mips/bcm63xx/dts/bcm6368.dtsi |  196 
 arch/mips/bcm63xx/dts/bcm96328_generic.dts |   21 ++
 arch/mips/bcm63xx/dts/bcm96338_generic.dts |   21 ++
 arch/mips/bcm63xx/dts/bcm96345_generic.dts |   21 ++
 arch/mips/bcm63xx/dts/bcm96348_g

[RFC] MIPS: BCM63XX: add generic fallback device trees

[Jonas Gorski]

Add generic fallback device trees to load if there is no specific
device tree for the board available. This ensures that always present
devices like interrupt controllers are always available.

Signed-off-by: Jonas Gorski 
---
 arch/mips/bcm63xx/dts/Makefile |8 
 arch/mips/bcm63xx/dts/bcm96328_generic.dts |   21 +
 arch/mips/bcm63xx/dts/bcm96338_generic.dts |   21 +
 arch/mips/bcm63xx/dts/bcm96345_generic.dts |   21 +
 arch/mips/bcm63xx/dts/bcm96348_generic.dts |   21 +
 arch/mips/bcm63xx/dts/bcm96358_generic.dts |   21 +
 arch/mips/bcm63xx/dts/bcm96368_generic.dts |   21 +
 arch/mips/bcm63xx/setup.c  |   17 +++--
 8 files changed, 145 insertions(+), 6 deletions(-)
 create mode 100644 arch/mips/bcm63xx/dts/bcm96328_generic.dts
 create mode 100644 arch/mips/bcm63xx/dts/bcm96338_generic.dts
 create mode 100644 arch/mips/bcm63xx/dts/bcm96345_generic.dts
 create mode 100644 arch/mips/bcm63xx/dts/bcm96348_generic.dts
 create mode 100644 arch/mips/bcm63xx/dts/bcm96358_generic.dts
 create mode 100644 arch/mips/bcm63xx/dts/bcm96368_generic.dts

diff --git a/arch/mips/bcm63xx/dts/Makefile b/arch/mips/bcm63xx/dts/Makefile
index 69c374b..94d1057 100644
--- a/arch/mips/bcm63xx/dts/Makefile
+++ b/arch/mips/bcm63xx/dts/Makefile
@@ -1,2 +1,10 @@
+# generic fallback boards
+obj-$(CONFIG_BCM63XX_CPU_6328) += bcm96328_generic.dtb.o
+obj-$(CONFIG_BCM63XX_CPU_6338) += bcm96338_generic.dtb.o
+obj-$(CONFIG_BCM63XX_CPU_6345) += bcm96345_generic.dtb.o
+obj-$(CONFIG_BCM63XX_CPU_6348) += bcm96348_generic.dtb.o
+obj-$(CONFIG_BCM63XX_CPU_6358) += bcm96358_generic.dtb.o
+obj-$(CONFIG_BCM63XX_CPU_6368) += bcm96368_generic.dtb.o
+
 $(obj)/%.dtb: $(obj)/%.dts
$(call if_changed,dtc)
diff --git a/arch/mips/bcm63xx/dts/bcm96328_generic.dts 
b/arch/mips/bcm63xx/dts/bcm96328_generic.dts
new file mode 100644
index 000..13cdc48
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/bcm96328_generic.dts
@@ -0,0 +1,21 @@
+/dts-v1/;
+
+/*
+ * Fallback Device Tree Source for Broadcom BCM6328 based boards
+ *
+ * Copyright (C) 2012 Jonas Gorski 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "bcm6328.dtsi"
+
+/ {
+   model = "Generic BCM6328 board";
+   compatible = "bcm96328-generic";
+
+   ubus@1000 {
+   };
+};
diff --git a/arch/mips/bcm63xx/dts/bcm96338_generic.dts 
b/arch/mips/bcm63xx/dts/bcm96338_generic.dts
new file mode 100644
index 000..3b4e7b0
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/bcm96338_generic.dts
@@ -0,0 +1,21 @@
+/dts-v1/;
+
+/*
+ * Fallback Device Tree Source for Broadcom BCM6338 based boards
+ *
+ * Copyright (C) 2012 Jonas Gorski 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "bcm6338.dtsi"
+
+/ {
+   model = "Generic BCM6338 board";
+   compatible = "bcm96338-generic";
+
+   ubus@fffe {
+   };
+};
diff --git a/arch/mips/bcm63xx/dts/bcm96345_generic.dts 
b/arch/mips/bcm63xx/dts/bcm96345_generic.dts
new file mode 100644
index 000..2bbf69e
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/bcm96345_generic.dts
@@ -0,0 +1,21 @@
+/dts-v1/;
+
+/*
+ * Fallback Device Tree Source for Broadcom BCM6345 based boards
+ *
+ * Copyright (C) 2012 Jonas Gorski 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "bcm6345.dtsi"
+
+/ {
+   model = "Generic BCM6345 board";
+   compatible = "bcm96345-generic";
+
+   ubus@fffe {
+   };
+};
diff --git a/arch/mips/bcm63xx/dts/bcm96348_generic.dts 
b/arch/mips/bcm63xx/dts/bcm96348_generic.dts
new file mode 100644
index 000..d3c21a9
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/bcm96348_generic.dts
@@ -0,0 +1,21 @@
+/dts-v1/;
+
+/*
+ * Fallback Device Tree Source for Broadcom BCM6348 based boards
+ *
+ * Copyright (C) 2012 Jonas Gorski 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "bcm6348.dtsi"
+
+/ {
+   model = "Generic BCM6348 board";
+   compatible = "bcm96348-generic";
+
+   ubus@fffe {
+   };
+};
diff --git a/arch/mips/bcm63xx/dts/bcm96358_generic.dts 
b/arch/mips/bcm63xx/dts/bcm96358_gener

[RFC] net: ethernet: bcm63xx_enet: use clk_{prepare_enable,disable_unprepare}

[Jonas Gorski]

Use proper clk_prepare/unprepare calls in preparation for switching to
the generic clock framework.

Signed-off-by: Jonas Gorski 
---
 drivers/net/ethernet/broadcom/bcm63xx_enet.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c 
b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index c7ca7ec..9449e13 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -1677,7 +1677,7 @@ static int __devinit bcm_enet_probe(struct 
platform_device *pdev)
ret = PTR_ERR(priv->mac_clk);
goto out_unmap;
}
-   clk_enable(priv->mac_clk);
+   clk_prepare_enable(priv->mac_clk);
 
/* initialize default and fetch platform data */
priv->rx_ring_size = BCMENET_DEF_RX_DESC;
@@ -1706,7 +1706,7 @@ static int __devinit bcm_enet_probe(struct 
platform_device *pdev)
priv->phy_clk = NULL;
goto out_put_clk_mac;
}
-   clk_enable(priv->phy_clk);
+   clk_prepare_enable(priv->phy_clk);
}
 
/* do minimal hardware init to be able to probe mii bus */
@@ -1808,12 +1808,12 @@ out_uninit_hw:
/* turn off mdc clock */
enet_writel(priv, 0, ENET_MIISC_REG);
if (priv->phy_clk) {
-   clk_disable(priv->phy_clk);
+   clk_disable_unprepare(priv->phy_clk);
clk_put(priv->phy_clk);
}
 
 out_put_clk_mac:
-   clk_disable(priv->mac_clk);
+   clk_disable_unprepare(priv->mac_clk);
clk_put(priv->mac_clk);
 
 out_unmap:
@@ -1864,10 +1864,10 @@ static int __devexit bcm_enet_remove(struct 
platform_device *pdev)
 
/* disable hw block clocks */
if (priv->phy_clk) {
-   clk_disable(priv->phy_clk);
+   clk_disable_unprepare(priv->phy_clk);
clk_put(priv->phy_clk);
}
-   clk_disable(priv->mac_clk);
+   clk_disable_unprepare(priv->mac_clk);
clk_put(priv->mac_clk);
 
platform_set_drvdata(pdev, NULL);
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] MIPS: BCM63XX: switch to common clock and Device Tree

[Jonas Gorski]

Switch BCM63XX to the common clock framework and use clkdev for
providing clock name lookups for non-DT devices.

Clocks can have a frequency and gate-bit, or none, in case they
are just provided for drivers expecting them to be present.

Signed-off-by: Jonas Gorski 
---
 .../devicetree/bindings/clock/bcm63xx-clock.txt|   32 ++
 arch/mips/Kconfig  |3 +-
 arch/mips/bcm63xx/Makefile |7 +-
 arch/mips/bcm63xx/clk.c|  331 
 arch/mips/include/asm/mach-bcm63xx/bcm63xx_clk.h   |   11 -
 drivers/clk/Makefile   |1 +
 drivers/clk/clk-bcm63xx.c  |  241 ++
 7 files changed, 279 insertions(+), 347 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/bcm63xx-clock.txt
 delete mode 100644 arch/mips/bcm63xx/clk.c
 delete mode 100644 arch/mips/include/asm/mach-bcm63xx/bcm63xx_clk.h
 create mode 100644 drivers/clk/clk-bcm63xx.c

diff --git a/Documentation/devicetree/bindings/clock/bcm63xx-clock.txt 
b/Documentation/devicetree/bindings/clock/bcm63xx-clock.txt
new file mode 100644
index 000..467c0c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/bcm63xx-clock.txt
@@ -0,0 +1,32 @@
+* Broadcom BCM63XX Clock bindings
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible: one of
+  a) "brcm,bcm63xx-clock"
+  Standard BCM63XX clock.
+  b) "brcm,bcm63xx-sar-clock"
+  SAR/ATM clock, which requires a reset of the SAR/ATM block.
+  c) "brcm,bcm63xx-enetsw-clock"
+  Generic ethernet switch clock, which requires a reset of the block.
+  d) "brcm,bcm6368-enetsw-clock"
+  BCM6368 ethernet switch clock, which requires additional clocks to be
+  enabled during reset.
+
+Optional properties:
+- brcm,gate-bit: gate bit in the clock control register.
+
+- clock-frequency: frequency of this clock.
+
+Example:
+
+   hsspi: clock@9 {
+   compatible = "brcm,bcm63xx-clock";
+   #clock-cells = <0>;
+   clock-output-names = "hsspi";
+   brcm,gate-bit = <9>;
+   clock-frequency = <1>;
+   };
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 168b0fc..1203113 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -131,7 +131,8 @@ config BCM63XX
select SYS_HAS_EARLY_PRINTK
select SWAP_IO_SPACE
select ARCH_REQUIRE_GPIOLIB
-   select HAVE_CLK
+   select COMMON_CLK
+   select CLKDEV
select USE_OF
help
 Support for BCM63XX based boards
diff --git a/arch/mips/bcm63xx/Makefile b/arch/mips/bcm63xx/Makefile
index 30971a7..994893c 100644
--- a/arch/mips/bcm63xx/Makefile
+++ b/arch/mips/bcm63xx/Makefile
@@ -1,7 +1,6 @@
-obj-y  += clk.o cpu.o cs.o gpio.o irq.o nvram.o prom.o reset.o \
-  setup.o timer.o dev-dsp.o dev-enet.o dev-flash.o \
-  dev-pcmcia.o dev-rng.o dev-spi.o dev-uart.o dev-wdt.o \
-  dev-usb-usbd.o
+obj-y  += cpu.o cs.o gpio.o irq.o nvram.o prom.o reset.o setup.o \
+  timer.o dev-dsp.o dev-enet.o dev-flash.o dev-pcmcia.o \
+  dev-rng.o dev-spi.o dev-uart.o dev-wdt.o dev-usb-usbd.o
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 
 obj-y  += boards/
diff --git a/arch/mips/bcm63xx/clk.c b/arch/mips/bcm63xx/clk.c
deleted file mode 100644
index b9e948d..000
--- a/arch/mips/bcm63xx/clk.c
+++ /dev/null
@@ -1,331 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 2008 Maxime Bizon 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-static DEFINE_MUTEX(clocks_mutex);
-
-
-static void clk_enable_unlocked(struct clk *clk)
-{
-   if (clk->set && (clk->usage++) == 0)
-   clk->set(clk, 1);
-}
-
-static void clk_disable_unlocked(struct clk *clk)
-{
-   if (clk->set && (--clk->usage) == 0)
-   clk->set(clk, 0);
-}
-
-static void bcm_hwclock_set(u32 mask, int enable)
-{
-   u32 reg;
-
-   reg = bcm_perf_readl(PERF_CKCTL_REG);
-   if (enable)
-   reg |= mask;
-   else
-   reg &= ~mask;
-   bcm_perf_writel(reg, PERF_CKCTL_REG);
-}
-
-/*
- * Ethernet MAC "misc" clock: dma clocks and main clock on 6348
- */
-static void enet_misc_set(struct clk *clk, int enable)
-{
-   u32 mask;
-
-   if (BCMCPU_IS_6338())
-   mask = CKCTL_6338_ENET_EN;
-   else if (BCMCPU_IS_6345())
-   mask = CKCTL_6345_ENET_EN;
-   else if (BCMCPU_IS_6348())

[RFC] MIPS: BCM63XX: add Device Tree clock definitions

[Jonas Gorski]

Add definitions for the clocks found and used in all supported SoCs.

Signed-off-by: Jonas Gorski 
---
 arch/mips/bcm63xx/dts/bcm6328.dtsi |   90 ++
 arch/mips/bcm63xx/dts/bcm6338.dtsi |   47 +
 arch/mips/bcm63xx/dts/bcm6345.dtsi |   33 ++
 arch/mips/bcm63xx/dts/bcm6348.dtsi |   54 +++
 arch/mips/bcm63xx/dts/bcm6358.dtsi |   85 
 arch/mips/bcm63xx/dts/bcm6368.dtsi |  125 
 6 files changed, 434 insertions(+), 0 deletions(-)

diff --git a/arch/mips/bcm63xx/dts/bcm6328.dtsi 
b/arch/mips/bcm63xx/dts/bcm6328.dtsi
index a41033a..9055187 100644
--- a/arch/mips/bcm63xx/dts/bcm6328.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6328.dtsi
@@ -41,6 +41,96 @@
interrupt-controller;
#interrupt-cells = <1>;
};
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   periph: pll {
+   compatible = "brcm,bcm63xx-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5000>;
+   clock-output-names = "periph";
+   };
+
+   phymips: clock@0 {
+   compatible = "brcm,bcm63xx-clock";
+   #clock-cells = <0>;
+   clock-output-names = "phymips";
+   brcm,gate-bit = <0>;
+   };
+
+   adsl_qproc: clock@1 {
+   compatible = "brcm,bcm63xx-clock";
+   #clock-cells = <0>;
+   clock-output-names = "adsl-qproc";
+   brcm,gate-bit = <1>;
+   };
+
+   adsl_afe: clock@2 {
+   compatible = "brcm,bcm63xx-clock";
+   #clock-cells = <0>;
+   clock-output-names = "adsl-afe";
+   brcm,gate-bit = <2>;
+   };
+
+   adsl: clock@3 {
+   compatible = "brcm,bcm63xx-clock";
+   #clock-cells = <0>;
+   clock-output-names = "adsl";
+   brcm,gate-bit = <3>;
+   };
+
+   sar: clock@5 {
+   compatible = "brcm,bcm63xx-clock";
+   #clock-cells = <0>;
+   clock-output-names = "sar", "xtm";
+   brcm,gate-bit = <5>;
+   };
+
+   pcm: clock@6 {
+   compatible = "brcm,bcm63xx-clock";
+   #clock-cells = <0>;
+   clock-output-names = "pcm";
+   brcm,gate-bit = <6>;
+   };
+
+   usbd: clock@7 {
+   compatible = "brcm,bcm63xx-clock";
+   #clock-cells = <0>;
+   clock-output-names = "usbd";
+   brcm,gate-bit = <7>;
+   };
+
+   usbh: clock@8 {
+   compatible = "brcm,bcm63xx-clock";
+   #clock-cells = <0>;
+   clock-output-names = "usbh";
+   brcm,gate-bit = <8>;
+   };
+
+   hsspi: clock@9 {
+   compatible = "brcm,bcm63xx-clock";
+   #clock-cells = <0>;
+   clock-output-names = "hsspi";
+   clock-frequency = <1>;
+   brcm,gate-bit = <9&

[RFC] serial: bcm63xx_uart: allow probing through Device Tree

[Jonas Gorski]

Add support for probing the serial ports through Device Tree.

Signed-off-by: Jonas Gorski 
---
 .../bindings/tty/serial/bcm63xx-uart.txt   |   17 +
 drivers/tty/serial/bcm63xx_uart.c  |   35 ++--
 2 files changed, 42 insertions(+), 10 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/tty/serial/bcm63xx-uart.txt

diff --git a/Documentation/devicetree/bindings/tty/serial/bcm63xx-uart.txt 
b/Documentation/devicetree/bindings/tty/serial/bcm63xx-uart.txt
new file mode 100644
index 000..7623604
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/bcm63xx-uart.txt
@@ -0,0 +1,17 @@
+* Broadcom BCM63XX UART
+
+Required properties:
+- compatible: "brcm,bcm63xx-uart"
+  Compatible with all BCM63XX SoCs.
+
+- reg: address and length of the register block.
+
+- interrupts: the uart's interrupt number.
+
+Example:
+
+   uart0: serial@100 {
+   compatible = "brcm,bcm63xx";
+   reg = <0x100 0x18>;
+   interrupts = <2>;
+   };
diff --git a/drivers/tty/serial/bcm63xx_uart.c 
b/drivers/tty/serial/bcm63xx_uart.c
index 0187aff..4521a52 100644
--- a/drivers/tty/serial/bcm63xx_uart.c
+++ b/drivers/tty/serial/bcm63xx_uart.c
@@ -802,23 +802,32 @@ static struct uart_driver bcm_uart_driver = {
  */
 static int __devinit bcm_uart_probe(struct platform_device *pdev)
 {
-   struct resource *res_mem, *res_irq;
+   struct resource *res_mem;
struct uart_port *port;
struct clk *clk;
-   int ret;
+   int ret, irq;
 
-   if (pdev->id < 0 || pdev->id >= BCM63XX_NR_UARTS)
-   return -EINVAL;
+   res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res_mem)
+   return -ENODEV;
+
+   if (pdev->id < 0)  {
+   void __iomem *membase;
+
+   membase = ioremap(res_mem->start, resource_size(res_mem));
+   if (membase == (void *)bcm63xx_regset_address(RSET_UART0))
+   pdev->id = 0;
+   else
+   pdev->id = 1;
+   iounmap(membase);
+   }
 
if (ports[pdev->id].membase)
return -EBUSY;
 
-   res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res_mem)
-   return -ENODEV;
 
-   res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
-   if (!res_irq)
+   irq = platform_get_irq(pdev, 0);
+   if (!irq)
return -ENODEV;
 
clk = clk_get(&pdev->dev, "periph");
@@ -829,7 +838,7 @@ static int __devinit bcm_uart_probe(struct platform_device 
*pdev)
memset(port, 0, sizeof(*port));
port->iotype = UPIO_MEM;
port->mapbase = res_mem->start;
-   port->irq = res_irq->start;
+   port->irq = irq;
port->ops = &bcm_uart_ops;
port->flags = UPF_BOOT_AUTOCONF;
port->dev = &pdev->dev;
@@ -862,12 +871,18 @@ static int __devexit bcm_uart_remove(struct 
platform_device *pdev)
 /*
  * platform driver stuff
  */
+static const struct of_device_id bcm_uart_match[] = {
+   { .compatible = "brcm,bcm63xx-uart" },
+   { },
+};
+
 static struct platform_driver bcm_uart_platform_driver = {
.probe  = bcm_uart_probe,
.remove = __devexit_p(bcm_uart_remove),
.driver = {
.owner = THIS_MODULE,
.name  = "bcm63xx_uart",
+   .of_match_table = bcm_uart_match,
},
 };
 
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] MIPS: BCM63XX: add empty Device Trees for all supported boards

[Jonas Gorski]

Add empty board files for all boards supported by the legacy board
support.

Signed-off-by: Jonas Gorski 
---
 arch/mips/bcm63xx/dts/96328avng.dts   |   22 +++
 arch/mips/bcm63xx/dts/96338gw.dts |   22 +++
 arch/mips/bcm63xx/dts/96338w.dts  |   22 +++
 arch/mips/bcm63xx/dts/96345gw2.dts|   22 +++
 arch/mips/bcm63xx/dts/96348gw.dts |   22 +++
 arch/mips/bcm63xx/dts/96348gw_10.dts  |   22 +++
 arch/mips/bcm63xx/dts/96348gw_11.dts  |   22 +++
 arch/mips/bcm63xx/dts/96348gw_a.dts   |   22 +++
 arch/mips/bcm63xx/dts/96348r.dts  |   22 +++
 arch/mips/bcm63xx/dts/96358vw.dts |   22 +++
 arch/mips/bcm63xx/dts/96358vw2.dts|   23 
 arch/mips/bcm63xx/dts/Kconfig |   64 +
 arch/mips/bcm63xx/dts/Makefile|   18 +
 arch/mips/bcm63xx/dts/agpf_s0.dts |   22 +++
 arch/mips/bcm63xx/dts/dv201amr.dts|   22 +++
 arch/mips/bcm63xx/dts/dwv_s0.dts  |   22 +++
 arch/mips/bcm63xx/dts/fast2404.dts|   22 +++
 arch/mips/bcm63xx/dts/rta1025w_16.dts |   22 +++
 18 files changed, 435 insertions(+), 0 deletions(-)
 create mode 100644 arch/mips/bcm63xx/dts/96328avng.dts
 create mode 100644 arch/mips/bcm63xx/dts/96338gw.dts
 create mode 100644 arch/mips/bcm63xx/dts/96338w.dts
 create mode 100644 arch/mips/bcm63xx/dts/96345gw2.dts
 create mode 100644 arch/mips/bcm63xx/dts/96348gw.dts
 create mode 100644 arch/mips/bcm63xx/dts/96348gw_10.dts
 create mode 100644 arch/mips/bcm63xx/dts/96348gw_11.dts
 create mode 100644 arch/mips/bcm63xx/dts/96348gw_a.dts
 create mode 100644 arch/mips/bcm63xx/dts/96348r.dts
 create mode 100644 arch/mips/bcm63xx/dts/96358vw.dts
 create mode 100644 arch/mips/bcm63xx/dts/96358vw2.dts
 create mode 100644 arch/mips/bcm63xx/dts/agpf_s0.dts
 create mode 100644 arch/mips/bcm63xx/dts/dv201amr.dts
 create mode 100644 arch/mips/bcm63xx/dts/dwv_s0.dts
 create mode 100644 arch/mips/bcm63xx/dts/fast2404.dts
 create mode 100644 arch/mips/bcm63xx/dts/rta1025w_16.dts

diff --git a/arch/mips/bcm63xx/dts/96328avng.dts 
b/arch/mips/bcm63xx/dts/96328avng.dts
new file mode 100644
index 000..c1aee15
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/96328avng.dts
@@ -0,0 +1,22 @@
+/dts-v1/;
+
+/*
+ * Device Tree Source for Broadcom BCM96328avng reference board
+ *
+ * Copyright (C) 2012 Jonas Gorski 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "bcm6328.dtsi"
+
+/ {
+   model = "96328avng";
+   compatible = "96328avng";
+
+   ubus@1000 {
+
+   };
+};
diff --git a/arch/mips/bcm63xx/dts/96338gw.dts 
b/arch/mips/bcm63xx/dts/96338gw.dts
new file mode 100644
index 000..5e4f893
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/96338gw.dts
@@ -0,0 +1,22 @@
+/dts-v1/;
+
+/*
+ * Device Tree Source for Broadcom BCM96338GW reference board
+ *
+ * Copyright (C) 2012 Jonas Gorski 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "bcm6338.dtsi"
+
+/ {
+   model = "96338GW";
+   compatible = "96338GW";
+
+   ubus@fffe {
+
+   };
+};
diff --git a/arch/mips/bcm63xx/dts/96338w.dts b/arch/mips/bcm63xx/dts/96338w.dts
new file mode 100644
index 000..972a530
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/96338w.dts
@@ -0,0 +1,22 @@
+/dts-v1/;
+
+/*
+ * Device Tree Source for Broadcom BCM963338W reference board
+ *
+ * Copyright (C) 2012 Jonas Gorski 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "bcm6338.dtsi"
+
+/ {
+   model = "96338W";
+   compatible = "96338W";
+
+   ubus@fffe {
+
+   };
+};
diff --git a/arch/mips/bcm63xx/dts/96345gw2.dts 
b/arch/mips/bcm63xx/dts/96345gw2.dts
new file mode 100644
index 000..0114733
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/96345gw2.dts
@@ -0,0 +1,22 @@
+/dts-v1/;
+
+/*
+ * Device Tree Source for Broadcom BCM96345GW2 reference board
+ *
+ * Copyright (C) 2012 Jonas Gorski 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "bcm6345.dtsi"
+
+/ {
+   model = "96345GW2";
+   compatible = "96345GW2";
+
+   ubus@fffe {
+
+   };
+};
diff --git a/arch/mips/bcm63xx/dts/96348gw.dts 
b/arch/mips/bcm63xx/dts/96348gw.dt

[RFC] MIPS: BCM63XX: enable serial through Device Tree

[Jonas Gorski]

Enable serial through Device Tree board files instead of legacy
board files.

Signed-off-by: Jonas Gorski 
---
 arch/mips/bcm63xx/boards/board_bcm963xx.c |   15 ---
 arch/mips/bcm63xx/dts/96328avng.dts   |3 +++
 arch/mips/bcm63xx/dts/96338gw.dts |3 +++
 arch/mips/bcm63xx/dts/96338w.dts  |3 +++
 arch/mips/bcm63xx/dts/96345gw2.dts|3 +++
 arch/mips/bcm63xx/dts/96348gw.dts |3 +++
 arch/mips/bcm63xx/dts/96348gw_10.dts  |3 +++
 arch/mips/bcm63xx/dts/96348gw_11.dts  |3 +++
 arch/mips/bcm63xx/dts/96348gw_a.dts   |3 +++
 arch/mips/bcm63xx/dts/96348r.dts  |3 +++
 arch/mips/bcm63xx/dts/96358vw.dts |3 +++
 arch/mips/bcm63xx/dts/96358vw2.dts|3 +++
 arch/mips/bcm63xx/dts/dv201amr.dts|3 +++
 arch/mips/bcm63xx/dts/dwv_s0.dts  |3 +++
 arch/mips/bcm63xx/dts/fast2404.dts|3 +++
 arch/mips/bcm63xx/dts/rta1025w_16.dts |3 +++
 16 files changed, 45 insertions(+), 15 deletions(-)

diff --git a/arch/mips/bcm63xx/boards/board_bcm963xx.c 
b/arch/mips/bcm63xx/boards/board_bcm963xx.c
index 73be9b3..c64cf7c 100644
--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
+++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
@@ -40,7 +40,6 @@ static struct board_info __initdata board_96328avng = {
.name   = "96328avng",
.expected_cpu_id= 0x6328,
 
-   .has_uart0  = 1,
.has_pci= 1,
.has_usbd   = 0,
 
@@ -88,7 +87,6 @@ static struct board_info __initdata board_96338gw = {
.name   = "96338GW",
.expected_cpu_id= 0x6338,
 
-   .has_uart0  = 1,
.has_enet0  = 1,
.enet0 = {
.force_speed_100= 1,
@@ -131,7 +129,6 @@ static struct board_info __initdata board_96338w = {
.name   = "96338W",
.expected_cpu_id= 0x6338,
 
-   .has_uart0  = 1,
.has_enet0  = 1,
.enet0 = {
.force_speed_100= 1,
@@ -176,8 +173,6 @@ static struct board_info __initdata board_96338w = {
 static struct board_info __initdata board_96345gw2 = {
.name   = "96345GW2",
.expected_cpu_id= 0x6345,
-
-   .has_uart0  = 1,
 };
 #endif
 
@@ -189,7 +184,6 @@ static struct board_info __initdata board_96348r = {
.name   = "96348R",
.expected_cpu_id= 0x6348,
 
-   .has_uart0  = 1,
.has_enet0  = 1,
.has_pci= 1,
 
@@ -233,7 +227,6 @@ static struct board_info __initdata board_96348gw_10 = {
.name   = "96348GW-10",
.expected_cpu_id= 0x6348,
 
-   .has_uart0  = 1,
.has_enet0  = 1,
.has_enet1  = 1,
.has_pci= 1,
@@ -293,7 +286,6 @@ static struct board_info __initdata board_96348gw_11 = {
.name   = "96348GW-11",
.expected_cpu_id= 0x6348,
 
-   .has_uart0  = 1,
.has_enet0  = 1,
.has_enet1  = 1,
.has_pci= 1,
@@ -347,7 +339,6 @@ static struct board_info __initdata board_96348gw = {
.name   = "96348GW",
.expected_cpu_id= 0x6348,
 
-   .has_uart0  = 1,
.has_enet0  = 1,
.has_enet1  = 1,
.has_pci= 1,
@@ -405,7 +396,6 @@ static struct board_info __initdata board_FAST2404 = {
.name   = "F@ST2404",
.expected_cpu_id= 0x6348,
 
-   .has_uart0  = 1,
 .has_enet0 = 1,
 .has_enet1 = 1,
 .has_pci   = 1,
@@ -448,7 +438,6 @@ static struct board_info __initdata board_DV201AMR = {
.name   = "DV201AMR",
.expected_cpu_id= 0x6348,
 
-   .has_uart0  = 1,
.has_pci= 1,
.has_ohci0  = 1,
 
@@ -468,7 +457,6 @@ static struct board_info __initdata board_96348gw_a = {
.name   = "96348GW-A",
.expected_cpu_id= 0x6348,
 
-   .has_uart0  = 1,
.has_enet0

[RFC] MIPS: BCM63XX: add serial blocks to Device Tree includes

[Jonas Gorski]

Add the serial block to the Device Tree includes for all SoCs.

Signed-off-by: Jonas Gorski 
---
 arch/mips/bcm63xx/dts/bcm6328.dtsi |   14 ++
 arch/mips/bcm63xx/dts/bcm6338.dtsi |7 +++
 arch/mips/bcm63xx/dts/bcm6345.dtsi |8 
 arch/mips/bcm63xx/dts/bcm6348.dtsi |7 +++
 arch/mips/bcm63xx/dts/bcm6358.dtsi |   14 ++
 arch/mips/bcm63xx/dts/bcm6368.dtsi |   14 ++
 6 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/arch/mips/bcm63xx/dts/bcm6328.dtsi 
b/arch/mips/bcm63xx/dts/bcm6328.dtsi
index e2e92c3..d29d43c 100644
--- a/arch/mips/bcm63xx/dts/bcm6328.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6328.dtsi
@@ -140,5 +140,19 @@
#gpio-cells = <2>;
ngpio = <32>;
};
+
+   uart0: serial@100 {
+   compatible = "brcm,bcm63xx-uart";
+   reg = <0x100 0x18>;
+   interrupts = <28>;
+   status = "disabled";
+   };
+
+   uart1: serial@120 {
+   compatible = "brcm,bcm63xx-uart";
+   reg = <0x120 0x18>;
+   interrupts = <39>;
+   status = "disabled";
+   };
};
 };
diff --git a/arch/mips/bcm63xx/dts/bcm6338.dtsi 
b/arch/mips/bcm63xx/dts/bcm6338.dtsi
index 28e7cb6..c7b45c1 100644
--- a/arch/mips/bcm63xx/dts/bcm6338.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6338.dtsi
@@ -90,6 +90,13 @@
};
};
 
+   uart0: serial@300 {
+   compatible = "brcm,bcm63xx-uart";
+   reg = <0x300 0x18>;
+   interrupts = <2>;
+   status = "disabled";
+   };
+
gpio0: gpio@400 {
compatible = "brcm,bcm63xx-gpio";
reg = <0x400 0x80>;
diff --git a/arch/mips/bcm63xx/dts/bcm6345.dtsi 
b/arch/mips/bcm63xx/dts/bcm6345.dtsi
index 1ebc024..055f66c 100644
--- a/arch/mips/bcm63xx/dts/bcm6345.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6345.dtsi
@@ -75,6 +75,14 @@
};
};
};
+
+   uart0: serial@300 {
+   compatible = "brcm,bcm63xx-uart";
+   reg = <0x300 0x18>;
+   interrupts = <2>;
+   status = "disabled";
+   };
+
gpio0: gpio@400 {
compatible = "brcm,bcm63xx-gpio";
reg = <0x400 0x80>;
diff --git a/arch/mips/bcm63xx/dts/bcm6348.dtsi 
b/arch/mips/bcm63xx/dts/bcm6348.dtsi
index 89acec7..5d1d10a 100644
--- a/arch/mips/bcm63xx/dts/bcm6348.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6348.dtsi
@@ -97,6 +97,13 @@
};
};
 
+   uart0: serial@300 {
+   compatible = "brcm,bcm63xx-uart";
+   reg = <0x300 0x18>;
+   interrupts = <2>;
+   status = "disabled";
+   };
+
gpio0: gpio@400 {
compatible = "brcm,bcm63xx-gpio";
regs = <0x400 0x80>;
diff --git a/arch/mips/bcm63xx/dts/bcm6358.dtsi 
b/arch/mips/bcm63xx/dts/bcm6358.dtsi
index 52170d6..702882d 100644
--- a/arch/mips/bcm63xx/dts/bcm6358.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6358.dtsi
@@ -138,5 +138,19 @@
#gpio-cells = <2>;
ngpio = <40>;
};
+
+   uart0: serial@100 {
+   compatible = "brcm,bcm63xx-uart";
+   reg = <0x100 0x18>;
+   interrupts = <2>;
+   status = "disabled";
+   };
+
+   uart1: serial@120 {
+   compatible = "brcm,bcm63xx-uart";
+   reg = <0x120 0x18>;
+   interrupts = <3>;
+   status = "disabled";
+   };
};
 };
diff --git a/arch/mips/bcm63xx/dts/bcm6368.dtsi 
b/arch/mips/bcm63xx/dts/bcm6368.dtsi
index 068231b..82cd030 100644
--- a/arch/mips/bcm63xx/dts/bcm6368.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6368.dtsi
@@ -178,5 +178,19 @@
#gpio-cells = <2>;
ngpio = <38>;
};
+
+   uart0: serial@100 {
+   compatible = "brcm,bcm63xx-uart";
+   reg = <0x100 0x18>;
+   interrupts = <2>;
+   status = "disabled";

[RFC] MIPS: BCM63XX: register GPIO controller through Device Tree

[Jonas Gorski]

Register the GPIO controller through Device Tree and add the
appropriate values in the include files.

Since we can't register a platform driver at this early stage move the
direct call to bcm63xx_gpio_init from prom_init to an arch initcall.

Signed-off-by: Jonas Gorski 
---
 .../devicetree/bindings/gpio/bcm63xx-gpio.txt  |   24 +
 arch/mips/bcm63xx/dts/bcm6328.dtsi |8 
 arch/mips/bcm63xx/dts/bcm6338.dtsi |8 
 arch/mips/bcm63xx/dts/bcm6345.dtsi |7 
 arch/mips/bcm63xx/dts/bcm6348.dtsi |8 
 arch/mips/bcm63xx/dts/bcm6358.dtsi |8 
 arch/mips/bcm63xx/dts/bcm6368.dtsi |8 
 arch/mips/bcm63xx/gpio.c   |   35 +--
 arch/mips/bcm63xx/prom.c   |3 --
 9 files changed, 102 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/bcm63xx-gpio.txt

diff --git a/Documentation/devicetree/bindings/gpio/bcm63xx-gpio.txt 
b/Documentation/devicetree/bindings/gpio/bcm63xx-gpio.txt
new file mode 100644
index 000..283765d
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/bcm63xx-gpio.txt
@@ -0,0 +1,24 @@
+* Broadcom BCM63XX GPIO controller
+
+Required properties:
+- compatible: "brcm,bcm63xx-gpio"
+  Compatible with all BCM63XX SoCs.
+
+- reg: address and length of the register block.
+
+- gpio-controller: This is a GPIO controller.
+
+- #gpio-cells: Must be <2>. The first cell is the GPIO pin, and
+  the second one the standard linux flags.
+
+- ngpio: number of GPIOs present in this SoC.
+
+Example:
+
+   gpio: gpio@80 {
+   compatible = "brcm,bcm63xx-gpio";
+   reg = <0x80 0x80>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   ngpio = <40>;
+   };
diff --git a/arch/mips/bcm63xx/dts/bcm6328.dtsi 
b/arch/mips/bcm63xx/dts/bcm6328.dtsi
index 9055187..e2e92c3 100644
--- a/arch/mips/bcm63xx/dts/bcm6328.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6328.dtsi
@@ -132,5 +132,13 @@
};
};
};
+
+   gpio0: gpio@80 {
+   compatible = "brcm,bcm63xx-gpio";
+   reg = <0x80 0x80>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   ngpio = <32>;
+   };
};
 };
diff --git a/arch/mips/bcm63xx/dts/bcm6338.dtsi 
b/arch/mips/bcm63xx/dts/bcm6338.dtsi
index 6346a7e..28e7cb6 100644
--- a/arch/mips/bcm63xx/dts/bcm6338.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6338.dtsi
@@ -89,5 +89,13 @@
};
};
};
+
+   gpio0: gpio@400 {
+   compatible = "brcm,bcm63xx-gpio";
+   reg = <0x400 0x80>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   ngpio = <8>;
+   };
};
 };
diff --git a/arch/mips/bcm63xx/dts/bcm6345.dtsi 
b/arch/mips/bcm63xx/dts/bcm6345.dtsi
index 1771775..1ebc024 100644
--- a/arch/mips/bcm63xx/dts/bcm6345.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6345.dtsi
@@ -75,5 +75,12 @@
};
};
};
+   gpio0: gpio@400 {
+   compatible = "brcm,bcm63xx-gpio";
+   reg = <0x400 0x80>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   ngpio = <16>;
+   };
};
 };
diff --git a/arch/mips/bcm63xx/dts/bcm6348.dtsi 
b/arch/mips/bcm63xx/dts/bcm6348.dtsi
index 14f1996..89acec7 100644
--- a/arch/mips/bcm63xx/dts/bcm6348.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6348.dtsi
@@ -96,5 +96,13 @@
};
};
};
+
+   gpio0: gpio@400 {
+   compatible = "brcm,bcm63xx-gpio";
+   regs = <0x400 0x80>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   ngpio = <37>;
+   };
};
 };
diff --git a/arch/mips/bcm63xx/dts/bcm6358.dtsi 
b/arch/mips/bcm63xx/dts/bcm6358.dtsi
index 943b480..52170d6 100644
--- a/arch/mips/bcm63xx/dts/bcm6358.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6358.dtsi
@@ -130,5 +130,13 @@
};
};
};
+
+   gpio0: gpio@80 {
+   compatible = "brcm,bcm63xx-gpio";
+   reg = <0x80 0x80>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   ngpio = 

[RFC] MIPS: BCM63XX: add simple Device Tree includes for all SoCs

[Jonas Gorski]

Add simple Device Tree include files for all currently supported SoCs.
These will be populated with device definitions as driver support
gets added.

Signed-off-by: Jonas Gorski 
---
 arch/mips/bcm63xx/dts/bcm6328.dtsi |   30 ++
 arch/mips/bcm63xx/dts/bcm6338.dtsi |   30 ++
 arch/mips/bcm63xx/dts/bcm6345.dtsi |   30 ++
 arch/mips/bcm63xx/dts/bcm6348.dtsi |   30 ++
 arch/mips/bcm63xx/dts/bcm6358.dtsi |   33 +
 arch/mips/bcm63xx/dts/bcm6368.dtsi |   33 +
 6 files changed, 186 insertions(+), 0 deletions(-)
 create mode 100644 arch/mips/bcm63xx/dts/bcm6328.dtsi
 create mode 100644 arch/mips/bcm63xx/dts/bcm6338.dtsi
 create mode 100644 arch/mips/bcm63xx/dts/bcm6345.dtsi
 create mode 100644 arch/mips/bcm63xx/dts/bcm6348.dtsi
 create mode 100644 arch/mips/bcm63xx/dts/bcm6358.dtsi
 create mode 100644 arch/mips/bcm63xx/dts/bcm6368.dtsi

diff --git a/arch/mips/bcm63xx/dts/bcm6328.dtsi 
b/arch/mips/bcm63xx/dts/bcm6328.dtsi
new file mode 100644
index 000..a0e1835
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/bcm6328.dtsi
@@ -0,0 +1,30 @@
+/*
+ * Device Tree Include file for Broadcom BCM6328 SoC
+ *
+ * Copyright (C) 2012 Jonas Gorski 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "brcm,bcm6328";
+
+   cpus {
+   cpu@0 {
+   compatible = "brcm,bmips4350", "mips,mips4Kc";
+   };
+   };
+
+   memory { device_type = "memory"; reg = <0 0>; };
+
+   ubus@1000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x1000 0x2>;
+   compatible = "simple-bus";
+   };
+};
diff --git a/arch/mips/bcm63xx/dts/bcm6338.dtsi 
b/arch/mips/bcm63xx/dts/bcm6338.dtsi
new file mode 100644
index 000..21772d9
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/bcm6338.dtsi
@@ -0,0 +1,30 @@
+/*
+ * Device Tree Include file for Broadcom BCM6338 SoC
+ *
+ * Copyright (C) 2012 Jonas Gorski 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "brcm,bcm6338";
+
+   cpus {
+   cpu@0 {
+   compatible = "brcm,bmips3300", "mips,mips4Kc";
+   };
+   };
+
+   memory { device_type = "memory"; reg = <0 0>; };
+
+   ubus@fffe {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0xfffe 0x2>;
+   compatible = "simple-bus";
+   };
+};
diff --git a/arch/mips/bcm63xx/dts/bcm6345.dtsi 
b/arch/mips/bcm63xx/dts/bcm6345.dtsi
new file mode 100644
index 000..f1e7153
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/bcm6345.dtsi
@@ -0,0 +1,30 @@
+/*
+ * Device Tree Include file for Broadcom BCM6345 SoC
+ *
+ * Copyright (C) 2012 Jonas Gorski 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "brcm,bcm6345";
+
+   cpus {
+   cpu@0 {
+   compatible = "brcm,bmips3300", "mips,mips4Kc";
+   };
+   };
+
+   memory { device_type = "memory"; reg = <0 0>; };
+
+   ubus@fffe {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0xfffe 0x2>;
+   compatible = "simple-bus";
+   };
+};
diff --git a/arch/mips/bcm63xx/dts/bcm6348.dtsi 
b/arch/mips/bcm63xx/dts/bcm6348.dtsi
new file mode 100644
index 000..8a5a2dc
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/bcm6348.dtsi
@@ -0,0 +1,30 @@
+/*
+ * Device Tree Include file for Broadcom BCM6348 SoC
+ *
+ * Copyright (C) 2012 Jonas Gorski 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "brcm,bcm6348";
+
+   cpus {
+

[RFC] serial: bcm63xx_uart: remove unnecessary include

[Jonas Gorski]

bcm63xx_clk.h does not need to be included anymore as clk.h already
provides all required prototypes.

Signed-off-by: Jonas Gorski 
---
 drivers/tty/serial/bcm63xx_uart.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/tty/serial/bcm63xx_uart.c 
b/drivers/tty/serial/bcm63xx_uart.c
index c0b68b9..0187aff 100644
--- a/drivers/tty/serial/bcm63xx_uart.c
+++ b/drivers/tty/serial/bcm63xx_uart.c
@@ -30,7 +30,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] bcm63xx-rng: use clk_{prepare_enable,disable_unprepare}

[Jonas Gorski]

Use proper clk_prepare/unprepare calls in preparation for switching to
the generic clock framework.

Signed-off-by: Jonas Gorski 
---
 drivers/char/hw_random/bcm63xx-rng.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/bcm63xx-rng.c 
b/drivers/char/hw_random/bcm63xx-rng.c
index aec6a42..3693f56 100644
--- a/drivers/char/hw_random/bcm63xx-rng.c
+++ b/drivers/char/hw_random/bcm63xx-rng.c
@@ -122,7 +122,7 @@ static int __devinit bcm63xx_rng_probe(struct 
platform_device *pdev)
goto out_free_rng;
}
 
-   clk_enable(clk);
+   clk_prepare_enable(clk);
 
ret = hwrng_register(rng);
if (ret) {
@@ -135,7 +135,7 @@ static int __devinit bcm63xx_rng_probe(struct 
platform_device *pdev)
return 0;
 
 out_clk_disable:
-   clk_disable(clk);
+   clk_disable_unprepare(clk);
 out_free_rng:
platform_set_drvdata(pdev, NULL);
kfree(rng);
@@ -151,7 +151,7 @@ static int __devexit bcm63xx_rng_remove(struct 
platform_device *pdev)
struct bcm63xx_rng_priv *priv = to_rng_priv(rng);
 
hwrng_unregister(rng);
-   clk_disable(priv->clk);
+   clk_disable_unprepare(priv->clk);
kfree(priv);
kfree(rng);
platform_set_drvdata(pdev, NULL);
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] SPI: spi-bcm63xx: use clk_{prepare_enable,disable_unprepare}

[Jonas Gorski]

Use proper clk_prepare/unprepare calls in preparation for switching
to the generic clock framework.

Signed-off-by: Jonas Gorski 
---
 drivers/spi/spi-bcm63xx.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-bcm63xx.c b/drivers/spi/spi-bcm63xx.c
index a9f4049..69cb96a 100644
--- a/drivers/spi/spi-bcm63xx.c
+++ b/drivers/spi/spi-bcm63xx.c
@@ -431,7 +431,7 @@ static int __devinit bcm63xx_spi_probe(struct 
platform_device *pdev)
}
 
/* Initialize hardware */
-   clk_enable(bs->clk);
+   clk_prepare_enable(bs->clk);
bcm_spi_writeb(bs, SPI_INTR_CLEAR_ALL, SPI_INT_STATUS);
 
/* register and we are done */
@@ -447,7 +447,7 @@ static int __devinit bcm63xx_spi_probe(struct 
platform_device *pdev)
return 0;
 
 out_clk_disable:
-   clk_disable(clk);
+   clk_disable_unprepare(clk);
 out_err:
platform_set_drvdata(pdev, NULL);
spi_master_put(master);
@@ -468,7 +468,7 @@ static int __devexit bcm63xx_spi_remove(struct 
platform_device *pdev)
bcm_spi_writeb(bs, 0, SPI_INT_MASK);
 
/* HW shutdown */
-   clk_disable(bs->clk);
+   clk_disable_unprepare(bs->clk);
clk_put(bs->clk);
 
platform_set_drvdata(pdev, 0);
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] MIPS: BCM63XX: add support for loading DTB

[Jonas Gorski]

Add support for loading DTBs embedded into the kernel. Iterate through
all embedded ones until a match is found and use that.

Use the NVRAM provided board name for constructing the compatible
property for selecting the appropriate in-kernel DTB.

Signed-off-by: Jonas Gorski 
---
 arch/mips/Kconfig  |1 +
 arch/mips/bcm63xx/Kconfig  |2 +
 arch/mips/bcm63xx/Makefile |1 +
 arch/mips/bcm63xx/dts/Kconfig  |3 +
 arch/mips/bcm63xx/dts/Makefile |2 +
 arch/mips/bcm63xx/setup.c  |   80 
 6 files changed, 89 insertions(+), 0 deletions(-)
 create mode 100644 arch/mips/bcm63xx/dts/Kconfig
 create mode 100644 arch/mips/bcm63xx/dts/Makefile

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 9934a46..168b0fc 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -132,6 +132,7 @@ config BCM63XX
select SWAP_IO_SPACE
select ARCH_REQUIRE_GPIOLIB
select HAVE_CLK
+   select USE_OF
help
 Support for BCM63XX based boards
 
diff --git a/arch/mips/bcm63xx/Kconfig b/arch/mips/bcm63xx/Kconfig
index d03e879..03d693b 100644
--- a/arch/mips/bcm63xx/Kconfig
+++ b/arch/mips/bcm63xx/Kconfig
@@ -31,3 +31,5 @@ config BCM63XX_CPU_6368
 endmenu
 
 source "arch/mips/bcm63xx/boards/Kconfig"
+
+source "arch/mips/bcm63xx/dts/Kconfig"
diff --git a/arch/mips/bcm63xx/Makefile b/arch/mips/bcm63xx/Makefile
index ac28073..30971a7 100644
--- a/arch/mips/bcm63xx/Makefile
+++ b/arch/mips/bcm63xx/Makefile
@@ -5,3 +5,4 @@ obj-y   += clk.o cpu.o cs.o gpio.o irq.o nvram.o prom.o 
reset.o \
 obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
 
 obj-y  += boards/
+obj-y  += dts/
diff --git a/arch/mips/bcm63xx/dts/Kconfig b/arch/mips/bcm63xx/dts/Kconfig
new file mode 100644
index 000..919f3f6
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/Kconfig
@@ -0,0 +1,3 @@
+menu "Built-in Device Tree support"
+
+endmenu
diff --git a/arch/mips/bcm63xx/dts/Makefile b/arch/mips/bcm63xx/dts/Makefile
new file mode 100644
index 000..69c374b
--- /dev/null
+++ b/arch/mips/bcm63xx/dts/Makefile
@@ -0,0 +1,2 @@
+$(obj)/%.dtb: $(obj)/%.dts
+   $(call if_changed,dtc)
diff --git a/arch/mips/bcm63xx/setup.c b/arch/mips/bcm63xx/setup.c
index 314231b..8712354 100644
--- a/arch/mips/bcm63xx/setup.c
+++ b/arch/mips/bcm63xx/setup.c
@@ -4,6 +4,7 @@
  * for more details.
  *
  * Copyright (C) 2008 Maxime Bizon 
+ * Copyright (C) 2012 Jonas Gorski 
  */
 
 #include 
@@ -12,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -20,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 void bcm63xx_machine_halt(void)
 {
@@ -152,6 +156,82 @@ void __init plat_mem_setup(void)
board_setup();
 }
 
+extern struct boot_param_header __dtb_start;
+extern struct boot_param_header __dtb_end;
+
+int __init bcm63xx_is_compatible(struct boot_param_header *devtree,
+  const char *compat)
+{
+   unsigned long dt_root;
+   struct boot_param_header *old_ibp = initial_boot_params;
+   int ret;
+
+   initial_boot_params = devtree;
+
+   dt_root = of_get_flat_dt_root();
+   ret = of_flat_dt_is_compatible(dt_root, compat);
+
+   initial_boot_params = old_ibp;
+
+   return ret;
+}
+
+static struct of_device_id of_ids[] = {
+   { /* will be filled at runtime */ },
+   { .compatible = "simple-bus" },
+   { },
+};
+
+static struct boot_param_header *find_compatible_tree(const char *compat)
+{
+   struct boot_param_header *curr = &__dtb_start;
+
+   while (curr < &__dtb_end) {
+   if (be32_to_cpu(curr->magic) != OF_DT_HEADER)
+   continue;
+
+   if (bcm63xx_is_compatible(curr, compat))
+   return curr;
+
+   /* in-kernel dtbs are aligned to 32 bytes */
+   curr = (void *)curr + roundup(be32_to_cpu(curr->totalsize), 32);
+   }
+
+   return NULL;
+}
+
+void __init device_tree_init(void)
+{
+   struct boot_param_header *devtree = NULL;
+   const char *name = board_get_name();
+
+   strncpy(of_ids[0].compatible, name, BOARDID_LEN);
+
+   devtree = find_compatible_tree(of_ids[0].compatible);
+   if (!devtree) {
+   pr_warn("no compatible device tree found for board %s\n"
+   of_ids[0].compatible);
+   return;
+   }
+
+   __dt_setup_arch(devtree);
+   reserve_bootmem(virt_to_phys(devtree), be32_to_cpu(devtree->totalsize),
+   BOOTMEM_DEFAULT);
+
+   unflatten_device_tree();
+}
+
+int __init bcm63xx_populate_device_tree(void)
+{
+   if (!of_have_populated_dt()) {
+   pr_warn("device tree not available\n");
+   return -ENODEV;
+   }
+
+   return of_platform_populate(NULL, of_ids, NULL, NULL);
+}
+arch_ini

[RFC] MIPS: BCM63XX: add Device Tree glue code for IRQ handling

[Jonas Gorski]

Register IRQ domains through Device Tree for the internal and external
interrupt controllers. Register the same IRQ ranges as previously to
provide backward compatibility for non-DT drivers.

Signed-off-by: Jonas Gorski 
---
 .../devicetree/bindings/mips/bcm63xx/epic.txt  |   20 
 .../devicetree/bindings/mips/bcm63xx/ipic.txt  |   18 +++
 arch/mips/bcm63xx/dts/bcm6328.dtsi |   16 ++
 arch/mips/bcm63xx/dts/bcm6338.dtsi |   16 ++
 arch/mips/bcm63xx/dts/bcm6345.dtsi |   16 ++
 arch/mips/bcm63xx/dts/bcm6348.dtsi |   16 ++
 arch/mips/bcm63xx/dts/bcm6358.dtsi |   16 ++
 arch/mips/bcm63xx/dts/bcm6368.dtsi |   16 ++
 arch/mips/bcm63xx/irq.c|   32 
 9 files changed, 166 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mips/bcm63xx/epic.txt
 create mode 100644 Documentation/devicetree/bindings/mips/bcm63xx/ipic.txt

diff --git a/Documentation/devicetree/bindings/mips/bcm63xx/epic.txt 
b/Documentation/devicetree/bindings/mips/bcm63xx/epic.txt
new file mode 100644
index 000..4fc74e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/bcm63xx/epic.txt
@@ -0,0 +1,20 @@
+* Broadcom BCM63XX External Interrupt Controller
+
+Properties:
+- compatible: "brcm,bcm63xx-epic"
+  Compatible with all bcm63xx SoCs.
+
+- interrupt-controller: This is an interrupt controller.
+
+- #interrupt-cells: <2>
+  This controller supports level and edge triggered interrupts. The
+  first cell is the interrupt number, the second is a 1:1 mapping to
+  the linux interrupt flags.
+
+Example:
+
+   epic: interrupt-controller@18 {
+   compatible = "brcm,bcm63xx-epic";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   }
diff --git a/Documentation/devicetree/bindings/mips/bcm63xx/ipic.txt 
b/Documentation/devicetree/bindings/mips/bcm63xx/ipic.txt
new file mode 100644
index 000..1cbabf90
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/bcm63xx/ipic.txt
@@ -0,0 +1,18 @@
+* BCM63XX Internal Interrupt Controller
+
+Properties:
+- compatible: "brcm,bcm63xx-ipic"
+  Compatible with all bcm63xx SoCs.
+
+- interrupt-controller: This is an interrupt controller.
+
+- #interrupt-cells: <1>
+  This controller supports only level interrupts.
+
+Example:
+
+   ipic: interrupt-controller@20 {
+   compatible = "brcm,bcm63xx-ipic";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   }
diff --git a/arch/mips/bcm63xx/dts/bcm6328.dtsi 
b/arch/mips/bcm63xx/dts/bcm6328.dtsi
index a0e1835..a41033a 100644
--- a/arch/mips/bcm63xx/dts/bcm6328.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6328.dtsi
@@ -26,5 +26,21 @@
#size-cells = <1>;
ranges = <0 0x1000 0x2>;
compatible = "simple-bus";
+
+   interrupt-parent = <&ipic>;
+
+   perf@0 {
+   epic: interrupt-controller@18 {
+   compatible = "brcm,bcm63xx-epic";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   ipic: interrupt-controller@20 {
+   compatible = "brcm,bcm63xx-ipic";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   };
+   };
};
 };
diff --git a/arch/mips/bcm63xx/dts/bcm6338.dtsi 
b/arch/mips/bcm63xx/dts/bcm6338.dtsi
index 21772d9..8ecbc4f 100644
--- a/arch/mips/bcm63xx/dts/bcm6338.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6338.dtsi
@@ -26,5 +26,21 @@
#size-cells = <1>;
ranges = <0 0xfffe 0x2>;
compatible = "simple-bus";
+
+   interrupt-parent = <&ipic>;
+
+   perf@0 {
+   ipic: interrupt-controller@c {
+   compatible = "brcm,bcm63xx-ipic";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   };
+
+   epic: interrupt-controller@14 {
+   compatible = "brcm,bcm63xx-epic";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+   };
};
 };
diff --git a/arch/mips/bcm63xx/dts/bcm6345.dtsi 
b/arch/mips/bcm63xx/dts/bcm6345.dtsi
index f1e7153..ed17c12 100644
--- a/arch/mips/bcm63xx/dts/bcm6345.dtsi
+++ b/arch/mips/bcm63xx/dts/bcm6345.dt

Second ethernet on kirkwood does not work when probed through DT

[Jonas Gorski]

Hello Sebastian,

using your DT patches[1] (on top of 3.10) I can't get the second ethernet to 
work on my kirkwood board.

in my dts file I use:

&mdio {
status = "okay";
};

ð0 {
status = "okay";
ethernet0-port@0 {
speed = <1000>;
duplex = <1>;
};
};

ð1 {
status = "okay";
ethernet1-port@1 {
speed = <1000>;
duplex = <1>;
};
};

(Both macs are connected to a switch, so use a fixed link, and no phy).

Eth1 gets probed fine, but never gets a link when brought up, and trying to 
bring it down again hangs the board hard.

Using Florian's older patches, it is brought up fine and works (after adapting 
the node names of course).

Also I noticed that you named eth1's ethernet1-port node wrongly in (at least) 
your kirkwood conversion patch[2]; you used

ð1 {
status = "okay";
ethernet1-port@0 {
   must be @1--^
phy-handle = <ðphy1>;
};
};

which results in a null pointer access on boot:

...
[   12.627136] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC 
address ...
[   12.635955] Unable to handle kernel NULL pointer dereference at virtual 
address 
[   12.644100] pgd = c0004000
[   12.646821] [] *pgd=
[   12.650418] Internal error: Oops: 5 [#1] ARM
[   12.654702] Modules linked in:
[   12.657778] CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0 #10
[   12.663634] task: c7827d60 ti: c782e000 task.ti: c782e000
[   12.669073] PC is at mv643xx_eth_probe+0x98/0x708
...


Regards
Jonas

P.S: I'm not on any ML you posted these patches to, so I could not reply 
directly.

[1] https://patchwork.kernel.org/patch/2632571/ etc
[2] https://patchwork.kernel.org/patch/2811861/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Second ethernet on kirkwood does not work when probed through DT

[Jonas Gorski]

On Sat, 06 Jul 2013 23:22:22 +0200
Sebastian Hesselbarth  wrote:

> On 07/06/2013 09:54 PM, Jonas Gorski wrote:
> > Hello Sebastian,
> >
> > using your DT patches[1] (on top of 3.10) I can't get the second
> > ethernet to work on my kirkwood board.
> 
> Hi Jonas,
> 
> next time please name your board, because there are plenty of it.
> Kirkwood is just the SoC used on them.

Oops, sorry. It's D-Link DIR-665, with a 6281. Currently not upstream,
but mostly supported (the switch isn't supported by DSA but works fine
without it).

 
> > in my dts file I use:
> >
> > &mdio { status = "okay"; };
> >
> > ð0 { status = "okay"; ethernet0-port@0 { speed =<1000>; duplex
> > =<1>; }; };
> >
> 
> I guess you are using Iomega IX2 200?
> 
> > ð1 { status = "okay"; ethernet1-port@1 { speed =<1000>; duplex
> > =<1>; }; };
> >
> > (Both macs are connected to a switch, so use a fixed link, and no
> > phy).
> >
> > Eth1 gets probed fine, but never gets a link when brought up, and
> > trying to bring it down again hangs the board hard.
> >
> > Using Florian's older patches, it is brought up fine and works (after
> > adapting the node names of course).
> >
> > Also I noticed that you named eth1's ethernet1-port node wrongly in
> > (at least) your kirkwood conversion patch[2]; you used
> >
> > ð1 { status = "okay"; ethernet1-port@0 { must be @1--^ phy-handle
> > =<ðphy1>; }; };
> 
> Can you please try to leave ethernet1-port@0 and match
> the one in kirkwood.dtsi?
> 
> Both "ports" need reg = <0> as there is two controllers
> with one port at 0 on Kirkwood.

kirkwood.dtsi itself says ethernet1-port@1 with reg = <1>.

Changing reg to 0 for eth1 brings:

[9.586915] [ cut here ]
[9.591590] WARNING: at fs/sysfs/dir.c:530 sysfs_add_one+0x88/0xa8()
[9.597973] sysfs: cannot create duplicate filename 
'/devices/platform/mv643xx_eth_port.0'
[9.606286] Modules linked in:
[9.609366] CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0 #12
[9.615231] Backtrace:
[9.617714] [] (dump_backtrace+0x0/0x114) from [] 
(show_stack+0x18/0x1c)
[9.626205]  r6:0212 r5:c02cd6e0 r4:c782fbe0 r3:
[9.631972] [] (show_stack+0x0/0x1c) from [] 
(dump_stack+0x20/0x28)
[9.640024] [] (dump_stack+0x0/0x28) from [] 
(warn_slowpath_common+0x58/0x74)
[9.648958] [] (warn_slowpath_common+0x0/0x74) from [] 
(warn_slowpath_fmt+0x38/0x40)
[9.658492]  r8:c780d288 r7:c7823000 r6:c782fc28 r5:c73c1c88 r4:c782fc04
r3:0009
[9.666436] [] (warn_slowpath_fmt+0x0/0x40) from [] 
(sysfs_add_one+0x88/0xa8)
[9.675357]  r3:c7823000 r2:c02cd750
[9.678964]  r4:ffef
[9.681539] [] (sysfs_add_one+0x0/0xa8) from [] 
(create_dir+0x70/0xc0)
[9.689836]  r7:c78c64d8 r6: r5:c73c1c88 r4:2001
[9.695577] [] (create_dir+0x0/0xc0) from [] 
(sysfs_create_dir+0xbc/0xdc)
[9.704165] [] (sysfs_create_dir+0x0/0xdc) from [] 
(kobject_add_internal+0xb8/0x1e4)
[9.713698]  r6:c07ae3b0 r5:c78c64d8 r4:c78c64d8
[9.718375] [] (kobject_add_internal+0x0/0x1e4) from [] 
(kobject_add+0x80/0x98)
[9.727487] [] (kobject_add+0x0/0x98) from [] 
(device_add+0xd8/0x54c)
[9.735708]  r3: r2:
[9.739315]  r6: r5:c78c64d0 r4:c78c64c0
[9.744002] [] (device_add+0x0/0x54c) from [] 
(platform_device_add+0x14c/0x1e0)
[9.753117] [] (platform_device_add+0x0/0x1e0) from [] 
(mv643xx_eth_shared_of_add_port+0x240/0x2a8)
[9.763962]  r8:0e00 r7:c73b1b70 r6:003e r5: r4:c78c64c0
r3:
[9.771899] [] (mv643xx_eth_shared_of_add_port+0x0/0x2a8) from 
[] (mv643xx_eth_shared_probe+0x22c/0x318)
[9.783172]  r5:c08ea74c r4:c08ea89c
[9.786790] [] (mv643xx_eth_shared_probe+0x0/0x318) from 
[] (platform_drv_probe+0x1c/0x20)
[9.796860] [] (platform_drv_probe+0x0/0x20) from [] 
(driver_probe_device+0xe4/0x210)
[9.806493] [] (driver_probe_device+0x0/0x210) from [] 
(__driver_attach+0x68/0x8c)
[9.815853]  r7: r6:c07b3f64 r5:c785bdb0 r4:c785bde4
[9.821594] [] (__driver_attach+0x0/0x8c) from [] 
(bus_for_each_dev+0x58/0x90)
[9.830600]  r6:c07b3f64 r5:c0161f24 r4: r3:0002
[9.836329] [] (bus_for_each_dev+0x0/0x90) from [] 
(driver_attach+0x20/0x28)
[9.845162]  r6:c07ae368 r5:c07b3f64 r4:c73ad4a0
[9.849836] [] (driver_attach+0x0/0x28) from [] 
(bus_add_driver+0xb8/0x21c)
[9.858596] [] (bus_add_driver+0x0/0x21c) from [] 
(driver_register+0xa8/0x138)
[9.867606]  r8:003e r7: r6:c07b3f64 r5:c033dd5c r4:c034200c
[9.874409] [] (driver_register+0x0/0x138) from [] 
(platform_driver_register+0x4c/0x60)
[9.884216] [] (platform_driver_register+0x0

Re: Second ethernet on kirkwood does not work when probed through DT

[Jonas Gorski]

On Sun, 07 Jul 2013 12:52:52 +0200
Sebastian Hesselbarth  wrote:

> On 07/06/2013 11:39 PM, Jonas Gorski wrote:
> > On Sat, 06 Jul 2013 23:22:22 +0200
> > Sebastian Hesselbarth  wrote:
> >> On 07/06/2013 09:54 PM, Jonas Gorski wrote:
> >>> Hello Sebastian,
> >>>
> >>> using your DT patches[1] (on top of 3.10) I can't get the second
> >>> ethernet to work on my kirkwood board.
> >>
> >> Hi Jonas,
> >>
> >> next time please name your board, because there are plenty of it.
> >> Kirkwood is just the SoC used on them.
> >
> > Oops, sorry. It's D-Link DIR-665, with a 6281. Currently not upstream,
> > but mostly supported (the switch isn't supported by DSA but works fine
> > without it).
> 
> Jonas,
> 
> sorry, I didn't realize you already sent your request on MLs. It was
> too late yesterday :P I also added Florian, Jason, and Andrew to the Cc
> list.
> 
> Ok, so the DIR665 has this switch configuration on both KW ethernet
> controllers. Just to make sure, the first one is working but the second
> isn't?

Right. Its a 7-Port switch (88E6171R) with two CPU ports, each
connected to one of the ethernet controllers. Then port vlans split the
switch into two groups; (lan1,lan2,lan3,lan4,eth0) and (wan,eth1).

The same setup is used on other kirkwood based routers (e.g. Linksys
EA4500).

> >>> (Both macs are connected to a switch, so use a fixed link, and no
> >>> phy).
> >>>
> >>> Eth1 gets probed fine, but never gets a link when brought up, and
> >>> trying to bring it down again hangs the board hard.
> >>>
> >>> Using Florian's older patches, it is brought up fine and works (after
> >>> adapting the node names of course).
> >>>
> >>> Also I noticed that you named eth1's ethernet1-port node wrongly in
> >>> (at least) your kirkwood conversion patch[2]; you used
> >>>
> >>> ð1 { status = "okay"; ethernet1-port@0 { must be @1--^ phy-handle
> >>> =<ðphy1>; }; };
> >>
> >> Can you please try to leave ethernet1-port@0 and match
> >> the one in kirkwood.dtsi?
> >>
> >> Both "ports" need reg =<0>  as there is two controllers
> >> with one port at 0 on Kirkwood.
> >
> > kirkwood.dtsi itself says ethernet1-port@1 with reg =<1>.
> >
> > Changing reg to 0 for eth1 brings:
> 
> The error below is a naming issue for the port. As there is only one
> port per controller, both reg properties of the port nodes of
> kirkwood.dtsi have to be <0> as they determine the register offset
> within the controller registers. As mentioned before, KW has a
> dual-controller, single port configuration.
> 
> So the wrong reg property in kirkwood.dtsi is a bug and I will update
> the patch.
> 
> Second, mv643xx_eth as in net-next does a
> platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number)
> which will cause two devices named mv643xx_eth_port.0 if you change
> both of the reg property to <0>.
> 
> A quick fix would be to change the above to
> platform_device_alloc(pnp->name, ppd.port_number)
> so the port devices will be named after the device nodes name.
>
> Also, for this I will prepare a patch. But the rename of the port
> devices could again raise the clock gating/loosing MAC issue.

In my case it's a non-issue as the studid D-Link U-Boot doesn't even
setup a mac for eth1, so there's nothing to lose ;).

> (I know again, why I hate this shared/port separation of mv643xx_eth)
> 
> Anyway, can you please try to have both ports reg properties set
> to <0>, with nodes named ethernet0-port@0 and ethernet1-port@0,
> and the platform_device_alloc in mv643xx_eth modified?

In addition I added a static counter for the allocated devs (to not
overwrite the pointers in port_platdev[]).

That seems to work, as now eth1 comes up and works (successfully got a
IP through DHCP).


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Second ethernet on kirkwood does not work when probed through DT

[Jonas Gorski]

On Sun, 07 Jul 2013 13:36:51 +0200
Sebastian Hesselbarth  wrote:

> On 07/07/2013 01:26 PM, Jonas Gorski wrote:
> > On Sun, 07 Jul 2013 12:52:52 +0200
> > Sebastian Hesselbarth  wrote:
> >> Anyway, can you please try to have both ports reg properties set
> >> to<0>, with nodes named ethernet0-port@0 and ethernet1-port@0,
> >> and the platform_device_alloc in mv643xx_eth modified?
> >
> > In addition I added a static counter for the allocated devs (to not
> > overwrite the pointers in port_platdev[]).
> 
> Ok, but that is not required to make it work, is it? IMHO we should
> honor what is passed by reg property, even it will be always zero
> for KW and the other Orion SoCs. Otherwise, we would implicitly put
> the numbering in the order of port nodes.

No, picking the next free "slot" should work, too - it was just the
easiest to fix the name for the alloc to what seems to be expected by
other parts.

> > That seems to work, as now eth1 comes up and works (successfully got a
> > IP through DHCP).
> 
> Ok, great. Will prepare a fix for mv643xx_eth on top of net-next. And
> an update of the kirkwood conversion patches.


Thanks,
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: mv643xx_eth: fix DT port device name

[Jonas Gorski]

On Sun,  7 Jul 2013 22:33:51 +0200
Sebastian Hesselbarth  wrote:

> Device tree support added to Marvell MV643xx ethernet driver registers
> port devices from port device nodes found on the corresponding controller
> node. The current port device name will cause the second controller to
> fail on registration because of two identical device names. This fixes
> the issue by taking the device node's name also as port device name.
> 
> Signed-off-by: Sebastian Hesselbarth 
> Reported-by: Jonas Gorski 
> ---
> Cc: Lennert Buytenhek 
> Cc: Jonas Gorski 
> Cc: net...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/net/ethernet/marvell/mv643xx_eth.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
> b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index 6495bea..1f3a03d 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -2521,7 +2521,7 @@ static int mv643xx_eth_shared_of_add_port(struct 
> platform_device *pdev,
>   of_property_read_u32(pnp, "duplex", &ppd.duplex);
>   }
>  
> - ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
> + ppdev = platform_device_alloc(pnp->name, ppd.port_number);
>   if (!ppdev)
>   return -ENOMEM;
>   ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);

This breaks ethernet completely, as there is no platform driver
registered for pnp->name ("ethernetX-port"), only for MV643XX_ETH_NAME.

Also since I didn't see a patch for it and no mentioning of it:

There's still one further issue from having two ethernet-ports with
port_number 0, it causes a device leak:

static struct platform_device *port_platdev[3];

mv643xx_eth_shared_of_add_port()
{
...
port_platdev[ppd.port_number] = ppdev;
...
}

The second port at 0 will overwrite the first and thus will never be
deleted in

mv643xx_eth_shared_of_remove()
{
...
for (n = 0; n < 3; n++) {
platform_device_del(port_platdev[n]);
port_platdev[n] = NULL;
}
}

I doubt a insmod-rmmod-insmod will go well in that case ;-)


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: mv643xx_eth: fix DT port device name

[Jonas Gorski]

On Sun, 7 Jul 2013 23:43:41 +0200
Jonas Gorski  wrote:

> On Sun,  7 Jul 2013 22:33:51 +0200
> Sebastian Hesselbarth  wrote:
> 
> > Device tree support added to Marvell MV643xx ethernet driver registers
> > port devices from port device nodes found on the corresponding controller
> > node. The current port device name will cause the second controller to
> > fail on registration because of two identical device names. This fixes
> > the issue by taking the device node's name also as port device name.
> > 
> > Signed-off-by: Sebastian Hesselbarth 
> > Reported-by: Jonas Gorski 
> > ---
> > Cc: Lennert Buytenhek 
> > Cc: Jonas Gorski 
> > Cc: net...@vger.kernel.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> >  drivers/net/ethernet/marvell/mv643xx_eth.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
> > b/drivers/net/ethernet/marvell/mv643xx_eth.c
> > index 6495bea..1f3a03d 100644
> > --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> > +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> > @@ -2521,7 +2521,7 @@ static int mv643xx_eth_shared_of_add_port(struct 
> > platform_device *pdev,
> > of_property_read_u32(pnp, "duplex", &ppd.duplex);
> > }
> >  
> > -   ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
> > +   ppdev = platform_device_alloc(pnp->name, ppd.port_number);
> > if (!ppdev)
> > return -ENOMEM;
> > ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> 
> This breaks ethernet completely, as there is no platform driver
> registered for pnp->name ("ethernetX-port"), only for MV643XX_ETH_NAME.

Looking back at our conversation, this is my fault.
I actually did not change this part as you asked, but I saw the
alloc/del issue with port 0, then added the counter and also only
replaced the ppd.port_number in the alloc with it. I had completely
forgotten at that time to replace the device name; else I would
have caught it back then.

I only caught it now because I tried your patch and wondered why there
wasn't anything registered, not because I saw the problem by review.

Sorry for that.

Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] net: mv643xx_eth: do not use port number as platform device id

[Jonas Gorski]

The port number is only local to the ethernet block, not global, so
there can be two ethernet blocks both using the same port, like
kirkwood with both using port 0.

Fix this by using the array index offset for the allocated platform
devices as the id.

Signed-off-by: Jonas Gorski 
---
 drivers/net/ethernet/marvell/mv643xx_eth.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 6495bea..c35db73 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2483,6 +2483,7 @@ static int mv643xx_eth_shared_of_add_port(struct 
platform_device *pdev,
struct resource res;
const char *mac_addr;
int ret;
+   int dev_num = 0;
 
memset(&ppd, 0, sizeof(ppd));
ppd.shared = pdev;
@@ -2503,6 +2504,14 @@ static int mv643xx_eth_shared_of_add_port(struct 
platform_device *pdev,
return -EINVAL;
}
 
+   while (dev_num < 3 && port_platdev[dev_num])
+   dev_num++;
+
+   if (dev_num == 3) {
+   dev_err(&pdev->dev, "too many ports registered\n");
+   return -EINVAL;
+   }
+
mac_addr = of_get_mac_address(pnp);
if (mac_addr)
memcpy(ppd.mac_addr, mac_addr, 6);
@@ -2521,7 +2530,7 @@ static int mv643xx_eth_shared_of_add_port(struct 
platform_device *pdev,
of_property_read_u32(pnp, "duplex", &ppd.duplex);
}
 
-   ppdev = platform_device_alloc(MV643XX_ETH_NAME, ppd.port_number);
+   ppdev = platform_device_alloc(MV643XX_ETH_NAME, dev_num);
if (!ppdev)
return -ENOMEM;
ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
@@ -2538,7 +2547,7 @@ static int mv643xx_eth_shared_of_add_port(struct 
platform_device *pdev,
if (ret)
goto port_err;
 
-   port_platdev[ppd.port_number] = ppdev;
+   port_platdev[dev_num] = ppdev;
 
return 0;
 
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] arm: ixp4xx: set cohorent_dma_mask for ethernet platform devices

[Jonas Gorski]

ARM requires the cohorent_dma_mask set, so set it for the platform
devices so that the ethernet driver has access to it.

Signed-off-by: Jonas Gorski 
---
 arch/arm/mach-ixp4xx/fsg-setup.c | 2 ++
 arch/arm/mach-ixp4xx/goramo_mlr.c| 2 ++
 arch/arm/mach-ixp4xx/ixdp425-setup.c | 3 +++
 arch/arm/mach-ixp4xx/nas100d-setup.c | 1 +
 arch/arm/mach-ixp4xx/nslu2-setup.c   | 1 +
 arch/arm/mach-ixp4xx/omixp-setup.c   | 3 +++
 arch/arm/mach-ixp4xx/vulcan-setup.c  | 2 ++
 7 files changed, 14 insertions(+)

diff --git a/arch/arm/mach-ixp4xx/fsg-setup.c b/arch/arm/mach-ixp4xx/fsg-setup.c
index 429966b7..c120e78 100644
--- a/arch/arm/mach-ixp4xx/fsg-setup.c
+++ b/arch/arm/mach-ixp4xx/fsg-setup.c
@@ -142,12 +142,14 @@ static struct platform_device fsg_eth[] = {
.id = IXP4XX_ETH_NPEB,
.dev = {
.platform_data  = fsg_plat_eth,
+   .coherent_dma_mask = DMA_BIT_MASK(32),
},
}, {
.name   = "ixp4xx_eth",
.id = IXP4XX_ETH_NPEC,
.dev = {
.platform_data  = fsg_plat_eth + 1,
+   .coherent_dma_mask = DMA_BIT_MASK(32),
},
}
 };
diff --git a/arch/arm/mach-ixp4xx/goramo_mlr.c 
b/arch/arm/mach-ixp4xx/goramo_mlr.c
index e54ff49..0d1b101 100644
--- a/arch/arm/mach-ixp4xx/goramo_mlr.c
+++ b/arch/arm/mach-ixp4xx/goramo_mlr.c
@@ -294,10 +294,12 @@ static struct platform_device device_eth_tab[] = {
.name   = "ixp4xx_eth",
.id = IXP4XX_ETH_NPEB,
.dev.platform_data  = eth_plat,
+   .dev.coherent_dma_mask  = DMA_BIT_MASK(32),
}, {
.name   = "ixp4xx_eth",
.id = IXP4XX_ETH_NPEC,
.dev.platform_data  = eth_plat + 1,
+   .dev.coherent_dma_mask  = DMA_BIT_MASK(32),
}
 };
 
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c 
b/arch/arm/mach-ixp4xx/ixdp425-setup.c
index 22d688b..f608629 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -195,10 +196,12 @@ static struct platform_device ixdp425_eth[] = {
.name   = "ixp4xx_eth",
.id = IXP4XX_ETH_NPEB,
.dev.platform_data  = ixdp425_plat_eth,
+   .dev.coherent_dma_mask  = DMA_BIT_MASK(32),
}, {
.name   = "ixp4xx_eth",
.id = IXP4XX_ETH_NPEC,
.dev.platform_data  = ixdp425_plat_eth + 1,
+   .dev.coherent_dma_mask  = DMA_BIT_MASK(32),
}
 };
 
diff --git a/arch/arm/mach-ixp4xx/nas100d-setup.c 
b/arch/arm/mach-ixp4xx/nas100d-setup.c
index ed667ce..59654f3 100644
--- a/arch/arm/mach-ixp4xx/nas100d-setup.c
+++ b/arch/arm/mach-ixp4xx/nas100d-setup.c
@@ -170,6 +170,7 @@ static struct platform_device nas100d_eth[] = {
.name   = "ixp4xx_eth",
.id = IXP4XX_ETH_NPEB,
.dev.platform_data  = nas100d_plat_eth,
+   .dev.coherent_dma_mask  = DMA_BIT_MASK(32),
}
 };
 
diff --git a/arch/arm/mach-ixp4xx/nslu2-setup.c 
b/arch/arm/mach-ixp4xx/nslu2-setup.c
index 7e55236..ff078d2 100644
--- a/arch/arm/mach-ixp4xx/nslu2-setup.c
+++ b/arch/arm/mach-ixp4xx/nslu2-setup.c
@@ -182,6 +182,7 @@ static struct platform_device nslu2_eth[] = {
.name   = "ixp4xx_eth",
.id = IXP4XX_ETH_NPEB,
.dev.platform_data  = nslu2_plat_eth,
+   .dev.coherent_dma_mask  = DMA_BIT_MASK(32),
}
 };
 
diff --git a/arch/arm/mach-ixp4xx/omixp-setup.c 
b/arch/arm/mach-ixp4xx/omixp-setup.c
index 75ef03d..b79cd51 100644
--- a/arch/arm/mach-ixp4xx/omixp-setup.c
+++ b/arch/arm/mach-ixp4xx/omixp-setup.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_LEDS_CLASS
 #include 
 #endif
@@ -190,10 +191,12 @@ static struct platform_device ixdp425_eth[] = {
.name   = "ixp4xx_eth",
.id = IXP4XX_ETH_NPEB,
.dev.platform_data  = ixdp425_plat_eth,
+   .dev.coherent_dma_mask  = DMA_BIT_MASK(32),
}, {
.name   = "ixp4xx_eth",
.id = IXP4XX_ETH_NPEC,
.dev.platform_data  = ixdp425_plat_eth + 1,
+   .dev.coherent_dma_mask  = DMA_BIT_MASK(32),
},
 };
 
diff --git a/arch/arm/mach-ixp4xx/vulcan-setup.c 
b/arch/arm/mach-ixp

[PATCH 0/2] net: fix ixp4xx_eth

[Jonas Gorski]

This patchset aims at fixing ethernet for ixp4xx, which is broken since
3.7. It is basedon discussion to the patch from Krzysztof Halasa [1],
following Russel King's suggestion.

This patchset is currently in use at OpenWrt and successfully tested
on Linksys NSLU2.

These patches are independent of each other, so they could go each in
a different tree or both in the same, and the order does not matter.

[1] https://patchwork.kernel.org/patch/2325151/

Jonas Gorski (2):
  arm: ixp4xx: set cohorent_dma_mask for ethernet platform devices
  net: ixp4xx_eth: use parent device for dma allocations

 arch/arm/mach-ixp4xx/fsg-setup.c |  2 ++
 arch/arm/mach-ixp4xx/goramo_mlr.c|  2 ++
 arch/arm/mach-ixp4xx/ixdp425-setup.c |  3 +++
 arch/arm/mach-ixp4xx/nas100d-setup.c |  1 +
 arch/arm/mach-ixp4xx/nslu2-setup.c   |  1 +
 arch/arm/mach-ixp4xx/omixp-setup.c   |  3 +++
 arch/arm/mach-ixp4xx/vulcan-setup.c  |  2 ++
 drivers/net/ethernet/xscale/ixp4xx_eth.c | 23 ---
 8 files changed, 26 insertions(+), 11 deletions(-)

-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] net: ixp4xx_eth: use parent device for dma allocations

[Jonas Gorski]

Now that the platfomr device provides a dma_cohorent_mask, use it for
dma operations.

This fixes ethernet on ixp4xx which was broken since 3.7.

Signed-off-by: Jonas Gorski 
---
 drivers/net/ethernet/xscale/ixp4xx_eth.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c 
b/drivers/net/ethernet/xscale/ixp4xx_eth.c
index 3d689fc..18aa660 100644
--- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -641,10 +641,10 @@ static inline void queue_put_desc(unsigned int queue, u32 
phys,
 static inline void dma_unmap_tx(struct port *port, struct desc *desc)
 {
 #ifdef __ARMEB__
-   dma_unmap_single(&port->netdev->dev, desc->data,
+   dma_unmap_single(port->netdev->dev.parent, desc->data,
 desc->buf_len, DMA_TO_DEVICE);
 #else
-   dma_unmap_single(&port->netdev->dev, desc->data & ~3,
+   dma_unmap_single(port->netdev->dev.parent, desc->data & ~3,
 ALIGN((desc->data & 3) + desc->buf_len, 4),
 DMA_TO_DEVICE);
 #endif
@@ -711,9 +711,9 @@ static int eth_poll(struct napi_struct *napi, int budget)
 
 #ifdef __ARMEB__
if ((skb = netdev_alloc_skb(dev, RX_BUFF_SIZE))) {
-   phys = dma_map_single(&dev->dev, skb->data,
+   phys = dma_map_single(dev->dev.parent, skb->data,
  RX_BUFF_SIZE, DMA_FROM_DEVICE);
-   if (dma_mapping_error(&dev->dev, phys)) {
+   if (dma_mapping_error(dev->dev.parent, phys)) {
dev_kfree_skb(skb);
skb = NULL;
}
@@ -736,10 +736,11 @@ static int eth_poll(struct napi_struct *napi, int budget)
 #ifdef __ARMEB__
temp = skb;
skb = port->rx_buff_tab[n];
-   dma_unmap_single(&dev->dev, desc->data - NET_IP_ALIGN,
+   dma_unmap_single(dev->dev.parent, desc->data - NET_IP_ALIGN,
 RX_BUFF_SIZE, DMA_FROM_DEVICE);
 #else
-   dma_sync_single_for_cpu(&dev->dev, desc->data - NET_IP_ALIGN,
+   dma_sync_single_for_cpu(dev->dev.parent,
+   desc->data - NET_IP_ALIGN,
RX_BUFF_SIZE, DMA_FROM_DEVICE);
memcpy_swab32((u32 *)skb->data, (u32 *)port->rx_buff_tab[n],
  ALIGN(NET_IP_ALIGN + desc->pkt_len, 4) / 4);
@@ -858,7 +859,7 @@ static int eth_xmit(struct sk_buff *skb, struct net_device 
*dev)
memcpy_swab32(mem, (u32 *)((int)skb->data & ~3), bytes / 4);
 #endif
 
-   phys = dma_map_single(&dev->dev, mem, bytes, DMA_TO_DEVICE);
+   phys = dma_map_single(dev->dev.parent, mem, bytes, DMA_TO_DEVICE);
if (dma_mapping_error(&dev->dev, phys)) {
dev_kfree_skb(skb);
 #ifndef __ARMEB__
@@ -1104,7 +1105,7 @@ static int init_queues(struct port *port)
int i;
 
if (!ports_open) {
-   dma_pool = dma_pool_create(DRV_NAME, &port->netdev->dev,
+   dma_pool = dma_pool_create(DRV_NAME, port->netdev->dev.parent,
   POOL_ALLOC_SIZE, 32, 0);
if (!dma_pool)
return -ENOMEM;
@@ -1132,9 +1133,9 @@ static int init_queues(struct port *port)
data = buff;
 #endif
desc->buf_len = MAX_MRU;
-   desc->data = dma_map_single(&port->netdev->dev, data,
+   desc->data = dma_map_single(port->netdev->dev.parent, data,
RX_BUFF_SIZE, DMA_FROM_DEVICE);
-   if (dma_mapping_error(&port->netdev->dev, desc->data)) {
+   if (dma_mapping_error(port->netdev->dev.parent, desc->data)) {
free_buffer(buff);
return -EIO;
}
@@ -1154,7 +1155,7 @@ static void destroy_queues(struct port *port)
struct desc *desc = rx_desc_ptr(port, i);
buffer_t *buff = port->rx_buff_tab[i];
if (buff) {
-   dma_unmap_single(&port->netdev->dev,
+   dma_unmap_single(port->netdev->dev.parent,
 desc->data - NET_IP_ALIGN,
 RX_BUFF_SIZE, DMA_FROM_DEVICE);
free_buffer(buff);
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MIPS: Get rid of CONFIG_CPU_HAS_LLSC again

[Jonas Gorski]

On 5 March 2013 11:03, Paul Bolle  wrote:
> Commit f7ade3c168e4f437c11f57be012992bbb0e3075c ("MIPS: Get rid of
> CONFIG_CPU_HAS_LLSC") did what it promised to do. But since then that
> macro and its Kconfig symbol popped up again. Get rid of those again.
>
> Signed-off-by: Paul Bolle 
> ---
> 0) Untested.

Obviously :p.

> 1) The related commits are 1c773ea4dceff889c2f872343609a87ae0cfbf56
> ("MIPS: Netlogic: Add XLP makefiles and config") and
> 3070033a16edcc21688d5ea8967c89522f833862 ("MIPS: Add core files for MIPS
> SEAD-3 development platform.").
>
>  arch/mips/Kconfig| 1 -
>  arch/mips/include/asm/mach-sead3/cpu-feature-overrides.h | 3 ---
>  2 files changed, 4 deletions(-)
>
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index ae9c716..310f1e6 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -1493,7 +1493,6 @@ config CPU_XLP
> select CPU_SUPPORTS_32BIT_KERNEL
> select CPU_SUPPORTS_64BIT_KERNEL
> select CPU_SUPPORTS_HIGHMEM
> -   select CPU_HAS_LLSC
> select WEAK_ORDERING
> select WEAK_REORDERING_BEYOND_LLSC
> select CPU_HAS_PREFETCH
> diff --git a/arch/mips/include/asm/mach-sead3/cpu-feature-overrides.h 
> b/arch/mips/include/asm/mach-sead3/cpu-feature-overrides.h
> index d9c8284..2a945b4 100644
> --- a/arch/mips/include/asm/mach-sead3/cpu-feature-overrides.h
> +++ b/arch/mips/include/asm/mach-sead3/cpu-feature-overrides.h
> @@ -28,9 +28,6 @@
>  /* #define cpu_has_prefetch? */
>  #define cpu_has_mcheck 1
>  /* #define cpu_has_ejtag   ? */
> -#ifdef CONFIG_CPU_HAS_LLSC
> -#define cpu_has_llsc   1
> -#else
>  #define cpu_has_llsc   0
>  #endif

You need to remove these two lines, too, else you have an #endif without an #if.

>  /* #define cpu_has_vtag_icache ? */
> --
> 1.7.11.7
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] MIPS: Get rid of CONFIG_CPU_HAS_LLSC again

[Jonas Gorski]

On 5 March 2013 13:20, Paul Bolle  wrote:
> Commit f7ade3c168e4f437c11f57be012992bbb0e3075c ("MIPS: Get rid of
> CONFIG_CPU_HAS_LLSC") did what it promised to do. But since then that
> macro and its Kconfig symbol popped up again. Get rid of those again.

Now let's do a review of the contents.

> Signed-off-by: Paul Bolle 
> ---
> 0) This version fixes an embarrassing dangling "#endif" spotted by
> Jonas. Thanks for that! Still untested.
>
> 1) The related commits are 1c773ea4dceff889c2f872343609a87ae0cfbf56
> ("MIPS: Netlogic: Add XLP makefiles and config") and
> 3070033a16edcc21688d5ea8967c89522f833862 ("MIPS: Add core files for MIPS
> SEAD-3 development platform.").
>
>  arch/mips/Kconfig| 1 -
>  arch/mips/include/asm/mach-sead3/cpu-feature-overrides.h | 4 
>  2 files changed, 5 deletions(-)
>
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index ae9c716..310f1e6 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -1493,7 +1493,6 @@ config CPU_XLP
> select CPU_SUPPORTS_32BIT_KERNEL
> select CPU_SUPPORTS_64BIT_KERNEL
> select CPU_SUPPORTS_HIGHMEM
> -   select CPU_HAS_LLSC
> select WEAK_ORDERING
> select WEAK_REORDERING_BEYOND_LLSC
> select CPU_HAS_PREFETCH
> diff --git a/arch/mips/include/asm/mach-sead3/cpu-feature-overrides.h 
> b/arch/mips/include/asm/mach-sead3/cpu-feature-overrides.h
> index d9c8284..b40f37f 100644
> --- a/arch/mips/include/asm/mach-sead3/cpu-feature-overrides.h
> +++ b/arch/mips/include/asm/mach-sead3/cpu-feature-overrides.h
> @@ -28,11 +28,7 @@
>  /* #define cpu_has_prefetch? */
>  #define cpu_has_mcheck 1
>  /* #define cpu_has_ejtag   ? */
> -#ifdef CONFIG_CPU_HAS_LLSC
> -#define cpu_has_llsc   1
> -#else
>  #define cpu_has_llsc   0
> -#endif

Hm, shouldn't you leave cpu_has_llsc set to 1? At least the "old" path
SEAD3 => CPU_MIPS32_R1/R2/64_R1 => select CPU_HAS_LLSC for all three
would have always caused this to be 1.

>  /* #define cpu_has_vtag_icache ? */
>  /* #define cpu_has_dc_aliases  ? */
>  /* #define cpu_has_ic_fills_f_dc ? */
> --
> 1.7.11.7
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MIPS: remove USB_EHCI_BIG_ENDIAN_{DESC,MMIO} depends on architecture symbol

[Jonas Gorski]

On Thu, May 2, 2013 at 9:39 AM, EUNBONG SONG  wrote:
>
> This patch removes the architecture specific symbols which prevent these
> configuration symbols from being selected by platforms/architectures 
> requiring it.
> I reference commit 9296d94d83649e1c2f25c87dc4ead9c2ab073305.

These are selects and don't prevent anyone else from also selecting
them. If you look at your referenced commit, you see it removed the
/depends/, not the selects. It actually added selects to several
platforms. Platforms are supposed to select them if they need them.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mips; boot fail after merge 3.9+

[Jonas Gorski]

On Wed, May 1, 2013 at 6:57 AM, EUNBONG SONG  wrote:
>
> Hello.
> After merge cavium board boots fail, boot log messages are as follows.
> I enabled initcall_debug for debugging.

I can confirm that MIPS does not seem to finish to boot after using
the generic idle loop, I have the same problem on a different platform
(bcm63xx), and bisecting showed the same commit.

(snip)

> I found this issue after cdbedc61c8d0122ad682815936f0d11df1fe5f57.
> And i found something strange. I ran the git show for this commit.
> As below "select GENERIC_IDLE_LOOP" is added for CONFIG_MIPS.
> but the latest arch/mips/Kconfig file has not this one. I have tried to find 
> when this is gone. but i can't find.
> Is there any problem with this?

No, after all architectures were converted to use the generic idle
loop the config symbol was removed, so it's now always on. The problem
is rather that the generic idle loop does not seem to work on MIPS.
Unfortunately due to limited knowledge in this area I can't really
tell which part broke it.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [PATCH] MIPS: remove USB_EHCI_BIG_ENDIAN_{DESC,MMIO} depends on architecture symbol

[Jonas Gorski]

On Thu, May 2, 2013 at 11:27 AM, EUNBONG SONG  wrote:
>
>>These are selects and don't prevent anyone else from also selecting
>> them. If you look at your referenced commit, you see it removed the
>>/depends/, not the selects. It actually added selects to several
>> platforms. Platforms are supposed to select them if they need them.
>
> Hello.
> Every time i config with arch/mips/configs/cavium_octeon_defconfig, the 
> following warning messages
> are showed.
> warning: (MIPS_SEAD3 && PMC_MSP && CPU_CAVIUM_OCTEON) selects 
> USB_EHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && 
> USB && USB_EHCI_HCD)
> warning: (MIPS_SEAD3 && PMC_MSP && CPU_CAVIUM_OCTEON) selects 
> USB_EHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && 
> USB && USB_EHCI_HCD)
>
> And after applying this patch, the warning messages were disappeared.

But after this patch likely EHCI is also broken on these platforms.
The solution is to either guard the USB_EHCI_BIG_ENDIAN_MMIO/DESC
selects with if USB_EHCI_HCD etc, or make
USB_EHCI_BIG_ENDIAN_MMIO/DESC not depend on USB_EHCI_HCD etc.

As far as I can tell, USB_EHCI_BIG_ENDIAN_MMIO/DESC only have any
effect on the ehci_hcd code anyway, so removing the dependencies of
these symbols should be fine and without any side effects, thus allow
platforms/drivers to select them unconditionally.

Greg, what do you think?


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mips; boot fail after merge 3.9+

[Jonas Gorski]

On Thu, May 2, 2013 at 12:42 PM, Thomas Gleixner  wrote:
> Does the patch below fix your issue ?

Does not work for me either. I don't even have SMP enabled, so this
codepath isn't taken for me at all.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MIPS: Enable interrupts before WAIT instruction.

[Jonas Gorski]

On Thu, May 2, 2013 at 11:04 PM, Thomas Gleixner  wrote:
>
>
> On Thu, 2 May 2013, David Daney wrote:
>
>> From: David Daney 
>>
>> As noted by Thomas Gleixner:
>>
>>commit cdbedc61c8 (mips: Use generic idle loop) broke MIPS as I did
>>not realize that MIPS wants to invoke the wait instructions with
>>interrupts enabled.
>>
>> Instead of enabling interrupts in arch_cpu_idle() as Thomas' initial
>> patch does, we follow Linus' suggestion of doing it in the assembly
>> code to prevent the compiler from rearranging things.
>
> Yeah, that looks way more sane.

In a first quick test I can also confirm that it seems to work (as an
alternative to the other fix).


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] checkpatch: whitelist SUPPORTED_*/ADVERTISED_* defines from ethtool.h

[Jonas Gorski]

Don't complain about camelcase when using SUPPORTED_*/ADVERTISED_*
defines, they are part of the user api so can't be (easily) fixed.

Removes false positives in e.g. ethernet drivers like:

WARNING: Avoid CamelCase: 
+ SUPPORTED_Autoneg |

Signed-off-by: Jonas Gorski 
---
 scripts/checkpatch.pl |1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index b28cc38..349559a4 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2931,6 +2931,7 @@ sub process {
if ($var !~ /$Constant/ &&
$var =~ /[A-Z]\w*[a-z]|[a-z]\w*[A-Z]/ &&
$var !~ 
/"^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ &&
+   $var !~ /^(?:SUPPORTED|ADVERTISED)_\w*/ &&
!defined $camelcase{$var}) {
$camelcase{$var} = 1;
WARN("CAMELCASE",
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Would like to form a pool of Linux copyright holders for faster GPL enforcement against Anthrax Kernels

[Jonas Gorski]

On Sun, May 19, 2013 at 12:39 PM, luke.leighton  wrote:
> On Sun, May 19, 2013 at 12:03 AM, Cole Johnson
>  wrote:
>>> question: what is the procedure for having that licensing explicitly
>>
>> added to the linux kernel sources?
>>
>> IIRC Linus said he will NOT use the GPLv3 for the kernel.
>
>  mr linus torvalds is one person.  he is not a god.  he does not
> dictate that which everyone else can choose to do.  if mr linus
> torvalds is telling everyone "he will not use the GPLv3 for the
> kernel" i.e. NOBODY may dual-license their copyright material in the
> linux kernel then he is *MASSIVELY* overstepping a serious boundary of
> both propriety and copyright law.  if i choose to release all
> copyright code under dual licenses then THAT IS MY RIGHT AND NO FUCKER
> IS GOING TO TELL ME OTHERWISE.
>
>  so, let's nip this in the bud and set it straight, ok?
>
>  i assume that what mr linus torvalds *meant* to say was "i have some
> code, it is under my copyright.  i personally choose not to release
> that copyright material under any license other than the GPLv2 and
> that is my choice and my right as the owner of that copyright
> material.  signed, mr linus torvalds".
>
>  that choice - made by mr linus torvalds - has *nothing to do with
> anybody else's choice*.
>
>  so the question remains, and i'd like an answer: what is the
> procedure for formally adding to the linux kernel that my copyrighted
> material is dual-licensed under both the GPLv2 and the GPLv3+?  do i
> submit a patch, and is it as simple as that?
>
>  unless unless what mr linus torvalds meant to say was, "i don't
> like the GPLv3+ license.  if any fucker wants to release linux kernel
> code under the GPLv3+ (as well as the GPLv2), they can fuck off.  in
> fact, they will be banned from submitting contributions that are not
> specifically GPLv2.  if they try to dual-license their code, it will
> not be accepted. i, linus torvalds, have spoken".  which i seriously
> seriously doubt, but there seems to be some implication that that's
> the case, here.

But dual license means the license taker may chose which license to
apply, not that you can dictate which one to use. And as long as any
part of the kernel is GPLv2 (no +), (s)he can't choose anything except
GPLv2, as GPLv2 and GPLv3 are incompatible.

So any further licenses will never apply to any use in the kernel.
Only if somebody took your code out of the kernel and used it in a
separate GPLv3+ project, then the GPLv3+ license could and would
apply.

Also GPLv2 + GPLv3+ == GPLv2+. And there are already plenty of
examples in the kernel that are GPLv2+ licensed (try searching for "or
later").


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Would like to form a pool of Linux copyright holders for faster GPL enforcement against Anthrax Kernels

[Jonas Gorski]

On Sun, May 19, 2013 at 2:34 PM, luke.leighton  wrote:
> On Sun, May 19, 2013 at 12:19 PM, Jonas Gorski
>  wrote:
>
>> But dual license means the license taker may chose which license to
>> apply, not that you can dictate which one to use.
>
>  yes.
>
>> And as long as any
>> part of the kernel is GPLv2 (no +), (s)he can't choose anything except
>> GPLv2, as GPLv2 and GPLv3 are incompatible.
>
>  that doesn't sound right.  actually, this is a very very important
> misunderstanding, jonas.
>
>  you *can* choose GPLv3 code.  what you can choose is: *only* those
> files of the linux kernel that are released under GPLv3.
>
>
>  pseudo-algorithm in bash script and maybe a bit of python:
>
>  $ filenames_gplv3 = `find . | xargs grep -l GPLv3`
>  $ filenames_gplv2 = `find . | xargs grep -l GPLv2`
>  $ files_to_delete = []
>  $ for x in filenames_gplv2:
> if x not in filenames_gplv2:
> files_to_delete.append(x)
>  $ for x in files_to_delete:
>  rm $x
>
> after that procedure is done, _then_ try doing a kernel compile, see
> how far you get.

This will produce an empty directory.

There are 0 files released under GPLv3 (because its incompatible with
GPLv2). There are some release under GPLv2+, but this is mostly
drivers and architecture specific code, and a collection of drivers
does not make a kernel.

Almost nothing of the parts that define a kernel (like memory and
process management) are GPLv2+. Therefore I say the kernel will always
be GPLv2, no matter how many files you *add* that are GPLv2+.

> many people point out that just because this is unlikely to result in
> success any time in the next 100 years, that nobody should bother even
> starting.

Because Linus /is/ the highest authority regarding Linux. He holds the
copyright to the most crucial parts, and without his cooperation, you
will never get the GPLv2 parts to be re-licensed to GPLv2+, unless you
remove everything from him and replace it with your own
implementations. And do the same with every other contributors' code
who doesn't agree to switch to GPLv2+.

>> So any further licenses will never apply to any use in the kernel.
>
>  incorrect!!  logical assertion error!! :)  
> assert(ELOGICALCONCLUSIONBRAINFART)
>
>> Only if somebody took your code out of the kernel and used it in a
>> separate GPLv3+ project, then the GPLv3+ license could and would
>> apply.
>
>  after reviewing the above pseudo-code i believe you'll agree that
> that's slightly misleading. one could also choose to leave the files
> in-place in the *same* project's source tree, and just not use any of
> the ones that were incompatibly-licensed.

Have fun with that. That isn't a kernel any more, that's a loose
collection of drivers and architecture support code.

You will have to re-invent every GPLv2 only part they link
against/require, or rewrite the GPLv2+ code to not use it. And if you
finally got it to work, it has already become a separate project as it
won't have much resemblance with the Linux kernel any more. ;-)

Also no company will ever bother to do that, because choosing GPLv3
will only bring disadvantages to them. And writing their own kernel/OS
will likely be less work and more rewarding, because then they own the
copyright for it and can choose any license they want.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] MIPS: fix module.c build for 32 bit

[Jonas Gorski]

Fixes the following build failure introduced by "Make most arch
asm/module.h files use asm-generic/module.h".

  CC  arch/mips/kernel/module.o
arch/mips/kernel/module.c:250:14: error: 'reloc_handlers_rela' defined but not 
used [-Werror=unused-variable]
cc1: all warnings being treated as errors

make[6]: *** [arch/mips/kernel/module.o] Error 1

Signed-off-by: Jonas Gorski 

---
I don't mind this patch being squashed into the original patch. The
patch isn't in any stable git yet, so I assume any git id would be
outdated soon anyway.

Linus, I CC'd you because there already is a pending pull request for
this patch.

David, it would have been nice if the mentioned patch had made it to 
linux-mips. I just caught this more or less by accident by building
linux-next.

 arch/mips/kernel/module.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/mips/kernel/module.c b/arch/mips/kernel/module.c
index 1500c80..afbd717 100644
--- a/arch/mips/kernel/module.c
+++ b/arch/mips/kernel/module.c
@@ -65,12 +65,14 @@ static int apply_r_mips_32_rel(struct module *me, u32 
*location, Elf_Addr v)
return 0;
 }
 
+#ifdef CONFIG_MODULES_USE_ELF_RELA
 static int apply_r_mips_32_rela(struct module *me, u32 *location, Elf_Addr v)
 {
*location = v;
 
return 0;
 }
+#endif
 
 static int apply_r_mips_26_rel(struct module *me, u32 *location, Elf_Addr v)
 {
@@ -93,6 +95,7 @@ static int apply_r_mips_26_rel(struct module *me, u32 
*location, Elf_Addr v)
return 0;
 }
 
+#ifdef CONFIG_MODULES_USE_ELF_RELA
 static int apply_r_mips_26_rela(struct module *me, u32 *location, Elf_Addr v)
 {
if (v % 4) {
@@ -112,6 +115,7 @@ static int apply_r_mips_26_rela(struct module *me, u32 
*location, Elf_Addr v)
 
return 0;
 }
+#endif
 
 static int apply_r_mips_hi16_rel(struct module *me, u32 *location, Elf_Addr v)
 {
@@ -134,6 +138,7 @@ static int apply_r_mips_hi16_rel(struct module *me, u32 
*location, Elf_Addr v)
return 0;
 }
 
+#ifdef CONFIG_MODULES_USE_ELF_RELA
 static int apply_r_mips_hi16_rela(struct module *me, u32 *location, Elf_Addr v)
 {
*location = (*location & 0x) |
@@ -141,6 +146,7 @@ static int apply_r_mips_hi16_rela(struct module *me, u32 
*location, Elf_Addr v)
 
return 0;
 }
+#endif
 
 static int apply_r_mips_lo16_rel(struct module *me, u32 *location, Elf_Addr v)
 {
@@ -206,6 +212,7 @@ out_danger:
return -ENOEXEC;
 }
 
+#ifdef CONFIG_MODULES_USE_ELF_RELA
 static int apply_r_mips_lo16_rela(struct module *me, u32 *location, Elf_Addr v)
 {
*location = (*location & 0x) | (v & 0x);
@@ -237,6 +244,7 @@ static int apply_r_mips_highest_rela(struct module *me, u32 
*location,
 
return 0;
 }
+#endif
 
 static int (*reloc_handlers_rel[]) (struct module *me, u32 *location,
Elf_Addr v) = {
@@ -247,6 +255,7 @@ static int (*reloc_handlers_rel[]) (struct module *me, u32 
*location,
[R_MIPS_LO16]   = apply_r_mips_lo16_rel
 };
 
+#ifdef CONFIG_MODULES_USE_ELF_RELA
 static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
Elf_Addr v) = {
[R_MIPS_NONE]   = apply_r_mips_none,
@@ -258,6 +267,7 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32 
*location,
[R_MIPS_HIGHER] = apply_r_mips_higher_rela,
[R_MIPS_HIGHEST]= apply_r_mips_highest_rela
 };
+#endif
 
 int apply_relocate(Elf_Shdr *sechdrs, const char *strtab,
   unsigned int symindex, unsigned int relsec,
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SPI: bcm63xx_dev_spi.h

[Jonas Gorski]

On 12 July 2012 22:55, Paul Bolle  wrote:
> 0) Commit b42dfed83d95a3c9e9cbd708f1993a7474abb79a ("spi: add Broadcom
> BCM63xx SPI controller driver") added drivers/spi/spi-bcm63xx.c to the
> mainline tree. That file includes bcm63xx_dev_spi.h.
>
> 1) bcm63xx_dev_spi.h is not part of the current tree, and, as far as I
> can tell, has actually never been part of the tree. So it seems that
> this driver could never be built using the mainline tree since it got
> added (in v3.4).
>
> 2) What's the current status of this header?

It currently sits in Ralf Baechle's queue and waits for the merge window:

http://git.linux-mips.org/?p=ralf/upstream-sfr.git;a=commit;h=435f920f35e90b4681e68002d2e2f6724b0c21b7


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] MIPS: BCM63XX: select HAVE_CLK

[Jonas Gorski]

BCM63XX implements the clk interface, but does not advertise it.

Signed-off-by: Jonas Gorski 
---

This fixes a build failure in linux-next caused by
5afae362dc79cb8b6b3965422d13d118c63d4ee4 ("clk: Add non CONFIG_HAVE_CLK
routines"):

  CC  arch/mips/bcm63xx/clk.o
arch/mips/bcm63xx/clk.c:285:5: error: redefinition of 'clk_enable'
include/linux/clk.h:294:19: note: previous definition of 'clk_enable' was here

and so on (I think you have already seen one of these).

@Andrew: This patch should apply cleanly to any tree, so maybe you
could add it to your patch series in front of the mentioned
patch, to keep bisectability for bcm63xx.

@Ralf: I hope it is okay for you that this goes through a different
tree.

 arch/mips/Kconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 09ab87e..80d9199 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -122,6 +122,7 @@ config BCM63XX
select SYS_HAS_EARLY_PRINTK
select SWAP_IO_SPACE
select ARCH_REQUIRE_GPIOLIB
+   select HAVE_CLK
help
 Support for BCM63XX based boards
 
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/8] PCI: host: brcmstb: add DT docs for Brcmstb PCIe device

[Jonas Gorski]

Hi,

On 24 October 2017 at 20:15, Jim Quinlan  wrote:
> The DT bindings description of the Brcmstb PCIe device is described.  This
> node can be used by almost all Broadcom settop box chips, using
> ARM, ARM64, or MIPS CPU architectures.
>
> Signed-off-by: Jim Quinlan 
> ---
>  .../devicetree/bindings/pci/brcmstb-pci.txt| 63 
> ++
>  1 file changed, 63 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pci.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/brcmstb-pci.txt 
> b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> new file mode 100644
> index 000..49f9852
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/brcmstb-pci.txt
> @@ -0,0 +1,63 @@
> +Brcmstb PCIe Host Controller Device Tree Bindings
> +
> +Required Properties:
> +- compatible
> +  "brcm,bcm7425-pcie" -- for 7425 family MIPS-based SOCs.
> +  "brcm,bcm7435-pcie" -- for 7435 family MIPS-based SOCs.
> +  "brcm,bcm7445-pcie" -- for 7445 and later ARM based SOCs (not including
> +  the 7278).
> +  "brcm,bcm7278-pcie"  -- for 7278 family ARM-based SOCs.
> +

(snip)

> +
> +Example Node:
> +
> +pcie0: pcie@f046 {
> +   reg = <0x0 0xf046 0x0 0x9310>;
> +   interrupts = <0x0 0x0 0x4>;
> +   compatible = "brcm,pci-plat-dev";

This is not one of the valid compatibles mentioned above.


Regards
Jonas

Re: [PATCH linux-next v5 1/5] mtd: spi-nor: notify (Q)SPI controller about protocol change

[Jonas Gorski]

Hi,

On Thu, Aug 27, 2015 at 11:51 AM, Cyrille Pitchen
 wrote:
> Hi Jonas,
>
> Le 26/08/2015 16:02, Jonas Gorski a écrit :
>> On Wed, Aug 26, 2015 at 2:30 PM, Cyrille Pitchen
>>  wrote:
>>> Once the Quad SPI mode has been enabled on a Micron flash memory, this
>>> device expects ALL the following commands to use the SPI 4-4-4 protocol.
>>> The (Q)SPI controller needs to be notified about the protocol change so it
>>> can adapt and keep on dialoging with the Micron memory.
>>
>> Doesn't that mean you need to disable quad mode on removal? Else the
>> following will break/fail:
>>
>> insmod atmel-quadspi.ko ~> spi-nor attaches -> sees micron -> enables quad 
>> mode
>> rmmod atmel-quadspi.ko ~> spi-nor detaches
>> insmod atmel-quadspi.ko ~> spi-nor attaches -> fails to read the id
>> because flash is still in quad mode.
>>
>
> Indeed you're right such an issue does exist. So as you said one solution
> could be create a new function to "clean" what have been done by 
> spi_nor_scan()
> then call it from remove() function of each driver calling spi_nor_scan() from
> its probe().
> However we could also enhance the probing of the memory. It is true that 
> Micron
> spi nor memories only accept SPI 4-4-4 commands once switched in quad mode but
> actually they also provide a new command for this purpose:
> "Multiple I/O Read ID" (0xAF).
> Hence we could first try to probe using the regular Read ID (0x9F) command 
> then
> change the protocol, for instance to SPI 4-4-4, and try the 0xAF command.
> I don't think all combinations for command/protocol need to be tested: for
> Micron memories, their datasheets claim the 0x9F command is only supported in
> "extended spi mode" so for the SPI 1-1-1 protocol whereas the 0xAF command
> only works in dual or quad modes.
> On the other hand Spansion memories still reply to the regular 0x9F command in
> SPI 1-1-1 protocol even after their quad mode had been enabled.
> For other manufacturers, well... I don't know!

At least from the two spansion datasheets I looked at, there is no 2_
or 4_ mode for spansion flashes, and the quad mode only enables the
1_x_4 commands, where as on micron the 1_x_4 commands are always
available, and you only need to switch to DIO or QIO if you want to
use 2_2_2 or 4_4_4.

The question is how to detect if the READID command failed. Hopefully
it will result in an invalid command, and we get 0xff... (or 0x00...)
for the the id. And from there on we can first test 4_4_4 MIORDID (so
it won't a a full command on a DIO-enabled flash), and if that fails,
2_2_2. We need to tell the spi-nor controller to send these
accordingly though. I wonder if it might not be better to pass the
c_a_d as an additional parameter to the read_reg/write_reg etc call
backs, because they might change depending on the command used. E.g.
when using SPI_NOR_QUAD, we might want to make use of the quad page
program command (which is 1_1_4), but there is no 1_1_2 version, so we
cannot rely on a global "protocol" member for that, unless we want to
do a set_protocol before every command.

>
> Some of the advantages of the probe solution as compared to the remove one 
> are:
> - we don't need to patch all drivers using spi_nor_scan() to call a new
>   function from their remove().
> - it doesn't rely on the assumption that the spi-nor memory starts in
>   SPI 1-1-1 protocol. As a matter of fact the remove() won't be called for
>   built-in modules or in many (all ?) cases of reset. Moreover some 
> bootloaders
>   may have already enabled the quad mode before starting the Linux kernel. 
> This
>   is what the sama5d2 romcode does when it is configured to boot from a QSPI
>   memory.
>
> Anyway you're right and the issue need to be addressed but maybe in another
> dedicated patch ?

Yes, probably as a prerequisite to the quad mode on micron flashes. I
think we should also add a separate flag for the DIO/QIO modes for
micron flashes, as these are something separate from just the DOR/QOR
commands usually implied by SPI_NOR_DUAL/QUAD (well they are the same,
but work differently)

>>> Signed-off-by: Cyrille Pitchen 
>>> Acked-by: Marek Vasut 
>>> Acked-by: Bean Huo 
>>> ---
>>>  drivers/mtd/spi-nor/spi-nor.c | 21 +
>>>  include/linux/mtd/spi-nor.h   | 13 +
>>>  2 files changed, 34 insertions(+)
>>>
>>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>>> index c27d427fead4..c8810313a752 100644
>>> --- a/drivers/mtd/spi-nor/spi-nor.c
>>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>>> @@ -165,6 +165,22

[PATCH] irqchip/bcm7038-l1: hide cpu offline callback when building for !SMP

[Jonas Gorski]

When compiling bmips with SMP disabled, the build fails with:

drivers/irqchip/irq-bcm7038-l1.o: In function `bcm7038_l1_cpu_offline':
drivers/irqchip/irq-bcm7038-l1.c:242: undefined reference to 
`irq_set_affinity_locked'
make[5]: *** [vmlinux] Error 1

Fix this by adding and setting bcm7038_l1_cpu_offline only when actually
compiling for SMP. It wouldn't have been used anyway, as it requires
CPU_HOTPLUG, which in turn requires SMP.

Fixes: 34c535793bcb ("irqchip/bcm7038-l1: Implement irq_cpu_offline() callback")
Signed-off-by: Jonas Gorski 
---
 drivers/irqchip/irq-bcm7038-l1.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/irqchip/irq-bcm7038-l1.c b/drivers/irqchip/irq-bcm7038-l1.c
index faf734ff4cf3..0f6e30e9009d 100644
--- a/drivers/irqchip/irq-bcm7038-l1.c
+++ b/drivers/irqchip/irq-bcm7038-l1.c
@@ -217,6 +217,7 @@ static int bcm7038_l1_set_affinity(struct irq_data *d,
return 0;
 }
 
+#ifdef CONFIG_SMP
 static void bcm7038_l1_cpu_offline(struct irq_data *d)
 {
struct cpumask *mask = irq_data_get_affinity_mask(d);
@@ -241,6 +242,7 @@ static void bcm7038_l1_cpu_offline(struct irq_data *d)
}
irq_set_affinity_locked(d, &new_affinity, false);
 }
+#endif
 
 static int __init bcm7038_l1_init_one(struct device_node *dn,
  unsigned int idx,
@@ -293,7 +295,9 @@ static struct irq_chip bcm7038_l1_irq_chip = {
.irq_mask   = bcm7038_l1_mask,
.irq_unmask = bcm7038_l1_unmask,
.irq_set_affinity   = bcm7038_l1_set_affinity,
+#ifdef CONFIG_SMP
.irq_cpu_offline= bcm7038_l1_cpu_offline,
+#endif
 };
 
 static int bcm7038_l1_map(struct irq_domain *d, unsigned int virq,
-- 
2.13.2

Re: [PATCH AUTOSEL for 4.9 002/219] spi/bcm63xx: make spi subsystem aware of message size limits

[Jonas Gorski]

On 5 March 2018 at 21:35, Mark Brown  wrote:
> On Mon, Mar 05, 2018 at 08:07:46PM +, Sasha Levin wrote:
>> On Mon, Mar 05, 2018 at 10:23:10AM +, Mark Brown wrote:
>> >On Sat, Mar 03, 2018 at 10:27:56PM +, Sasha Levin wrote:
>
>> >> The bcm63xx SPI controller does not allow manual control of the CS
>> >> lines and will toggle it automatically before and after sending data,
>> >> so we are limited to messages that fit in the FIFO buffer. Since the CS
>> >> lines aren't available as GPIOs either, we will need to make slave
>> >> drivers aware of this limitation so they can handle them accordingly.
>
>> >This seems really aggressive for stable...
>
>> Why so?
>
> It's exposing more capability information but it's in the "how did this
> ever work without the fix" range, and I'd worry that this might cause us
> to do something like start exercising handling code in client drivers
> that had never been tested.  Not that I can immediately see any client
> drivers in mainline that actually pay attention...  :/

I would assume that most spi client drivers use short messages, so
they aren't affected unless the max message size is really short.
m25p80 on the other hand will do arbitrarily large transfers/reads, so
there it was supported first.

m25p80 supports max_transfer_size since 4,9, and max_message_size
since 4.11 with commit 9e276de6a367cde07c1a63522152985d4e5cca8b. So
that one would need to be backported as well for the max_message_size
being actually meaningful.

tinydrm-helpers also observes max_transfers_size since 4.11 with
commit 9f69eb5c36a644571cca6b2f8dc5f6a7cba04a8b where it was added,
but since this is a larger commit and not just a "bugfix" one, this
doesn't seem like a candidate for backporting.


Regards
Jonas

Re: [PATCH AUTOSEL for 4.9 002/219] spi/bcm63xx: make spi subsystem aware of message size limits

[Jonas Gorski]

On 6 March 2018 at 15:20, Mark Brown  wrote:
> On Tue, Mar 06, 2018 at 02:42:43PM +0100, Jonas Gorski wrote:
>> On 5 March 2018 at 21:35, Mark Brown  wrote:
>
>> > It's exposing more capability information but it's in the "how did this
>> > ever work without the fix" range, and I'd worry that this might cause us
>> > to do something like start exercising handling code in client drivers
>> > that had never been tested.  Not that I can immediately see any client
>> > drivers in mainline that actually pay attention...  :/
>
>> I would assume that most spi client drivers use short messages, so
>> they aren't affected unless the max message size is really short.
>> m25p80 on the other hand will do arbitrarily large transfers/reads, so
>> there it was supported first.
>
> There's a bunch of SPI drivers that do firmware downloads which I'd
> expect to be affected, the limit the device has is tiny so it's
> relatively easy to bump into it.  It's very rare for devices to be so
> limited so unfortunately client drivers don't generally check though.

Well, at least for bcm63xx it's very rare to have something other than
a flash chip, a (broadcom) ethernet switch management interface, or a
SLIC/SLAC attached to the SPI controller. And AFAICT of these three
only the flash chip uses large SPI transfers. Furthermore, unless you
have a development board, you won't be able to attach anything
different to it. So the chance to bump into the limits with other
drivers is rather low.

I would assume that this is true for most systems with a limited SPI
controller. I would hope that most board designers are sensible enough
to not add devices that won't work ;-)


Regards
Jonas

Re: [PATCH v2] spi: fsl-spi: use of_iomap() to map parameter ram on CPM1

[Jonas Gorski]

Hi Christophe,

On Wed, Apr 22, 2015 at 4:17 PM, Christophe Leroy
 wrote:
> On CPM2, the SPI parameter RAM is dynamically allocated in the
> dualport RAM whereas in CPM1, it is statically allocated to a default
> address with capability to relocate it somewhere else via the use of
> CPM micropatch. The address of the parameter RAM is given by the boot
> loader and expected to be mapped via of_iomap()
>
> In the current implementation, in function fsl_spi_cpm_get_pram()
> there is a confusion between the SPI_BASE register and the base of the
> SPI parameter RAM. Fortunatly, it is working properly with MPC866 and
> MPC885 because they do set SPI_BASE, but on MPC860 and other old
> MPC8xx that doesn't set SPI_BASE, pram_ofs is not properly set.
> Also, the parameter RAM is not properly mapped with of_iomap() as it
> should but still gets accessible by chance through the full RAM which
> is mapped from somewhere else.
>
> This patch applies to the SPI driver the same principle as for the
> CPM UART: when the CPM is of type CPM1, we simply do an of_iomap() of
> the area provided via the device tree.
>
> Signed-off-by: Christophe Leroy 
>
> ---
>  v2: Use devm_ioremap_resource() instead of_iomap()

Your subject and commitlog still talk about using of_iomap(), you need
to update them too.


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] spi: fsl-spi: use of_iomap() to map parameter ram on CPM1

[Jonas Gorski]

Hi (again),

as usual you only see issues *after* sending the email ...

On Wed, Apr 22, 2015 at 4:17 PM, Christophe Leroy
 wrote:
> On CPM2, the SPI parameter RAM is dynamically allocated in the
> dualport RAM whereas in CPM1, it is statically allocated to a default
> address with capability to relocate it somewhere else via the use of
> CPM micropatch. The address of the parameter RAM is given by the boot
> loader and expected to be mapped via of_iomap()
>
> In the current implementation, in function fsl_spi_cpm_get_pram()
> there is a confusion between the SPI_BASE register and the base of the
> SPI parameter RAM. Fortunatly, it is working properly with MPC866 and
> MPC885 because they do set SPI_BASE, but on MPC860 and other old
> MPC8xx that doesn't set SPI_BASE, pram_ofs is not properly set.
> Also, the parameter RAM is not properly mapped with of_iomap() as it
> should but still gets accessible by chance through the full RAM which
> is mapped from somewhere else.
>
> This patch applies to the SPI driver the same principle as for the
> CPM UART: when the CPM is of type CPM1, we simply do an of_iomap() of
> the area provided via the device tree.
>
> Signed-off-by: Christophe Leroy 
>
> ---
>  v2: Use devm_ioremap_resource() instead of_iomap()
>
>  drivers/spi/spi-fsl-cpm.c | 35 ++-
>  1 file changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/spi/spi-fsl-cpm.c b/drivers/spi/spi-fsl-cpm.c
> index e85ab1c..4e5c945 100644
> --- a/drivers/spi/spi-fsl-cpm.c
> +++ b/drivers/spi/spi-fsl-cpm.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "spi-fsl-cpm.h"
>  #include "spi-fsl-lib.h"
> @@ -264,17 +265,6 @@ static unsigned long fsl_spi_cpm_get_pram(struct 
> mpc8xxx_spi *mspi)
> if (mspi->flags & SPI_CPM2) {
> pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64);
> out_be16(spi_base, pram_ofs);
> -   } else {
> -   struct spi_pram __iomem *pram = spi_base;
> -   u16 rpbase = in_be16(&pram->rpbase);
> -
> -   /* Microcode relocation patch applied? */
> -   if (rpbase) {
> -   pram_ofs = rpbase;
> -   } else {
> -   pram_ofs = cpm_muram_alloc(SPI_PRAM_SIZE, 64);
> -   out_be16(spi_base, pram_ofs);
> -   }
> }
>
> iounmap(spi_base);
> @@ -287,7 +277,6 @@ int fsl_spi_cpm_init(struct mpc8xxx_spi *mspi)
> struct device_node *np = dev->of_node;
> const u32 *iprop;
> int size;
> -   unsigned long pram_ofs;
> unsigned long bds_ofs;
>
> if (!(mspi->flags & SPI_CPM_MODE))
> @@ -314,8 +303,21 @@ int fsl_spi_cpm_init(struct mpc8xxx_spi *mspi)
> }
> }
>
> -   pram_ofs = fsl_spi_cpm_get_pram(mspi);
> -   if (IS_ERR_VALUE(pram_ofs)) {
> +   if (mspi->flags & SPI_CPM1) {
> +   struct resource *res;
> +
> +   res = platform_get_resource(to_platform_device(dev),
> +   IORESOURCE_MEM, 1);
> +   mspi->pram = devm_ioremap_resource(dev, res);
> +   } else {
> +   unsigned long pram_ofs = fsl_spi_cpm_get_pram(mspi);
> +
> +   if (IS_ERR_VALUE(pram_ofs))
> +   mspi->pram = NULL;
> +   else
> +   mspi->pram = cpm_muram_addr(pram_ofs);
> +   }
> +   if (mspi->pram == NULL) {

devm_ioremap_resource will never return NULL; you either need to check
with IS_ERR(), or do that after calling devm_ioremap_resource and setg
pram to NULL in that case.

> dev_err(dev, "can't allocate spi parameter ram\n");
> goto err_pram;
> }
> @@ -341,8 +343,6 @@ int fsl_spi_cpm_init(struct mpc8xxx_spi *mspi)
> goto err_dummy_rx;
> }
>
> -   mspi->pram = cpm_muram_addr(pram_ofs);
> -
> mspi->tx_bd = cpm_muram_addr(bds_ofs);
> mspi->rx_bd = cpm_muram_addr(bds_ofs + sizeof(*mspi->tx_bd));
>
> @@ -370,7 +370,8 @@ err_dummy_rx:
>  err_dummy_tx:
> cpm_muram_free(bds_ofs);
>  err_bds:
> -   cpm_muram_free(pram_ofs);
> +   if (!(mspi->flags & SPI_CPM1))
> +   cpm_muram_free(cpm_muram_offset(mspi->pram));
>  err_pram:
> fsl_spi_free_dummy_rx();
> return -ENOMEM;


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] spi: fsl-spi: use of_iomap() to map parameter ram on CPM1

[Jonas Gorski]

On Wed, Apr 22, 2015 at 10:46 PM, Jonas Gorski  wrote:
>> ---
>>  v2: Use devm_ioremap_resource() instead of_iomap()
>
> Your subject and commitlog still talk about using of_iomap(), you need
> to update them too.

Hmm I didn't see the V3. Ignore this comment (the other one still applies).

Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] spi: Add SPI driver for Mikrotik RB4xx series boards

[Jonas Gorski]

Hi,

On Tue, Mar 31, 2015 at 6:25 PM, Bert Vermeulen  wrote:
> This driver mediates access between the connected CPLD and other devices
> on the bus.
>
> The m25p80-compatible boot flash and (some models) MMC use regular SPI,
> bitbanged as required by the SoC. However the SPI-connected CPLD has
> a "fast write" mode, in which two bits are transferred by SPI clock
> cycle. The second bit is transmitted with the SoC's CS2 pin.
>
> Protocol drivers using this fast write facility signal this by setting
> the cs_change flag on transfers.
>
> Signed-off-by: Bert Vermeulen 
> ---
>  drivers/spi/Kconfig |   6 ++
>  drivers/spi/Makefile|   1 +
>  drivers/spi/spi-rb4xx.c | 244 
> 
>  3 files changed, 251 insertions(+)
>  create mode 100644 drivers/spi/spi-rb4xx.c
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index ab8dfbe..aa76ce5 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -429,6 +429,12 @@ config SPI_ROCKCHIP
>   The main usecase of this controller is to use spi flash as boot
>   device.
>
> +config SPI_RB4XX
> +   tristate "Mikrotik RB4XX SPI master"
> +   depends on SPI_MASTER && ATH79_MACH_RB4XX

There is no ATH79_MACH_RB4XX in upstream. I suggest depending on just
ATH79, allowing maintainers/patch submitters to at least test build
any future modifications on it.


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] ar7: replace mac address parsing

[Jonas Gorski]

On Tue, Jun 24, 2014 at 9:26 PM, Florian Fainelli  wrote:
> 2014-06-24 8:48 GMT-07:00 Joe Perches :
>> On Tue, 2014-06-24 at 16:39 +0100, Daniel Walter wrote:
>>> Replace sscanf() with mac_pton().
>> []
>>> diff --git a/arch/mips/ar7/platform.c b/arch/mips/ar7/platform.c
>> []
>>> @@ -307,10 +307,7 @@ static void __init cpmac_get_mac(int instance, 
>>> unsigned char *dev_addr)
>>>   }
>>>
>>>   if (mac) {
>>> - if (sscanf(mac, "%hhx:%hhx:%hhx:%hhx:%hhx:%hhx",
>>> - &dev_addr[0], &dev_addr[1],
>>> - &dev_addr[2], &dev_addr[3],
>>> - &dev_addr[4], &dev_addr[5]) != 6) {
>>> + if (!mac_pton(mac, dev_addr)) {
>>
>> There is a slight functional change with this conversion.
>>
>> mac_pton is strict about leading 0's and requires a 17 char strlen.
>
> I do not have my devices handy, but I am fairly positive the use of
> sscanf() was exactly for that, we may or may not have leading zeroes.
> I am feeling a little uncomfortable with random code changes like that
> without being actually able to test on real hardware that has a
> variety of bootloaders and environment variables.

One of my two devices has a mac address with one of the numbers being
< 16, and it uses a fixed length mac:

(psbl) printenv
...
HWA_0   00:16:B6:2A:A4:3B

Also looking at the history[1] of this code, it looks like this was
just an optimization of an earlier code which did expect 17 char len:

   for (i = 0; i < 6; i++)
   dev_addr[i] = (char2hex(mac[i * 3]) << 4) +
   char2hex(mac[i * 3 + 1]);


So I'm tempted to say it should not cause any issues. But my sample
size is rather small.


Regards
Jonas


[1] d16f7093b6eb4f3859856f6ee4ab504cbeeea0b9
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MIPS: R6: memcpy bugfix - zero length overwrites memory

[Jonas Gorski]

Hi,

On Tue, Apr 28, 2015 at 1:35 AM, Leonid Yegoshin
 wrote:
> MIPS R6 version of memcpy has bug - then length to copy is zero
> and addresses are not aligned then it can overwrite a whole memory.
>
> Signed-off-by: Leonid Yegoshin 
> ---
>  arch/mips/lib/memcpy.S |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S
> index 9245e1705e69..7e0250f3aec8 100644
> --- a/arch/mips/lib/memcpy.S
> +++ b/arch/mips/lib/memcpy.S
> @@ -514,6 +514,8 @@
>
>  #ifdef CONFIG_CPU_MIPSR6
>  .Lcopy_unaligned_bytes\@:
> +   beqzlen, .Ldone\@
> +nop
>  1:
> COPY_BYTE(0)
> COPY_BYTE(1)

AFAICT it should never reach that if the amount to copy is zero bytes,
so the check seems to be superfluous:

sltut2, len, NBYTES <- check for < NBYTES (4/8 bit
depending on 32/64 bit)
and t1, dst, ADDRMASK
PREFS(  0, 1*32(src) )
PREFD(  1, 1*32(dst) )
bnezt2, .Lcopy_bytes_checklen\@ <- skip to
copy_bytes_checklen if < NBYTES
 andt0, src, ADDRMASK
PREFS(  0, 2*32(src) )
PREFD(  1, 2*32(dst) )
#ifndef CONFIG_CPU_MIPSR6
bnezt1, .Ldst_unaligned\@
 nop
bnezt0, .Lsrc_unaligned_dst_aligned\@
#else
or  t0, t0, t1
bnezt0, .Lcopy_unaligned_bytes\@ <- only outside place to
branch to it, and only reachable if len >= NBYTES bytes.
#endif


And in the loop itself each COPY_BYTE() will already break out if len
becomes zero, so the unconditional b 1b should also never be reached
with len == 0 in that case..

But maybe I overlooked something.


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/5] spi: bcm-mspi: Make BCMA optional to support non-BCMA chips

[Jonas Gorski]

Hi,

On Wed, Apr 8, 2015 at 8:04 PM, Jonathan Richardson
 wrote:
> The Broadcom MSPI controller is used on various chips. The driver only
> supported BCM53xx chips with BCMA (an AMBA bus variant). It now supports
> both BCMA MSPI and non-BCMA MSPI. To do this the following changes were
> made:
>
>   - A new config for non-BCMA chips has been added.
>   - Common code between the BCMA and non BCMA version are shared.
>   - Function pointers to set read/write functions to abstract bcma
> and non-bcma versions are provided.
>   - DT is now mandatory. Hard coded SPI devices are removed and must be
> set in DT.
>   - Remove function was unnecessary and removed.
>
> Signed-off-by: Jonathan Richardson 
> ---
>  drivers/spi/Kconfig|5 +
>  drivers/spi/Makefile   |1 +
>  drivers/spi/spi-bcm-mspi.c |  228 
> 
>  3 files changed, 171 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 766e08d..23f2357 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -120,6 +120,11 @@ config SPI_BCMA_MSPI
> help
>   Enable support for the Broadcom BCMA MSPI controller.
>
> +config SPI_BCM_MSPI
> +   tristate "Broadcom MSPI controller"

You say "DT is now mandatory", but I don't see you depending on OF.
Does it compile with OF disabled?

> +   help
> + Enable support for the Broadcom MSPI controller.
> +
>  config SPI_BCM63XX
> tristate "Broadcom BCM63xx SPI controller"
> depends on BCM63XX
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 6b58100..36872d2 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_SPI_ATH79)   += spi-ath79.o
>  obj-$(CONFIG_SPI_AU1550)   += spi-au1550.o
>  obj-$(CONFIG_SPI_BCM2835)  += spi-bcm2835.o
>  obj-$(CONFIG_SPI_BCMA_MSPI)+= spi-bcm-mspi.o
> +obj-$(CONFIG_SPI_BCM_MSPI) += spi-bcm-mspi.o

What happens if SPI_BCMA_MSPI and SPI_BCM_MSPI are both set? What
happens if they disagree, i.e. one is y, the other m?

>  obj-$(CONFIG_SPI_BCM63XX)  += spi-bcm63xx.o
>  obj-$(CONFIG_SPI_BCM63XX_HSSPI)+= spi-bcm63xx-hsspi.o
>  obj-$(CONFIG_SPI_BFIN5XX)  += spi-bfin5xx.o
> diff --git a/drivers/spi/spi-bcm-mspi.c b/drivers/spi/spi-bcm-mspi.c
> index 502227d..32bb1f0 100644
> --- a/drivers/spi/spi-bcm-mspi.c
> +++ b/drivers/spi/spi-bcm-mspi.c
> @@ -11,11 +11,13 @@
>   * GNU General Public License for more details.
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "spi-bcm-mspi.h"
>
> @@ -25,22 +27,17 @@
>  #define BCM_MSPI_SPE_TIMEOUT_MS 80
>
>  struct bcm_mspi {
> +#ifdef CONFIG_SPI_BCMA_MSPI
> struct bcma_device *core;
> -   struct spi_master *master;
> +#endif
>
> +   void __iomem *base;
> +   struct spi_master *master;

You could make this part a bit more readable by not reordering existing members.

> size_t read_offset;
> -};
> -
> -static inline u32 bcm_mspi_read(struct bcm_mspi *mspi, u16 offset)
> -{
> -   return bcma_read32(mspi->core, offset);
> -}
>
> -static inline void bcm_mspi_write(struct bcm_mspi *mspi, u16 offset,
> -   u32 value)
> -{
> -   bcma_write32(mspi->core, offset, value);
> -}
> +   void (*mspi_write)(struct bcm_mspi *mspi, u16 offset, u32 value);
> +   u32 (*mspi_read)(struct bcm_mspi *mspi, u16 offset);
> +};

Why not keep these and let them call mspi->mspi_read() resp.
mspi->mspi_write()? It would reduce the amount of changes quite a bit.

>
>  static inline unsigned int bcm_mspi_calc_timeout(size_t len)
>  {
> @@ -56,7 +53,7 @@ static int bcm_mspi_wait(struct bcm_mspi *mspi, unsigned 
> int timeout_ms)
> /* SPE bit has to be 0 before we read MSPI STATUS */
> deadline = jiffies + BCM_MSPI_SPE_TIMEOUT_MS * HZ / 1000;
> do {
> -   tmp = bcm_mspi_read(mspi, MSPI_SPCR2);
> +   tmp = mspi->mspi_read(mspi, MSPI_SPCR2);
> if (!(tmp & MSPI_SPCR2_SPE))
> break;
> udelay(5);
> @@ -68,9 +65,9 @@ static int bcm_mspi_wait(struct bcm_mspi *mspi, unsigned 
> int timeout_ms)
> /* Check status */
> deadline = jiffies + timeout_ms * HZ / 1000;
> do {
> -   tmp = bcm_mspi_read(mspi, MSPI_STATUS);
> +   tmp = mspi->mspi_read(mspi, MSPI_STATUS);
> if (tmp & MSPI_STATUS_SPIF) {
> -   bcm_mspi_write(mspi, MSPI_STATUS, 0);
> +   mspi->mspi_write(mspi, MSPI_STATUS, 0);
> return 0;
> }
>
> @@ -79,7 +76,7 @@ static int bcm_mspi_wait(struct bcm_mspi *mspi, unsigned 
> int timeout_ms)
> } while (!time_after_eq(jiffies, deadline));
>
>  spi_timeout:
> -   bcm_mspi_write

Re: [PATCH v2 5/5] spi: bcm-mspi: Add support to set serial baud clock rate

[Jonas Gorski]

Hi,

On Wed, Apr 8, 2015 at 8:04 PM, Jonathan Richardson
 wrote:
> The driver wasn't setting the SPBR (serial clock baud rate) which caused
> it to run at the slowest speed possible. The driver now calculates the
> SPBR based on the reference clock frequency resulting in much faster
> SPI transfers.
>
> Signed-off-by: Jonathan Richardson 
> ---
>  drivers/spi/spi-bcm-mspi.c |   50 
> 
>  1 file changed, 50 insertions(+)
>
> diff --git a/drivers/spi/spi-bcm-mspi.c b/drivers/spi/spi-bcm-mspi.c
> index 32bb1f0..9320de9 100644
> --- a/drivers/spi/spi-bcm-mspi.c
> +++ b/drivers/spi/spi-bcm-mspi.c
> @@ -18,10 +18,15 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "spi-bcm-mspi.h"
>
>  #define BCM_MSPI_MAX_SPI_BAUD   1350   /* 216 MHz? */
> +#define SPBR_MIN8U
> +#define SPBR_MAX255U
> +#define MSPI_SPCR0_LSB_OFFSET   0x200
> +#define MSPI_SPCR0_LSB_SHIFT0
>
>  /* The longest observed required wait was 19 ms */
>  #define BCM_MSPI_SPE_TIMEOUT_MS 80
> @@ -33,7 +38,9 @@ struct bcm_mspi {
>
> void __iomem *base;
> struct spi_master *master;
> +   struct clk *clk;
> size_t read_offset;
> +   u32spbr;
>
> void (*mspi_write)(struct bcm_mspi *mspi, u16 offset, u32 value);
> u32 (*mspi_read)(struct bcm_mspi *mspi, u16 offset);
> @@ -45,6 +52,15 @@ static inline unsigned int bcm_mspi_calc_timeout(size_t 
> len)
> return (len * 9000 / BCM_MSPI_MAX_SPI_BAUD * 110 / 100) + 1;
>  }
>
> +static void bcm_mspi_hw_init(struct bcm_mspi *mspi)
> +{
> +   /* Set SPBR (serial clock baud rate). */
> +   if (mspi->spbr) {
> +   mspi->mspi_write(mspi, MSPI_SPCR0_LSB_OFFSET,
> +   mspi->spbr << MSPI_SPCR0_LSB_SHIFT);
> +   }
> +}
> +
>  static int bcm_mspi_wait(struct bcm_mspi *mspi, unsigned int timeout_ms)
>  {
> unsigned long deadline;
> @@ -222,6 +238,7 @@ static struct bcm_mspi *bcm_mspi_init(struct device *dev)
>  {
> struct bcm_mspi *data;
> struct spi_master *master;
> +   u32 desired_rate;
>
> master = spi_alloc_master(dev, sizeof(*data));
> if (!master) {
> @@ -236,6 +253,33 @@ static struct bcm_mspi *bcm_mspi_init(struct device *dev)
> master->dev.of_node = dev->of_node;
> master->transfer_one = bcm_mspi_transfer_one;
>
> +   /*
> +* Enable clock if provided. The frequency can be changed by setting
> +* SPBR (serial clock baud rate) based on the desired 
> 'clock-frequency'.
> +*
> +* Baud rate is calculated as: mspi_clk / (2 * SPBR) where SPBR is a
> +* value between 1-255. If not set then it is left at the h/w default.
> +*/
> +   data->clk = devm_clk_get(dev, "mspi_clk");
> +   if (!IS_ERR(data->clk)) {
> +   int ret = clk_prepare_enable(data->clk);

You need to disable_unprepare the clock on removal, I don't see you doing that.

> +
> +   if (ret < 0) {
> +   dev_err(dev, "failed to enable clock: %d\n", ret);
> +   return 0;
> +   }
> +
> +   /* Calculate SPBR if clock-frequency provided. */
> +   if (of_property_read_u32(dev->of_node, "clock-frequency",
> +   &desired_rate) >= 0) {
> +   u32 spbr = clk_get_rate(data->clk) / (2 * 
> desired_rate);
> +
> +   if (spbr > 0)
> +   data->spbr = clamp_val(spbr, SPBR_MIN,
> +   SPBR_MAX);
> +   }
> +   }
> +
> return data;
>  }
>
> @@ -287,6 +331,9 @@ static int bcm_mspi_probe(struct platform_device *pdev)
> data->mspi_write = bcm_mspi_write;
> platform_set_drvdata(pdev, data);
>
> +   /* Initialize SPI controller. */
> +   bcm_mspi_hw_init(data);
> +
> err = devm_spi_register_master(dev, data->master);
> if (err)
> goto out;
> @@ -362,6 +409,9 @@ static int bcm_mspi_bcma_probe(struct bcma_device *core)
>
> bcma_set_drvdata(core, data);
>
> +   /* Initialize SPI controller. */
> +   bcm_mspi_hw_init(data);
> +
> err = devm_spi_register_master(&core->dev, data->master);
> if (err) {
> spi_master_put(data->master);
> --

Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] MIPS: ath79: Fix the PCI memory size and offset of window 7

[Jonas Gorski]

Hi,

On Fri, Apr 17, 2015 at 2:36 PM, Alban Bedel  wrote:
> The define AR71XX_PCI_MEM_SIZE miss one window, there is 7 windows,
> not 6. To make things clearer, and allow simpler code, derive
> AR71XX_PCI_MEM_SIZE from the newly introduced AR71XX_PCI_WIN_COUNT
> and AR71XX_PCI_WIN_SIZE.
>
> The define AR71XX_PCI_WIN7_OFFS also add a typo, fix it.

I think this will break PCI on ar71xx.

>
> Signed-off-by: Alban Bedel 
> ---
>  arch/mips/include/asm/mach-ath79/ar71xx_regs.h | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h 
> b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
> index aa3800c..e2669a8 100644
> --- a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
> +++ b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
> @@ -41,7 +41,9 @@
>  #define AR71XX_RESET_SIZE  0x100
>
>  #define AR71XX_PCI_MEM_BASE0x1000
> -#define AR71XX_PCI_MEM_SIZE0x0700
> +#define AR71XX_PCI_WIN_COUNT   8
> +#define AR71XX_PCI_WIN_SIZE0x0100
> +#define AR71XX_PCI_MEM_SIZE(AR71XX_PCI_WIN_COUNT * AR71XX_PCI_WIN_SIZE)
>
>  #define AR71XX_PCI_WIN0_OFFS   0x1000
>  #define AR71XX_PCI_WIN1_OFFS   0x1100
> @@ -50,7 +52,7 @@
>  #define AR71XX_PCI_WIN4_OFFS   0x1400
>  #define AR71XX_PCI_WIN5_OFFS   0x1500
>  #define AR71XX_PCI_WIN6_OFFS   0x1600
> -#define AR71XX_PCI_WIN7_OFFS   0x0700
> +#define AR71XX_PCI_WIN7_OFFS   0x1700

These values are used in exactly one place, for writing into the PCI
address space offset registers.
The 7th PCI window is a special one for accessing the configuration
space registers, which requires to be set to 0x0700 for that
purpose. So by changing this value you likely break access to these
values.

>
>  #define AR71XX_PCI_CFG_BASE\
> (AR71XX_PCI_MEM_BASE + AR71XX_PCI_WIN7_OFFS + 0x1)

Also this macro would now be wrong, and calculate a wrong address.


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 09/12] devicetree: Add bindings for the ATH79 GPIO controllers

[Jonas Gorski]

On Sun, Apr 19, 2015 at 3:42 PM, Alban Bedel  wrote:
> These bindings support the GPIO controllers found on the Qualcomm
> Atheros AR7xxx/AR9XXX SoC.
>
> Signed-off-by: Alban Bedel 
> ---
> v2: * Add the ngpios property to have fewer fallbacks and simpler code
> ---
>  .../devicetree/bindings/gpio/gpio-ath79.txt| 38 
> ++
>  1 file changed, 38 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-ath79.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-ath79.txt 
> b/Documentation/devicetree/bindings/gpio/gpio-ath79.txt
> new file mode 100644
> index 000..e027864
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-ath79.txt
> @@ -0,0 +1,38 @@
> +Binding for Qualcomm  Atheros AR7xxx/AR9xxx GPIO controller
> +
> +Required properties:
> +- compatible: has to be "qca,-gpio" and one of the following
> +  fallback:

maybe plural?

> +  - "qca,ar7100-gpio"
> +  - "qca,ar9340-gpio"
> +- reg: Base address and size of the controllers memory area
> +- gpio-controller : Marks the device node as a GPIO controller.
> +- #gpio-cells : Should be two. The first cell is the pin number and the
> +  second cell is used to specify optional parameters.
> +- ngpios: Should be set to the number of GPIOs available on the SoC.
> +
> +Optional properties:
> +- interrupt-parent: phandle of the parent interrupt controller.
> +- interrupts: Interrupt specifier for the controllers interrupt.
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode interrupt
> +source, should be 2
> +
> +Please refer to interrupts.txt in this directory for details of the common
> +Interrupt Controllers bindings used by client devices.
> +
> +Example:
> +
> +   gpio@1804 {
> +   compatible = "qca,ar9132-gpio", "qca,ar9130-gpio";

You have neither "qca,ar7100-gpio" nor "qca,ar9340-gpio", so by your
own documentation this would be invalid.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 07/12] devicetree: Add bindings for the ATH79 PLL controllers

[Jonas Gorski]

Hi,

On Sun, Apr 19, 2015 at 2:58 PM, Alban Bedel  wrote:
> Signed-off-by: Alban Bedel 
> ---
> v2: * Fixed the node names to respect ePAPR
> * Fixed the missing 's' in 'fallbacks' and the 'clocks' property
> ---
>  .../devicetree/bindings/clock/qca,ath79-pll.txt| 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/qca,ath79-pll.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/qca,ath79-pll.txt 
> b/Documentation/devicetree/bindings/clock/qca,ath79-pll.txt
> new file mode 100644
> index 000..df3dbc8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/qca,ath79-pll.txt
> @@ -0,0 +1,33 @@
> +Binding for Qualcomm Atheros AR7xxx/AR9XXX PLL controller
> +
> +The PPL controller provides the 3 main clocks of the SoC: CPU, DDR and AHB.
> +
> +Required Properties:
> +- compatible: has to be "qca,-cpu-intc" and one of the following
> +  fallbacks:
> +  - "qca,ar7100-pll"
> +  - "qca,ar7240-pll"
> +  - "qca,ar9130-pll"
> +  - "qca,ar9330-pll"
> +  - "qca,ar9340-pll"
> +  - "qca,ar9550-pll"

Shouldn't this be "qca,qca9550-pll"?


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] spi: img-spfi: Same Edge bit set to double supported transfer speed

[Jonas Gorski]

Hi,

On Wed, Jun 17, 2015 at 12:01 PM, Sifan Naeem  wrote:
> Same edge bit set in SPFI Control register to double the supported
> spfi clock speed. Setting this bit increases the supported spfi
> frequency from 1/8 to 1/4 of the core clock frequency.
>
> Without this bit set the maximum speed supported was 25MHz on
> Pistachio.
>
> Change-Id: I26782ea88ac3567e72dac11e46c5b5f5f52c5e3d
> Signed-off-by: Sifan Naeem 
> ---
>  drivers/spi/spi-img-spfi.c |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/spi/spi-img-spfi.c b/drivers/spi/spi-img-spfi.c
> index 788e2b1..acce90a 100644
> --- a/drivers/spi/spi-img-spfi.c
> +++ b/drivers/spi/spi-img-spfi.c
> @@ -40,6 +40,7 @@
>  #define SPFI_CONTROL_SOFT_RESETBIT(11)
>  #define SPFI_CONTROL_SEND_DMA  BIT(10)
>  #define SPFI_CONTROL_GET_DMA   BIT(9)
> +#define SPFI_CONTROL_SEBIT(8)
>  #define SPFI_CONTROL_TMODE_SHIFT   5
>  #define SPFI_CONTROL_TMODE_MASK0x7
>  #define SPFI_CONTROL_TMODE_SINGLE  0
> @@ -491,6 +492,7 @@ static void img_spfi_config(struct spi_master *master, 
> struct spi_device *spi,
> else if (xfer->tx_nbits == SPI_NBITS_QUAD &&
>  xfer->rx_nbits == SPI_NBITS_QUAD)
> val |= SPFI_CONTROL_TMODE_QUAD << SPFI_CONTROL_TMODE_SHIFT;
> +   val |= SPFI_CONTROL_SE;
> spfi_writel(spfi, val, SPFI_CONTROL);
>  }

Don't you also need to update master->max_speed_hz? And if it doubles
the clock speed, don't you need to reflect that in the calculation for
the devider? Currently it looks like it would just cause all transfers
to go with the doubled requested rate. But maybe I'm missing
something.


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] spi: img-spfi: Same Edge bit set to double supported transfer speed

[Jonas Gorski]

Hi,

On Wed, Jun 17, 2015 at 3:36 PM, Sifan Naeem  wrote:
> Hi Jonas,
>
>> -Original Message-----
>> From: Jonas Gorski [mailto:j...@openwrt.org]
>> Sent: 17 June 2015 13:12
>> To: Sifan Naeem
>> Cc: Mark Brown; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> Andrew Bresticker
>> Subject: Re: [PATCH v2] spi: img-spfi: Same Edge bit set to double supported
>> transfer speed
>>
>> Hi,
>>
>> On Wed, Jun 17, 2015 at 12:01 PM, Sifan Naeem 
>> wrote:
>> > Same edge bit set in SPFI Control register to double the supported
>> > spfi clock speed. Setting this bit increases the supported spfi
>> > frequency from 1/8 to 1/4 of the core clock frequency.
>> >
>> > Without this bit set the maximum speed supported was 25MHz on
>> > Pistachio.
>> >
>> > Change-Id: I26782ea88ac3567e72dac11e46c5b5f5f52c5e3d
>> > Signed-off-by: Sifan Naeem 
>> > ---
>> >  drivers/spi/spi-img-spfi.c |2 ++
>> >  1 file changed, 2 insertions(+)
>> >
>> > diff --git a/drivers/spi/spi-img-spfi.c b/drivers/spi/spi-img-spfi.c
>> > index 788e2b1..acce90a 100644
>> > --- a/drivers/spi/spi-img-spfi.c
>> > +++ b/drivers/spi/spi-img-spfi.c
>> > @@ -40,6 +40,7 @@
>> >  #define SPFI_CONTROL_SOFT_RESETBIT(11)
>> >  #define SPFI_CONTROL_SEND_DMA  BIT(10)
>> >  #define SPFI_CONTROL_GET_DMA   BIT(9)
>> > +#define SPFI_CONTROL_SEBIT(8)
>> >  #define SPFI_CONTROL_TMODE_SHIFT   5
>> >  #define SPFI_CONTROL_TMODE_MASK0x7
>> >  #define SPFI_CONTROL_TMODE_SINGLE  0
>> > @@ -491,6 +492,7 @@ static void img_spfi_config(struct spi_master
>> *master, struct spi_device *spi,
>> > else if (xfer->tx_nbits == SPI_NBITS_QUAD &&
>> >  xfer->rx_nbits == SPI_NBITS_QUAD)
>> > val |= SPFI_CONTROL_TMODE_QUAD <<
>> > SPFI_CONTROL_TMODE_SHIFT;
>> > +   val |= SPFI_CONTROL_SE;
>> > spfi_writel(spfi, val, SPFI_CONTROL);  }
>>
>> Don't you also need to update master->max_speed_hz? And if it doubles the
>> clock speed, don't you need to reflect that in the calculation for the 
>> devider?
>> Currently it looks like it would just cause all transfers to go with the 
>> doubled
>> requested rate. But maybe I'm missing something.
>>
> max_speed_hz is already set to 1/4  of the Core clock. So I don't think we 
> need to change that.
> In Pistachio SoC the max speed of SPFI block is limited to 1/4 of the core 
> clock or to 50Mhz, to achieve these values the change suggested in this patch 
> should have always been set. In the device tree node for SPFI we have to 
> mention the limit of 50Mhz as spi-max-frequency = <5000>;

So it calculated the wrong divisor before, and the resulting speed was
half of that and setting this bit actually fixes it? Or does the block
just treat speeds > 25 MHz as 25 MHz when this bit is set? I'm still
trying to wrap my head around that setting a single bit in a register
allows going from 0~25 MHz to 0~50 MHz without needing to update the
calculation of the divisor.


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] spi: img-spfi: Same Edge bit set to double supported transfer speed

[Jonas Gorski]

Hi,

On Wed, Jun 17, 2015 at 6:08 PM, Sifan Naeem  wrote:
> Hi Jonas,
>
>> -Original Message-----
>> From: Jonas Gorski [mailto:j...@openwrt.org]
>> Sent: 17 June 2015 15:31
>> To: Sifan Naeem
>> Cc: Mark Brown; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> Andrew Bresticker
>> Subject: Re: [PATCH v2] spi: img-spfi: Same Edge bit set to double supported
>> transfer speed
>>
>> Hi,
>>
>> On Wed, Jun 17, 2015 at 3:36 PM, Sifan Naeem 
>> wrote:
>> > Hi Jonas,
>> >
>> >> -Original Message-
>> >> From: Jonas Gorski [mailto:j...@openwrt.org]
>> >> Sent: 17 June 2015 13:12
>> >> To: Sifan Naeem
>> >> Cc: Mark Brown; linux-...@vger.kernel.org;
>> >> linux-kernel@vger.kernel.org; Andrew Bresticker
>> >> Subject: Re: [PATCH v2] spi: img-spfi: Same Edge bit set to double
>> >> supported transfer speed
>> >>
>> >> Hi,
>> >>
>> >> On Wed, Jun 17, 2015 at 12:01 PM, Sifan Naeem
>> >> 
>> >> wrote:
>> >> > Same edge bit set in SPFI Control register to double the supported
>> >> > spfi clock speed. Setting this bit increases the supported spfi
>> >> > frequency from 1/8 to 1/4 of the core clock frequency.
>> >> >
>> >> > Without this bit set the maximum speed supported was 25MHz on
>> >> > Pistachio.
>> >> >
>> >> > Change-Id: I26782ea88ac3567e72dac11e46c5b5f5f52c5e3d
>> >> > Signed-off-by: Sifan Naeem 
>> >> > ---
>> >> >  drivers/spi/spi-img-spfi.c |2 ++
>> >> >  1 file changed, 2 insertions(+)
>> >> >
>> >> > diff --git a/drivers/spi/spi-img-spfi.c
>> >> > b/drivers/spi/spi-img-spfi.c index 788e2b1..acce90a 100644
>> >> > --- a/drivers/spi/spi-img-spfi.c
>> >> > +++ b/drivers/spi/spi-img-spfi.c
>> >> > @@ -40,6 +40,7 @@
>> >> >  #define SPFI_CONTROL_SOFT_RESETBIT(11)
>> >> >  #define SPFI_CONTROL_SEND_DMA  BIT(10)
>> >> >  #define SPFI_CONTROL_GET_DMA   BIT(9)
>> >> > +#define SPFI_CONTROL_SEBIT(8)
>> >> >  #define SPFI_CONTROL_TMODE_SHIFT   5
>> >> >  #define SPFI_CONTROL_TMODE_MASK0x7
>> >> >  #define SPFI_CONTROL_TMODE_SINGLE  0
>> >> > @@ -491,6 +492,7 @@ static void img_spfi_config(struct spi_master
>> >> *master, struct spi_device *spi,
>> >> > else if (xfer->tx_nbits == SPI_NBITS_QUAD &&
>> >> >  xfer->rx_nbits == SPI_NBITS_QUAD)
>> >> > val |= SPFI_CONTROL_TMODE_QUAD <<
>> >> > SPFI_CONTROL_TMODE_SHIFT;
>> >> > +   val |= SPFI_CONTROL_SE;
>> >> > spfi_writel(spfi, val, SPFI_CONTROL);  }
>> >>
>> >> Don't you also need to update master->max_speed_hz? And if it doubles
>> >> the clock speed, don't you need to reflect that in the calculation for the
>> devider?
>> >> Currently it looks like it would just cause all transfers to go with
>> >> the doubled requested rate. But maybe I'm missing something.
>> >>
>> > max_speed_hz is already set to 1/4  of the Core clock. So I don't think we
>> need to change that.
>> > In Pistachio SoC the max speed of SPFI block is limited to 1/4 of the
>> > core clock or to 50Mhz, to achieve these values the change suggested
>> > in this patch should have always been set. In the device tree node for
>> > SPFI we have to mention the limit of 50Mhz as spi-max-frequency =
>> > <5000>;
>>
>> So it calculated the wrong divisor before, and the resulting speed was half 
>> of
>> that and setting this bit actually fixes it? Or does the block just treat 
>> speeds >
>> 25 MHz as 25 MHz when this bit is set? I'm still trying to wrap my head 
>> around
>> that setting a single bit in a register allows going from 0~25 MHz to 0~50 
>> MHz
>> without needing to update the calculation of the divisor.
>>
>
> Yes, if the requested speed is 50Mhz without the SE bit set, the divisor 
> calculated would still request 50Mhz from the spfi block, which is correct, 
> but the transfer would fail as SE bit is not set and the maximum speed 
> supported would be 25Mhz.

So this is actually a bug fix, and it should be noted as such so that
stable maintainers can properly decide to pick it up.

>From the original commit message it sounds like this is an enhancement
that increases the max speed from 25 to 50 MHz, and not that speeds
25~50 MHz are currently broken (i.e. transfers will fail) and require
this to be set to work.


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] modpost: make KBUILD_MODPOST_WARN also configurable for external modules

[Jonas Gorski]

Hi,

本当に申し訳ありません, I got sidetracked and completely forgot about it. I
actually still have my old tree with the suggested changes for v2.

On Tue, 9 Apr 2019 at 11:01, Masahiro Yamada
 wrote:
>
> Hi.
>
> On Mon, Apr 8, 2019 at 5:03 PM Wiebe, Wladislav (Nokia - DE/Ulm)
>  wrote:
> >
> > Hi!
> >
> > On 07.04.2019 11:04, Masahiro Yamada wrote:
> > > (+CC Jonas Gorski)
> > >
> > >
> > > On Tue, Mar 26, 2019 at 6:58 PM Wiebe, Wladislav (Nokia - DE/Ulm)
> > >  wrote:
> > >>
> > >> Commit ea837f1c0503 ("kbuild: make modpost processing configurable")
> > >> was intended to give KBUILD_MODPOST_WARN flexibility to be configurable.
> > >> Right now KBUILD_MODPOST_WARN gets just ignored when KBUILD_EXTMOD is
> > >> set which happens per default when building modules out of the tree.
> > >>
> > >> This change gives the opportunity to define module build behaving also
> > >> in case of out of tree builds and default will become exit on error.
> > >> Errors which can be detected by the build should be trapped out of the 
> > >> box
> > >> there, unless somebody wants to notice broken stuff later at runtime.
> > >
> > > If an external module refers to a symbol
> > > provided by another external module,
> > > this patch will turn the warning into the error by default,
> > > which is probably a bad idea.
> >
> > Indeed, exactly this should happen. You should fix your external module
> > dependencies by providing their symbols. Please use e.g.
> > KBUILD_EXTRA_SYMBOLS instead of converting errors to warning and hoping
> > that things will work.
>
> I know this option.
> What I want to say is, this patch changes the behavior, and
> may annoy some people.
>
> > Or how do you want to make sure module A still
> > delivers all symbols needed by module B after an update/changes?
> > Manually comparing the logs after an update or waiting until it turns
> > out broken during run-time? I wouldn't say this is a good idea :-)
>
> OK, so the commit log should record both the behavior change
> and workarounds.
>
> - If an external module being built refers to symbols
>   in another external module, Kbuild previously showed a warning,
>   but going forward it will turn it into an error.
>
> - To work around this, you should pass a symbol table via 
> KBUILD_EXTRA_SYMBOLS,
>   or KBUILD_EXTRA_SYMBOLS=1 to turn the error into a warning.

This sounds like a good middle ground. When you do the effort of
setting KBUILD_EXTRA_SYMBOLS, you are likely interested in proper
dependency resolution and being notified if it fails.

I would probably still use KBUILD_MODPOST_WARN=0 to force the warnings
as errors, to have it as the central switch for the behaviour. So the
behaviour would then become

- If KBUILD_MODPOST_WARN is set to any value, set -w accordingly
- else, set -w only when building for an external module and
KBUILD_EXTRA_SYMBOLS is empty

or

ifdef KBUILD_MODPOST_WARN
KBUILD_MODPOST_WARN:=$(filter-out 0,$(KBUILD_MODPOST_WARN))
else
KBUILD_MODPOST_WARN:=$(if $(KBUILD_EXTMOD),$(if $(KBUILD_EXTRA_SYMBOLS),,1))
endif

(completely untested)


Regards
Jonas

Re: [PATCH net-next 1/2] net: dsa: tag_brcm: add support for legacy tags

[Jonas Gorski]

On Wed, 17 Mar 2021 at 10:16, Álvaro Fernández Rojas  wrote:
>
> Hi Vladimir,
>
> > El 15 mar 2021, a las 22:28, Vladimir Oltean  escribió:
> >
> > On Mon, Mar 15, 2021 at 03:27:35PM +0100, Álvaro Fernández Rojas wrote:
> >> Add support for legacy Broadcom tags, which are similar to 
> >> DSA_TAG_PROTO_BRCM.
> >> These tags are used on BCM5325, BCM5365 and BCM63xx switches.
> >>
> >> Signed-off-by: Álvaro Fernández Rojas 
> >> ---
> >> include/net/dsa.h  |  2 +
> >> net/dsa/Kconfig|  7 
> >> net/dsa/tag_brcm.c | 96 ++
> >> 3 files changed, 105 insertions(+)
> >>
> >> diff --git a/include/net/dsa.h b/include/net/dsa.h
> >> index 83a933e563fe..dac303edd33d 100644
> >> --- a/include/net/dsa.h
> >> +++ b/include/net/dsa.h
> >> @@ -49,10 +49,12 @@ struct phylink_link_state;
> >> #define DSA_TAG_PROTO_XRS700X_VALUE  19
> >> #define DSA_TAG_PROTO_OCELOT_8021Q_VALUE 20
> >> #define DSA_TAG_PROTO_SEVILLE_VALUE  21
> >> +#define DSA_TAG_PROTO_BRCM_LEGACY_VALUE 22
> >>
> >> enum dsa_tag_protocol {
> >>  DSA_TAG_PROTO_NONE  = DSA_TAG_PROTO_NONE_VALUE,
> >>  DSA_TAG_PROTO_BRCM  = DSA_TAG_PROTO_BRCM_VALUE,
> >> +DSA_TAG_PROTO_BRCM_LEGACY   = DSA_TAG_PROTO_BRCM_LEGACY_VALUE,
> >
> > Is there no better qualifier for this tagging protocol name than "legacy"?
>
> It’s always referred to as “legacy”, so that’s what I used.
> Maybe @Florian can suggest a better name for this...

Broadcom refers to both as "the BRCM tag" or "the Broadcom Management
Header/Tag" in documentation with no versioning at all.

Codewise, the brcm963xx code names the old one BRCM_TAG and the newer
one BRCM_TAG_TYPE2. Not really better IMHO.

Maybe BRCM_OLD? less characters than Legacy, and doesn't need to be abbreviated.

To make matters worse, there seem to exist different versions of the
tag variants where some opcodes mean different things, e.g. BCM5325
might set the opcode to 1 for Multicast frames.

I would probably suggest enabling it only for switch models we
verified to be working with it.

On a different side node, should the dsa_tag_protocol be ordered
numerically, i.e. should DSA_TAG_PROTO_BRCM_PREPEND be the last one
since it is the highest with 22?

> >
> >>  DSA_TAG_PROTO_BRCM_PREPEND  = DSA_TAG_PROTO_BRCM_PREPEND_VALUE,
> >>  DSA_TAG_PROTO_DSA   = DSA_TAG_PROTO_DSA_VALUE,
> >>  DSA_TAG_PROTO_EDSA  = DSA_TAG_PROTO_EDSA_VALUE,
> >> diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
> >> index 58b8fc82cd3c..aaf8a452fd5b 100644
> >> --- a/net/dsa/Kconfig
> >> +++ b/net/dsa/Kconfig
> >> @@ -48,6 +48,13 @@ config NET_DSA_TAG_BRCM
> >>Say Y if you want to enable support for tagging frames for the
> >>Broadcom switches which place the tag after the MAC source address.
> >>
> >> +config NET_DSA_TAG_BRCM_LEGACY
> >> +tristate "Tag driver for Broadcom legacy switches using in-frame 
> >> headers"
> >
> > Aren't all headers in-frame?
>
> I copied that from NET_DSA_TAG_BRCM:
> https://github.com/torvalds/linux/blob/1df27313f50a57497c1faeb6a6ae4ca939c85a7d/net/dsa/Kconfig#L45
>
> Do you want me to change it to "Tag driver for Broadcom legacy switches” or  
> “Legacy tag driver for Broadcom switches"?

This means that the tag is inserted after the SRC/DST mac addresses,
in contrast to BRCM_PREPEND that gets prepended to the full frame.

> >> +select NET_DSA_TAG_BRCM_COMMON
> >> +help
> >> +  Say Y if you want to enable support for tagging frames for the
> >> +  Broadcom legacy switches which place the tag after the MAC source
> >> +  address.
> >>
> >> config NET_DSA_TAG_BRCM_PREPEND
> >>  tristate "Tag driver for Broadcom switches using prepended headers"
> >> diff --git a/net/dsa/tag_brcm.c b/net/dsa/tag_brcm.c
> >> index e2577a7dcbca..9dbff771c9b3 100644
> >> --- a/net/dsa/tag_brcm.c
> >> +++ b/net/dsa/tag_brcm.c
> >> @@ -9,9 +9,23 @@
> >> #include 
> >> #include 
> >> #include 
> >> +#include 
> >>
> >> #include "dsa_priv.h"
> >>
> >> +struct bcm_legacy_tag {
> >> +uint16_t type;
> >> +#define BRCM_LEG_TYPE   0x8874
> >> +
> >> +uint32_t tag;
> >> +#define BRCM_LEG_TAG_PORT_ID(0xf)
> >> +#define BRCM_LEG_TAG_MULTICAST  (1 << 29)
> >> +#define BRCM_LEG_TAG_EGRESS (2 << 29)
> >> +#define BRCM_LEG_TAG_INGRESS(3 << 29)
> >> +} __attribute__((packed));
> >> +
> >> +#define BRCM_LEG_TAG_LENsizeof(struct bcm_legacy_tag)
> >> +
> >
> > As Florian pointed out, tagging protocol parsing should be
> > endian-independent, and mapping a struct over the frame header is pretty
> > much not that.
>
> Ok, I will change that in v2.
>
> >
> >> /* This tag length is 4 bytes, older ones were 6 bytes, we do not
> >>  * handle them

You might want to update this comment, since you now handle them ;-)

Best Regards
Jonas

Re: [PATCH 2/2] rsi: fix memory leaks and error handling in rsi_91x_usb

[Jonas Gorski]

On Fri, Jun 27, 2014 at 12:51 AM, Alexey Khoroshilov
 wrote:
> The patch fixes a couple of issues:
> - absence of deallocation of rsi_dev->rx_usb_urb[0] in the driver;
> - potential NULL pointer dereference because of lack of checks for memory
>   allocation success in rsi_init_usb_interface().
>
> By the way, it makes rsi_probe() returning error code instead of 1
> and fixes comments regarding returning values.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov 

I count four different issues being fixed, so maybe split this into
four patches?


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MIPS: Fix incorrect NULL check in local_flush_tlb_page()

[Jonas Gorski]

On Fri, Jul 4, 2014 at 7:07 PM, Emil Goode  wrote:
> We check that the struct vm_area_struct pointer vma is NULL and
> then dereference it. The intent must have been to check that
> vma is not NULL before we dereference it in the next condition.

Actually if it is NULL, then it will short-cut and won't dereference
it (because !vma is true it can never become false again), so the
condition would be fine previously.

But, looking at the code a few lines into branch:

if (!vma || cpu_context(cpu, vma->vm_mm) != 0) {
unsigned long flags;
int oldpid, newpid, idx;

#ifdef DEBUG_TLB
printk("[tlbpage<%lu,0x%08lx>]", cpu_context(cpu,
vma->vm_mm), page);
#endif
newpid = cpu_context(cpu, vma->vm_mm) & ASID_MASK;

it will be then dereferenced here, so the change is actually sensible,
even if the description isn't quite spot-on where it breaks.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] spi: add driver for Rockchip RK3xxx SoCs integrated SPI

[Jonas Gorski]

On Fri, Jul 4, 2014 at 8:32 PM, Mark Brown  wrote:
> On Tue, Jul 01, 2014 at 09:03:59AM +0800, addy ke wrote:
>> In order to facilitate understanding, rockchip SPI controller IP design
>> looks similar in its registers to designware. But IC implementation
>> is different from designware, So we need a dedicated driver for Rockchip
>> RK3XXX SoCs integrated SPI. The main differences:
>
> This looks good overall, a nice clean driver.  I've applied it but there
> are a few small issues that need fixing up which I've noted below, can
> you please send followup patches dealing with these?
>
>> +  * static void spi_set_cs(struct spi_device *spi, bool enable)
>> +  * {
>> +  *  if (spi->mode & SPI_CS_HIGH)
>> +  *  enable = !enable;
>> +  *
>> +  *  if (spi->cs_gpio >= 0)
>> +  *  gpio_set_value(spi->cs_gpio, !enable);
>> +  *  else if (spi->master->set_cs)
>> +  *  spi->master->set_cs(spi, !enable);
>> +  * }
>> +  *
>> +  * Note: enable(rockchip_spi_set_cs) = !enable(spi_set_cs)
>> +  */
>
> So, the point here is that chip select is an active low signal by
> default which means that if chip select is asserted we have a low logic
> level and the parameter means "asserted" not "logic level for the
> output".  It doesn't really matter but it might be clearer to say so
> directly.
>
>> + if (spi->mode & SPI_CS_HIGH) {
>> + dev_err(rs->dev, "spi_cs_hign: not support\n");
>> + return -EINVAL;
>
> Typo here (high).

This whole check looks bogus and should probably be removed. Either
the driver/hardware does not support SPI_CS_HIGH, then the
master->mode_bits set in rockchip_spi_probe are wrong and SPI_CS_HIGH
should be removed. The common code already ensures that spi_device's
mode match the master's mode_bits, so the condition then could never
be true.
Or the driver/hardware does actually support it as it claims with it
mode_bits, then the check is wrong and it will wrongfully rejects
spi_devices using/requiring SPI_CS_HIGH.

Going that the rockchip_spi_set_cs has this extra explanation about
enable being inverted with CS_HIGH, I would guess the latter.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] MIPS: Fix incorrect NULL check in local_flush_tlb_page()

[Jonas Gorski]

On Sat, Jul 5, 2014 at 8:26 PM, Emil Goode  wrote:
> We check that the struct vm_area_struct pointer vma is NULL and then
> dereference it a few lines below. The intent must have been to make sure
> that vma is not NULL and then to check the value from cpu_context() for
> the condition to be true.
>
> Signed-off-by: Emil Goode 
> ---
>
> v2: Updated the commit message with a better explanation.
>
>  arch/mips/mm/tlb-r3k.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/mips/mm/tlb-r3k.c b/arch/mips/mm/tlb-r3k.c
> index d657493..6546758 100644
> --- a/arch/mips/mm/tlb-r3k.c
> +++ b/arch/mips/mm/tlb-r3k.c
> @@ -158,7 +158,7 @@ void local_flush_tlb_page(struct vm_area_struct *vma, 
> unsigned long page)
>  {
> int cpu = smp_processor_id();
>
> -   if (!vma || cpu_context(cpu, vma->vm_mm) != 0) {
> +   if (vma && cpu_context(cpu, vma->vm_mm) != 0) {

Sorry for replying "too late", but grepping through the kernel code I
fail to find any caller that does not dereference vma before calling
(local)flush_tlb_page(). Also both tlb-4k and tlb-8k assume vma cannot
be NULL, so I would say it is safe to assume vma is never NULL, and
the NULL check can be removed completely.

Also it looks like this "bug" was there since at least 2.6.12, and
never seem to have bitten anyone.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MIPS: Remove incorrect NULL check in local_flush_tlb_page()

[Jonas Gorski]

On Sun, Jul 6, 2014 at 1:23 AM, Emil Goode  wrote:
> We check that the struct vm_area_struct pointer vma is NULL and then
> dereference it a few lines below. The intent was to make sure vma is
> not NULL but this is not necessary since the bug pre-dates GIT history
> and seem to never have caused a problem. The tlb-4k and tlb-8k versions
> of local_flush_tlb_page() don't bother checking if vma is NULL, also
> vma is dereferenced before being passed to local_flush_tlb_page(),
> thus it is safe to remove this NULL check.
>
> Signed-off-by: Emil Goode 

Looks good.

Reviewed-by: Jonas Gorski 

> ---
>  arch/mips/mm/tlb-r3k.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/mips/mm/tlb-r3k.c b/arch/mips/mm/tlb-r3k.c
> index d657493..4094bbd 100644
> --- a/arch/mips/mm/tlb-r3k.c
> +++ b/arch/mips/mm/tlb-r3k.c
> @@ -158,7 +158,7 @@ void local_flush_tlb_page(struct vm_area_struct *vma, 
> unsigned long page)
>  {
> int cpu = smp_processor_id();
>
> -   if (!vma || cpu_context(cpu, vma->vm_mm) != 0) {
> +   if (cpu_context(cpu, vma->vm_mm) != 0) {
> unsigned long flags;
> int oldpid, newpid, idx;
>
> --
> 1.7.10.4
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Staging:et131x: change memcpy() ether_addr_copy()

[Jonas Gorski]

On Mon, Mar 31, 2014 at 10:56 AM, Dan Carpenter
 wrote:
> On Fri, Mar 28, 2014 at 10:27:22PM +, paulmcquad wrote:
>> >From 63f3c8948d5264ab22695502b201ff50edb9028d Mon Sep 17 00:00:00 2001
>> From: Paul McQuade 
>> Date: Fri, 28 Mar 2014 22:16:22 +
>> Subject: [PATCH] Staging:et131x: change memcpy()  ether_addr_copy()
>
> Don't include this header block.
>
>>
>> replace memcpy() with ether_addr_copy()
>> make checkpatch.pl clean
>
> Patch doesn't apply to linux-next.
>
>> @@ -4337,7 +4337,7 @@ static void et131x_multicast(struct net_device *netdev)
>>  netdev_for_each_mc_addr(ha, netdev) {
>>  if (i == NIC_MAX_MCAST_LIST)
>>  break;
>> -memcpy(adapter->multicast_list[i++], ha->addr, ETH_ALEN);
>> +ether_addr_copy(adapter->multicast_list[i++], ha->addr, ETH_ALEN);
>
> There is an indenting error here.

Also ether_addr_copy does not have a third argument, so it would not
even compile.


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] staging: rtl8712: use kcalloc instead of kmalloc(x*y, ...)

[Jonas Gorski]

On Sat, Jun 14, 2014 at 1:48 PM, Vitaly Osipov  wrote:
> Replaced kmalloc(x*y, ...) with kcalloc(x,y,...)
>
> Signed-off-by: Vitaly Osipov 
> ---
>  drivers/staging/rtl8712/rtl871x_mlme.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c 
> b/drivers/staging/rtl8712/rtl871x_mlme.c
> index 26b8f37..8561841 100644
> --- a/drivers/staging/rtl8712/rtl871x_mlme.c
> +++ b/drivers/staging/rtl8712/rtl871x_mlme.c
> @@ -62,8 +62,7 @@ static sint _init_mlme_priv(struct _adapter *padapter)
> _init_queue(&(pmlmepriv->scanned_queue));
> set_scanned_network_val(pmlmepriv, 0);
> memset(&pmlmepriv->assoc_ssid, 0, sizeof(struct ndis_802_11_ssid));
> -   pbuf = kmalloc(MAX_BSS_CNT * (sizeof(struct wlan_network)),
> -  GFP_ATOMIC);
> +   pbuf = kcalloc(MAX_BSS_CNT, sizeof(struct wlan_network), GFP_ATOMIC);

kcalloc() additionally zeroes the memory, so this is a change in
behaviour. A better replacement would be kmalloc_array().


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MIPS: Replace CONFIG_MIPS64 and CONFIG_MIPS32_R2

[Jonas Gorski]

On Sun, Feb 9, 2014 at 2:32 PM, Paul Bolle  wrote:
> Commit 597ce1723e0f ("MIPS: Support for 64-bit FP with O32 binaries")
> introduced references to two undefined Kconfig macros. CONFIG_MIPS32_R2
> should clearly be replaced with CONFIG_CPU_MIPS32_R2. And CONFIG_MIPS64
> should apparently be replaced with CONFIG_64BIT.

While I agree about the CONFIG_MIPS64 => CONFIG_64BIT replacement, I
wonder if CONFIG_MIPS32_R2 shouldn't rather be CONFIG_CPU_MIPSR2
(maybe even the existing CONFIG_CPU_MIPS32_R2 are wrong here).
CPU_XLP selects CPU_MIPSR2, and CPU_LONGSOON1 selects CPU_MIPS32 and
CPU_MIPSR2, so they should probably be treated the same way as
CPU_MIPS32_R2 (for e.g. the di/ei availability), but since all three
are choice values, there can't be CPU_MIPS32_R2 selected if
CPU_LONGSOON1 or CPU_XLP is chosen.


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Jonas Gorski]

On Sat, Aug 23, 2014 at 12:10 AM, Andrew Bresticker
 wrote:
> On Fri, Aug 22, 2014 at 1:57 PM, David Daney  wrote:
>> On 08/22/2014 01:42 PM, Florian Fainelli wrote:
>>>
>>> On Aug 21, 2014 3:05 PM, "Andrew Bresticker" >> > wrote:
>>>  >
>>>  > To be consistent with other architectures and to avoid unnecessary
>>>  > makefile duplication, move all MIPS device-trees to arch/mips/boot/dts
>>>  > and build them with a common makefile.
>>>
>>> I recall reading that the ARM organization for DTS files was a bit
>>> unfortunate and should have been something like:
>>>
>>> arch/arm/boot/dts//
>>>
>>> Is this something we should do for the MIPS and update the other
>>> architectures to follow that scheme?
>>
>>
>> If we choose not to intermingle .dts files from all the vendors in a single
>> directory, why do anything at all?  Currently the .dts files for a vendor
>> are nicely segregated with the rest of the vendors code under a single
>> directory.
>>
>> Personally I think things are fine as they are.  Any common code remaining
>> in the Makefiles could be moved to the scripts directory for a smaller
>> change.
>
> Assuming we don't move them to a common location just to segregate
> them again, it makes MIPS consistent with every other architecture
> (not just ARM!) using DT.  It also makes it easier to introduce common
> changes later on, like the 'dtbs' or 'dtbs_install' make targets.

I think having dts files under a predictable location is a good idea,
especially if it allows common code/targets as "dtbs".

Maybe a totally insane idea, but how this for having the cake and eating it too:

arch/mips/boot/dts/*.dts => dts files to be built along side the kernel as .dtbs

arch/mips//*.dts => dts files built into the kernel

(the ../*.dts isn't meant as they should be in the top directory, just
somewhere in that sub tree)

Because I can see a use case where you want both. For example octeon
uses generic device tree boards to use as a basis if the bootloader
did not provide one/is too old, but maybe also provide dts files for
known boards, which shouldn't be included in the kernel binary itself.

And I would like to do a similar thing when I want to convert bcm63xx
to device tree, i.e. have dts files for supported boards, but also
include a "standard"/"fall-back" dts for each of the supported SoCs to
load if there is no dtb passed and the old board registration code is
used.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Jonas Gorski]

On Sat, Aug 23, 2014 at 3:56 PM, Arnd Bergmann  wrote:
> Another argument is that we plan to actually move all the dts files out of
> the kernel into a separate project in the future. We really don't want to
> have the churn of moving all the files now when they get deleted in one
> of the next merge windows.
>
> I don't know if we talked about whether that move should be done for
> all architectures at the same time. If that is the plan, I think it
> would be best to not move the MIPS files at all but also wait until
> they can get removed from the kernel tree.

I wonder how this is supposed to work with dtbs that are currently
expected to be built into the kernel?


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] MIPS: Move device-tree files to a common location

[Jonas Gorski]

On Sat, Aug 23, 2014 at 9:50 PM, Geert Uytterhoeven
 wrote:
> On Sat, Aug 23, 2014 at 8:31 AM, Olof Johansson  wrote:
>>> > arch/arm/boot/dts//
>>> >
>>> > Is this something we should do for the MIPS and update the other 
>>> > architectures
>>> > to follow that scheme?
>>>
>>> I recall reading that as well and that it would be adopted for ARM64,
>>> but that hasn't seemed to have happened.  Perhaps Olof (CC'ed) will no
>>> more.
>>
>> Yeah, I highly recommend having a directory per vendor. We didn't on ARM,
>> and the amount of files in that directory is becoming pretty
>> insane. Moving to a subdirectory structure later gets messy which is
>> why we've been holding off on it.
>
> It would mean we can change our scripts to operate on "interesting"
> DTS files from
>
>  do-something-with $(git grep -l $vendor, -- arch/arm/boot/dts)
>
> to
>
> do-something-with arch/arm/boot/dts/$vendor/*
>
> which is easier to type...

Btw, do you mean chip-vendor or device-vendor with vendor?
Device-vendor could get a bit messy on the source part as the router
manufacturers tend to switch them quite often. E.g. d-link used arm,
mips and ubi32 chips from marvell, ubicom, broadcom, atheros, realtek
and ralink for their dir-615 router, happily switching back and forth.
There are 14 known different hardware revisions of it where the chip
differed from the previous one.



Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/7] MIPS: BCM63xx: delete double assignment

[Jonas Gorski]

On Mon, Aug 25, 2014 at 1:27 PM, Ralf Baechle  wrote:
> On Sat, Aug 23, 2014 at 08:33:25PM +0200, Julia Lawall wrote:
>
>> Delete successive assignments to the same location.  In each case, the
>> duplicated assignment is modified to be in line with other nearby code.
>>
>> A simplified version of the semantic match that finds this problem is as
>> follows: (http://coccinelle.lip6.fr/)
>
> Looking good, applied.

Huh, somehow gmail decided the original emails were spam.

> Thanks,
>
>   Ralf

Also thanks from me for cleaning up behind me! These mistakes were
definitely mine.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2] device coredump: add new device coredump class

[Jonas Gorski]

On Fri, Sep 5, 2014 at 10:50 AM, Johannes Berg
 wrote:
> From: Johannes Berg 

Can't you just send from the correct address? ;p

(snip)

> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 4e7f0ff83ae7..134f763d90fd 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -165,6 +165,27 @@ config FW_LOADER_USER_HELPER_FALLBACK
>
>   If you are unsure about this, say N here.
>
> +config WANT_DEV_COREDUMP
> +   bool
> +   help
> + Drivers should "select" this option if they desire to use the
> + device coredump mechanism.
> +
> +config DISABLE_DEV_COREDUMP
> +   bool "Disable device coredump" if EXPERT
> +   help
> + Disable the device coredump mechanism despite drivers wanting to
> + use it; this allows for more sensitive systems or systems that
> + don't want to ever access the information to not have the code,
> + nor keep any data.
> +
> + If unsure, say N.
> +
> +config DEV_COREDUMP
> +   bool
> +   default y if WANT_DEV_COREDUMP
> +   depends on !DISABLE_DEV_COREDUMP

How about the following to avoid negative options:

config DEV_COREDUMP
   bool "Enable device coredump" if EXPERT
   default y if WANT_DEV_COREDUMP
   help
 Enable the device coredump mechanism for drivers wanting to
 use it. Disabling allows for more sensitive systems or systems that
 don't want to ever access the information to not have the code,
 nor keep any data.

 If unsure, say Y.



Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/12] MIPS: Provide a generic plat_irq_dispatch

[Jonas Gorski]

On Sat, Aug 30, 2014 at 12:14 AM, Andrew Bresticker
 wrote:
> For platforms which boot with device-tree and use the MIPS CPU interrupt
> controller binding, a generic plat_irq_dispatch() can be used since all
> CPU interrupts should be mapped through the CPU IRQ domain.  Implement a
> plat_irq_dispatch() which simply handles the highest pending interrupt.
>
> Signed-off-by: Andrew Bresticker 

I gave this a short test by hackishly adding IRQ_DOMAIN support to
bcm63xx and removing the local plat_irq_dispatch, and it booted fine,
and cascaded interrupts were still working. Therefore

Tested-by: Jonas Gorski 


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] allow setting wiphy.perm_addr after driver probe

[Jonas Gorski]

On Tue, Aug 12, 2014 at 9:59 AM, Marcel Holtmann  wrote:
> Hi Daniel,
>
>>> the way I read the nl80211 code is that the NL80211_CMD_NEW_INTERFACE
>>> requires a wiphy device to be specified. And that is actually just a
>>> number. So I have no idea what the MAC has to here.
>>>
>> OpenWrt finds a wiphy by its MAC.
>
> maybe that is the first problem right there. I see that over sysfs you get 
> phy80211/macaddress. However if you do a dump via NL80211_CMD_GET_WIPHY then 
> you do not have the MAC address there.

OpenWrt nowadays uses the device path in sysfs/devices to identify
wiphys, not the mac anymore (e.g 'pci:00/:00:01.0/ssb0:0').


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MIPS: ath79: irq: Remove the include of drivers/irqchip/irqchip.h

[Jonas Gorski]

On Wed, Jul 8, 2015 at 8:11 PM, Alban Bedel  wrote:
> We shouldn't include irqchip.h from outside of the drivers/irqchip
> directory. The irq driver should idealy be there, however this not
> trivial at the moment. We still need to support platforms without DT
> support and the interface to the DDR controller still use a custom
> arch specific API.
>
> For now just redefine the IRQCHIP_DECLARE macro to avoid the cross
> tree include.
>
> Signed-off-by: Alban Bedel 

The define was moved into linux/irqchip.h in
91e20b5040c67c51aad88cf87db4305c5bd7f79d, so all you can/need to do is
...
> ---
>  arch/mips/ath79/irq.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/ath79/irq.c b/arch/mips/ath79/irq.c
> index afb0096..c5ad737 100644
> --- a/arch/mips/ath79/irq.c
> +++ b/arch/mips/ath79/irq.c
> @@ -17,7 +17,6 @@
>  #include 
>  #include 
>  #include 
> -#include "../../../drivers/irqchip/irqchip.h"
>
>  #include 
>  #include 

this removal ;)


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH linux-next v4 5/5] mtd: atmel-quadspi: add driver for Atmel QSPI controller

[Jonas Gorski]

On Mon, Aug 24, 2015 at 7:45 PM, Marek Vasut  wrote:
> On Monday, August 24, 2015 at 07:04:38 PM, Cyrille Pitchen wrote:
>> Hi Marek,
>
> Hi!
>
>> Le 24/08/2015 13:03, Marek Vasut a écrit :
>> > On Monday, August 24, 2015 at 12:14:00 PM, Cyrille Pitchen wrote:
>> >> This driver add support to the new Atmel QSPI controller embedded into
>> >> sama5d2x SoCs. It expects a NOR memory to be connected to the QSPI
>> >> controller.
>
> [...]
>
>> >> +  /* Compute address parameters */
>> >> +  switch (cmd->enable.bits.address) {
>> >> +  case 4:
>> >> +  ifr |= QSPI_IFR_ADDRL;
>> >> +  /*break;*/ /* fallback to the 24bit address case */
>> >
>> > What's this commented out bit of code for ? :-)
>>
>> I just wanted to stress out there was no missing "break;".
>> I've reworded the comment to:
>> /* No "break" on purpose: fallback to the 24bit address case. */
>
> Oh, the address is in bytes . I see, yes, it makes sense to be more
> explicit here about the purpose of the fallback. I think this change
> in the comment will make it easier for everyone who comes back in a
> few years and reads this code.

I think you are looking for the term "(switch case) fallthrough", not
"fallback". "Fallback" makes it sound like there is something missing,
or an invalid state.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] qcom: ipq4019: Add basic board/dts support for IPQ4019 SoC

[Jonas Gorski]

Hi,

On Tue, Aug 25, 2015 at 2:08 PM, Varadarajan Narayanan
 wrote:
> Add initial dts files and SoC support for IPQ4019
>
> Signed-off-by: Varadarajan Narayanan 
> ---
> Changes in v2:
>   - Added devicetree bindings documentation
>
> Changes in v3:
>   - Split 'gcnt' into a separate patch
>   - Added the new entries to Makefiles, Kconfig & board.c in sorted order
>   - Used "qcom,ipq40xx" instead of "qcom,ipq40xx-r3pc" in board.c
>
> Changes in v4:
>   - Renamed IPQ40xx as IPQ4019
>   - Moved kconfig and defconfig enablement to separate patch
>   - Dropped Documentation/devicetree/bindings/qcom.txt
>
>  arch/arm/boot/dts/Makefile  |  1 +
>  arch/arm/boot/dts/qcom-ipq4019-r3pc.dts | 34 ++
>  arch/arm/boot/dts/qcom-ipq4019.dtsi | 81 
> +
>  3 files changed, 116 insertions(+)
>  create mode 100644 arch/arm/boot/dts/qcom-ipq4019-r3pc.dts
>  create mode 100644 arch/arm/boot/dts/qcom-ipq4019.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 246473a..ca603f3 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -474,6 +474,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
> qcom-apq8074-dragonboard.dtb \
> qcom-apq8084-ifc6540.dtb \
> qcom-apq8084-mtp.dtb \
> +   qcom-ipq4019-r3pc.dtb \
> qcom-ipq8064-ap148.dtb \
> qcom-msm8660-surf.dtb \
> qcom-msm8960-cdp.dtb \
> diff --git a/arch/arm/boot/dts/qcom-ipq4019-r3pc.dts 
> b/arch/arm/boot/dts/qcom-ipq4019-r3pc.dts
> new file mode 100644
> index 000..e3855d7
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-ipq4019-r3pc.dts
> @@ -0,0 +1,34 @@
> +/* Copyright (c) 2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include "qcom-ipq4019.dtsi"
> +
> +/ {
> +   model = "Qualcomm Technologies, Inc. IPQ4019 R3PC";
> +   compatible = "qcom,ipq4019-r3pc", "qcom,ipq4019";
> +
> +   memory {
> +   device_type = "memory";
> +   reg = <0x8000 0x2000>; /* 512MB */
> +   };
> +
> +   chosen {
> +   bootargs = "root=/dev/ram rw init=/init 
> initrd=0x8200,0x000E2246";
> +   stdout-path = "/serial@78b:115200";

I suggest adding an alias to the serial node, so you can just use the
alias name instead of the path (also I never tried using an actual
path, but wouldn't it be "/soc/serial@78b"?).

> +   };
> +
> +   soc {
> +   serial@78b {
> +   status = "ok";
> +   };
> +   };
> +};
> diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi 
> b/arch/arm/boot/dts/qcom-ipq4019.dtsi
> new file mode 100644
> index 000..1be0322
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
> @@ -0,0 +1,81 @@
> +/*
> + * Copyright (c) 2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +/dts-v1/;
> +
> +#include "skeleton.dtsi"
> +
> +/ {
> +   model = "Qualcomm Technologies, Inc. IPQ4019";
> +   compatible = "qcom,ipq4019";
> +   interrupt-parent = <&intc>;
> +
> +   cpus {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   cpu@0 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a7";
> +   reg = <0x0>;
> +   };
> +
> +   cpu@1 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a7";
> +   reg = <0x1>;
> +   };
> +
> +   cpu@2 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a7";
> +   reg = <0x2>;
> +   };
> +
> +   cpu@3 {
> +   device_type = "cpu";
> +   compatible = "arm,cortex-a7";
> +   reg = <0x3>;
> +   };
> +   };
> +
> +   soc {
> +   #address-cells = <1>;
> +   #size-cells =

Re: [PATCH linux-next v5 1/5] mtd: spi-nor: notify (Q)SPI controller about protocol change

[Jonas Gorski]

On Wed, Aug 26, 2015 at 2:30 PM, Cyrille Pitchen
 wrote:
> Once the Quad SPI mode has been enabled on a Micron flash memory, this
> device expects ALL the following commands to use the SPI 4-4-4 protocol.
> The (Q)SPI controller needs to be notified about the protocol change so it
> can adapt and keep on dialoging with the Micron memory.

Doesn't that mean you need to disable quad mode on removal? Else the
following will break/fail:

insmod atmel-quadspi.ko ~> spi-nor attaches -> sees micron -> enables quad mode
rmmod atmel-quadspi.ko ~> spi-nor detaches
insmod atmel-quadspi.ko ~> spi-nor attaches -> fails to read the id
because flash is still in quad mode.

> Signed-off-by: Cyrille Pitchen 
> Acked-by: Marek Vasut 
> Acked-by: Bean Huo 
> ---
>  drivers/mtd/spi-nor/spi-nor.c | 21 +
>  include/linux/mtd/spi-nor.h   | 13 +
>  2 files changed, 34 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index c27d427fead4..c8810313a752 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -165,6 +165,22 @@ static inline int write_disable(struct spi_nor *nor)
> return nor->write_reg(nor, SPINOR_OP_WRDI, NULL, 0, 0);
>  }
>
> +/*
> + * Let the spi-nor framework notify lower layers, especially the driver of 
> the
> + * (Q)SPI controller, about the new protocol to be used. Indeed, once the
> + * spi-nor framework has sent manufacturer specific commands to a memory to
> + * enable its Quad SPI mode, it should immediately after tell the QSPI
> + * controller to use the very same Quad SPI protocol as expected by the 
> memory.
> + */
> +static inline int spi_nor_set_protocol(struct spi_nor *nor,
> +  enum spi_protocol proto)
> +{
> +   if (nor->set_protocol)
> +   return nor->set_protocol(nor, proto);
> +
> +   return 0;

Shouldn't the default assumption be that it won't support it? Also it
might make sense to first check if it's supported before enabling it
in the chip, so that we don't enable something just to then find out
we can't back out of it.

I also wonder if we need an extra flag for that as at least SPI has
RX_{DUAL,QUAD} and TX_{DUAL,QUAD} separated, so in theory there could
be a controller that supports quad read, but not quad write, so we
shouldn't be using the quad mode in that case. m25p80 currently sets
SPI_NOR_{DUAL,QUAD} only based on SPI_RX_{DUAL,QUAD}, so that would
then fail.

At least the n25q32 seems to support the "boring" 1_1_2 and 1_1_4
commands, so these should work in case the spi controller does not
support quad tx, but quad rx.

So maybe an additional flag for the "full" dual/quad modes would be in order.

Last but not least, the protocol probably should be stored somewhere
in the nor struct, so that users don't have to store it themselves (I
assume they will need to check it for each command again to know if
the cmd/address should be send in serial or quad mode).


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/3] dt-binding: spi: Mediatek: Document devicetree bindings for spi bus

[Jonas Gorski]

Hi,

On Wed, Jul 29, 2015 at 1:04 PM, Leilk Liu  wrote:
> Signed-off-by: Leilk Liu 
> ---
>  .../devicetree/bindings/spi/spi-mt65xx.txt | 38 
> ++
>  1 file changed, 38 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/spi/spi-mt65xx.txt
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt 
> b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
> new file mode 100644
> index 000..f8005d6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
> @@ -0,0 +1,38 @@
> +MTK SPI device

You are calling it "MediaTek SPI controller" in the Kconfig entry, so
you should call it that here as well.

> +
> +Required properties:
> +- compatible: should be one of the following.
> +- mediatek,mt8173-spi: for mt8173 platforms
> +- mediatek,mt8135-spi: for mt8135 platforms
> +- mediatek,mt6589-spi: for mt6589 platforms
> +
> +- #address-cells: should be 1.
> +
> +- #size-cells: should be 0.
> +
> +- reg: Address and length of the register set for the device
> +
> +- interrupts: Should contain spi interrupt
> +
> +- clocks: phandles to input clocks.
> +
> +- clock-names: tuple listing input clock names.
> +   Required elements: "main"
> +
> +- pad-select: should specify spi pad used, only required for MT8173.
> +This value should be 0~3.

As already commented on the v3, this is a vendor property, and must
have a vendor prefix, so it must be called "mediatek,pad-select".

> +
> +Example:
> +
> +- SoC Specific Portion:
> +spi: spi@1100a000 {
> +   compatible = "mediatek,mt8173-spi";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   reg = <0 0x1100a000 0 0x1000>;
> +   interrupts = ;
> +   clocks = <&pericfg CLK_PERI_SPI0>;
> +   clock-names = "main";
> +   pad-select = <0>;
> +   status = "disabled";
> +};


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 0/3] Add Mediatek SPI bus driver

[Jonas Gorski]

Hi,

On Wed, Jul 29, 2015 at 1:04 PM, Leilk Liu  wrote:
> Change in v4:
> 1. fix Mark Brown review comment.

You should say what you actually fixed/changed, not just that you
changed something. Also the individual patches should contain
changelogs as well (under the tear-off line (--), so one knows if
something was changed between
versions.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MIPS: Remove all the uses of custom gpio.h

[Jonas Gorski]

Hi,

On Thu, Jul 30, 2015 at 7:28 PM, Alban Bedel  wrote:
> Currently CONFIG_ARCH_HAVE_CUSTOM_GPIO_H is defined for all MIPS
> machines, and each machine type provides its own gpio.h. However
> only a handful really implement the GPIO API, most just forward
> everythings to gpiolib.
>
> The Alchemy machine is notable as it provides a system to allow
> implementing the GPIO API at the board level. But it is not used by
> any board currently supported, so it can also be removed.
>
> For most machine types we can just remove the custom gpio.h, as well
> as the custom wrappers if some exists. Some of the code found in
> the wrappers must be moved to the respective GPIO driver.
>
> A few more fixes are need in some drivers as they rely on linux/gpio.h
> to provides some machine specific definitions, or used asm/gpio.h
> instead of linux/gpio.h for the gpio API.
>
> Signed-off-by: Alban Bedel 
> ---
>
> This patch is based on my previous serie:
> "MIPS: ath79: Move the GPIO driver to drivers/gpio".
>
> It supercede my previous patch named:
> "MIPS: Remove most of the custom gpio.h"
>
> Compared to the previous patch:
> * Fixed gpio_to_irq on jz4740 and rb532
> * Cleaned up alchemy as well
> * Removed asm/gpio.h
>
> For testing I tried to build all mips defconfig, however my toolchain
> couldn't handle a few configs: ip28 malta_qemu_32r6 maltasmvp_eva
> sead3micro. If somebody can test these that would be more than welcome.
>
> Now a few stats about the state of CONFIG_ARCH_HAVE_CUSTOM_GPIO_H
> after appling this patch. Of the 31 supportd arch, 15 still have
> asm/gpio.h, of these 9 are just a "#warning Include linux/gpio.h
> instead of asm/gpio.h". So we have 6 arch left: arm, avr32, blackfin,
> m68k, sh and unicore32. But only m68k and unicore32 really provides
> custom wrappers, all the others only forward to gpiolib.
>
> On the drivers side we only have 13 occurences of '#include
> ' left, mostly in drivers used on ARM SoC.
>
> So the work left to phase out the legacy GPIO is really not that much
> anymore.
>
> Alban
> ---
>  arch/mips/Kconfig   |   1 -
>  arch/mips/alchemy/Kconfig   |   7 --
>  arch/mips/alchemy/board-gpr.c   |   1 +
>  arch/mips/alchemy/board-mtx1.c  |   1 +
>  arch/mips/alchemy/common/Makefile   |   7 +-
>  arch/mips/alchemy/devboards/db1000.c|   1 +
>  arch/mips/alchemy/devboards/db1300.c|   1 +
>  arch/mips/alchemy/devboards/db1550.c|   1 +
>  arch/mips/alchemy/devboards/pm.c|   2 +-
>  arch/mips/ar7/gpio.c|  12 +-
>  arch/mips/ar7/platform.c|   1 -
>  arch/mips/ar7/setup.c   |   1 -
>  arch/mips/include/asm/gpio.h|   6 -
>  arch/mips/include/asm/mach-ar7/ar7.h|   4 +
>  arch/mips/include/asm/mach-ar7/gpio.h   |  41 ---
>  arch/mips/include/asm/mach-ath25/gpio.h |  16 ---
>  arch/mips/include/asm/mach-ath79/gpio.h |  26 -
>  arch/mips/include/asm/mach-au1x00/gpio-au1000.h | 148 
> ++--
>  arch/mips/include/asm/mach-au1x00/gpio.h|  86 --
>  arch/mips/include/asm/mach-bcm47xx/gpio.h   |  17 ---
>  arch/mips/include/asm/mach-bcm63xx/gpio.h   |  15 ---
>  arch/mips/include/asm/mach-cavium-octeon/gpio.h |  21 
>  arch/mips/include/asm/mach-generic/gpio.h   |  21 
>  arch/mips/include/asm/mach-jz4740/gpio.h|   2 -
>  arch/mips/include/asm/mach-lantiq/gpio.h|  13 ---
>  arch/mips/include/asm/mach-loongson64/gpio.h|  36 --
>  arch/mips/include/asm/mach-pistachio/gpio.h |  21 
>  arch/mips/include/asm/mach-rc32434/gpio.h   |  12 --
>  arch/mips/jz4740/gpio.c |  20 ++--
>  arch/mips/pci/pci-lantiq.c  |   1 -
>  arch/mips/rb532/devices.c   |   1 +
>  arch/mips/rb532/gpio.c  |   6 +
>  arch/mips/txx9/generic/setup.c  |  16 ---
>  drivers/ata/pata_rb532_cf.c |   3 +-
>  drivers/gpio/gpio-ath79.c   |  32 -
>  drivers/input/misc/rb532_button.c   |   1 +
>  drivers/net/ethernet/ti/cpmac.c |   2 +
>  37 files changed, 44 insertions(+), 559 deletions(-)
>  delete mode 100644 arch/mips/include/asm/gpio.h
>  delete mode 100644 arch/mips/include/asm/mach-ar7/gpio.h
>  delete mode 100644 arch/mips/include/asm/mach-ath25/gpio.h
>  delete mode 100644 arch/mips/include/asm/mach-ath79/gpio.h
>  delete mode 100644 arch/mips/include/asm/mach-au1x00/gpio.h
>  delete mode 100644 arch/mips/include/asm/mach-bcm47xx/gpio.h
>  delete mode 100644 arch/mips/include/asm/mach-bcm63xx/gpio.h
>  delete mode 100644 arch/mips/include/asm/mach-cavium-octeon/gpio.h
>  delete mode 100644 arch/mips/include/asm/mach-generic/gpio.h
>  delete mode 100644 arch/mips/include/asm/mach-lantiq/gp

Re: [PATCH] spi: mediatek: fix spi incorrect endian usage and remove redundant clock

[Jonas Gorski]

Hi,

On Tue, Aug 18, 2015 at 12:53 PM, Leilk Liu  wrote:
> This patch fixes incorrect endian usage, removes redundant
> clock in prepare_hardware/unprepare_hardware and revises
> coding styles.
>
> Signed-off-by: Leilk Liu 
>
> ---
> Change in this patch:
> 1. fix incorrect endian usage on big-endian system.
> 2. delete redundant clock in prepare/unprepare_hardware.
> 3. revise coding styles.

The usual philosophy is to have one change per patch, so this might be
better as three patches. But this is Mark's call. Since the driver
isn't yet in Linus' tree, it might be a-ok to mix style improvements
and actual fixes, but as soon as it landed in Linus' tree you need to
keep them separate, so fixes can be easily backported.

Regarding the content ...

> ---
>  drivers/spi/spi-mt65xx.c | 163 
> +--
>  include/linux/platform_data/spi-mt65xx.h |   2 -
>  2 files changed, 69 insertions(+), 96 deletions(-)
>
> diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
> index 519f50c..a9da887 100644
> --- a/drivers/spi/spi-mt65xx.c
> +++ b/drivers/spi/spi-mt65xx.c
> @@ -694,6 +662,7 @@ static int mtk_spi_resume(struct device *dev)
> if (!pm_runtime_suspended(dev)) {
> ret = clk_prepare_enable(mdata->spi_clk);
> if (ret < 0)
> +   dev_err(dev, "failed to enable spi_clk (%d)\n", ret);
> return ret;

You need to add braces here, else the "return ret" isn't covered by
the if () anymore and you always return at this place.

> }
>
> @@ -720,8 +689,14 @@ static int mtk_spi_runtime_resume(struct device *dev)
>  {
> struct spi_master *master = dev_get_drvdata(dev);
> struct mtk_spi *mdata = spi_master_get_devdata(master);
> +   int ret;
> +
> +   ret = clk_prepare_enable(mdata->spi_clk);
> +   if (ret < 0)
> +   dev_err(dev, "failed to enable spi_clk (%d)\n", ret);
> +   return ret;

Same here. Although at least here it should be harmless, as
clk_prepare_enable doesn't return > 0.

>
> -   return clk_prepare_enable(mdata->spi_clk);
> +   return 0;
>  }
>  #endif /* CONFIG_PM */
>


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/3] qcom: Add SMEM MTD parser

[Jonas Gorski]

Hi,

On Tue, Aug 18, 2015 at 1:47 AM, Mathieu Olivari  wrote:
> QCOM platforms such as IPQ806x are using SMEM to store their flash
> layout. This patch set adds the DT nodes required to instanciate SMEM
> on IPQ806x and add an MTD parser using it.
>
> This change is based on the SMEM driver posted here:
> *https://lkml.org/lkml/2015/7/27/1125

Nice work. After testing it on AP148 I see this:

[2.481507] 12 qcom-smem partitions found on MTD device qcom-nandc
[2.481540] Creating 12 MTD partitions on "qcom-nandc":
[2.486690] 0x-0x0004 : "0:SBL1"
[2.492842] 0x0004-0x0018 : "0:MIBIB"
[2.497857] 0x0018-0x002c : "0:SBL2"
[2.502895] 0x002c-0x0054 : "0:SBL3"
[2.507828] 0x0054-0x0066 : "0:DDRCONFIG"
[2.512857] 0x0066-0x0078 : "0:SSD"
[2.518074] 0x0078-0x00a0 : "0:TZ"
[2.522834] 0x00a0-0x00c8 : "0:RPM"
[2.527607] 0x00c8-0x0118 : "0:APPSBL"
[2.532472] 0x0118-0x0120 : "0:APPSBLENV"
[2.537586] 0x0120-0x0134 : "0:ART"
[2.543140] 0x0134-0x0534 : "rootfs"

Are all these partition names supposed to be prefixed with "0:"? This
is using the OpenWrt applied version.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] mtd: brcmnand: Add brcm,bcm6368-nand device tree binding

[Jonas Gorski]

On Thu, Dec 3, 2015 at 12:41 AM, Simon Arlott  wrote:
> Add device tree binding for NAND on the BCM6368.
>
> The BCM6368 has a NAND interrupt register with combined status and enable
> registers. It also requires a clock, so add an optional clock to the
> common brcmnand binding.
>
> Signed-off-by: Simon Arlott 
> ---
> Renamed from BCM63268, made clock a generic property.
>
>  .../devicetree/bindings/mtd/brcm,brcmnand.txt  | 32 
> ++
>  1 file changed, 32 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt 
> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> index 4ff7128..16d7835 100644
> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> @@ -45,6 +45,8 @@ Required properties:
>  - #size-cells  : <0>
>
>  Optional properties:
> +- clock : reference to the clock for the NAND controller
> +- clock-names   : "nand" (required for the above clock)
>  - brcm,nand-has-wp  : Some versions of this IP include a 
> write-protect
>(WP) control bit. It is always available on >=
>v7.0. Use this property to describe the rare
> @@ -72,6 +74,12 @@ we define additional 'compatible' properties and 
> associated register resources w
> and enable registers
>   - reg-names: (required) "nand-int-base"
>
> +   * "brcm,nand-bcm6368"
> + - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm6368"
> + - reg: (required) the 'NAND_INTR_BASE' register range, with combined 
> status
> +   and enable registers, and boot address registers
> + - reg-names: (required) "nand-intr-base"

Can't we use the same name as bcm63138, i.e. nand-int-base?

> +
> * "brcm,nand-iproc"
>   - reg: (required) the "IDM" register range, for interrupt enable and APB
> bus access endianness configuration, and the "EXT" register range,
> @@ -148,3 +156,27 @@ nand@f0442800 {
> };
> };
>  };
> +
> +nand@1200 {
> +   compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368",
> +   "brcm,brcmnand-v4.0", "brcm,brcmnand";

I know it's now much too late, but this is IMHO a very odd way of
defining that this is a v4 nand, but uses bcm6368 compatible
interrupts, as bcm6368 is a much older, unsupported nand revision.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/7] mtd: partitions: add of_match_table support

[Jonas Gorski]

Hi,

On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
 wrote:
> Hi,
>
> There have been several discussions [1] about adding a device tree binding for
> associating flash devices with the partition parser(s) that are used on the
> flash. There are a few reasons:
>
>  (1) drivers shouldn't have to be encoding platform knowledge by listing what
>  parsers might be used on a given system (this is the currently all that's
>  supported)
>  (2) we can't just scan for all supported parsers (like the block system 
> does), since
>  there is a wide diversity of "formats" (no standardization), and it is 
> not
>  always safe or efficient to attempt to do so, particularly since many of
>  them allow their data structures to be placed anywhere on the flash, and
>  so require scanning the entire flash device to find them.
>
> So instead, let's support a new binding so that a device tree can specify what
> partition formats might be used. This seems like a reasonable choice (even
> though it's not strictly a hardware description) because the flash layout /
> partitioning is often very closely tied with the bootloader/firmware, at
> production time.

On a first glance this looks good to me, and looks easily extensible
for application of non-complete partition parsers.

E.g. for the "brcm,bcm6345-imagetag" we would want to actually do something like

partitions {


partition@0 {
reg = <0x0 0x1>;
label = "cfe";
read-only;
};

partition@1 {
reg = <0x1 0x3d>;
label = "firmware";
compatible = "brcm,bcm6345-imagetag";
};

partition@3e {
reg = <0x3e 0x1>;
label = "art";
read-only;
};

   partition@3f {
reg = <0x3f 0x1>;
label = "nvram";
read-only;
};
};

as the image tag can only specify the offsets and sizes of the rootfs
and kernel parts, but not of any other parts.

>
> Also, as an example first-use of this mechanism, I support Google's FMAP flash
> structure, used on Chrome OS devices.
>
> Note that this is an RFC, mainly for the reason noted in patch 6 ("RFC: mtd:
> partitions: enable of_match_table matching"): the of_match_table support won't
> yet autoload a partition parser that is built as a module. I'm not quite sure
> if there's a lot of value in supporting MTD parsers as modules (block 
> partition
> support can't be), but that is supported for "by-name" parser lookups in MTD
> already, so I don't feel like dropping that feature yet. Tips or thoughts are
> particularly welcome on this aspect!

I would assume a lot of the cases these would be a chicken-egg
problem, you need the parser to be able to find and mount the rootfs,
but you you need mount the rootfs to load the parser.

> Also note that there's an existing undocumented binding for a
> "linux,part-probe" property, but it is only usable on the physmap_of.c driver
> at the moment, and it is IMO not a good binding. I posted my thoughts on that
> previously here [2], and since no one else cared to make a better one...I did
> it myself.
>
> I'd love it if we could kill the unreviewed binding off in favor of something
> more like this...

I agree fully that this is a bad binding, as it exposes internal names
that aren't supposed to be fixed.


Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding

[Jonas Gorski]

On Sat, Dec 5, 2015 at 6:19 AM, Brian Norris
 wrote:
> The platform description (such as the type of partition formats used on
> a given flash) should be done independently of the flash driver in use.
> However, we can't reasonably have *all* partition parsers run on all
> flash (until they find a match), so let's overload the 'partitions'
> subnode to support specifying which format(s) to try in the device tree.
>
> Start by supporting Google's (Chrome OS) FMAP structure.
>
> There have been others interested in extending devicetree support to
> other parsers, like the bcm47xxpart parser:
>
>   http://patchwork.ozlabs.org/patch/475986/
>
> and the AFS (ARM Flash Structure?) parser:
>
>   http://patchwork.ozlabs.org/patch/537827/
>
> Signed-off-by: Brian Norris 
> ---
>  .../devicetree/bindings/mtd/partition.txt  | 75 
> --
>  1 file changed, 69 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
> b/Documentation/devicetree/bindings/mtd/partition.txt
> index 28ae56f5c972..1bf9a7243993 100644
> --- a/Documentation/devicetree/bindings/mtd/partition.txt
> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> @@ -1,29 +1,56 @@
> -Representing flash partitions in devicetree
> +Flash partitions in device tree
> +===
>
> -Partitions can be represented by sub-nodes of an mtd device. This can be used
> +Flash devices can be partitioned into one or more functional ranges (e.g.,
> +"boot code", "nvram", and "kernel") in at least two distinct ways:
> +
> + (A) a fixed flash layout at production time or
> + (B) with an on-flash partition table, such as RedBoot, that describes the
> + geometry and naming/purpose of each functional region
> +
> +The former typically requires an operating system to learn about the
> +partitioning from some kind of metadata provided by the bootloader/firmware.
> +Such partitions can be described using the method in "Section A: Fixed 
> Partitions".
> +
> +The latter is somewhat analogous to partition tables used on block devices
> +(e.g., MBR or GPT), except that there is less standardization for flash
> +devices, and it is not always safe or efficient to attempt to search for all 
> of
> +them on every flash device in the system, particularly since many of them 
> allow
> +their data structures to be placed anywhere on the flash, and so require
> +scanning the entire flash device to find them.
> +
> +To assist system software in locating these partition tables, we provide a
> +binding to describe which partition format(s) may be used on a given flash,
> +found below in "Section B: On-Flash Partition Tables".
> +
> +
> +Section A: Fixed Partitions
> +---
> +
> +Partitions can be represented by sub-nodes of a flash device. This can be 
> used
>  on platforms which have strong conventions about which portions of a flash 
> are
>  used for what purposes, but which don't use an on-flash partition table such
>  as RedBoot.
>
> -The partition table should be a subnode of the mtd node and should be named
> +The partition table should be a subnode of the flash node and should be named
>  'partitions'. This node should have the following property:
>  - compatible : (required) must be "partitions"
>  Partitions are then defined in subnodes of the partitions node.
>
> -For backwards compatibility partitions as direct subnodes of the mtd device 
> are
> +For backwards compatibility partitions as direct subnodes of the flash 
> device are
>  supported. This use is discouraged.
>  NOTE: also for backwards compatibility, direct subnodes that have a 
> compatible
>  string are not considered partitions, as they may be used for other bindings.
>
>  #address-cells & #size-cells must both be present in the partitions subnode 
> of the
> -mtd device. There are two valid values for both:
> +flash device. There are two valid values for both:
>  <1>: for partitions that require a single 32-bit cell to represent their
>   size/address (aka the value is below 4 GiB)
>  <2>: for partitions that require two 32-bit cells to represent their
>   size/address (aka the value is 4 GiB or greater).
>
>  Required properties:
> -- reg : The partition's offset and size within the mtd bank.
> +- reg : The partition's offset and size within the flash
>
>  Optional properties:
>  - label : The label / name for this partition.  If omitted, the label is 
> taken
> @@ -89,3 +116,39 @@ flash@2 {
> };
> };
>  };
> +
> +
> +Section B: On-Flash Partition Tables
> +
> +
> +System designers use a variety of on-flash data structures to describe the
> +layout of the flash. Because it's not always optimal for system software to
> +scan for every sort of data structure that might be used, one can specify 
> which
> +structure(s) might be used on a given flash using the 'partitions' subnode of
> +the flash node.
> +
> +Node name: partition

Re: [PATCH] mtd: brcmnand: Workaround false ECC uncorrectable errors

[Jonas Gorski]

Hi,

On Sat, Nov 28, 2015 at 8:23 PM, Simon Arlott  wrote:
> Workaround false ECC uncorrectable errors by checking if the data
> has been erased and the OOB data indicates that the data has been
> erased. The v4.0 controller on the BCM63168 incorrectly handles
> these as uncorrectable errors.
>
> I don't know which version of the controller handles this scenario
> correctly. I'm only able to test this in Hamming mode, so the BCH
> version needs to be checked.
>
> This code is quite complicated because the fact that either the data
> buffer or the OOB data may not have been read from the controller, and
> both of them are required to determine if the error is incorrect.
>
> Signed-off-by: Simon Arlott 
> ---
>  drivers/mtd/nand/brcmnand/brcmnand.c | 107 
> ++-
>  1 file changed, 106 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
> b/drivers/mtd/nand/brcmnand/brcmnand.c
> index 5f26b8a..0857af7 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -1387,6 +1387,102 @@ static int brcmnand_dma_trans(struct brcmnand_host 
> *host, u64 addr, u32 *buf,
>  }
>
>  /*
> + * Workaround false ECC uncorrectable errors by checking if the data
> + * has been erased and the OOB data indicates that the data has been
> + * erased. The controller incorrectly handles these as uncorrectable
> + * errors.
> + */
> +static void brcmnand_read_ecc_unc_err(struct mtd_info *mtd,
> +   struct nand_chip *chip,
> +   int idx, unsigned int trans,
> +   u32 *buf, u8 *oob_begin, u8 *oob_end,
> +   u64 *err_addr)
> +{
> +   struct brcmnand_host *host = chip->priv;
> +   struct brcmnand_controller *ctrl = host->ctrl;
> +   u32 *buf_tmp = NULL;
> +   u8 *oob_tmp = NULL;
> +   bool buf_erased = false;
> +   bool oob_erased = false;
> +   int j;
> +
> +   /* Assume this is fixed in v5.0+ */
> +   if (ctrl->nand_version >= 0x0500)
> +   return;
> +
> +   /* Read OOB data if not already read */
> +   if (!oob_begin) {
> +   oob_tmp = kmalloc(ctrl->max_oob, GFP_KERNEL);
> +   if (!oob_tmp)
> +   goto out_free;
> +
> +   oob_begin = oob_tmp;
> +   oob_end = oob_tmp;
> +
> +   oob_end += read_oob_from_regs(ctrl, idx, oob_tmp,
> +   mtd->oobsize / trans,
> +   host->hwcfg.sector_size_1k);
> +   }
> +
> +   if (is_hamming_ecc(&host->hwcfg)) {
> +   u8 *oob_offset = oob_begin + 6;
> +
> +   if (oob_offset + 3 < oob_end)
> +   /* Erased if ECC bytes are all 0xFF, or the data bytes
> +* are all 0xFF which should have Hamming codes of 
> 0x00
> +*/
> +   oob_erased = memchr_inv(oob_offset, 0xFF, 3) == NULL 
> ||
> +   memchr_inv(oob_offset, 0x00, 3) == NULL;
> +   } else { /* BCH */
> +   u8 *oob_offset = oob_end - ctrl->max_oob;
> +
> +   if (oob_offset >= oob_begin)
> +   /* Erased if ECC bytes are all 0xFF */
> +   oob_erased = memchr_inv(oob_offset, 0xFF,
> +   oob_end - oob_offset) == NULL;
> +   }
> +
> +   if (!oob_erased)
> +   goto out_free;
> +
> +   /* Read data buffer if not already read */
> +   if (!buf) {
> +   buf_tmp = kmalloc_array(FC_WORDS, sizeof(*buf_tmp), 
> GFP_KERNEL);
> +   if (!buf_tmp)
> +   goto out_free;
> +
> +   buf = buf_tmp;
> +
> +   brcmnand_soc_data_bus_prepare(ctrl->soc);
> +
> +   for (j = 0; j < FC_WORDS; j++, buf++)
> +   *buf = brcmnand_read_fc(ctrl, j);
> +
> +   brcmnand_soc_data_bus_unprepare(ctrl->soc);
> +   }
> +
> +   /* Go to start of buffer */
> +   buf -= FC_WORDS;
> +
> +   /* Erased if all data bytes are 0xFF */
> +   buf_erased = memchr_inv(buf, 0xFF, FC_WORDS) == NULL;
> +
> +   if (!buf_erased)
> +   goto out_free;

We now have a function exactly for that use case in 4.4,
nand_check_erased_buf [1], consider using that. This also has the
benefit of treating bit flips as correctable as long as the ECC scheme
is strong enough.


Jonas

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/nand/nand_base.c#n1110
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Revert "of/irq: make of_irq_find_parent static"

[Jonas Gorski]

Hi,

On Wed, Dec 2, 2015 at 5:14 PM, Qais Yousef  wrote:
> This reverts commit 52493d446141b07c8ba28dd6a529513f8b2342bd.
>
> Signed-off-by: Qais Yousef 
>
> Conflicts:
> include/linux/of_irq.h
> ---
> I have a patch series that is under review that makes use of 
> of_irq_find_parent()
>
> The affected patch is this:
>
> https://lkml.org/lkml/2015/11/25/291
>
> Is it wrong to use this function? If yes, what's the alternative?
> If no, OK to revert?

Make the revert part of the series that needs it, so it won't get
moved again because of no external users.

also ...

>
> Thanks,
> Qais
>
>
>  drivers/of/irq.c   | 2 +-
>  include/linux/of_irq.h | 6 ++
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 902b89be7217..45735d56e435 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -53,7 +53,7 @@ EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
>   * Returns a pointer to the interrupt parent node, or NULL if the interrupt
>   * parent could not be determined.
>   */
> -static struct device_node *of_irq_find_parent(struct device_node *child)
> +struct device_node *of_irq_find_parent(struct device_node *child)
>  {
> struct device_node *p;
> const __be32 *parp;
> diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
> index 039f2eec49ce..0c9ea9fb5b63 100644
> --- a/include/linux/of_irq.h
> +++ b/include/linux/of_irq.h
> @@ -93,6 +93,7 @@ static inline void of_msi_configure(struct device *dev, 
> struct device_node *np)
>   * so declare it here regardless of the CONFIG_OF_IRQ setting.
>   */
>  extern unsigned int irq_of_parse_and_map(struct device_node *node, int 
> index);
> +extern struct device_node *of_irq_find_parent(struct device_node *child);

This is the wrong place to add the prototype, and

>  u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 
> rid_in);
>
>  #else /* !CONFIG_OF && !CONFIG_SPARC */
> @@ -102,6 +103,11 @@ static inline unsigned int irq_of_parse_and_map(struct 
> device_node *dev,
> return 0;
>  }
>
> +static inline void *of_irq_find_parent(struct device_node *child)
> +{
> +   return NULL;
> +}
> +

This is the wrong place to add the inline version. Both need to be
within the #ifdef CONFIG_OF_IRQ ... #else ... #endif block, as the
function is not available just with CONFIG_OF.


>  static inline u32 of_msi_map_rid(struct device *dev,
>  struct device_node *msi_np, u32 rid_in)

@Daney:

And this one is at the wrong place as well. Please fix it.

This will break the build if CONFIG_OF is enabled but CONFIG_OF_IRQ
isn't, and something tries to call these functions.


Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/