kernel: Disable IXP4xx physmap by default

This makes no sense on anything but the IXP4xx platform
that we do not even support anymore. If we bring it back,
it can be selectively enabled for that platform only.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 target/linux/generic/config-5.10 | 1 +
 1 file changed, 1 insertion(+)

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
Now that there is DTS support in the mainline kernel for IXP4xx what is the recommended approach for re-enabling support for devices with adequate Flash and RAM (i.e. ADI Engineering SBC250, Gateworks Avila and Cambria, US Robotics USR8200)?

There is already a DTS available for the Gateworks Cambria GW2358.  I also have access to Edgewater Networks, Secure Computing and WatchGuard devices that use the IXP4xx processor and have adequate Flash and RAM.

Ray


> On Apr 14, 2021, at 4:36 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> 
> This makes no sense on anything but the IXP4xx platform
> that we do not even support anymore. If we bring it back,
> it can be selectively enabled for that platform only.
> 
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> target/linux/generic/config-5.10 | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10
> index 457f62b195c0..a52fa1e6812b 100644
> --- a/target/linux/generic/config-5.10
> +++ b/target/linux/generic/config-5.10
> @@ -3556,6 +3556,7 @@ CONFIG_MTD_OF_PARTS=y
> # CONFIG_MTD_PHYSMAP is not set
> # CONFIG_MTD_PHYSMAP_COMPAT is not set
> # CONFIG_MTD_PHYSMAP_GEMINI is not set
> +# CONFIG_MTD_PHYSMAP_IXP4XX is not set
> # CONFIG_MTD_PHYSMAP_GPIO_ADDR is not set
> CONFIG_MTD_PHYSMAP_OF=y
> # CONFIG_MTD_PHYSMAP_OF_GEMINI is not set
> --
> 2.29.2
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

On Thu, Apr 15, 2021 at 8:03 AM Raylynn Knight <rayknight@me.com> wrote:

> Now that there is DTS support in the mainline kernel for IXP4xx what is the
> recommended approach for re-enabling support for devices with adequate
> Flash and RAM (i.e. ADI Engineering SBC250, Gateworks Avila and Cambria,
> US Robotics USR8200)?

The right approach is to finish the driver migration in the mainline kernel,
so that all of the platform can be probed from DTS files.

The two main drivers to be fixed are:

- The ethernet phy DTS binding (I was planning to work on this but you
  know, time)

- The PCI host complex

I think complete migration should be doable, some minor drivers may
need some extra work after that but these two things would make
complete device tree migration possible for all boards.
So if we fix this we can start to re-enable IXP4xx on top.

(Then there will be some fringe drivers, for example the NSLU2
beeper driver...)

There is a bigger issue for complete modernization of the architecture.
The PCI host is a complicated beast because accesses to PCI on
IXP4xx are crippled. You can see that in this file:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-ixp4xx/include/mach/io.h
the _indirect versions of generic readw/writel etc are really serious
stuff. My idea for a long-term solution is to create some infrastructure
for runtime patching. A really complicated problem for someone
who has time to spend.

> There is already a DTS available for the Gateworks Cambria GW2358.
> I also have access to Edgewater Networks, Secure Computing and
> WatchGuard devices that use the IXP4xx processor and have adequate
> Flash and RAM.

I think making device trees for all of them should be doable once we
have migrated ethernet and PCI host to device tree.

Now that I know there is interest I might get more motivation to
work on it :) can I include you on CC if I post patches for
review?

Yours,
Linus Walleij

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
I definitely have interested, but I’m currently trying to contribute to the new realtek switch effort and also have some D-Link and Netgear Octeon devices I’d like to add support for.  I would be happy to provide reviews and testing on devices as time permits.  I have about 30 different IXP4xx devices available in my collection.

The Edgewater Networks and WatchGuard IXP4xx devices have decent specs and are widely available on eBay now that the vendors no longer support them.


Ray

> On Apr 15, 2021, at 4:48 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> 
> On Thu, Apr 15, 2021 at 8:03 AM Raylynn Knight <rayknight@me.com> wrote:
> 
>> Now that there is DTS support in the mainline kernel for IXP4xx what is the
>> recommended approach for re-enabling support for devices with adequate
>> Flash and RAM (i.e. ADI Engineering SBC250, Gateworks Avila and Cambria,
>> US Robotics USR8200)?
> 
> The right approach is to finish the driver migration in the mainline kernel,
> so that all of the platform can be probed from DTS files.
> 
> The two main drivers to be fixed are:
> 
> - The ethernet phy DTS binding (I was planning to work on this but you
>  know, time)
> 
> - The PCI host complex
> 
> I think complete migration should be doable, some minor drivers may
> need some extra work after that but these two things would make
> complete device tree migration possible for all boards.
> So if we fix this we can start to re-enable IXP4xx on top.
> 
> (Then there will be some fringe drivers, for example the NSLU2
> beeper driver...)
> 
> There is a bigger issue for complete modernization of the architecture.
> The PCI host is a complicated beast because accesses to PCI on
> IXP4xx are crippled. You can see that in this file:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-ixp4xx/include/mach/io.h
> the _indirect versions of generic readw/writel etc are really serious
> stuff. My idea for a long-term solution is to create some infrastructure
> for runtime patching. A really complicated problem for someone
> who has time to spend.
> 
>> There is already a DTS available for the Gateworks Cambria GW2358.
>> I also have access to Edgewater Networks, Secure Computing and
>> WatchGuard devices that use the IXP4xx processor and have adequate
>> Flash and RAM.
> 
> I think making device trees for all of them should be doable once we
> have migrated ethernet and PCI host to device tree.
> 
> Now that I know there is interest I might get more motivation to
> work on it :) can I include you on CC if I post patches for
> review?
> 
> Yours,
> Linus Walleij
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

On Fri, Apr 16, 2021 at 5:27 AM Raylynn Knight <rayknight@me.com> wrote:

> I definitely have interested, but I’m currently trying to contribute to the new
> realtek switch effort and also have some D-Link and Netgear Octeon
> devices I’d like to add support for.  I would be happy to provide reviews
> and testing on devices as time permits.  I have about 30 different IXP4xx
> devices available in my collection.

Fair enough, I pulled out my Cambria yesterday to continue some of the
work. I will include you on Cc for patches I send so you know what is
happening.

Yours,
Linus Walleij