Re: [PATCH 2/7] realtek: rtl83xx-phy: decouple RTL8214FC media change and power config

[Birger Koblitz]

On 7/23/22 22:53, Jan Hoffmann wrote:

Move RTL8214FC power configuration to newly created suspend and resume
methods. A media change now only results in power configuration if the
PHY is not suspended, to avoid powering up a port when the interface is
currently not up.

While at it, remove the rtl8380 prefix from function names, as this is
actually not SoC-specific.

Nice work! Tested on D-Link DGS-1210-16.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 4/7] realtek: clean up rtl838x MDIO busy wait loop

[Birger Koblitz]

On 7/23/22 22:53, Jan Hoffmann wrote:

Don't use udelay to allow other kernel tasks to execute if the kernel
has been built without preemption. Also determine the timeout based on
jiffies instead of loop iterations.


Tested on a D-Link DGS-1210-16.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 3/7] realtek: add SFP support for RTL8214FC PHY

[Birger Koblitz]

On 7/23/22 22:53, Jan Hoffmann wrote:

Probe the SFP module during PHY initialization and implement
insertion/removal handlers to automatically configure the media type
of the respective port.


Tested on a D-Link DGS-1210-16, which however needs updated .dts to make 
use of this feature.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [RFC PATCH 0/7] realtek: MFD for switch core

[Birger Koblitz]

Hi Sander,

On 7/17/22 15:37, Sander Vanheule wrote:

On Sat, 2022-07-16 at 23:09 +0200, Birger Koblitz wrote:

Hi,

On 7/16/22 21:31, Sander Vanheule wrote:

On Sat, 2022-07-16 at 21:09 +0200, Sander Vanheule wrote:

This RFC series introduces a new MFD device for the switch core found
in the Realtek SoCs. Currently only an implementation is provided for
RTL8380, but it written with the register structure of other generations
in mind.

this looks very promising as it offers the pin control we always needed.

I have not looked through the code in detail, yet. The biggest question
I have at this point is that at this point the code does not include the
other SoC generations.


It doesn't because most users are currently on RTL8380, so that's where I can
get some feedback from real use cases. I usually run an initramfs image loaded
via u-boot, so it's quite possible some setup is still missing.


Especially when it comes to the LEDs, they are
very different. In fact the RTL838x is the odd-man-out. I would really
like to see how they will be included. In the past several design
decision turned out to be not so optimal after we learned about the
newer SoCs. Today we have all of them very well understood, so it should
not be an issue to add at least some code for the RTL93xx generation,
which has the LEDs modernized quite a bit.


Although I only wrote the RTL8380 implementation, the code is already structured
to follow the RTL8390 and later. Aside from correctly defining most pin muxes, I
was able to add port LED and pinctrl support for RTL8390 this morning in about
4h. I wouldn't say my code was that badly suited to those chips then.
I don't see that you actually do the hardware setup for the LEDs, or am 
I missing something? You rely on u-boot or the existing led_init() 
functions (e.g. 
https://github.com/openwrt/openwrt/commit/3190361ace26cc63fe64a166067c7c543d568337) 
to configure the HW offload settings, to setup the LED topology and 
attributing it to a LED-set and define what port type it is (fibre, 
ethernet, combo,...), right? For that one needs to have access to the 
PHY-information. Would you add that into the LED driver, or should that 
be a property of the switch driver?
On the RTL93xx devices that correctly initializes the LEDs in u-boot are 
an exception, that was BTW the reason I pointed to the other SoCs.




This is still an RFC, and if it goes upstream it needs to go through staging.
Staging should allow for things to evolve more freely. You're right that is
isn't a finished product, but if we don't push this out early to get feedback,
it's never going to be.
I don't really see the hurry. There are different design options for 
this, I would like to understand implications, first. At least we are 
now in a position to understand all SoC generations and can take that 
into account.






The other question I have is whether this allows us to solve the other
big issue we have with these SoCs: Providing information between
drivers.


Thats why this is an MFD. IIUC these can provide extra data to child devices, so
that could solve that issue (if needed). Generally speaking, this is something
you want to avoid however IMHO. In most cases, a SoC-generation specific DT
compatible already provides sufficient info.

One potential issue that comes to mind, is that the regmap is currently globally
locked on any access. I can imagine this will casue performace issues for the
ethernet driver. Those registers are mostly independent from the rest of the
register space though, so custom regmap locking will probably need to be used.
We should be sure this will work. Ethernet performance is not fantastic 
as it is, further degradation would be really bad. The driver should 
also anticipate more of the possible offloading, e.g. not copying over 
TX buffers as MIPS can do DMA from anywhere.





For example you have written the 2nd copy of the model name
reading function in rtl8380_probe_model_name(), and it does not even
probe the other 3 SoC generations.


See above, this isn't intended to be a complete implementation. And it's really
there just to print the SoC name so the user knows which platform they are on,
nothing else.


But this information is needed
already at the very start of the boot process and several other drivers.
So why not provide a global structure like on other MIPS architectures
and populate it with information such as machine name and especially
switch structure for other drivers to use plus all the other
configuration details of a particular SoC (there are nearly 2 dozen
different RTL9300 SoCs all having a different structure for the MII
ports). In a very simple example, NOR access needs information about the
3/4 byte strapping pin from the switch core, but its registers live at a
completely different place in the SoC. The lack of such global
information is evident from e.g. your Netgear .dts.


I could be wrong, but providing global structures seems to be a thing of the
past. I

Re: [RFT 0/5] realtek: support boards similar to DGS-1210-10

[Birger Koblitz]

Hi,

On 7/17/22 11:55, Paul Fertser wrote:

On Sat, Jul 16, 2022 at 11:32:52PM -0300, Luiz Angelo Daros de Luca wrote:

It uses SOC := rtl8380 while all existing dgs-1210 F1 variants use
rtl8382 (except for the pending -52 variant). The commit didn't
mention why that happened.


It's just cosmetic AFAICT but the datasheet clearly states that the
SoC used for <=18 ports switches is called RTL8380.
during OpenWRT boot, the SoC is identified by reading out a 
configuration register. It will say something like
[0.00] Linux version 5.10.127 (birger@MintDesktop) 
(mips-openwrt-linux-musl-gcc (OpenWrt GCC 11.3.0 r18457+1542-4b587f2561) 
11.3.0, GNU ld (GNU Binutils) 2.37) #0 SMP Tue Jul 12 19:01:38 2022

[0.00] RTL838X model is 8380 (4 first hex digits give model ID)
[0.00] SoC Type: RTL8380
That should always be correct, unless there is something we are missing.

Cheers,
  Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [RFC PATCH 0/7] realtek: MFD for switch core

[Birger Koblitz]

Hi,

On 7/16/22 21:31, Sander Vanheule wrote:

On Sat, 2022-07-16 at 21:09 +0200, Sander Vanheule wrote:

This RFC series introduces a new MFD device for the switch core found
in the Realtek SoCs. Currently only an implementation is provided for
RTL8380, but it written with the register structure of other generations
in mind.

this looks very promising as it offers the pin control we always needed.

I have not looked through the code in detail, yet. The biggest question 
I have at this point is that at this point the code does not include the 
other SoC generations. Especially when it comes to the LEDs, they are 
very different. In fact the RTL838x is the odd-man-out. I would really 
like to see how they will be included. In the past several design 
decision turned out to be not so optimal after we learned about the 
newer SoCs. Today we have all of them very well understood, so it should 
not be an issue to add at least some code for the RTL93xx generation, 
which has the LEDs modernized quite a bit.


The other question I have is whether this allows us to solve the other 
big issue we have with these SoCs: Providing information between 
drivers. For example you have written the 2nd copy of the model name 
reading function in rtl8380_probe_model_name(), and it does not even 
probe the other 3 SoC generations. But this information is needed 
already at the very start of the boot process and several other drivers.
So why not provide a global structure like on other MIPS architectures 
and populate it with information such as machine name and especially 
switch structure for other drivers to use plus all the other 
configuration details of a particular SoC (there are nearly 2 dozen 
different RTL9300 SoCs all having a different structure for the MII 
ports). In a very simple example, NOR access needs information about the 
3/4 byte strapping pin from the switch core, but its registers live at a 
completely different place in the SoC. The lack of such global 
information is evident from e.g. your Netgear .dts. Although you know 
that the first used port is 8, from the fact its an RTL8382M SoC or 
alternatively the ports in the .dts, you need to add another time the 
information about port to LED number.


Another point I have is more general: The pinctrl driver is a lot of 
code for controlling the LEDs, which are not even pins on the SoC, but 
controlled through a serial bus. Is this really the right type of 
driver? Many of the LED drivers in Linux work similarly and provide a 
standard interface to users. Also the LEDs are actually controlled by 
the RTL8231 via a serial link on many models, not the Switch Core. 
Placing the LED control into the switch core is a bit confusing, should 
there not at least be a node for the RTL8231 in the .dts reflecting the 
actual HW setup? Why not a small setup function for automatic HW control 
of all LEDs as already done for the other SoC generations and a 
dedicated LED driver. This might reduce code complexity and reflect the 
actual hardware setup.


Cheers,
  Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v2 1/4] realtek: correct egress frame priority assignment

[Birger Koblitz]

On 19/06/2022 13:46, Sander Vanheule wrote:

Priority values passed to the egress (TX) frame header initialiser are
invalid when smaller than 0, and should not be assigned to the frame.
Queue assignment is then left to the switch core logic.

Current code for RTL83xx forces the passed priority value to be
positive, by always masking it to the lower bits, resulting in the
priority always being set and enabled. RTL93xx code doesn't even check
the value and unconditionally assigns the (32 bit) value to the (5 bit)
QID field without masking.

Fix priority assignment by only setting the AS_QID/AS_PRI flag when a
valid value is passed, and properly mask the value to not overflow the
QID/PRI field.

For RTL839x, also assign the priority to the right part of the frame
header. Counting from the leftmost bit, AS_PRI and PRI are in bits 36
and 37-39. The means they should be assigned to the third 16 bit value,
containing bits 32-47.


Perfect!

Best
 Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: correct egress frame port verification

[Birger Koblitz]

Hi,

On 19.06.22 10:56, Sander Vanheule wrote:

> - h->cpu_tag[1] = h->cpu_tag[2] = 0;
> - if (prio >= 0)
> - h->cpu_tag[2] = BIT(13) | prio << 8; // Enable and set Priority 
> Queue
> + h->cpu_tag[1] = 0;
> + /* Enable (AS_QID) and set Priority Queue (QID) */
> + h->cpu_tag[2] = (BIT(5) | (prio & 0x1f)) << 8;
You are removing the possibility to let the SoC choose a Queue on its own based 
on congestion,
if you always enable AS_QID. There was a reason that there were negative 
Queue-ID values, which
denoted allowing the SoC to choose, i.e. AS_QID was not set.

Cheers,
  Birger


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v3] realtek: fix tx checks

[Birger Koblitz]

Hi,

dest_port -1 means flood all ports with a broadcast packet in the tx routine,
the tag functions can only be called with dest_port >= 0, however.
In the case of broadcast packets there should not be a CPU-tag with a 
destination port,
or all bits in the destination port mask would need to be set.
So within the tx routine dest_port < 0 is OK, but the tag routines should not
be called with such a value currently, since for RTL93xx the >= 0 check was 
missing.
For RTL93xx there is currently a bug for dest_port < 0 here, which does however
not seem to have any obvious negative impact.

In principle for RTL83xx dest_port < 0 could be provided, in which case AS_DPM
(assert Destination Port Mask) should not be set and dest_port would be ignored,
meaning the packet is either broadcast or is making use of the Forwarding DB.
Alternatively all destination port bits could be set and AS_DPM set.

For RTL93xx it is not clear how this works as the AS_DPM bit is missing and
there is a different mechanism which involves stacked devices.

The destination port is read from the DSA tag at the beginning of the tx 
routine:

/* Check for DSA tagging at the end of the buffer */
if (netdev_uses_dsa(dev) && skb->data[len-4] == 0x80
&& skb->data[len-3] < priv->cpu_port && skb->data[len-2] == 0x10
&& skb->data[len-1] == 0x00) {
/* Reuse tag space for CRC if possible */
dest_port = skb->data[len-3];   <<<
skb->data[len-4] = skb->data[len-3] = skb->data[len-2] = 
skb->data[len-1] = 0x00;
len -= 4;
}

The tx routines can be called with a priority < 0 in which case the default 
priority for
the CPU-port and that type of packet would be used. All SoC generations accept
a bit (AS_PRIO for assert priority) that if not set means the priority is 
ignored
and the default is applied. The tx routine currently does not make use of this
feature, it always calls the header create routines with prio >= 0.

Cheers,
  Birger


On 13.06.22 17:08, Arinc UNAL (Xeront) wrote:
>>>   
>>>   static void rtl930x_create_tx_header(struct p_hdr *h, int dest_port, int
>>> prio)
>>> @@ -1135,6 +1131,9 @@ static int rtl838x_eth_tx(struct sk_buff *skb, struct
>>> net_device *dev)
>>>  int dest_port = -1;
>>>  int q = skb_get_queue_mapping(skb) % TXRINGS;
>>>   
>>> +   if (dest_port >= 0)
>>> +   priv->r->create_tx_header(h, dest_port, skb->priority >> 1);
>>> +
>>
>> dest_port was just initialised to -1 here, so this code will never run. Maybe
>> you actually wanted to get the TX port number from somewhere else?
> 
> Oops, thanks for pointing that out! I don't know this driver very well 
> (I'm relatively new at coding too). I made this off of Birger's 
> suggestion. I'm going to need a directive to fix the patch with all the 
> comments you've made.
> 
> Arınç

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: fix VLAN 0 tag at egress on port 0

[Birger Koblitz]

Hi Arinc,

yes, this would be what I suggest.

Cheers,
  Birger

On 13.06.22 13:32, Arinc UNAL (Xeront) wrote:
> Hey Birger,
> 
> On 09/06/2022 14:30, Birger Koblitz wrote:
>> Hi Arinc,
>>
>> very well spotted! If I could make a suggestion, the RTL93xx tag generation
>> functions have the opposite problem, i.e. rtl930x_decode_tag() and
>> rtl931x_decode_tag() do not do the check for the destination port being >= 0,
>> i.e. defined and the packet not being a broadcast packet.
>>
>> So I would suggest to remove the
>>  if (dest_port >= 0) {
>> in rtl838x_create_tx_header and rtl839x_create_tx_header() entirely
>> and do the check for all 4 SoC families directly in rtl838x_eth_tx():
>>
>>  if (dest_port >= 0)
>>  priv->r->create_tx_header(h, dest_port, skb->priority >> 1);
>>
>> this will fix all 4 cases.
> 
> Thanks for the suggestion. If I understand this correctly, it should be 
> something like this?
> 
> ---
> 
> diff --git 
> a/target/linux/realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c 
> b/target/linux/realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c
> index cf6aabc614..f3b7c994c3 100644
> --- a/target/linux/realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c
> +++ b/target/linux/realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c
> @@ -96,42 +96,38 @@ static void rtl838x_create_tx_header(struct p_hdr 
> *h, int dest_port, int prio)
>   {
>   prio &= 0x7;
> 
> - if (dest_port > 0) {
> - // cpu_tag[0] is reserved on the RTL83XX SoCs
> - h->cpu_tag[1] = 0x0401;  // BIT 10: RTL8380_CPU_TAG, BIT0: 
> L2LEARNING on
> - h->cpu_tag[2] = 0x0200;  // Set only AS_DPM, to enable DPM 
> settings below
> - h->cpu_tag[3] = 0x;
> - h->cpu_tag[4] = BIT(dest_port) >> 16;
> - h->cpu_tag[5] = BIT(dest_port) & 0x;
> - // Set internal priority and AS_PRIO
> - if (prio >= 0)
> - h->cpu_tag[2] |= (prio | 0x8) << 12;
> - }
> + // cpu_tag[0] is reserved on the RTL83XX SoCs
> + h->cpu_tag[1] = 0x0401;  // BIT 10: RTL8380_CPU_TAG, BIT0: L2LEARNING on
> + h->cpu_tag[2] = 0x0200;  // Set only AS_DPM, to enable DPM settings 
> below
> + h->cpu_tag[3] = 0x;
> + h->cpu_tag[4] = BIT(dest_port) >> 16;
> + h->cpu_tag[5] = BIT(dest_port) & 0x;
> + // Set internal priority and AS_PRIO
> + if (prio >= 0)
> + h->cpu_tag[2] |= (prio | 0x8) << 12;
>   }
> 
>   static void rtl839x_create_tx_header(struct p_hdr *h, int dest_port, 
> int prio)
>   {
>   prio &= 0x7;
> 
> - if (dest_port > 0) {
> - // cpu_tag[0] is reserved on the RTL83XX SoCs
> - h->cpu_tag[1] = 0x0100; // RTL8390_CPU_TAG marker
> - h->cpu_tag[2] = h->cpu_tag[3] = h->cpu_tag[4] = h->cpu_tag[5] = 
> 0;
> - // h->cpu_tag[1] |= BIT(1) | BIT(0); // Bypass filter 1/2
> - if (dest_port >= 32) {
> - dest_port -= 32;
> - h->cpu_tag[2] = BIT(dest_port) >> 16;
> - h->cpu_tag[3] = BIT(dest_port) & 0x;
> - } else {
> - h->cpu_tag[4] = BIT(dest_port) >> 16;
> - h->cpu_tag[5] = BIT(dest_port) & 0x;
> - }
> - h->cpu_tag[2] |= BIT(5); // Enable destination port mask use
> - h->cpu_tag[2] |= BIT(8); // Enable L2 Learning
> - // Set internal priority and AS_PRIO
> - if (prio >= 0)
> - h->cpu_tag[1] |= prio | BIT(3);
> + // cpu_tag[0] is reserved on the RTL83XX SoCs
> + h->cpu_tag[1] = 0x0100; // RTL8390_CPU_TAG marker
> + h->cpu_tag[2] = h->cpu_tag[3] = h->cpu_tag[4] = h->cpu_tag[5] = 0;
> + // h->cpu_tag[1] |= BIT(1) | BIT(0); // Bypass filter 1/2
> + if (dest_port >= 32) {
> + dest_port -= 32;
> + h->cpu_tag[2] = BIT(dest_port) >> 16;
> + h->cpu_tag[3] = BIT(dest_port) & 0x;
> + } else {
> + h->cpu_tag[4] = BIT(dest_port) >> 16;
> + h->cpu_tag[5] = BIT(dest_port) & 0x;
>   }
> + h->cpu_tag[2] |= BIT(5); // Enable destination port mask use
> + h->cpu_tag[2] |= BIT(8); // Enable L2 Learning
> + // Set internal priority and AS_PRIO
> + if (prio >= 0)
> + h->cpu_tag[1] |= prio | BIT(3);
>   }
> 
>  

Re: [PATCH] realtek: fix VLAN 0 tag at egress on port 0

[Birger Koblitz]

Hi Arinc,

very well spotted! If I could make a suggestion, the RTL93xx tag generation
functions have the opposite problem, i.e. rtl930x_decode_tag() and
rtl931x_decode_tag() do not do the check for the destination port being >= 0,
i.e. defined and the packet not being a broadcast packet.

So I would suggest to remove the
if (dest_port >= 0) {
in rtl838x_create_tx_header and rtl839x_create_tx_header() entirely
and do the check for all 4 SoC families directly in rtl838x_eth_tx():

if (dest_port >= 0)
priv->r->create_tx_header(h, dest_port, skb->priority >> 1);

this will fix all 4 cases.

Cheers,
  Birger

On 09.06.22 10:32, Arinc UNAL (Xeront) wrote:
> There is a bug on the ethernet driver where the checks for the DSA tag and
> creating the tx header don't include port 0. This causes any frame
> egressing from the first port of the switch to have a VLAN 0 tag.
> 
> Fix this by extending the checks to include port 0.
> 
> Signed-off-by: Arınç ÜNAL 
> ---
>  .../realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c   | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git 
> a/target/linux/realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c 
> b/target/linux/realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c
> index cf6aabc614..88a27e78ab 100644
> --- a/target/linux/realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c
> +++ b/target/linux/realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c
> @@ -96,7 +96,7 @@ static void rtl838x_create_tx_header(struct p_hdr *h, int 
> dest_port, int prio)
>  {
>   prio &= 0x7;
>  
> - if (dest_port > 0) {
> + if (dest_port >= 0) {
>   // cpu_tag[0] is reserved on the RTL83XX SoCs
>   h->cpu_tag[1] = 0x0401;  // BIT 10: RTL8380_CPU_TAG, BIT0: 
> L2LEARNING on
>   h->cpu_tag[2] = 0x0200;  // Set only AS_DPM, to enable DPM 
> settings below
> @@ -113,7 +113,7 @@ static void rtl839x_create_tx_header(struct p_hdr *h, int 
> dest_port, int prio)
>  {
>   prio &= 0x7;
>  
> - if (dest_port > 0) {
> + if (dest_port >= 0) {
>   // cpu_tag[0] is reserved on the RTL83XX SoCs
>   h->cpu_tag[1] = 0x0100; // RTL8390_CPU_TAG marker
>   h->cpu_tag[2] = h->cpu_tag[3] = h->cpu_tag[4] = h->cpu_tag[5] = 
> 0;
> @@ -1142,7 +1142,7 @@ static int rtl838x_eth_tx(struct sk_buff *skb, struct 
> net_device *dev)
>   len = skb->len;
>  
>   /* Check for DSA tagging at the end of the buffer */
> - if (netdev_uses_dsa(dev) && skb->data[len-4] == 0x80 && 
> skb->data[len-3] > 0
> + if (netdev_uses_dsa(dev) && skb->data[len-4] == 0x80 && 
> skb->data[len-3] >= 0
>   && skb->data[len-3] < priv->cpu_port &&  
> skb->data[len-2] == 0x10
>   &&  skb->data[len-1] == 0x00) {
>   /* Reuse tag space for CRC if possible */

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v1 5/5] realtek: remove hardcoded sys-led configurations

[Birger Koblitz]

Hi,

On 07.06.22 11:10, Sander Vanheule wrote:
> On Tue, 2022-06-07 at 10:24 +0200, Birger Koblitz wrote:
>> Hi,
>>
>> at least for the RTL931x, removing the rtl931x_setup() is not a good idea as 
>> the WDT reset does
>> not work for that architecture.
>> The only way to get a working reset is via registering a reset handler:
>>
>> static void __init rtl931x_setup(void)
>> {
>> pr_info("Registering _machine_restart\n");
>> _machine_restart = rtl931x_restart;
>> _machine_halt = rtl931x_halt;
> 
> We've gotten rid of _machine_restart and _machine_halt already, let's not 
> reintroduce them.
> 
> If you don't feel like writing a driver for the reset controller, perhaps 
> syscon-reboot [1] can be
> useful?
That sounds interesting, I'll try.

Cheers,
  Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v1 3/5] realtek: add sys-led disable pinctrl for rtl931x

[Birger Koblitz]

Hi,

On 07.06.22 11:04, Sander Vanheule wrote:
> On Tue, 2022-06-07 at 10:15 +0200, Birger Koblitz wrote:
>> Hi,
>>
>> has anyone tested that???
> 
> I don't have any 931x hardware, but it is based on what you put into setup.c.
What is in the setup.c makes the System LED solid on. It is the same for all
the architectures:
static void __init rtl838x_setup(void)
{
/* Setup System LED. Bit 15 then allows to toggle it */
sw_w32_mask(0, 3 << 16, RTL838X_LED_GLB_CTRL);
}

static void __init rtl839x_setup(void)
{
/* Setup System LED. Bit 14 of RTL839X_LED_GLB_CTRL then allows to 
toggle it */
sw_w32_mask(0, 3 << 15, RTL839X_LED_GLB_CTRL);
}
static void __init rtl931x_setup(void)
{
sw_w32_mask(0, 3 << 12, RTL931X_LED_GLB_CTRL);
}

You are not using that to disable the system led on the 838x/839x, so why would 
it do something
different on the RTL931x? Note that at that time it was not know how to toggle 
the LED, because
that is somewhere else.

> 
>> This does not make sense at all, there is no LED disable
>> in the LED_GLB_CTRL register. Instead one needs to use 
>> RTL9310_MAC_L2_GLOBAL_CTRL2
>>
>> The following works nicely on the XS1930 and Edgecore:
>>
>> pinmux: pinmux@1b001358 {
>> compatible = "pinctrl-single";
>> reg = <0x1b001358 0x4>;
>>
>> pinctrl-single,bit-per-mux;
>> pinctrl-single,register-width = <32>;
>> pinctrl-single,function-mask = <0x1>;
>> #pinctrl-cells = <2>;
>>
>> /* Enable GPIO6 and GPIO7, possibly unknown others */
>> pinmux_disable_jtag: disable_jtag {
>> pinctrl-single,bits = <0x0 0x0 0x8000>;
>> };
>>
>> pinmux_disable_sys_led: disable_sys_led {
>> pinctrl-single,bits = <0x0 0x0 0x100>;
>> };
> 
> Thanks, I wasn't aware of these fields. Will update in v2.
Good.

> 
>>>  
>>> +   pinmux_led: pinmux@1b000600 {
>>> +   compatible = "pinctrl-single";
>>> +   reg = <0x1b000600 0x4>;
>>> +
>>> +   pinctrl-single,bit-per-mux;
>>> +   pinctrl-single,register-width = <32>;
>>> +   pinctrl-single,function-mask = <0x1>;
>>> +   #pinctrl-cells = <2>;
>>> +
>>> +   /* enable GPIO 0 */
>>> +   pinmux_disable_sys_led: disable_sys_led {
>>> +   pinctrl-single,bits = <0x0 0x3000 0x3000>;
>>> +   };
> 
> This field, I assume, controls the toggling rate of the system led then. 
> Would explain why it has
> two bits and is called SYS_LED_MODE.
Yes, see above.

Cheers,
  Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v1 5/5] realtek: remove hardcoded sys-led configurations

[Birger Koblitz]

Hi,

at least for the RTL931x, removing the rtl931x_setup() is not a good idea as 
the WDT reset does not work for that architecture.
The only way to get a working reset is via registering a reset handler:

static void __init rtl931x_setup(void)
{
pr_info("Registering _machine_restart\n");
_machine_restart = rtl931x_restart;
_machine_halt = rtl931x_halt;

// Enable system LED, no flashing
sw_w32_mask(0, 3 << 12, RTL931X_LED_GLB_CTRL);
}

Cheers,
  Birger



On 07.06.22 09:50, Sander Vanheule wrote:
> Disabling the sys-led peripheral should be done via a pin controller,
> for which pinctrl-single nodes are present in the platform DTSI files.
> Drop the hardcoded per-platform sys-led configurations, and require
> things to be set up in the devicetree.
> 
> Co-developed-by: INAGAKI Hiroshi 
> Signed-off-by: INAGAKI Hiroshi 
> Signed-off-by: Sander Vanheule 
> Tested-by: Bjørn Mork 
> ---
>  .../files-5.10/arch/mips/rtl838x/setup.c  | 40 ---
>  1 file changed, 40 deletions(-)
> 
> diff --git a/target/linux/realtek/files-5.10/arch/mips/rtl838x/setup.c 
> b/target/linux/realtek/files-5.10/arch/mips/rtl838x/setup.c
> index 55419c7b0b7a..df29b76bbf0f 100644
> --- a/target/linux/realtek/files-5.10/arch/mips/rtl838x/setup.c
> +++ b/target/linux/realtek/files-5.10/arch/mips/rtl838x/setup.c
> @@ -28,31 +28,6 @@
>  
>  extern struct rtl83xx_soc_info soc_info;
>  
> -static void __init rtl838x_setup(void)
> -{
> - /* Setup System LED. Bit 15 then allows to toggle it */
> - sw_w32_mask(0, 3 << 16, RTL838X_LED_GLB_CTRL);
> -}
> -
> -static void __init rtl839x_setup(void)
> -{
> - /* Setup System LED. Bit 14 of RTL839X_LED_GLB_CTRL then allows to 
> toggle it */
> - sw_w32_mask(0, 3 << 15, RTL839X_LED_GLB_CTRL);
> -}
> -
> -static void __init rtl930x_setup(void)
> -{
> - if (soc_info.id == 0x9302)
> - sw_w32_mask(0, 3 << 13, RTL9302_LED_GLB_CTRL);
> - else
> - sw_w32_mask(0, 3 << 13, RTL930X_LED_GLB_CTRL);
> -}
> -
> -static void __init rtl931x_setup(void)
> -{
> - sw_w32_mask(0, 3 << 12, RTL931X_LED_GLB_CTRL);
> -}
> -
>  void __init plat_mem_setup(void)
>  {
>   void *dtb;
> @@ -71,21 +46,6 @@ void __init plat_mem_setup(void)
>* parsed resulting in our memory appearing
>*/
>   __dt_setup_arch(dtb);
> -
> - switch (soc_info.family) {
> - case RTL8380_FAMILY_ID:
> - rtl838x_setup();
> - break;
> - case RTL8390_FAMILY_ID:
> - rtl839x_setup();
> - break;
> - case RTL9300_FAMILY_ID:
> - rtl930x_setup();
> - break;
> - case RTL9310_FAMILY_ID:
> - rtl931x_setup();
> - break;
> - }
>  }
>  
>  void __init plat_time_init(void)

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v1 3/5] realtek: add sys-led disable pinctrl for rtl931x

[Birger Koblitz]

Hi,

has anyone tested that??? This does not make sense at all, there is no LED 
disable
in the LED_GLB_CTRL register. Instead one needs to use 
RTL9310_MAC_L2_GLOBAL_CTRL2

The following works nicely on the XS1930 and Edgecore:

pinmux: pinmux@1b001358 {
compatible = "pinctrl-single";
reg = <0x1b001358 0x4>;

pinctrl-single,bit-per-mux;
pinctrl-single,register-width = <32>;
pinctrl-single,function-mask = <0x1>;
#pinctrl-cells = <2>;

/* Enable GPIO6 and GPIO7, possibly unknown others */
pinmux_disable_jtag: disable_jtag {
pinctrl-single,bits = <0x0 0x0 0x8000>;
};

pinmux_disable_sys_led: disable_sys_led {
pinctrl-single,bits = <0x0 0x0 0x100>;
};
};

Cheers,
  Birger

On 07.06.22 09:50, Sander Vanheule wrote:
> Like for RTL838x devices, add a pinctrl-single node to manage the
> sys-led/gpio0 mux, and allow using the pin as GPIO.
> 
> Signed-off-by: Sander Vanheule 
> ---
>  target/linux/realtek/dts-5.10/rtl931x.dtsi | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/target/linux/realtek/dts-5.10/rtl931x.dtsi 
> b/target/linux/realtek/dts-5.10/rtl931x.dtsi
> index 29aee1f7b268..f4e2fd248f7e 100644
> --- a/target/linux/realtek/dts-5.10/rtl931x.dtsi
> +++ b/target/linux/realtek/dts-5.10/rtl931x.dtsi
> @@ -155,6 +155,20 @@
>   };
>   };
>  
> + pinmux_led: pinmux@1b000600 {
> + compatible = "pinctrl-single";
> + reg = <0x1b000600 0x4>;
> +
> + pinctrl-single,bit-per-mux;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0x1>;
> + #pinctrl-cells = <2>;
> +
> + /* enable GPIO 0 */
> + pinmux_disable_sys_led: disable_sys_led {
> + pinctrl-single,bits = <0x0 0x3000 0x3000>;
> + };
> + };
>  
>   ethernet0: ethernet@1b00a300 {
>   status = "okay";

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

TLS certificate on Forum expired

[Birger Koblitz]

Hi,

the TLS certificate expired on the forum
Valid: Not After Thu, 12 May 2022 04:05:04 GMT

Cheers,
  Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v2] realtek: do not reset SerDes on link change

[Birger Koblitz]

Thanks a lot Sander, helpful and efficient!

Cheers,
  Birger

On 11.05.22 22:26, Sander Vanheule wrote:
> Hi Birger,
> 
> On Sun, 2022-05-08 at 16:53 +0200, Birger Koblitz wrote:
>> Hi,
>>
>> On 08.05.22 13:11, Sander Vanheule wrote:
>>> Hi,
>>>
>>> Sorry I didn't get back to this any sooner.
>>>
>>> On Wed, 2022-04-27 at 20:16 +0200, Birger Koblitz wrote:
>>>> Hi,
>>> It's still not clear to me what issue or issues you are fixing exactly with 
>>> this patch,
>>> and in what way.
>> The patch fixes a bug that was introduced during the merging of the Zyxel 
>> XGS1250 code which
>> also is an issue for the XGS1210. The problem as stated with the submitted 
>> patch is that
>> a reset of the SerDes connecting to the 8 1GBit ports was done. This is a 
>> single XGMII link to
>> the RTL8218D, which provides 8 1GBit ports via this link.
>>
>> The handling of (US)XGMII links is entirely different from the handling of 
>> SGMII/HiSGMII, 1000BX
>> or 10GR with a completely different code-path on both the RTL9300 and the 
>> RTL9310. The difference
>> is that the internal SerDes is in fact turned "off" in the latter case, and 
>> in the former it
>> is put into a suitable XGMII mode. For (Hi)SGMII/1000BX/10GR the SerDes is 
>> then put (in its
>> outside "off" state") into what is on RTL931x a suitable "fibre" mode and on 
>> RTL9300 into a
>> "forced" mode. All these modes then need to be suitably RX calibrated and 
>> the pre- main and post-
>> amplifiers set up properly for TX.
>>
>> The bug was to do a complete SerDes reset on all SerDes links, although the 
>> code for setting
>> up the XGMII link was not there, thereby wiping the (RX/TX) setup done by 
>> u-boot and breaking the
>> 8 1GBit ports. The 10GBit SFP+ links are mostly understood (from the 
>> Ubiquiti USW switch),
>> so here we use the appropriate setup code, which e.g. is necessary when 
>> someone pulls a module
>> out and puts another in.
>>
>>>
>>> Is the suggested change in behaviour required for SFP+ modules to 
>>> completely fix bringing
>>> up new links? Or is this only part of the solution? Your reply makes me 
>>> think it's the
>> It is only part of the solution. It makes swapping out 10GBit (fiber!) 
>> modules possible.
>> It does not allow any 1GBit modules.
> 
> 
> Thanks, this is what I wanted to know! I've rewritten the commit message for 
> this patch to contain
> this info, and pushed it to master.
> 
> Best,
> Sander
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v2] realtek: do not reset SerDes on link change

[Birger Koblitz]

Hi,

On 08.05.22 13:11, Sander Vanheule wrote:
> Hi,
> 
> Sorry I didn't get back to this any sooner.
> 
> On Wed, 2022-04-27 at 20:16 +0200, Birger Koblitz wrote:
>> Hi,
> It's still not clear to me what issue or issues you are fixing exactly with 
> this patch,
> and in what way.
The patch fixes a bug that was introduced during the merging of the Zyxel 
XGS1250 code which
also is an issue for the XGS1210. The problem as stated with the submitted 
patch is that
a reset of the SerDes connecting to the 8 1GBit ports was done. This is a 
single XGMII link to
the RTL8218D, which provides 8 1GBit ports via this link.

The handling of (US)XGMII links is entirely different from the handling of 
SGMII/HiSGMII, 1000BX
or 10GR with a completely different code-path on both the RTL9300 and the 
RTL9310. The difference
is that the internal SerDes is in fact turned "off" in the latter case, and in 
the former it
is put into a suitable XGMII mode. For (Hi)SGMII/1000BX/10GR the SerDes is then 
put (in its
outside "off" state") into what is on RTL931x a suitable "fibre" mode and on 
RTL9300 into a
"forced" mode. All these modes then need to be suitably RX calibrated and the 
pre- main and post-
amplifiers set up properly for TX.

The bug was to do a complete SerDes reset on all SerDes links, although the 
code for setting
up the XGMII link was not there, thereby wiping the (RX/TX) setup done by 
u-boot and breaking the
8 1GBit ports. The 10GBit SFP+ links are mostly understood (from the Ubiquiti 
USW switch),
so here we use the appropriate setup code, which e.g. is necessary when someone 
pulls a module
out and puts another in.

> 
> Is the suggested change in behaviour required for SFP+ modules to completely 
> fix bringing
> up new links? Or is this only part of the solution? Your reply makes me think 
> it's the
It is only part of the solution. It makes swapping out 10GBit (fiber!) modules 
possible.
It does not allow any 1GBit modules.

> latter. If the changed behaviour for SFP+ modules here is fixing an issue, 
> please describe
> the issue as well as you can in this patch, and also describe any remaining 
> issues.
The patch only fixes what says it does. I don't see why I should list here all 
remaining issues,
especially since I am probably not aware of all of them. What works and does 
not work is
part of the description coming with the device commit. As the commit messages 
says it merely
fixes a bug introduced at that time.

> Otherwise, if this change by itself leaves SFP+ equally broken as before, 
> please just have
> this patch fix the GbE links, and keep other changes for a later patch.
No, it is necessary to keep the possibility to swap out 10G modules.

> 
> The network code on this platform is really not my area of expertise, so any 
> explanation
> on what is wrong, and why it needs to be fixed in this way, can help me 
> understand. It can
> also provide crucial information for others working on this code, since I 
> think we need to
> use every opportunity to (publicly) document the behaviour of this hardware.
I do not believe it is necessary for anyone to understand a patch to commit it. 
The question
here is about a sanity check. The code was tested as it says, and the commit 
message states
what it does. Documentation is better collected in the code so that it is 
always at hand and
in fact the explanation I give above can be found in the comments for the 
proposed patches
for support of all the serdes modes of the RTL9300 and the ongoing work with 
the RTL931x.
I would rather not waste time on this 2-line patch (!) which makes the XGS12x0 
users happy now
(they cannot use any of the 1GBit ports as it stands since several weeks now) 
and invest it
in solving things properly.

Cheers,
  Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v2] realtek: do not reset SerDes on link change

[Birger Koblitz]

Hi,

there are presently no working 1GBit SFP modules in master for RTL9300
(this patch only affects RTL93xx SoCs). On the Ubiquiti USW switch
only the 10GBit modules are set up by u-boot and they continue to work.
The setup really only does a setup of the link not the entire serdes. The 
initial reset
was done on initialization of the internal PHY associated with the SerDes
via rtl9300_configure_serdes() calling rtl9300_sds_rst() during the PHY
probe. So calling rtl9300_sds_rst() for every link change was anyway too much.

Complete control over SFP+ ports to allow 10G, 1G, Copper modules, and
DAC cables will only be available with the latest developments which were
posted in the forum recently and should lead to a PR soon. For this to work
the SerDes-MAC link needs to be switched and then this link re-calibrated
which I only figured out recently.

Cheers,
  Birger

On 27.04.22 18:06, Sander Vanheule wrote:
> Hi Birger,
> 
> On Sun, 2022-04-24 at 22:01 +0200, Birger Koblitz wrote:
>> Do not reset the RTL930x SerDes on link changes, instead set up
>> the SDS with internal PHYs for the SFP+ ports only.
>> This fixes the 8 1GBit ports on the Zyxel XGS1250 which
>> do not work without this patch.
>>
>> Tested-by: Stijn Segers 
>> Signed-off-by: Birger Koblitz 
>> ---
>> v2: A different patch was previously sent with this subject.
>>     This is the correct patch.
>>  target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c  | 3 ++-
>>  .../linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl83xx.h | 1 +
>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
>> b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
>> index 858b692640..5f19a1f590 100644
>> --- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
>> +++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
>> @@ -814,7 +814,8 @@ static void rtl93xx_phylink_mac_config(struct dsa_switch 
>> *ds, int
>> port,
>>    __func__, phy_modes(state->interface));
>> return;
>> }
>> -   rtl9300_sds_rst(sds_num, sds_mode);
>> +   if (state->interface == PHY_INTERFACE_MODE_10GBASER)
>> +   rtl9300_serdes_setup(sds_num, state->interface);
> 
> 
> Resetting the SerDes(-es?) makes it end up in a state where the 1Gb (copper) 
> ports don't
> work. So with fixed phy-s, I can see how skipping a reset could help.
> 
> Instead of a _reset_, you now only do a mode change on 10GBASER ports, using 
> a _setup_
> call. The reset and setup also are not entirely equivalent, so why change to
> rtl9300_serdes_setup()? Do 1G SFP modules still work if you only change modes 
> for
> 10GBASER?
> 
> Best,
> Sander
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] realtek: do not reset SerDes on link change

[Birger Koblitz]

Do not reset the RTL930x SerDes on link changes, instead set up
the SDS with internal PHYs for the SFP+ ports only.
This fixes the 8 1GBit ports on the Zyxel XGS1250 which
do not work without this patch.

Tested-by: Stijn Segers 
Signed-off-by: Birger Koblitz 
---
v2: A different patch was previously sent with this subject.
This is the correct patch.
 target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c  | 3 ++-
 .../linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl83xx.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c 
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
index 858b692640..5f19a1f590 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
@@ -814,7 +814,8 @@ static void rtl93xx_phylink_mac_config(struct dsa_switch 
*ds, int port,
   __func__, phy_modes(state->interface));
return;
}
-   rtl9300_sds_rst(sds_num, sds_mode);
+   if (state->interface == PHY_INTERFACE_MODE_10GBASER)
+   rtl9300_serdes_setup(sds_num, state->interface);
}

reg = sw_r32(priv->r->mac_force_mode_ctrl(port));
diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl83xx.h 
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl83xx.h
index 0bb11f9b8b..107016469c 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl83xx.h
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/rtl83xx.h
@@ -121,6 +121,7 @@ irqreturn_t rtl839x_switch_irq(int irq, void *dev_id);
 void rtl930x_vlan_profile_dump(int index);
 int rtl9300_sds_power(int mac, int val);
 void rtl9300_sds_rst(int sds_num, u32 mode);
+int rtl9300_serdes_setup(int sds_num, phy_interface_t phy_mode);
 void rtl930x_print_matrix(void);

 /* RTL931x-specific */
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] realtek: Trap all frames with switch as destination to CPU-port

[Birger Koblitz]

This fixes a bug where frames sent to the switch itself were
flooded to all ports unless the MAC address of the CPU-port
was learned otherwise.

Tested-by: Wenli Looi 
Tested-by: Bjørn Mork 
Signed-off-by: Birger Koblitz 
---
This was previously sent as a patch with a wrong subject
"[PATCH] realtek: do not reset SerDes on link change"

 .../linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c  | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c 
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
index 4780632983..858b692640 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
@@ -205,6 +205,12 @@ static int rtl83xx_setup(struct dsa_switch *ds)

priv->r->l2_learning_setup();

+   // Make sure all frames sent to the switch's MAC are trapped to the 
CPU-port
+   if (priv->family_id == RTL8380_FAMILY_ID)
+   sw_w32(0x2, RTL838X_SPCL_TRAP_SWITCH_MAC_CTRL);  // 0: FWD, 1: 
DROP, 2: TRAP2CPU
+   else
+   sw_w32(0x2, RTL839X_SPCL_TRAP_SWITCH_MAC_CTRL);
+
/* Enable MAC Polling PHY again */
rtl83xx_enable_phy_polling(priv);
pr_debug("Please wait until PHY is settled\n");
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: do not reset SerDes on link change

[Birger Koblitz]

Oops, I was trying to do too many things at the same time
Please forget that and I shall resend the email properly.

Birger

On 24.04.22 20:30, Bjørn Mork wrote:
> That subject doesn't look quite right?
> 
> 
> Bjørn
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] realtek: do not reset SerDes on link change

[Birger Koblitz]

This fixes a bug where frames sent to the switch itself were
flooded to all ports unless the MAC address of the CPU-port
was learned otherwise.

Tested-by: Wenli Looi 
Tested-by: Bjørn Mork 
Signed-off-by: Birger Koblitz 
---
 .../linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c  | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c 
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
index 4780632983..858b692640 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/dsa.c
@@ -205,6 +205,12 @@ static int rtl83xx_setup(struct dsa_switch *ds)

priv->r->l2_learning_setup();

+   // Make sure all frames sent to the switch's MAC are trapped to the 
CPU-port
+   if (priv->family_id == RTL8380_FAMILY_ID)
+   sw_w32(0x2, RTL838X_SPCL_TRAP_SWITCH_MAC_CTRL);  // 0: FWD, 1: 
DROP, 2: TRAP2CPU
+   else
+   sw_w32(0x2, RTL839X_SPCL_TRAP_SWITCH_MAC_CTRL);
+
/* Enable MAC Polling PHY again */
rtl83xx_enable_phy_polling(priv);
pr_debug("Please wait until PHY is settled\n");
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v2 0/3] realtek: Fix default package selection

[Birger Koblitz]

Hi,

sounds good to me!

Birger

On 25/03/2022 14:38, Hauke Mehrtens wrote:

Based on the discussion on the previews patch set I added a patch to
remove dnsmasq and odhcpd-ipv6only. I hope this is an adaptable middle
ground. I really would like to remove the old firewall3 here.

We should probably introduce a switch device type in OpenWrt soon.

I would like to backport these 3 patches also into openwrt 22.03.

I do not have a realtek board at hand, if you test this please add a
Tested-By please.

Hauke Mehrtens (3):
   realtek: Remove dnsmasq and odhcpd-ipv6only from default
   realtek: Use firewall4
   realtek: Fix tc default package

  target/linux/realtek/Makefile | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: realtek: remove firewall and other core components? [Was: Re: [PATCH 1/2] realtek: Use firewall4]

[Birger Koblitz]

Hi,

The layer 2 (MAC, VLAN, Ethernet frame contents) offloading in Linux is normally done over tc and not nftabels. With flower you can filter, redirect and modify packets based on VLAN IDs, VLAN PCP, MAC 
addresses, .. and so on. qdisc allows to configure traffic schedulers to do advance QoS based on Ethernet frames.

Ah, so they are complementary, thanks for that explanation.
The layer 2 stuff that is done with flower is all implemented as HW offloaded 
in the driver btw for all SoCs and cursory testing seems to show it works. The 
QoS is missing so far.



I think we backported all of the patches from flow offloading from kernel 5.15 
to our kernel 5.10.
The net/netfilter/nf_flow_table_core.c file in OpenWrt kernel 5.10 looks very 
similar to upstream 5.15.


Supporting tc flower and offloading it requires however about a dozen kernel 
modules and user
space tools, which is really tricky to get right. It would be great to have 
these packets
on board by default, to make this feature more usable, also for people to test 
it.


The tc command should be sufficient to configure the flower offloading, but we 
would need some more kernel modules, which are already packed, but not 
interluded by default in OpenWrt.

OpenWrt misses some central configuration service for tc flower and tc qdisc as 
far as I know. We could add this to netifd.

Indeed this would be great, because if routing is configured and offloaded this 
can circumvent firewall filtering.
If there is central configuration support, this is much easier to set up by 
users and sanity checks can be done, i.e.
that the filtering rules come first, before offloading the routes as both are 
handled by the Packet Inspection Engine
and this handles rules strictly in the sequence they are ordered in the content 
addressable memory. Currently this
only depends on the sequence routes and tc rules are being set up. The HW would 
however also support re-ordering
of rules even while switching packets.




I yesterday learned that someone was using an 838x device for OLSR with between 
200 and 300 offloaded
next-hop routes, so the hardware offload is something that interests people who 
would normally
find this only in proprietary vendor solutions.> 


Some of the switches which are used on normal consumer routers have some of these features as well. The Lantiq/Maxlinear switches support for example filtering based on VID, PCP and can also remove 
and add VLAN tags. They also support different traffic scheduling algorithms. Currently this is not implemented in the driver used in OpenWrt and I am not sure what is supported by the Lantiq switch 
support by Openwrt.


Hauke



Cheers,
  Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: realtek: remove firewall and other core components? [Was: Re: [PATCH 1/2] realtek: Use firewall4]

[Birger Koblitz]

Hi,

On 23/03/2022 21:09, Sander Vanheule wrote:

Hi everyone,



One extra argument in favour of keeping the firewall in the default config, is 
that the
devices with more advanced stock FW also provide an ACL feature to filter out 
traffic
based on MAC, IP, ethernet frame contents, etc. However, this is offloaded to a 
hardware
engine in the switch, but I'm not up to date on how well this offloading 
currently works
(with nftables). So, providing a firewall would put OpenWrt on the same feature 
level as
more advanced vendor offerings.

The features are quite powerful, even on RTL838x devices. The problem is that 
they are not
usable with nftables at least in kernel 5.10 because netfilter offload is so 
limited. The offloading
works via tc flower, which has extensive offloading support. I don't really 
understand how
this flow offloading can be used via nftables. There is a lot of development 
ongoing,
it seems kernel 5.13 was a big step forward.

Supporting tc flower and offloading it requires however about a dozen kernel 
modules and user
space tools, which is really tricky to get right. It would be great to have 
these packets
on board by default, to make this feature more usable, also for people to test 
it.

I yesterday learned that someone was using an 838x device for OLSR with between 
200 and 300 offloaded
next-hop routes, so the hardware offload is something that interests people who 
would normally
find this only in proprietary vendor solutions.






Obviously users may still install them if they really want their switch to
act as DHCP server and/or caching DNS resolver.


This topic is about firewall4, so are you suggesting to post-install firewall4
package as well?


Dropping dnsmasq and odhcpd-ipv6only makes more sense to me, since these are 
not features
that are normally provided on a managed switch AFAIK.

Agreed.

Cheers,
  Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: Fix kernel dependencies on CONFIG_MDIO_SMBUS

[Birger Koblitz]

Hi Bjørn,

On 15.03.22 15:10, Bjørn Mork wrote:
> Bjørn Mork  writes:
> 
>> Just drop the unnecssary I2C_SMBUS dependency.  AFAICS, you're only
>> using i2c_smbus_xfer() which is part of the i2c core.
The reason for the ifdefs were mdio_smbus_alloc().

> 
> Looking further at this, I believe there are good reasons to simply
> merge the mdio-smbus implementation into mdio-i2c: You seem to have lost
> some clause 45 specific stuff from commit 6912b712cd75 ("net: mdio-i2c:
> add support for Clause 45 accesses")
> 
> And the i2c_mii_valid_phy_id() tests to avoid eeprom access are also
> missing.  Maybe not important, but demonstrating the problems with
> copying code.  Even modules as small as these tend to grow apart over
> time.
> 
> I guess the clause 45 support could be important for multigig copper
> SFPs?
Absolutely. I just hope that we will soon have this support. The 10G SFPs
on the RTL93xx are a nightmare to understand.

I'll pick up your suggestion with merging into mdio-i2c and also ask the 
original
author of the patch why it was not upstreamed. Maybe we can learn what still
would have been necessary.

Cheers,
  Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: Fix kernel dependencies on CONFIG_MDIO_SMBUS

[Birger Koblitz]

Hi,

On 15.03.22 13:32, Bjørn Mork wrote:
> Birger Koblitz  writes:

> Yuck!
> 
> Why the heck can't this be made generic, auto-configured by DTS props
> and upstreamed?  There is a reason for this, you know:
> 
> bjorn@miraculix:/usr/local/src/git/linux$ git grep -E '^#ifdef' 
> drivers/net/phy/sfp.c|wc -c
> 0
> 
Well, we can of course always compile SMBus support in, i.e. make CONFIG_SFP 
depend on CONFIG_MDIO_SMBUS,
this is already done for the I2C equivalent and this is where we started:
config SFP
tristate "SFP cage support"
depends on I2C && PHYLINK
depends on HWMON || HWMON=n
select MDIO_I2C
+   select CONFIG_MDIO_SMBUS

But if we do not want to do that then #ifdefs are the only solution to prevent 
compiler errors
due to missing symbols. There is no need to do anything in a dts BTW. The code 
is already
auto-configuring, it first tries I2C which is more powerful and then
falls back to SMBus before it gives up.

Cheers,
  Birger


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: Fix kernel dependencies on CONFIG_MDIO_SMBUS

[Birger Koblitz]

Hi,

On 14.03.22 23:53, Hauke Mehrtens wrote:
> On 3/14/22 06:56, Birger Koblitz wrote:
>> Hi,
>>
>> CONFIG_SFP should only depend on CONFIG_MDIO_SMBUS on the RTL93xx platforms.
>> This is because only on those platforms there is hardware support for an 
>> SMBus
>> controller which is used for the MDIO of the SFP ports.
>> If we had known about the worning, then we would have tried to fix it by
>> making CONFIG_SFP only on the 93xx platforms dependent on CONFIG_MDIO_SMBUS.
>> How to do this is however not clear to me.
> 
> We should probably remove the dependency to CONFIG_MDIO_SMBUS from 
> CONFIG_SFP. This is added in 
> target/linux/realtek/patches-5.10/711-net-phy-add-an-MDIO-SMBus-library.patch
> 
> You could add the dependency to the CONFIG_I2C_RTL9300 in 
> target/linux/realtek/patches-5.10/310-add-i2c-rtl9300-support.patch
> 
> Hauke
> 

I would propose the following patch, which compiles on the 839x and 930x 
platforms:

>From 7fb7bb16fdd0a66fdd8dbd7cd071420d48df230a Mon Sep 17 00:00:00 2001
From: Birger Koblitz 
Date: Tue, 15 Mar 2022 10:53:21 +0100
Subject: [PATCH] realtek: fix CONFIG_MDIO_SMBUS dependency on RTL83xx

CONFIG_SFP depends on CONFIG_MDIO_SMBUS now and this depends on
CONFIG_I2C_SMBUS.
This created the following warnings on the RTL83xx platforms:
WARNING: unmet direct dependencies detected for MDIO_SMBUS
  Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y] && 
I2C_SMBUS [=n]
  Selected by [y]:
  - SFP [=y] && NETDEVICES [=y] && PHYLIB [=y] && I2C [=y] && PHYLINK [=y] && 
(HWMON [=y] || HWMON [=y]=n)

We remove the overall dependency to CONFIG_MDIO_SMBUS from CONFIG_SFP and 
instead add
it to CONFIG_I2C_RTL9300 since only the RTL93xx platforms make use of the SMBus 
capable
I2C controller.

Reported-by: Hauke Mehrtens 
Signed-off-by: Birger Koblitz 
---
 .../patches-5.10/310-add-i2c-rtl9300-support.patch |  3 ++-
 .../711-net-phy-add-an-MDIO-SMBus-library.patch| 10 --
 .../712-net-phy-sfp-add-support-for-SMBus.patch|  8 +++-
 3 files changed, 9 insertions(+), 12 deletions(-)

diff --git 
a/target/linux/realtek/patches-5.10/310-add-i2c-rtl9300-support.patch 
b/target/linux/realtek/patches-5.10/310-add-i2c-rtl9300-support.patch
index c4d23d90e1..96be87e08e 100644
--- a/target/linux/realtek/patches-5.10/310-add-i2c-rtl9300-support.patch
+++ b/target/linux/realtek/patches-5.10/310-add-i2c-rtl9300-support.patch
@@ -1,12 +1,13 @@
 --- a/drivers/i2c/busses/Kconfig
 +++ b/drivers/i2c/busses/Kconfig
-@@ -954,6 +954,16 @@ config I2C_RK3X
+@@ -954,6 +954,17 @@ config I2C_RK3X
  This driver can also be built as a module. If so, the module will
  be called i2c-rk3x.

 +config I2C_RTL9300
 +  tristate "Realtek RTL9300 I2C adapter"
 +  depends on OF
++  select MDIO_SMBUS
 +  help
 +Say Y here to include support for the I2C adapter in Realtek RTL9300
 +and RTL9310 SoCs.
diff --git 
a/target/linux/realtek/patches-5.10/711-net-phy-add-an-MDIO-SMBus-library.patch 
b/target/linux/realtek/patches-5.10/711-net-phy-add-an-MDIO-SMBus-library.patch
index 5e1053ca6c..aad70d8d6a 100644
--- 
a/target/linux/realtek/patches-5.10/711-net-phy-add-an-MDIO-SMBus-library.patch
+++ 
b/target/linux/realtek/patches-5.10/711-net-phy-add-an-MDIO-SMBus-library.patch
@@ -108,16 +108,6 @@ Signed-off-by: Antoine Tenart 
 +MODULE_AUTHOR("Antoine Tenart");
 +MODULE_DESCRIPTION("MDIO SMBus bridge library");
 +MODULE_LICENSE("GPL");
 a/drivers/net/phy/Kconfig
-+++ b/drivers/net/phy/Kconfig
-@@ -60,6 +60,7 @@ config SFP
-   depends on I2C && PHYLINK
-   depends on HWMON || HWMON=n
-   select MDIO_I2C
-+  select MDIO_SMBUS
-
- comment "Switch configuration API + drivers"
-
 --- a/include/linux/mdio/mdio-i2c.h
 +++ b/include/linux/mdio/mdio-i2c.h
 @@ -12,5 +12,21 @@ struct i2c_adapter;
diff --git 
a/target/linux/realtek/patches-5.10/712-net-phy-sfp-add-support-for-SMBus.patch 
b/target/linux/realtek/patches-5.10/712-net-phy-sfp-add-support-for-SMBus.patch
index 8eef1885ab..30085a8068 100644
--- 
a/target/linux/realtek/patches-5.10/712-net-phy-sfp-add-support-for-SMBus.patch
+++ 
b/target/linux/realtek/patches-5.10/712-net-phy-sfp-add-support-for-SMBus.patch
@@ -10,10 +10,11 @@ Signed-off-by: Antoine Tenart 

 --- a/drivers/net/phy/sfp.c
 +++ b/drivers/net/phy/sfp.c
-@@ -412,32 +412,72 @@ static int sfp_i2c_write(struct sfp *sfp
+@@ -412,32 +412,78 @@ static int sfp_i2c_write(struct sfp *sfp
return ret == ARRAY_SIZE(msgs) ? len : 0;
  }

++#ifdef CONFIG_MDIO_SMBUS
 +static int sfp_smbus_read(struct sfp *sfp, bool a2, u8 dev_addr, void *buf,
 +size_t len)
 +{
@@ -42,6 +43,7 @@ Signed-off-by: Antoine Tenart 
 +
 +  return sfp->i2c_mii->write(sfp->i2c_mii, bus_add

Re: [PATCH] realtek: Fix kernel dependencies on CONFIG_MDIO_SMBUS

[Birger Koblitz]

Hi,

CONFIG_SFP should only depend on CONFIG_MDIO_SMBUS on the RTL93xx platforms.
This is because only on those platforms there is hardware support for an SMBus
controller which is used for the MDIO of the SFP ports.
If we had known about the worning, then we would have tried to fix it by
making CONFIG_SFP only on the 93xx platforms dependent on CONFIG_MDIO_SMBUS.
How to do this is however not clear to me.

Cheers,
 Birger

On 13.03.22 20:47, Hauke Mehrtens wrote:
> CONFIG_SFP depends on CONFIG_MDIO_SMBUS now and this depends on
> CONFIG_I2C_SMBUS. Activate the missing kernel compile options.
> 
> This fixes the following warning:
> WARNING: unmet direct dependencies detected for MDIO_SMBUS
>   Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y] && 
> I2C_SMBUS [=n]
>   Selected by [y]:
>   - SFP [=y] && NETDEVICES [=y] && PHYLIB [=y] && I2C [=y] && PHYLINK [=y] && 
> (HWMON [=y] || HWMON [=y]=n)
> 
> Fixes: 45053b507c66 ("realtek: Add support for SFP EEPROM-access over SMBus")
> Signed-off-by: Hauke Mehrtens 
> ---
>  target/linux/realtek/rtl838x/config-5.10 | 2 ++
>  target/linux/realtek/rtl839x/config-5.10 | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/target/linux/realtek/rtl838x/config-5.10 
> b/target/linux/realtek/rtl838x/config-5.10
> index 8e27af95ba46..16964d94c967 100644
> --- a/target/linux/realtek/rtl838x/config-5.10
> +++ b/target/linux/realtek/rtl838x/config-5.10
> @@ -90,6 +90,7 @@ CONFIG_I2C_GPIO=y
>  CONFIG_I2C_MUX=y
>  # CONFIG_I2C_RTL9300 is not set
>  # CONFIG_I2C_MUX_RTL9300 is not set
> +CONFIG_I2C_SMBUS=y
>  CONFIG_INITRAMFS_SOURCE=""
>  CONFIG_IRQCHIP=y
>  CONFIG_IRQ_DOMAIN=y
> @@ -107,6 +108,7 @@ CONFIG_MDIO_BUS=y
>  CONFIG_MDIO_DEVICE=y
>  CONFIG_MDIO_DEVRES=y
>  CONFIG_MDIO_I2C=y
> +CONFIG_MDIO_SMBUS=y
>  CONFIG_MEMFD_CREATE=y
>  CONFIG_MFD_SYSCON=y
>  CONFIG_MIGRATION=y
> diff --git a/target/linux/realtek/rtl839x/config-5.10 
> b/target/linux/realtek/rtl839x/config-5.10
> index 5704b4265a3c..b3192d1866da 100644
> --- a/target/linux/realtek/rtl839x/config-5.10
> +++ b/target/linux/realtek/rtl839x/config-5.10
> @@ -86,6 +86,7 @@ CONFIG_I2C_BOARDINFO=y
>  CONFIG_I2C_GPIO=y
>  # CONFIG_I2C_RTL9300 is not set
>  # CONFIG_I2C_MUX_RTL9300 is not set
> +CONFIG_I2C_SMBUS=y
>  CONFIG_INITRAMFS_SOURCE=""
>  CONFIG_IRQCHIP=y
>  CONFIG_IRQ_DOMAIN=y
> @@ -104,6 +105,7 @@ CONFIG_MDIO_BUS=y
>  CONFIG_MDIO_DEVICE=y
>  CONFIG_MDIO_DEVRES=y
>  CONFIG_MDIO_I2C=y
> +CONFIG_MDIO_SMBUS=y
>  CONFIG_MEMFD_CREATE=y
>  CONFIG_MFD_SYSCON=y
>  CONFIG_MIGRATION=y

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] Add support for Renkforce WS-WN530HP3-A

[Birger Koblitz]

Hi Petr,

there is a v2 of this patch which I sent yesterday at 18:31 to the list.
I applied what I sent then as a patch and it works for me.
It fixes the subject by adding a ramips tag and adds a second LED, which
I did not notice initially.

Cheers,
  Birger

On 08.03.22 18:31, Petr Štetiar wrote:
> Hi,
> 
> it's somehow borken:
> 
>  $ curl 
> https://patchwork.ozlabs.org/project/openwrt/patch/d121def7-56f1-6bb4-4dfd-dcd848efd...@birger-koblitz.de/mbox/
>  | git am
>  ...
>  Applying: Add support for Renkforce WS-WN530HP3-A
>  error: corrupt patch at line 168
>  Patch failed at 0001 Add support for Renkforce WS-WN530HP3-A
> 
> -- ynezz
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] ramips: add support for Renkforce WS-WN530HP3-A

[Birger Koblitz]

This adds support for the Renkforce WS-WN530HP3-A ceiling-
mountable Wireless Access Point, which is powered over PoE.
Hardware:
- SoC: Mediatek MT7621DAT
- RAM: 128MiB on SoC
- Flash: 16MiB GigaDevice GD25Q128C
- 2.4Ghz Wifi: Mediatek MT603EN
- 5GHz Wifi: MT613BEN
- Ethernet:
  - 1x 1GBit WAN port, passive PoE capable
  - 2x 1GBit LAN ports
LEDs: 1x Bi-Color LED (red/blue)
Buttons: 1x Reset Button, 1x Power Button

Installation:
Power on the access point and immedately press the reset
button for 10 seconds. Connect web-browser to 192.168.10.1
and upload sysupgrade image. Flash uploaded image and wait
about 2 minutes for reboot.

Signed-off-by: Birger Koblitz 
---
Version v2: The LED visible through the casing window is in fact a bi-
color LED. Support it.

 .../dts/mt7621_renkforce_ws-wn530hp3-a.dts| 159 ++
 target/linux/ramips/image/mt7621.mk   |  11 ++
 .../mt7621/base-files/etc/board.d/02_network  |   1 +
 3 files changed, 171 insertions(+)
 create mode 100644 target/linux/ramips/dts/mt7621_renkforce_ws-wn530hp3-a.dts

diff --git a/target/linux/ramips/dts/mt7621_renkforce_ws-wn530hp3-a.dts 
b/target/linux/ramips/dts/mt7621_renkforce_ws-wn530hp3-a.dts
new file mode 100644
index 00..13e37d7124
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_renkforce_ws-wn530hp3-a.dts
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "renkforce,ws-wn530hp3-a", "mediatek,mt7621-soc";
+   model = "Renkforce WS-WN530HP3-A";
+
+   aliases {
+   label-mac-device = 
+   led-boot = _power;
+   led-failsafe = _power;
+   led-running = _power;
+   led-upgrade = _power;
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: led_1 {
+   label = "red:led1";
+   gpios = < 17 GPIO_ACTIVE_LOW>;
+   };
+
+   led_2 {
+   label = "blue:led2";
+   gpios = < 16 GPIO_ACTIVE_LOW>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <4000>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+   partition@5 {
+   compatible = "denx,uimage";
+   label = "firmware";
+   reg = <0x5 0xf3>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   wifi0: wifi@0,0 {
+   compatible = "mediatek,mt76";
+   reg = <0x 0 0 0 0>;
+   mediatek,mtd-eeprom = < 0x>;
+   ieee80211-freq-limit = <240 250>;
+   nvmem-cells = <_factory_4>;
+   nvmem-cell-names = "mac-address";
+   };
+};
+
+ {
+   wifi1: wifi@0,0 {
+   compatible = "mediatek,mt76";
+   reg = <0x 0 0 0 0>;
+   mediatek,mtd-eeprom = < 0x8000>;
+   ieee80211-freq-limit = <500 600>;
+   nvmem-cells = <_factory_4>;
+   nvmem-cell-names = "mac-address";
+   mac-address-increment = <1>;
+   };
+};
+
+ {
+   nvmem-cells = <_factory_4>;
+   nvmem-cell-names = "mac

[PATCH] Add support for Renkforce WS-WN530HP3-A

[Birger Koblitz]

This adds support for the Renkforce WS-WN530HP3-A ceiling-
mountable Wireless Access Point, which is powered over PoE.
Hardware:
- SoC: Mediatek MT7621DAT
- RAM: 128MiB on SoC
- Flash: 16MiB GigaDevice GD25Q128C
- 2.4Ghz Wifi: Mediatek MT603EN
- 5GHz Wifi: MT613BEN
- Ethernet:
  - 1x 1GBit WAN port, passive PoE capable
  - 2x 1GBit LAN ports
LEDs: 1x Power LED (red)
Buttons: 1x Reset Button, 1x Power Button

Installation:
Power on the access point and immediately press the reset
button for 10 seconds. Connect web-browser to 192.168.10.1
and upload sysupgrade image. Flash uploaded image and wait
about 2 minutes for reboot.

Signed-off-by: Birger Koblitz 
---
 .../dts/mt7621_renkforce_ws-wn530hp3-a.dts| 154 ++
 target/linux/ramips/image/mt7621.mk   |  11 ++
 .../mt7621/base-files/etc/board.d/02_network  |   1 +
 3 files changed, 167 insertions(+)
 create mode 100644 target/linux/ramips/dts/mt7621_renkforce_ws-wn530hp3-a.dts

diff --git a/target/linux/ramips/dts/mt7621_renkforce_ws-wn530hp3-a.dts 
b/target/linux/ramips/dts/mt7621_renkforce_ws-wn530hp3-a.dts
new file mode 100644
index 00..631cda6a2e
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_renkforce_ws-wn530hp3-a.dts
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "renkforce,ws-wn530hp3-a", "mediatek,mt7621-soc";
+   model = "Renkforce WS-WN530HP3-A";
+
+   aliases {
+   label-mac-device = 
+   led-boot = _power;
+   led-failsafe = _power;
+   led-running = _power;
+   led-upgrade = _power;
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: led_1 {
+   label = "red:led1";
+   gpios = < 17 GPIO_ACTIVE_LOW>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <4000>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+   partition@5 {
+   compatible = "denx,uimage";
+   label = "firmware";
+   reg = <0x5 0xf3>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   wifi0: wifi@0,0 {
+   compatible = "mediatek,mt76";
+   reg = <0x 0 0 0 0>;
+   mediatek,mtd-eeprom = < 0x>;
+   ieee80211-freq-limit = <240 250>;
+   nvmem-cells = <_factory_4>;
+   nvmem-cell-names = "mac-address";
+   };
+};
+
+ {
+   wifi1: wifi@0,0 {
+   compatible = "mediatek,mt76";
+   reg = <0x 0 0 0 0>;
+   mediatek,mtd-eeprom = < 0x8000>;
+   ieee80211-freq-limit = <500 600>;
+   nvmem-cells = <_factory_4>;
+   nvmem-cell-names = "mac-address";
+   mac-address-increment = <1>;
+   };
+};
+
+ {
+   nvmem-cells = <_factory_4>;
+   nvmem-cell-names = "mac-address";
+   mac-address-increment = <(-2)>;
+};
+
+ {
+   ports {
+   port@0 {
+   status = "okay";
+   label = "lan2";
+   };
+
+   port@1 {
+  

Re: [PATCH 1/2] realtek: Use firewall4

[Birger Koblitz]

Hi,

On 01/03/2022 22:11, Daniel Golle wrote:

We may need to add a 'switch' DEVICE_TYPE in include/target.mk
selecting packages relevant for this class of devices.
('bridge' or 'ip-full', 'ethtool', ...)Indeed, these devices are really not 
routers. Let's have the right

packages for them installed, and only those. I have a couple of
the realtek switches in use and none of them is routing anything or
would need a firewall. They are really what they are sold for: smart
switches, very good with VLANs and switching across many ports.




2. supporting more common use cases out of the box


It's just bloat.  The flash size is small on many of these devices.


It's rather the very limited performance of the CPU and Ethernet MAC
used for the CPU port which makes me disregard those (layer-2)
switches being used for anything else than that.

The RTL93xx based devices are probably a bit more powerful and have layer 3
offload support, but it will take some time until I would trust them at
the edge of a network. At that point probably other packages are needed than
software-based firewalling. So in my opinion, let's drop firewall and DHCP/DNS
server packages.

Cheers,
  Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: ZyXEL GS1900-48: drop gpio-restart

[Birger Koblitz]

Hi Sander,

I don't have the GS1900-48 at hand or even my records. I am on vacation and I 
will only
be back in 10 days, we actually got stuck here in quarantine...
You can also test the GPIO access in U-Boot using md.l and mw.l using the the 
indirect
access register. I tested this once for the indirect table access registers and 
that
worked.
But I looked up when the GS1900-48 was released and it was around since at 
least 2013.
I would be surprised if there are _not_ different versions around. We know that 
there
_are_ actually different version with regards to the SoC. They use at least 3 
different
processor generations including different work-arounds necessary. Have a look 
at the
forum on issues with reading non-existing PHYs and the port flooding table, 
which in SoC revisions
< D cannot be read and requires a shadow table (not implemented, since we 
always flood to
all ports, because port isolation overrides this anyway).
On the warning: At least the initial warning came from the lock debugging I 
compiled in,
which is based on Daniel's standard settings. IIRC, the lengthy warning was 
about
sleeping in the wrong context, maybe there was also something about an issue 
with lock
contention.

Cheers,
  Birger


On 24/02/2022 21:19, Sander Vanheule wrote:

On Tue, 2022-02-22 at 23:39 +0100, Birger Koblitz wrote:

Hi,

the information on the external GPIO resetting the board of
the Zyxel GS1900-48 comes from the hardware configuration
reported by the stock firmware. It says:
GS1900# show board
[...]
== Reset =
Type: GPIO
GPIO: EXT_5
[...]
Using the rtk gpio commands in u-boot this can be confirmed.


Can you list the commands that you used to test this? My bootloader only supports 
"rtk
network ..." and "cst pinSet ...".



On 22/02/2022 23:00, Sander Vanheule wrote:

On Mon, 2022-02-21 at 21:23 +0100, Birger Koblitz wrote:

Hi,


I just checked with my multimeter, and while the GPIO5 on the RTL8231 does go
high/low
when I set the output high/low from Linux, my device certainly doesn't reset. 
The
other
GPIO lines on the chip do work, since SFP modules are correctly detected.

Birger, just to be sure, can you confirm that your device does reset with GPIO5 
on
the
RTL8231?


Yes, it does.There is a warning, but then it reliably resets. That was why I 
left it
in as is.


I had another hard look at my board, to check if something may be wrong 
physically,
but I
cannot find anything. My device's board looks identical to the pictures on the 
switch
wiki
[1], which I think you uploaded earlier.

There is some reset logic on the board [2], but I cannot figure out how GPIO5 
would be
connected to it electrically. Unless I missed a via connecting to that pin on 
the
RTL8231,
GPIO5 only appears to lead to TP2. GPIO5/TP2 does not appear to be connected
electrically
to any part of the circuit next to SW1. I could add a bodge wire to connect TP2 
to pad
U25:3, but gpio-restart should really work on unmodified hardware.

[1] https://svanheule.net/switches/gs1900-48#board_details
[2] https://svanheule.net/switches/gs1900-48#hard_reset_circuit



Having another look at the source code of gpio-restart, the WARNING-s I 
reported in the
patch's commit message occur at the following points of the GPIO output 
waveform:

  |< 100ms >|< 100 ms >|<   3000 ms   >|< Restart failed
_|_|  |___|__ [ active ]
_X \__/   [inactive]
   ||  |   |
   ||  |   ^ WARN @ 
drivers/power/reset/gpio-restart.c:46
   ||  |
   ||  ^ WARN @ drivers/gpio/gpiolib.c:3098
   |^ WARN @ drivers/gpio/gpiolib.c:3098
   |
   ^ Restart should already occur here


If everything is set up correctly, the system should restart before execution 
reaches the
point where a warning can be emitted. If you say that you see a warning (any at 
all),
AFAICT that means gpio-restart is not working.

As they say, the proof of the pudding is in the eating, so I soldered a jumper 
wire
between the RTL8231's GPIO5 pin (U38:25) and the line driven by the hard reset 
button
(U25:3) [https://svanheule.net/switches/gs1900-48#hard_reset_circuit].
As expected from the analysis above, this results in a system rebooting without 
_any_
warning (using an initramfs from yesterday's snapshot builds):

root@OpenWrt:/# reboot
root@OpenWrt:/# [  185.092891] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 
not supported
[  185.101879] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 not supported
[  185.111835] rtl83xx_fib_event: FIB_RULE ADD/DELL for IPv6 not supported
[  185.120484] rtl83xx_fib4_del: found a route with id 1, nh-id 0
[  185.127681] rtl83xx-switch switch@1b00: unknown nexthop, id 0
[  185.149505] rtl83xx-switch switch@1b00: unknown nexthop, id 0
[  185.157262] rtl83xx_fib4_del: found a route with id 2, 

Re: [PATCH] realtek: ZyXEL GS1900-48: drop gpio-restart

[Birger Koblitz]

Hi,

the information on the external GPIO resetting the board of
the Zyxel GS1900-48 comes from the hardware configuration
reported by the stock firmware. It says:
GS1900# show board
[...]
== Reset =
Type: GPIO
GPIO: EXT_5
[...]
Using the rtk gpio commands in u-boot this can be confirmed.


Similarly the information on the XGS1250 comes from the output
of the "show tech-support" command which shows:

 ZYXEL XGS1250-12


 Board GPIO

Device  Pin  Direction  Default  Current  Purpose
---  --   
INT 0OUT00
INT 1IN 11FAN_CONTROL
INT 6IN 10HW_VER_BIT1
INT 7IN 11HW_VER_BIT0
INT 11   OUT00FAN_EN
INT 15   OUT00TX_DIS_P11
INT 16   IN 00SFP_Present_P11
INT 17   IN 01SFP_LOS_P11
INT 20   IN 00TX_FAULT_P11
INT 21   OUT11RESET_PHY
INT 22   IN 11RST_BTN_OUT
I also tested this in u-boot and toggling that output 21 definitely
only resets the PHYs (port leds turn off), not the entire board.

Cheers,
  Birger

On 22/02/2022 23:00, Sander Vanheule wrote:

On Mon, 2022-02-21 at 21:23 +0100, Birger Koblitz wrote:

Hi,


I just checked with my multimeter, and while the GPIO5 on the RTL8231 does go 
high/low
when I set the output high/low from Linux, my device certainly doesn't reset. 
The
other
GPIO lines on the chip do work, since SFP modules are correctly detected.

Birger, just to be sure, can you confirm that your device does reset with GPIO5 
on the
RTL8231?


Yes, it does.There is a warning, but then it reliably resets. That was why I 
left it
in as is.


I had another hard look at my board, to check if something may be wrong 
physically, but I
cannot find anything. My device's board looks identical to the pictures on the 
switch wiki
[1], which I think you uploaded earlier.

There is some reset logic on the board [2], but I cannot figure out how GPIO5 
would be
connected to it electrically. Unless I missed a via connecting to that pin on 
the RTL8231,
GPIO5 only appears to lead to TP2. GPIO5/TP2 does not appear to be connected 
electrically
to any part of the circuit next to SW1. I could add a bodge wire to connect TP2 
to pad
U25:3, but gpio-restart should really work on unmodified hardware.

Does my description of the hard reset circuit on the wiki match your board?

FWIW, the GPIO description reported by the stock firmware on the XGS1250-12 
claims that
internal GPIO21 can be used to reset the board, but you noted in the DTS it 
actually only
resets the phy-s. So it wouldn't be the first time the reported board config is 
partially
incorrect.


Best,
Sander

[1] https://svanheule.net/switches/gs1900-48#board_details
[2] https://svanheule.net/switches/gs1900-48#hard_reset_circuit



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: ZyXEL GS1900-48: drop gpio-restart

[Birger Koblitz]

Hi,


I just checked with my multimeter, and while the GPIO5 on the RTL8231 does go 
high/low
when I set the output high/low from Linux, my device certainly doesn't reset. 
The other
GPIO lines on the chip do work, since SFP modules are correctly detected.

Birger, just to be sure, can you confirm that your device does reset with GPIO5 
on the
RTL8231?


Yes, it does.There is a warning, but then it reliably resets. That was why I 
left it
in as is.

Cheers,
  Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: ZyXEL GS1900-48: drop gpio-restart

[Birger Koblitz]

Hi,

On 21/02/2022 10:04, Sander Vanheule wrote:

anymore. Even if it would work with the current driver, once the RTL8231 is
controlled through an MDIO bus (from a kernel perspective), things might change.

For me that would be a reason not to do it that way, because we will not be able
to support some devices (all that use an RTL8231 GPIO for the hardware reset).
At least we would not be able to reliably reset them
and they would either not reboot (because of the 3/4 byte issue) or a messed up
network configuration.

Cheers,
  birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: ZyXEL GS1900-48: drop gpio-restart

[Birger Koblitz]

Hi Daniel,

I understand that. My preferred solution would be to leave this in
but comment the node out so that we can use it in the future once
we either have made the 8231 gpio driver do busy waiting and avoid
anything that sleeps, or fix libgpiod.
The intention is to have every switch use a gpio for reset.
Some switches currently don't work at all because of functionality no longer
in the upstreamed spi-nor driver and no reset gpio being known:
https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/784

On others users have to do a manual switch on/off
 because the network is not properly reset by a software reset:
https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/948
https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/782

The 838x platform was definitely built for an external reset to be used, and
I have good reason to believe the 839x platform does not entirely fix this.
So the watchdog should be avoided if there is another way to reset the device.

Cheers,
  Birger


On 20/02/2022 21:25, Daniel Golle wrote:

On Sun, Feb 20, 2022 at 09:13:24PM +0100, Birger Koblitz wrote:

Hi,

during development I came across situations where the RTL839x
SoC's own reset did not always completely reset its state.
U-Boot was no longer able to boot via tftp afterwards.
This is the same situation we see on the RTL838x.
While users will hopefully never mess up the SoC as during
development, I would prefer a solution that reliably
resets the device over a solution that avoids a warning.
At least we should have a comment in, that states that
once this is fixed in libgpiod this should be the way
to reset the device. And we should look into fixing libgpiod.


In the case shown by Sander, gpio-restart isn't used and/or
doesn't have the desired effect of restarting the device anyway,
resulting in the next lower priority restart handler (in this case
the watchdog) to carry out the restart.
Ie. what is there right now is a no-op, at least on the device which
Sander has used to capture the log shown below.



On 20/02/2022 19:50, Sander Vanheule wrote:

GPIO 5 on the RTL8231 can be used to reset the system, but gpio-restart
uses gpiod_set_value. This triggers a kernel warning and backtrace for
GPIO pins that can sleep, such as the RTL8231's. Two warnings are
emitted by libgpiod, and a third warning by gpio-restart itself after it
fails to restart the system:

[  106.654008] [ cut here ]
[  106.659240] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098 
gpiod_set_value+0x7c/0x108
 [ Stack dump and call trace ]
[  106.826218] ---[ end trace d1de50b401f5a153 ]---
[  106.962992] [ cut here ]
[  106.968208] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098 
gpiod_set_value+0x7c/0x108
 [ Stack dump and call trace ]
[  107.136718] ---[ end trace d1de50b401f5a154 ]---
[  111.087092] [ cut here ]
[  111.092271] WARNING: CPU: 0 PID: 4279 at 
drivers/power/reset/gpio-restart.c:46 gpio_restart_notify+0xc0/0xdc
 [ Stack dump and call trace ]
[  111.256629] ---[ end trace d1de50b401f5a155 ]---

By removing gpio-restart from this device, we skip the restart-by-GPIO
attempt and rely only on the watchdog for restarts, which is already the
de facto behaviour.

Signed-off-by: Sander Vanheule 
---
   target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts | 5 -
   1 file changed, 5 deletions(-)

diff --git a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts 
b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
index dd392c5a9beb..e0e79068d2bc 100644
--- a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
+++ b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
@@ -39,11 +39,6 @@
gpio-controller;
};
-   gpio-restart {
-   compatible = "gpio-restart";
-   gpios = < 5 GPIO_ACTIVE_LOW>;
-   };
-
keys {
compatible = "gpio-keys-polled";
poll-interval = <20>;


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: ZyXEL GS1900-48: drop gpio-restart

[Birger Koblitz]

Hi,

during development I came across situations where the RTL839x
SoC's own reset did not always completely reset its state.
U-Boot was no longer able to boot via tftp afterwards.
This is the same situation we see on the RTL838x.
While users will hopefully never mess up the SoC as during
development, I would prefer a solution that reliably
resets the device over a solution that avoids a warning.
At least we should have a comment in, that states that
once this is fixed in libgpiod this should be the way
to reset the device. And we should look into fixing libgpiod.

Cheers,
  Birger


On 20/02/2022 19:50, Sander Vanheule wrote:

GPIO 5 on the RTL8231 can be used to reset the system, but gpio-restart
uses gpiod_set_value. This triggers a kernel warning and backtrace for
GPIO pins that can sleep, such as the RTL8231's. Two warnings are
emitted by libgpiod, and a third warning by gpio-restart itself after it
fails to restart the system:

[  106.654008] [ cut here ]
[  106.659240] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098 
gpiod_set_value+0x7c/0x108
[ Stack dump and call trace ]
[  106.826218] ---[ end trace d1de50b401f5a153 ]---
[  106.962992] [ cut here ]
[  106.968208] WARNING: CPU: 0 PID: 4279 at drivers/gpio/gpiolib.c:3098 
gpiod_set_value+0x7c/0x108
[ Stack dump and call trace ]
[  107.136718] ---[ end trace d1de50b401f5a154 ]---
[  111.087092] [ cut here ]
[  111.092271] WARNING: CPU: 0 PID: 4279 at 
drivers/power/reset/gpio-restart.c:46 gpio_restart_notify+0xc0/0xdc
[ Stack dump and call trace ]
[  111.256629] ---[ end trace d1de50b401f5a155 ]---

By removing gpio-restart from this device, we skip the restart-by-GPIO
attempt and rely only on the watchdog for restarts, which is already the
de facto behaviour.

Signed-off-by: Sander Vanheule 
---
  target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts | 5 -
  1 file changed, 5 deletions(-)

diff --git a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts 
b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
index dd392c5a9beb..e0e79068d2bc 100644
--- a/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
+++ b/target/linux/realtek/dts-5.10/rtl8393_zyxel_gs1900-48.dts
@@ -39,11 +39,6 @@
gpio-controller;
};
  
-	gpio-restart {

-   compatible = "gpio-restart";
-   gpios = < 5 GPIO_ACTIVE_LOW>;
-   };
-
keys {
compatible = "gpio-keys-polled";
poll-interval = <20>;


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] realtek: fix locking bug in rtl838x_hw_receive()

[Birger Koblitz]

A Locking bug in the packet receive path was introduced with PR
#4973. The following patch prevents the driver from locking
after a few minutes with an endless flow of

[ 1434.185085] rtl838x-eth 1b00a300.ethernet eth0: Ring contention: r: 0, last 
a28000f4, cur a28000f8
[ 1434.208971] rtl838x-eth 1b00a300.ethernet eth0: Ring contention: r: 0, last 
a28000f4, cur a28000fc
[ 1434.794800] rtl838x-eth 1b00a300.ethernet eth0: Ring contention: r: 0, last 
a28000f4, cur a28000fc
[ 1435.049187] rtl838x-eth 1b00a300.ethernet eth0: Ring contention: r: 0, last 
a28000f4, cur a28000fc

Signed-off-by: Bjørn Mork 
Signed-off-by: Birger Koblitz 
---
 .../realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c  | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/target/linux/realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c 
b/target/linux/realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c
index ab4a03550bd8..cf6aabc6142f 100644
--- a/target/linux/realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c
+++ b/target/linux/realtek/files-5.10/drivers/net/ethernet/rtl838x_eth.c
@@ -1254,8 +1254,9 @@ static int rtl838x_hw_receive(struct net_device *dev, int 
r, int budget)
bool dsa = netdev_uses_dsa(dev);
struct dsa_tag tag;

-   last = (u32 *)KSEG1ADDR(sw_r32(priv->r->dma_if_rx_cur + r * 4));
pr_debug("-- RX 
- %d\n", r);
+   spin_lock_irqsave(>lock, flags);
+   last = (u32 *)KSEG1ADDR(sw_r32(priv->r->dma_if_rx_cur + r * 4));

do {
if ((ring->rx_r[r][ring->c_rx[r]] & 0x1)) {
@@ -1329,7 +1330,6 @@ static int rtl838x_hw_receive(struct net_device *dev, int 
r, int budget)
}

/* Reset header structure */
-   spin_lock_irqsave(>lock, flags);
memset(h, 0, sizeof(struct p_hdr));
h->buf = data;
h->size = RING_BUFFER;
@@ -1338,12 +1338,13 @@ static int rtl838x_hw_receive(struct net_device *dev, 
int r, int budget)
| (ring->c_rx[r] == (priv->rxringlen - 1) ? WRAP : 0x1);
ring->c_rx[r] = (ring->c_rx[r] + 1) % priv->rxringlen;
last = (u32 *)KSEG1ADDR(sw_r32(priv->r->dma_if_rx_cur + r * 4));
-   spin_unlock_irqrestore(>lock, flags);
} while (>rx_r[r][ring->c_rx[r]] != last && work_done < budget);

// Update counters
priv->r->update_cntr(r, 0);

+   spin_unlock_irqrestore(>lock, flags);
+
return work_done;
 }

-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 00/13] Switch realtek target to upstream platform

[Birger Koblitz]

Hi,

On 12.12.21 20:51, Sander Vanheule wrote:
> Hi Sebastian,
> 
> On Sun, 2021-12-12 at 12:38 +0100, Sebastian Gottschall wrote:
>>
>>> I have not experienced a single lock-up when booting with this patch, but I 
>>> also
>>> didn't
>>> stress-test the machine or even used the switch part. Do you guys have more 
>>> details on
>>> why
>>> it locks up, or how exactly these lock-ups can be resolved?
>> so far we found out it was related to the ethernet driver. but this is 
>> all part of the work we spended into it
>> the last months and recently again since i'm back on this projects
> 
> If it's most likely caused by the ethernet driver, then I don't think 
> complaining about
> vsmp_smp_ops not being sufficient is appropriate here. We didn't touch the 
> ethernet driver
> with this patch series, so any of your changes there should still apply.
It has been mentioned that it is also other parts of the interplay between SMP 
code, clocksource and
IRQ driver, especially for the RTL93xx. What you are proposing will likely make 
it much harder
to tackle this, it might even mean that we have to revert everything back out.

> 
 if you do performance tests
 in addition the mainline still uses 4kc as cpu architecture, which is
 simply wrong for anything else but 838x
>>> Wrong or suboptimal? I don't currently experience any obvious issues, using 
>>> the same
>>> toolchain for 8380, 8390 and 9300.
>> below suboptimal. i mean it decreases performance in a significant 
>> amount and fixing this issue is more than just easy
> 
> If you know since a while that this will be necessary and is an easy win, 
> then please
> submit a patch upstream to break up the target into the SoC-families. I'd 
> actually love to
> see things like this being submitted by you or Birger!
There is a fundamental lack of understanding here. The break-up of the families 
is for
OpenWRT and the way things are being built, including different configurations 
and code
paths for targets. So this is nothing to upstream apart from maybe some 
additional driver
code going there. We are trying to make OWRT do the right thing, talking about 
upstream
is not getting us anywhere.

>From my point of view it looks like you are trying to pull the realtek 
>architecture
in OWRT into a direction that is based on our understanding more than 1 year 
ago when
stuff started to go upstream. Our understanding has fundamentally shifted with 
SMP and
the 93xx architectures.

> 
> Generally speaking, I don't see a reason to wait with submitting patches 
> until other parts
> have stopped breaking. At least then we can all work from a common code base. 
> I obviously
> prefer submitting upstream where possible, but the networking part will be 
> mostly (or
> only) OpenWrt for a while still. People could then enjoy a continous stream of
> improvements in the snapshot builds, and might be encouraged to try writing 
> some code
> themselves.
Indeed. A common code base. And that is moving into a completely different 
direction than
what you propose, based on current knowledge about the targets. If we don't 
have any
possibility to have different code paths plus go for GENERIC_MIPS which is 
likely the
wrong choice, then we essentially cut development off, because that is 
currently focussing
on diversifying the different architectures.

The network code is a long way away from going upstream. There is still a lot 
that is not
understood. From fundamentals like SMI to the right architecture of the 
Ethernet driver
in the face of SMP to how the SoC architectures can be put into one overall 
code-framework.
My point of view is that we should not be upstreaming half-baked stuff. But 
what is even
worse in my eyes is when we then take that half-baked stuff a year later and 
say: oh,
but this is the way it needs to be done now even if this no longer has anything 
to
do with our current understanding.

My proposal to go forward: please provide a patch to split architectures and 
show that
we can optimize compiler and code paths in the face of MIPS Generic for the 4 
SoC
families.

Cheers,
  Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 00/13] Switch realtek target to upstream platform

[Birger Koblitz]

Hi,

On 09.12.21 22:26, Sander Vanheule wrote:
> This patch series is intended to reduce the maintenance burden, without 
> introducing
> breaking changes to devices already in OpenWrt. No promises are made for 
> out-of-tree code.
This patch will unfortunately considerably increase the maintenance burden, 
because it
pushes the code into a direction which does not reflect what these devices are. 
They
use SMT, SMP and they have different cpu-architectures. This should be reflected
by any new choice for the core architecture of the realtek code in OpenWRT.

With regard to out-of tree code: This is where the features come from. They 
come from
that development and it's the features users care for, the reason they are 
willing
to test new stuff and the reason some users provide access to development 
devices. Also,
the RTL9300 and RTL9310 code is in-tree. This is how we make sure that new 
developments
are consistent across all architectures.

> Of course we need to discuss how we should move forward to implement working 
> SMT support
> etc., but I feel that this patch series should not depend on that discussion. 
> There is
> upstream code that runs on RTL8380 and RTL8390, and OpenWrt code provides the 
> same
> features in a different way. If we want to support SMT upstream, we may have 
> to submit
> code there anyway, so why do things twice?
It is much too early to submit this upstream. We have already provided code 
upstream
before we had sufficient understanding of how things work several times. 
Example:
the interrupt controller code was pushed to mainline before we understood that 
this actually is
at the core of how to make VSMP work on the RTL9300. We did not even understand 
why
there was a double set of registers already on the RTL8390, because of course 
there
this is not necessary. But now you just told me that the patches for this IRQ 
controller
do not apply to the patches that provide that controller from mainline? Patches 
on top of patches
are not a maintenance burden? When in addition the controller needs a complete 
re-write
because we had no clue what it really was supposed to do?
And another example: the GPIO driver went to mainline before we understood how 
it works
on the RTL9300. Again, in order to use it on these devices we have patches on 
top of
patches and this is not a figure of speech, this is reality. And it still does 
not work
on the RTL9300, at least not for me. But I need this to work reliably to be 
able to
provide support. And don't let me get started how it works on the RTL931x.
I am really happy I resisted the push to have the RTL9300 timer code 
upstreamed, because
again, it is doing something completely different from what we thought at that 
time:
the timer is not about being able to do precision cable diagnostics, it is 
about making
VSMP work on the RTL9300. And for that it needs to work quite differently 
including
a big re-write.

> 
> If you would like code to be supported, please submit patches we can review. 
> Frequent
> small, incremental changes would be fine for me; maybe even preferable. IMHO 
> you're not
> doing yourself a favour by keeping months worth of changes out-of-tree.
I have been providing code bit by bit in the past, such as the RTL9300 support 
and there
are even bits of the RTL931x architecture which allow booting of such devices. 
But
now this is not being recognised, since there are no devices in tree to use 
that code.
Well, I tried to add those, I tried with the GS1900-48 using the RTL8390 and I 
tried
with the XGS1210 using the RTL9300. But guess what? I was told to come back in 
a couple
of months because the support was not complete and SFP/SFP+ and the like worked.

I really would like to provide more often code, but something as simple as 
adding Routing
Offload needed 3k lines of code and that needs time to develop. Providing half 
of it is not
going to fly: which user wants half of their traffic end in nirvana, or all of 
their
traffic being uncontrollable by any firewall? Add on top of that that routing 
offload works
quite differently on the different platforms and the fact that you need to make 
a reasonable
choice how to support them under one hat, and unfortunately this means months 
of work.
I would love to provide 10GBit SFP+ support on the RTL9300 quickly at this 
point,
but then I am having real trouble with the GPIO driver on that platform which I 
need for
the SFP cages but is patches on top of mainline patches.
> Does enabling those different options on one build have that big an impact on 
> SoCs that
> don't support all selected features? (I really don't know, don't normally do 
> any
> performance testing.)
The differences to be expected are about 50-120% more speed for optimized 
architectures plus (V)SMP support.
50% for VSMP, 100% for SMP, plus maybe 20% for optimized compiler settings. I 
did some promising
tests with dropbearkey.

> 
> I would be happy to continue discussing the interrupt controller, 

Re: [PATCH 00/13] Switch realtek target to upstream platform

[Birger Koblitz]

Hi,

thanks for the quick reply.

On 09.12.21 10:38, Sander Vanheule wrote:
> Hi Birger,
> 
>>
>> I would suggest to use sub-targets for these platforms with optimized
>> compiler settings and SMP/single processor selected correctly for each,
>> see https://github.com/BrainSlayer/pie/commits/pie-5.10-rtl9313
>>
>> You already set up SMP build support in the config, but don't activate it.
> 
> Currently there are no supported devices in OpenWrt that have one of the SMP-
> capable SoCs, which is the main reason it is not yet included here. I've had 
> a 
> very quick look on enabling SMP for RTL839x with a mainline build, but haven't
> gotten it to work yet.
I don't think you can pull the argument about that there are currently no 
supported
devices in master as this concerns an architectural decision for all SoC 
generations.
Also people are already using these devices, plus there are several developers 
trying
to get support for the 839x up to the 931x into master bit-by-bit so it can see 
at
least a bit of peer-review. We need to find a long-term solution, here and this
change is very disruptive for development. As you can imagine, a lot of
the code I use is never in a git, but instrumentation of core mips code to
be able to debug deadlocks and RCU stalls.

> Hiroshi and I are still learning as we go along here. I don't know if we can
> reasonably expect to have one kernel that supports all SoCs, or if there are
> really conflicting build requirements.
> 
> 
>> However with 2 small patches to the IRQ controller
>> https://github.com/BrainSlayer/pie/commit/61860e04b89fa4c76a0e41af3e5d3480dabdf63c#diff-8b9c10bdba2282c6926cb9f7207ac869b011e248a6171f8132e79e1807c9f12a
>>
> 
> The patch you link here doesn't seem to apply to the current IRQ controller, 
> but
> to an already modified version of it. It also appears to implement interrupt
> balancing, but is that a hard requirement for SMP on RTL839x?
The IRQ controller needs a lot of update and the patch is not on the backported
patch for the controller but the actual file with the controller code.
I really don't like to debug or do development on top of patches, it is much
harder. I would suggest to just copy the new version into the tree, there was
nothing there before.

The IRQ balancing is not necessary strictly speaking for 8390, but if you want
to use it with the RTL9300 timer, which needs to send IRQs to both CPUs, it is
needed. So you would need it for your proposal below to test this on the 8390 
with the timer.

> 
>> and the Ethernet driver
>> https://github.com/BrainSlayer/pie/commit/cdbc6598a1e69f74aa5fbaac9c896595a06d21f4#diff-2adae55db41693c452fcc10fb3925ff8c5a38760243f0b77bbd54acc75170d0a
>> SMP can be enabled on the RTL8390 and the 9310 platform.
>>
>> I am a bit worried of using the generic MIPS platform for the RTL9300.
>> The SoC has a broken R4K Clock Event Interrupt and requires the RTL9300
>> timer to work plus SMP support for the IRQ controller. There are only
>> 2 examples in Linux which have such a combination of dedicated Timer
>> for SMP support and IRQ controller, the Sibyte SB1250 and the BCM1480
>> platforms.
> 
> A cursory search (and limited understanding of clocksources etc.) also turned 
> up
> the Ingenic SoCs for me. These appear to have custom timers too, but are still
> based on MIPS_GENERIC.
I had not noticed that one, it looks promising. There is now also a stand-alone
CEVT-reimplementation of the RTL9300 timer here:
https://github.com/BrainSlayer/pie/blob/pie-5.10-rtl9313/target/linux/realtek/files-5.10/arch/mips/kernel/cevt-rtl9300.c

> 
> Since this Realtek timer is also available on RTL838x/RTL839x, we could use
> these platforms for testing as well. The kernel also supports the clocksource=
> parameter, which appears to allow for alternative clock selection. So if a
> (generic) kernel with R4K-CEVT support is running on RTL930x, shouldn't we be
> able to convince it to really use the Realtek timer?
This should work. The RTL9300 event source actually pretends to be more 
accurate than
the R4K-CEVT (it isn't but has more features such as one-shot), so that it is
being picked up instead.

> If Realtek did really funny stuff that makes MIPS_GENERIC incompatible with 
> some
> of these SoCs, I still feel we should try going through upstream. But at least
> then we would be quite sure new code is the only way to support these chips.
Good idea. Could you try using the RTL9300-CEVT timer and the new IRQ controller
with MIPS_GENERIC and SMP? Maybe it works. Sebastian and I are quite sure the
timer does what it is supposed to do and the IRQ controller works like a charm
on the 8390 under SMP, so either MIPS_GENERIC works, or there are more issues
with the SoC, including ones that make it so broken that it does not actually 
work
with SMP. Realtek does not provide any support for SMP to device makers, so
maybe the silicon is kaputt.

In any case, could you look into the suggestion with the sub-targets? The 
different
compile 

Re: [PATCH 00/13] Switch realtek target to upstream platform

[Birger Koblitz]

Hi Sander and Hiroshi,

great work! A very big step to clean up this platform. Because this changes
the fundamentals of the target I have some suggestions and questions.

There are actually 4 RTL platforms which we now know how to support and you
are taking care of the first 3 in your patch to make use of the generic MIPS
platform:
 - RTL8380: 4Kec, single core
 - RTL8390: 34Kc, VSMP, MIPS timer works
 - RTL9300: 34Kc, VSMP, MIPS timer broken, but RTL9300 timer with SMP support
 - RTL9310: InterAptiv, SMP, GIC timer

I would suggest to use sub-targets for these platforms with optimized
compiler settings and SMP/single processor selected correctly for each,
see https://github.com/BrainSlayer/pie/commits/pie-5.10-rtl9313

You already set up SMP build support in the config, but don't activate it.
However with 2 small patches to the IRQ controller
https://github.com/BrainSlayer/pie/commit/61860e04b89fa4c76a0e41af3e5d3480dabdf63c#diff-8b9c10bdba2282c6926cb9f7207ac869b011e248a6171f8132e79e1807c9f12a
and the Ethernet driver
https://github.com/BrainSlayer/pie/commit/cdbc6598a1e69f74aa5fbaac9c896595a06d21f4#diff-2adae55db41693c452fcc10fb3925ff8c5a38760243f0b77bbd54acc75170d0a
SMP can be enabled on the RTL8390 and the 9310 platform.

I am a bit worried of using the generic MIPS platform for the RTL9300.
The SoC has a broken R4K Clock Event Interrupt and requires the RTL9300
timer to work plus SMP support for the IRQ controller. There are only
2 examples in Linux which have such a combination of dedicated Timer
for SMP support and IRQ controller, the Sibyte SB1250 and the BCM1480 platforms.
Both do not use the generic MIPS platform since they require lots of
specific SMP code. I would like to understand how this would be supported
with the generic MIPS platform, because I don't want to go there and
then back again.

Cheers,
  Birger


On 08.12.21 22:42, Sander Vanheule wrote:
> To reduce the maintenance burden of the realtek target in OpenWrt, Hiroshi and
> I have worked on these patches to switch to the upstream platform. Some
> downstream code is maintained, primarily for compatibility with the current
> downstream-only networking drivers. There should be no functional changes for
> users, although there will be some bootlog differences.
> 
> We hope these patches will make it easier for developers to write upstream-
> compatible code on OpenWrt. Vice versa, it should also be easier with these
> changes to backport drivers and patches that were upstreamed.
> 
> Sander Vanheule (13):
>   realtek: add missing gpio0 pinctrl properties
>   realtek: add sys-led disable pinctrl for rtl930x
>   realtek: remove hardcoded sys-led configurations
>   realtek: use fixed-clock as CPU clock
>   realtek: include io.h in mach-rtl83xx.h
>   realtek: update mach-rtl83xx.h includes
>   realtek: backport upstream platform
>   realtek: add board file for MACH_REALTEK_RTL
>   realtek: update driver platform dependencies
>   realtek: switch target to upstream platform
>   realtek: drop downstream platform
>   realtek: modernise devicetree console setup
>   realtek: use correct compatible for rtl930x SoCs
> 
>  target/linux/realtek/config-5.10  |  36 +++-
>  .../dts-5.10/rtl8380_netgear_gigabit.dtsi |   3 +
>  .../dts-5.10/rtl8382_d-link_dgs-1210.dtsi |   3 +
>  .../dts-5.10/rtl8382_inaba_aml2-17gp.dts  |   3 +
>  target/linux/realtek/dts-5.10/rtl838x.dtsi|  16 +-
>  target/linux/realtek/dts-5.10/rtl930x.dtsi|  26 ++-
>  .../arch/mips/generic/board-realtek.c | 145 ++
>  .../mips/include/asm/mach-rtl838x/ioremap.h   |  29 ---
>  .../include/asm/mach-rtl838x/mach-rtl83xx.h   |   1 +
>  .../files-5.10/arch/mips/rtl838x/Makefile |   5 -
>  .../files-5.10/arch/mips/rtl838x/Platform |   5 -
>  .../files-5.10/arch/mips/rtl838x/prom.c   | 183 --
>  .../files-5.10/arch/mips/rtl838x/setup.c  | 116 ---
>  .../drivers/clocksource/timer-rtl9300.c   |   2 +-
>  .../drivers/net/dsa/rtl83xx/Kconfig   |   2 +-
>  target/linux/realtek/image/Makefile   |   4 +-
>  ...-add-realtek-rtl838x-rtl839x-support.patch |  45 +
>  .../300-mips-add-rtl838x-platform.patch   |  39 
>  .../301-gpio-add-rtl8231-driver.patch |   2 +-
>  ...e-dependencies-for-gpio-realtek-otto.patch |  13 --
>  ...pdate-dependency-for-spi-realtek-rtl.patch |  11 --
>  ...pdate-dependency-for-irq-realtek-rtl.patch |   8 -
>  .../306-gpio-add-legacy-rtl838x-driver.patch  |   2 +-
>  ...date-dependency-for-realtek-otto-wdt.patch |  15 --
>  ...-in-board-realtek-for-generic-kernel.patch |   9 +
>  ...net-add-support-for-rtl838x-ethernet.patch |   2 +-
>  .../patches-5.10/705-add-rtl-phy.patch|   2 +-
>  27 files changed, 285 insertions(+), 442 deletions(-)
>  create mode 100644 
> target/linux/realtek/files-5.10/arch/mips/generic/board-realtek.c
>  delete mode 100644 
> target/linux/realtek/files-5.10/arch/mips/include/asm/mach-rtl838x/ioremap.h
>  delete 

Re: [PATCH v3 0/5] realtek: Use WDT for system restart

[Birger Koblitz]

Hi Sander,

On 06/11/2021 20:47, Sander Vanheule wrote:

With some extra testing, I have found that the network port that was active 
before a
watchdog reset, doesn't do much anymore after restarting. Replugging the cable 
into a port
that was not used before the reset works, but that's not really useful if the 
system isn't
readily accessible or has no unused ports. I don't think the current network 
code resets
more than just the CPU NIC, so maybe the networking code could be ammended to 
also reset
the switch control tables, etc. Any thoughts on this?

Resetting different SoC parts in the RTL chips is very badly documented in the 
GPLed SDK code
available, in fact the SDK only ever resets the NIC itself. Combine that with 
the fact that
the global SoC reset at least on the RTL8380 SoCs does not put the chip into 
the same state
as a power off, we are left with experimenting. My impression is that the 838x 
based
routers are not supposed to be software reset. Instead once the SoC is 
configured for switching
by a user through a web interface they will run forever doing everything in 
silicon even
if the CPU hangs completely.

In OWRT resets happen in rtl838x_hw_reset(), this is the latest version with 
RTL93xx support:
/* Reset NIC  */
if (priv->family_id == RTL9300_FAMILY_ID || priv->family_id == 
RTL9310_FAMILY_ID)
sw_w32(0x86, priv->r->rst_glb_ctrl);
else
sw_w32(0x8, priv->r->rst_glb_ctrl);

do { /* Wait for reset of NIC and Queues done */
udelay(20);
} while (sw_r32(priv->r->rst_glb_ctrl) & 0xff);
You can try to reset more parts of the switch by adding more bits to what is 
written
into the RST_GLB_CTRL register. Obvious candidates in addition to bit 3 (NIC 
reset) are:
BIT 0: SW_RST (switch reset?)
BIT 1: SW_CFG_RST (switch configuration reset?)
BIT 2: SW_Q_RST (switch Queues reset, this is done on the 93xx platforms in the 
SDK)
BIT 3: SW_NIC_RST
BIT 4: SW_SERDES_RST (reset the built-in SerDes?)
BIT 5: SW_PHY_RST (reset the built in PHY of the RTL838x? That is what I would 
try first.)
I would avoid the CPU_MEM_RST reset which sounds like a reset of the DRAM 
interface.
The TBL_*_RST bits seem to allow resetting the various L2 configuration tables 
but unless you see
a strange configuration after a WD trigger, I would not touch those.

Of course the issue you describe could also be due to an issue with the PHY-MAC 
communication
and you need to reset the external PHY (you don't mention the specific device).

Cheers,
  Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v3 0/5] realtek: Use WDT for system restart

[Birger Koblitz]

Nice work!
ACK

Birger

On 06/11/2021 15:52, Sander Vanheule wrote:

Backport and enable the Realtek Otto watchdog driver for enhanced system
reliability. The watchdog driver can also be used to restart the system,
but that requires the _machine_restart to be removed.

Removing _machine_restart has the added benefit of enabling the use of other
restart handlers in addition to the watchdog restart, such as gpio-restart,
which may be more reliable than the SoCs internal reset circuitry. Removing the
override also brings the current target closer to upstream, which will become
relevant when switching to the next LTS kernel.

This series contains the watchdog driver as currently submitted upstream,
without the devicetree bindings. If the driver gets accepted before this series
is merged, I can already update it with the final version. Otherwise, a
follow-up will be sent to replace the patch.

The WDT driver was previously tested on my Netgear GS110TPPv1, Zyxel GS1900-8,
and Zyxel XGS1250-12. Testers with other devices should ensure that their
system can still restart after applying the complete series.

Sander Vanheule (5):
   realtek: Consolidate bootargs
   realtek: Add Lexra bus clock
   realtek: Backport Realtek Otto WDT driver
   realtek: Add and enable watchdog node
   realtek: Remove _machine_restart and _machine_halt

  target/linux/realtek/config-5.10  |   2 +
  .../dts-5.10/rtl8380_netgear_gigabit.dtsi |   4 -
  .../dts-5.10/rtl8380_zyxel_gs1900.dtsi|   4 -
  .../dts-5.10/rtl8382_allnet_all-sg8208m.dts   |   4 -
  .../dts-5.10/rtl8382_d-link_dgs-1210-10p.dts  |   4 -
  .../dts-5.10/rtl8382_d-link_dgs-1210.dtsi |   4 -
  .../dts-5.10/rtl8382_inaba_aml2-17gp.dts  |   4 -
  target/linux/realtek/dts-5.10/rtl838x.dtsi|  27 +-
  target/linux/realtek/dts-5.10/rtl930x.dtsi|  32 +-
  .../files-5.10/arch/mips/rtl838x/setup.c  |  85 
  ...hdog-add-realtek-otto-watchdog-timer.patch | 456 ++
  ...date-dependency-for-realtek-otto-wdt.patch |  17 +
  ...308-otto-wdt-fix-missing-math-header.patch |  13 +
  13 files changed, 536 insertions(+), 120 deletions(-)
  create mode 100644 
target/linux/realtek/patches-5.10/100-watchdog-add-realtek-otto-watchdog-timer.patch
  create mode 100644 
target/linux/realtek/patches-5.10/307-wdt-update-dependency-for-realtek-otto-wdt.patch
  create mode 100644 
target/linux/realtek/patches-5.10/308-otto-wdt-fix-missing-math-header.patch



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: do not hardcode restart handler and enable gpio-restart

[Birger Koblitz]

Hi,

On 05/10/2021 22:59, Sander Vanheule wrote:

One alternative could be to create some extra driver(s) in OpenWrt already, to 
get rid of
setup.c (and prom.c at some later point) and work towards the upstream base for
RTL838x/RTL839x. Anyone else with an opinion on this?

That's a good idea. But I think that one should also already take the work by 
brainslayer into
account which adds a lot to the initial SoC configuration:
https://github.com/BrainSlayer/pie/tree/pie-5.10-rtl9313/target/linux/realtek/files-5.10/arch/mips/rtl838x
What we put in now should already anticipate the use of SMP (from 839x 
onwards), and for the 931x the GIC as the new
Interrupt controller, large memory support and the GIC timer.



I also see that you're removing the _machine_halt function, while this isn't 
mentioned in
the commit message. I had already removed _machine_halt in f4b687d1f053 
("realtek: use
kernel defined halt"), but apparently it quietly got reintroduced in 
8faffa00cb6b
("realtek: add support for the RTL9300 timer")Sh**, my bad.


Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ramips: add support for Wavlink WL-WN576A2

[Birger Koblitz]

Hi Thomas,

you are right, in the meantime I noticed that the reset button does not work.
I had overlooked the difference in the 5/6 of the name, but still, your image
made the device work nicely as an AP just like that. I'll look at the LEDs, too 
and
maybe submit a separate patch. Sorry for the confusion!

Cheers,
  Birger

On 16/07/2021 19:37, Thomas Aldrian wrote:

The WN575A2 shares many of the same internals with the WN576A2 (same
SoC and same wifi chip). However, I do not think it would be
appropriate to add it as an alternative vendor as the default
configuration would be suboptimal.

The WN576A2 has only one ethernet port, while I believe your device has
two. Also, I cannot imagine the GPIOs to be correct. The WN576A2 has
more LEDs, and probably uses them for different purposes. Ofc this does
not necessarily make an image incompatible, it just may lead to
slightly unexpected behaviour. Maybe the WN578A2 profile would be
better suited?

At least that's my oppinion. If anyone else wants to advise, go ahead.

Regards,
Thomas

On Thu, 2021-07-15 at 10:32 +0200, Birger Koblitz wrote:

Hi,

I tested this on a Renkforce WS-WN575A2 and it works nicely.
What I looked at was partitioning, GPIOs, WiFi and Switch setup.
Would it be possible to add an ALT1_VENDOR for this Renkforce device?
You may add a "Tested-by".

Cheers,
    Birger

On 05/07/2021 18:12, dev.aldr...@gmail.com wrote:

From: Thomas Aldrian 

This commit adds support for the Wavlink WL-WN576A2 wall-plug
wireles
repeater / router. It is also sold under the name SilverCrest SWV
733 B1.

Device specs:

- CPU: MediaTek MT7628AN
- Flash: 8MB
- RAM: 64MB
- Bootloader: U-Boot
- Ethernet: 1x 10/100 Mbps
- 2.4 GHz: b/g/n SoC
- 5 GHz: a/n/ac MT7610EN
- Buttons: WPS, reset, sliding switch (ap/repeater)
- LEDs: 5x wifi status, 1x LAN/WAN, 1x WPS

Flashing:

U-Boot launches a TFTP client if WPS button is held during boot.

- Server IP: 192.168.10.100
- Firmware file name: firmware.bin

Device will reboot automatically. First boot takes about 90s.

Coelner is the original author, but I have made some fixes. He does
not
wish to sign off using his real name.

Signed-off-by: Thomas Aldrian 
Co-authored-by: coelner 
---
   .../dts/mt7628an_wavlink_wl-wn576a2.dts   | 171
++
   target/linux/ramips/image/mt76x8.mk   |  10 +
   .../mt76x8/base-files/etc/board.d/01_leds |   3 +
   .../mt76x8/base-files/etc/board.d/02_network  |   2 +
   4 files changed, 186 insertions(+)
   create mode 100644 target/linux/ramips/dts/mt7628an_wavlink_wl-
wn576a2.dts

diff --git a/target/linux/ramips/dts/mt7628an_wavlink_wl-
wn576a2.dts b/target/linux/ramips/dts/mt7628an_wavlink_wl-
wn576a2.dts
new file mode 100644
index 00..333a7dc950
--- /dev/null
+++ b/target/linux/ramips/dts/mt7628an_wavlink_wl-wn576a2.dts
@@ -0,0 +1,171 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7628an.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "wavlink,wl-wn576a2", "mediatek,mt7628an-soc";
+   model = "Wavlink WL-WN576A2";
+
+   aliases {
+   led-boot = _wps;
+   led-failsafe = _wps;
+   led-running = _wps;
+   led-upgrade = _wps;
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   gpios = < 43 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   wps {
+   label = "wps";
+   gpios = < 38 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   ap {
+   label = "ap";
+   gpios = < 41 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   linux,input-type = ;
+   };
+
+   repeater {
+   label = "repeater";
+   gpios = < 42 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   linux,input-type = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   wifi-high {
+   label = "blue:wifi-high";
+   gpios = < 37 GPIO_ACTIVE_LOW>;
+   };
+
+   wifi-mediumhigh {
+   label = "blue:wifi-mediumhigh";
+   gpios = < 11 GPIO_ACTIVE_LOW>;
+   };
+
+   wifi-medium {
+   label = "blue:wifi-medium";
+   gpios = < 44 GPIO_ACTIVE_LOW>;
+   };
+
+   wifi-mediumlow {
+   label = "blue:wifi-mediumlow";
+   gpios = < 39 GPIO_ACTIVE_LOW

Re: [PATCH] ramips: add support for Wavlink WL-WN576A2

[Birger Koblitz]

Hi,

I tested this on a Renkforce WS-WN575A2 and it works nicely.
What I looked at was partitioning, GPIOs, WiFi and Switch setup.
Would it be possible to add an ALT1_VENDOR for this Renkforce device?
You may add a "Tested-by".

Cheers,
  Birger

On 05/07/2021 18:12, dev.aldr...@gmail.com wrote:

From: Thomas Aldrian 

This commit adds support for the Wavlink WL-WN576A2 wall-plug wireles
repeater / router. It is also sold under the name SilverCrest SWV 733 B1.

Device specs:

- CPU: MediaTek MT7628AN
- Flash: 8MB
- RAM: 64MB
- Bootloader: U-Boot
- Ethernet: 1x 10/100 Mbps
- 2.4 GHz: b/g/n SoC
- 5 GHz: a/n/ac MT7610EN
- Buttons: WPS, reset, sliding switch (ap/repeater)
- LEDs: 5x wifi status, 1x LAN/WAN, 1x WPS

Flashing:

U-Boot launches a TFTP client if WPS button is held during boot.

- Server IP: 192.168.10.100
- Firmware file name: firmware.bin

Device will reboot automatically. First boot takes about 90s.

Coelner is the original author, but I have made some fixes. He does not
wish to sign off using his real name.

Signed-off-by: Thomas Aldrian 
Co-authored-by: coelner 
---
  .../dts/mt7628an_wavlink_wl-wn576a2.dts   | 171 ++
  target/linux/ramips/image/mt76x8.mk   |  10 +
  .../mt76x8/base-files/etc/board.d/01_leds |   3 +
  .../mt76x8/base-files/etc/board.d/02_network  |   2 +
  4 files changed, 186 insertions(+)
  create mode 100644 target/linux/ramips/dts/mt7628an_wavlink_wl-wn576a2.dts

diff --git a/target/linux/ramips/dts/mt7628an_wavlink_wl-wn576a2.dts 
b/target/linux/ramips/dts/mt7628an_wavlink_wl-wn576a2.dts
new file mode 100644
index 00..333a7dc950
--- /dev/null
+++ b/target/linux/ramips/dts/mt7628an_wavlink_wl-wn576a2.dts
@@ -0,0 +1,171 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7628an.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "wavlink,wl-wn576a2", "mediatek,mt7628an-soc";
+   model = "Wavlink WL-WN576A2";
+
+   aliases {
+   led-boot = _wps;
+   led-failsafe = _wps;
+   led-running = _wps;
+   led-upgrade = _wps;
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   gpios = < 43 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   wps {
+   label = "wps";
+   gpios = < 38 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   ap {
+   label = "ap";
+   gpios = < 41 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   linux,input-type = ;
+   };
+
+   repeater {
+   label = "repeater";
+   gpios = < 42 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   linux,input-type = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   wifi-high {
+   label = "blue:wifi-high";
+   gpios = < 37 GPIO_ACTIVE_LOW>;
+   };
+
+   wifi-mediumhigh {
+   label = "blue:wifi-mediumhigh";
+   gpios = < 11 GPIO_ACTIVE_LOW>;
+   };
+
+   wifi-medium {
+   label = "blue:wifi-medium";
+   gpios = < 44 GPIO_ACTIVE_LOW>;
+   };
+
+   wifi-mediumlow {
+   label = "blue:wifi-mediumlow";
+   gpios = < 39 GPIO_ACTIVE_LOW>;
+   };
+
+   wifi-low {
+   label = "blue:wifi-low";
+   gpios = < 40 GPIO_ACTIVE_LOW>;
+   };
+
+   lan {
+   label = "blue:lan";
+   gpios = < 2 GPIO_ACTIVE_LOW>;
+   };
+
+   led_wps: wps {
+   label = "blue:wps";
+   gpios = < 4 GPIO_ACTIVE_LOW>;
+   };
+   };
+};
+
+_default {
+   gpio {
+   groups = "i2c", "i2s", "wdt", "wled_an", "p0led_an", "p1led_an",
+   "p2led_an", "p3led_an", "p4led_an", "refclk", "gpio";
+   function = "gpio";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   wifi@0,0 {
+   reg = <0x 0 0 0 0>;
+   mediatek,mtd-eeprom = < 0x8000>;
+   ieee80211-freq-limit = <500 600>;
+   };
+};
+
+ {
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <4000>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 

Re: [PATCH v2 4/5] realtek: Fix failsafe mode

[Birger Koblitz]

Hi Hauke,

it looks as if there could be a more elegant solution to this, tomn just posted
this on the forum:
https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875
I did not have time to test it so far, though.

Birger

On 22/06/2021 00:45, Hauke Mehrtens wrote:

The RTL8380-RTL9300 switches only forward packets when VLAN ID 1 is
configured. Do not use the standard failsafe configuration for DSA
accessing the default port directly, but configure a switch on the lan1
interface instead.

This will add the VLAN ID 1 configuration to the switch:
$ bridge vlan show
port  vlan-id
lan1  1 PVID Egress Untagged
switch1 PVID Egress Untagged

Signed-off-by: Hauke Mehrtens 
---
  .../lib/preinit/05_set_preinit_iface_realtek| 13 +
  .../lib/preinit/98_remove_preinit_realtek   |  6 ++
  2 files changed, 19 insertions(+)
  create mode 100644 
target/linux/realtek/base-files/lib/preinit/05_set_preinit_iface_realtek
  create mode 100644 
target/linux/realtek/base-files/lib/preinit/98_remove_preinit_realtek

diff --git 
a/target/linux/realtek/base-files/lib/preinit/05_set_preinit_iface_realtek 
b/target/linux/realtek/base-files/lib/preinit/05_set_preinit_iface_realtek
new file mode 100644
index ..e2a7cf5a69e9
--- /dev/null
+++ b/target/linux/realtek/base-files/lib/preinit/05_set_preinit_iface_realtek
@@ -0,0 +1,13 @@
+set_preinit_iface() {
+
+   # Create a switch on lan1 to configure the VLAN 1.
+   # Without configuring VLAN ID 1 RTL8380 - RTL9300 will not
+   # forward packets.
+   ip link add name switch type bridge vlan_filtering 1
+   ip link set dev lan1 master switch
+   ip link set lan1 up
+
+   pi_ifname=switch
+}
+
+boot_hook_add preinit_main set_preinit_iface
diff --git 
a/target/linux/realtek/base-files/lib/preinit/98_remove_preinit_realtek 
b/target/linux/realtek/base-files/lib/preinit/98_remove_preinit_realtek
new file mode 100644
index ..dc5fdb059b9b
--- /dev/null
+++ b/target/linux/realtek/base-files/lib/preinit/98_remove_preinit_realtek
@@ -0,0 +1,6 @@
+remove_switch() {
+   # delete switch created in 05_set_preinit_iface_realtek again
+   ip link del name switch
+}
+
+boot_hook_add preinit_main remove_switch



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: realtek: Traffic directly on lanX not working

[Birger Koblitz]

> Hi,
> 
> the hardware documentation is very poor, not much more than advertisement for 
> the SoCs, e.g. for the RTL8380
> https://manualzz.com/doc/31627850/draft-datasheet
> it does not mention these special VLAN properties.
> 
> All the code is based on the GPL drops. However, the latest ones comprise the 
> complete SDK for these chips
> and are relatively readable, pick the one on the XGS1210 from here:
> https://www.biot.com/switches/gpl_source_drops
> For the RTL8380, the VLAN configuration is done in 
> sdk/src/dal/maple/dal_maple_vlan.c
> The default VLAN configuration is done in function _dal_maple_vlan_init_config
> 
> Birger
>

And of course I forgot to mention the documentation we put together at

https://svanheule.net/realtek/

B.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: realtek: Traffic directly on lanX not working

[Birger Koblitz]

> 
> Hi,
> 
> Thank you for the links, I was not aware of this strange problem.
> 
> Do you have access to a documentation of any of these chips or only some 
> source code?
> 
> We could add some special handling for these chips in the failsafe mode, let 
> me look into this.
> 
> Hauke
> 

Hi,

the hardware documentation is very poor, not much more than advertisement for 
the SoCs, e.g. for the RTL8380
https://manualzz.com/doc/31627850/draft-datasheet
it does not mention these special VLAN properties.

All the code is based on the GPL drops. However, the latest ones comprise the 
complete SDK for these chips
and are relatively readable, pick the one on the XGS1210 from here:
https://www.biot.com/switches/gpl_source_drops
For the RTL8380, the VLAN configuration is done in 
sdk/src/dal/maple/dal_maple_vlan.c
The default VLAN configuration is done in function _dal_maple_vlan_init_config

Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: realtek: Traffic directly on lanX not working

[Birger Koblitz]

Hi,

On 19.06.21 14:25, Hauke Mehrtens wrote:
> Hi,
> 
> I am unable to send and receive packets directly on the lan1 interface when 
> it is not part of a bridge.
> 

> In wireshark on a connected host I do not see any packets from this device, 
> but the link is up.
> 
> When I use OpenWrt's default network configuration using a bridge, network 
> works like expected.
> I took care of the VLAN 100 which is used by default, but this setup does not 
> use any VLAN.
> 
> I would like to use a very similar configuration for the failsafe mode which 
> is also not working correctly.

This is the same finding tmon had:
https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/598

The reason is a hardware limitation on RTL chip families 8380-9300, they 
require a port to be a member of VLAN 1
in order to send/receive traffic:
https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/602

I am not sure how to proceed. One solution is to set this up silently in the 
driver, but then the existence of
vlan 1 would be intransparent to the user, a possible security risk.

Birger


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] realtek: Fix buffer length calculation on RTL8380 with CRC offload

[Birger Koblitz]

realtek: Fix buffer length calculation on RTL8380 with CRC offload

Fixes the buffer and packet length calculations for Ethernet TX on
the RTL8380 SoC when CRC calculation offload is enabled.
CRC-offload is always done by the SoC, but additional CRC
calculation was previously done also by the kernel.
It also fixes detection of the DSA tag for packets on RTL8390
SoCs for ports > 28.

v2 has correct whitespace

Signed-off-by: Birger Koblitz 

---
diff --git a/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c 
b/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
index c5c6e3b6b7..de54868cad 100644
--- a/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
+++ b/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
@@ -1129,23 +1129,16 @@ static int rtl838x_eth_tx(struct sk_buff *skb, struct 
net_device *dev)

/* Check for DSA tagging at the end of the buffer */
if (netdev_uses_dsa(dev) && skb->data[len-4] == 0x80 && 
skb->data[len-3] > 0
-   && skb->data[len-3] < 28 &&  skb->data[len-2] == 0x10
+   && skb->data[len-3] < priv->cpu_port &&  
skb->data[len-2] == 0x10
&&  skb->data[len-1] == 0x00) {
/* Reuse tag space for CRC if possible */
dest_port = skb->data[len-3];
+   skb->data[len-4] = skb->data[len-3] = skb->data[len-2] = 
skb->data[len-1] = 0x00;
len -= 4;
}

len += 4; // Add space for CRC

-   // On RTL8380 SoCs, the packet needs extra padding
-   if (priv->family_id == RTL8380_FAMILY_ID) {
-   if (len < ETH_ZLEN)
-   len = ETH_ZLEN; // SoC not automatically padding to 
ETH_ZLEN
-   else
-   len += 4;
-   }
-
if (skb_padto(skb, len)) {
ret = NETDEV_TX_OK;
goto txdone;
@@ -1158,6 +1151,11 @@ static int rtl838x_eth_tx(struct sk_buff *skb, struct 
net_device *dev)
h = >tx_header[q][ring->c_tx[q]];
h->size = len;
h->len = len;
+   // On RTL8380 SoCs, small packet lengths being sent need 
adjustments
+   if (priv->family_id == RTL8380_FAMILY_ID) {
+   if (len < ETH_ZLEN - 4)
+   h->len -= 4;
+   }

priv->r->create_tx_header(h, dest_port, skb->priority >> 1);


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: Fix buffer length calculation on RTL8380 with CRC offload

[Birger Koblitz]

Hi,

I messed up the whitespace, sorry!
Will send v2.

Birger

On 05.06.21 22:14, Hauke Mehrtens wrote:
> On 5/9/21 7:32 PM, Birger Koblitz wrote:
>> realtek: Fix buffer length calculation on RTL8380 with CRC offload
>>
>> Fixes the buffer and packet length calculations for Ethernet TX on
>> the RTL8380 SoC when CRC calculation offload is enabled.
>> CRC-offload is always done by the SoC, but additional CRC
>> calculation was previously done also by the kernel.
>> It also fixes detection of the DSA tag for packets on RTL8390
>> SoCs for ports > 28.
>>
>> Signed-off-by: Birger Koblitz 
> 
> 
> Hi,
> 
> This patch does not apply to master for me.
> 
> Hauke
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] realtek: Fix VLAN issues introduced by multicast patches

[Birger Koblitz]

realtek: Fix VLAN issues introduced by multicast patches

This adds the CPU port to the unknown multicast flooding port mask,
which fixes the VLAN issues introduced by the multicast group patches

Signed-off-by: Birger Koblitz 

---

v2: fixed typo in "unknown"

diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
index 8f66ae6f8f..7c0d55b67a 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
@@ -501,7 +501,7 @@ static void rtl838x_vlan_profile_setup(int profile)
 * On RTL93XX, the portmask is directly set in the profile,
 * see e.g. rtl9300_vlan_profile_setup
 */
-   rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0xfff);
+   rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0x1fff);
 }

 static inline int rtl838x_vlan_port_egr_filter(int port)
diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl839x.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl839x.c
index 74472461a1..c62dc441c1 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl839x.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl839x.c
@@ -411,7 +411,7 @@ static void rtl839x_vlan_profile_setup(int profile)
sw_w32(p[0], RTL839X_VLAN_PROFILE(profile));
sw_w32(p[1], RTL839X_VLAN_PROFILE(profile) + 4);

-   rtl839x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0x000f);
+   rtl839x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0x001f);
 }

 static inline int rtl839x_vlan_port_egr_filter(int port)
diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl930x.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl930x.c
index 820c78165a..7ff0001ec7 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl930x.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl930x.c
@@ -153,9 +153,9 @@ static void rtl930x_vlan_profile_setup(int profile)

// Enable routing of Ipv4/6 Unicast and IPv4/6 Multicast traffic
p[0] |= BIT(17) | BIT(16) | BIT(13) | BIT(12);
-   p[2] = 0x0fff; // L2 unknwon MC flooding portmask: all but the 
CPU-port
-   p[3] = 0x0fff; // IPv4 unknwon MC flooding portmask
-   p[4] = 0x0fff; // IPv6 unknwon MC flooding portmask
+   p[2] = 0x1fff; // L2 unknown MC flooding portmask all ports, 
including the CPU-port
+   p[3] = 0x1fff; // IPv4 unknown MC flooding portmask
+   p[4] = 0x1fff; // IPv6 unknown MC flooding portmask

sw_w32(p[0], RTL930X_VLAN_PROFILE_SET(profile));
sw_w32(p[1], RTL930X_VLAN_PROFILE_SET(profile) + 4);

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

[Birger Koblitz]

On 11/05/2021 19:51, Rafał Miłecki wrote:

On 11.05.2021 19:46, John Crispin wrote:

On 11.05.21 19:45, Rafał Miłecki wrote:

I'm really tired of dealing with such hacky solutions. Look at netifd,
DSA and LuCI as example. We ended up with something that noone fully
understands. Jo - our UI guru - couldn't deal with designing a proper
UI for that f*cked config syntax. 


sorry mate, I am not the reason you are having a bad day, so dont vent it out 
on me.


It's just an example of shitty situation we got. Nothing more.

I took a good amount of time to provide valuable review for the
[PATCH v2] rtl83xx-poe: add package

I described problems, missing parts, provided examples how one can
solve it. Let's discuss that please. Instead of commenting on one
example I provided.


I think the growing RTL83xx crowd has shown that we are able to refactor
code and strive for the good stuff, see all the drivers that are now
getting into mainline. I also don't think we are getting into any kind
of cul-de-sac we cannot get out, because also other platforms will make
use of the uart-based interface these PoE chips offer, so I do not see
that there would be any need for major re-designs, and in particular no
need to implement this in kernel space. If for some reasons there are
PoE solutions that have a similar command-set but different (GPIO) interface
then if necessary this could be handled by a separate kernel module
that would offer a uart interface for the user-space. Alternatively
we go to a different user-space interface altogether, but it is clear
a user-space solution which talks PoE commands will be needed.

Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] realtek: Fix buffer length calculation on RTL8380 with CRC offload

[Birger Koblitz]

realtek: Fix buffer length calculation on RTL8380 with CRC offload

Fixes the buffer and packet length calculations for Ethernet TX on
the RTL8380 SoC when CRC calculation offload is enabled.
CRC-offload is always done by the SoC, but additional CRC
calculation was previously done also by the kernel.
It also fixes detection of the DSA tag for packets on RTL8390
SoCs for ports > 28.

Signed-off-by: Birger Koblitz 

---
diff --git a/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c 
b/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
index c5c6e3b6b7..9fe4fcd647 100644
--- a/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
+++ b/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
@@ -1129,23 +1129,16 @@ static int rtl838x_eth_tx(struct sk_buff *skb, struct 
net_device *dev)

/* Check for DSA tagging at the end of the buffer */
if (netdev_uses_dsa(dev) && skb->data[len-4] == 0x80 && skb->data[len-3] 
> 0
-   && skb->data[len-3] < 28 &&  skb->data[len-2] == 0x10
+   && skb->data[len-3] < priv->cpu_port &&  
skb->data[len-2] == 0x10
&&  skb->data[len-1] == 0x00) {
/* Reuse tag space for CRC if possible */
dest_port = skb->data[len-3];
+   skb->data[len-4] = skb->data[len-3] = skb->data[len-2] = 
skb->data[len-1] = 0x00;
len -= 4;
}

len += 4; // Add space for CRC

-   // On RTL8380 SoCs, the packet needs extra padding
-   if (priv->family_id == RTL8380_FAMILY_ID) {
-   if (len < ETH_ZLEN)
-   len = ETH_ZLEN; // SoC not automatically padding to 
ETH_ZLEN
-   else
-   len += 4;
-   }
-
if (skb_padto(skb, len)) {
ret = NETDEV_TX_OK;
goto txdone;
@@ -1158,6 +1151,11 @@ static int rtl838x_eth_tx(struct sk_buff *skb, struct 
net_device *dev)
h = >tx_header[q][ring->c_tx[q]];
h->size = len;
h->len = len;
+   // On RTL8380 SoCs, small packet lengths being sent need 
adjustments
+   if (priv->family_id == RTL8380_FAMILY_ID) {
+   if (len < ETH_ZLEN - 4)
+   h->len -= 4;
+   }

priv->r->create_tx_header(h, dest_port, skb->priority >> 1);



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: realtek: Setup all VLANs with default configurations

[Birger Koblitz]

On 08/05/2021 17:39, Bjørn Mork wrote:


But I'm not convinced it works so well for the default either...  I see
this received on the native VLAN 1:


canardo:/tmp# tshark -nVi xeth0 -f 'udp port 67'
Running as user "root" and group "root". This could be dangerous.
Capturing on 'xeth0'
Frame 1: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits) on 
interface 0
 Interface id: 0 (xeth0)
 Interface name: xeth0
 Encapsulation type: Ethernet (1)
 Arrival Time: May  8, 2021 16:56:20.581072322 CEST
 [Time shift for this packet: 0.0 seconds]
 Epoch Time: 1620485780.581072322 seconds
 [Time delta from previous captured frame: 0.0 seconds]
 [Time delta from previous displayed frame: 0.0 seconds]
 [Time since reference or first frame: 0.0 seconds]
 Frame Number: 1
 Frame Length: 346 bytes (2768 bits)
 Capture Length: 346 bytes (2768 bits)
 [Frame is marked: False]
 [Frame is ignored: False]
 [Protocols in frame: eth:ethertype:ip:udp:bootp]
Ethernet II, Src: bc:a5:11:9f:e1:23, Dst: ff:ff:ff:ff:ff:ff
 Destination: ff:ff:ff:ff:ff:ff
 Address: ff:ff:ff:ff:ff:ff
  ..1.     = LG bit: Locally administered address 
(this is NOT the factory default)
  ...1     = IG bit: Group address 
(multicast/broadcast)
 Source: bc:a5:11:9f:e1:23
 Address: bc:a5:11:9f:e1:23
  ..0.     = LG bit: Globally unique address 
(factory default)
  ...0     = IG bit: Individual address (unicast)
 Type: IPv4 (0x0800)
 Frame check sequence: 0x80091000 incorrect, should be 0x63ff5c43
 [Expert Info (Error/Checksum): Bad checksum [should be 0x63ff5c43]]
 [Bad checksum [should be 0x63ff5c43]]
 [Severity level: Error]
 [Group: Checksum]
 [FCS Status: Bad]
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
 0100  = Version: 4
  0101 = Header Length: 20 bytes (5)
 Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
  00.. = Differentiated Services Codepoint: Default (0)
  ..00 = Explicit Congestion Notification: Not ECN-Capable 
Transport (0)
 Total Length: 328
 Identification: 0x (0)
 Flags: 0x
 0...    = Reserved bit: Not set
 .0..    = Don't fragment: Not set
 ..0.    = More fragments: Not set
 Fragment offset: 0
 Time to live: 64
 Protocol: UDP (17)
 Header checksum: 0x79a6 [validation disabled]
 [Header checksum status: Unverified]
 Source: 0.0.0.0
 Destination: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
 Source Port: 68
 Destination Port: 67
 Length: 308
 Checksum: 0xd82b [unverified]
 [Checksum Status: Unverified]
  
[etc]




That seemingly magic number 0x80091000 instead of the expected FCS is
pretty suspicious. Leaking tag?  Or what?


Yes, this looks like the DSA-tag in the packet buffer is not being overwritten 
by the CRC.
Could you try out the following patch, which tries to follow the convolutions 
of the SDK for the 8380,
with respect of buffer length and packet length when the CRC is being 
calculated by offloading.
On my DLink 1210-10hp I see properly formed packets with small (<60 octets) and 
larger size.
It fixes also the detection of DSA tags with a high port number (>=28) on the 
8390.

diff --git a/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c 
b/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
index c5c6e3b6b7..9fe4fcd647 100644
--- a/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
+++ b/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
@@ -1129,23 +1129,16 @@ static int rtl838x_eth_tx(struct sk_buff *skb, struct 
net_device *dev)

/* Check for DSA tagging at the end of the buffer */
if (netdev_uses_dsa(dev) && skb->data[len-4] == 0x80 && skb->data[len-3] 
> 0
-   && skb->data[len-3] < 28 &&  skb->data[len-2] == 0x10
+   && skb->data[len-3] < priv->cpu_port &&  
skb->data[len-2] == 0x10
&&  skb->data[len-1] == 0x00) {
/* Reuse tag space for CRC if possible */
dest_port = skb->data[len-3];
+   skb->data[len-4] = skb->data[len-3] = skb->data[len-2] = 
skb->data[len-1] = 0x00;
len -= 4;
}

len += 4; // Add space for CRC

-   // On RTL8380 SoCs, the packet needs extra padding
-   if (priv->family_id == RTL8380_FAMILY_ID) {
-   if (len < ETH_ZLEN)
-   len = ETH_ZLEN; // SoC not automatically padding to 
ETH_ZLEN
-   else
-   len += 4;
-   }
-
if (skb_padto(skb, len)) {
ret = NETDEV_TX_OK;

[PATCH] realtek: Fix VLAN issues introduced by multicast patches

[Birger Koblitz]

realtek: Fix VLAN issues introduced by multicast patches

This adds the CPU port to the unknown multicast flooding port mask,
which fixes the VLAN issues introduced by the multicast group patches

Signed-off-by: Birger Koblitz 

---

diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
index 8f66ae6f8f..7c0d55b67a 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
@@ -501,7 +501,7 @@ static void rtl838x_vlan_profile_setup(int profile)
 * On RTL93XX, the portmask is directly set in the profile,
 * see e.g. rtl9300_vlan_profile_setup
 */
-   rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0xfff);
+   rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0x1fff);
 }

 static inline int rtl838x_vlan_port_egr_filter(int port)
diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl839x.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl839x.c
index 74472461a1..c62dc441c1 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl839x.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl839x.c
@@ -411,7 +411,7 @@ static void rtl839x_vlan_profile_setup(int profile)
sw_w32(p[0], RTL839X_VLAN_PROFILE(profile));
sw_w32(p[1], RTL839X_VLAN_PROFILE(profile) + 4);

-   rtl839x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0x000f);
+   rtl839x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0x001f);
 }

 static inline int rtl839x_vlan_port_egr_filter(int port)
diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl930x.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl930x.c
index 820c78165a..7ff0001ec7 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl930x.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl930x.c
@@ -153,9 +153,9 @@ static void rtl930x_vlan_profile_setup(int profile)

// Enable routing of Ipv4/6 Unicast and IPv4/6 Multicast traffic
p[0] |= BIT(17) | BIT(16) | BIT(13) | BIT(12);
-   p[2] = 0x0fff; // L2 unknwon MC flooding portmask: all but the 
CPU-port
-   p[3] = 0x0fff; // IPv4 unknwon MC flooding portmask
-   p[4] = 0x0fff; // IPv6 unknwon MC flooding portmask
+   p[2] = 0x1fff; // L2 unknwon MC flooding portmask all ports, 
including the CPU-port
+   p[3] = 0x1fff; // IPv4 unknwon MC flooding portmask
+   p[4] = 0x1fff; // IPv6 unknwon MC flooding portmask

sw_w32(p[0], RTL930X_VLAN_PROFILE_SET(profile));
sw_w32(p[1], RTL930X_VLAN_PROFILE_SET(profile) + 4);

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: realtek: Setup all VLANs with default configurations

[Birger Koblitz]

Hi,

Actually, you don't have to disable the profile_setups.  This change is
sufficient to make VLANs work (at least in the limited testing I've done):


diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
index dfd773c5e6fc..5d764b6a32d6 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
@@ -398,7 +398,7 @@ static void rtl838x_vlan_profile_setup(int profile)
  * On RTL93XX, the portmask is directly set in the profile,
  * see e.g. rtl9300_vlan_profile_setup
  */
-   rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0xfff);
+   rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0x1fff);
  }
  
  static inline int rtl838x_vlan_port_egr_filter(int port)



No idea why or how.  Just a magic value with a magic result, like most
of the code.
Come on Björn, it wasn't so magic if you could figure that out although 
you hadn't seen the code before. There is more and more understanding on 
how this piece of hardware works, even though we only have an SDK which 
is spaghetti and magic sauce and you might have noticed there are more 
and more comments in the latest additions.


Yes, that was indeed my mistake, the second parameter is the mask of 
ports MC packets are flooded to as long as a multicast group has not 
been set up by the bridge, port 28 (= BIT 28) being the CPU port on the 
8380. I thought all relevant traffic would anyway be trapped to the CPU, 
I did quite some testing setting up the traps. I was evidently wrong.

I really don't think these changes have been tested well enough to be
pushed into openwrt master yet.  Based on this first impression, I would
be surprised if there isn't more broken stuff.
I asked for testing of this set of patches in the rtl83xx irc a week ago 
and the code was on GitHub since then. I got no feedback up til now when 
it ended up in master.

I'll post a patch for all the architectures for this problem.


Cheers,
  Birger



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: realtek: Setup all VLANs with default configurations

[Birger Koblitz]

yes, counters are reset on every read.
I guess I should have learned to do more vlan-testing.
I'll try to figure out what is going on.

Birger

On 08/05/2021 17:39, Bjørn Mork wrote:

Birger Koblitz  writes:


I tested the latest master on my 3 Zyxel devices, one for each SoC
generation, the GS1900-10HP, the GS1900-48 and the XGS-1210-10. They
got their IP addresses via DHCP on port 1 using the default network
setup. I then tested pinging, multicast (VLC) and iperf between
different non-management ports (2 and 3) and for multicast verified
that nothing could be seen on the router's CPU-Port nor the management
PC. I did not test anything specific to VLAN.

I don't think it's suficient to test without vlan tagging when messing
around with the vlan config on these switches. Experience has shown that
there are a number of possible and real failure modes, where you forward
with wrong tagging or filter on the wrong vid.


But I'm not convinced it works so well for the default either...  I see
this received on the native VLAN 1:


canardo:/tmp# tshark -nVi xeth0 -f 'udp port 67'
Running as user "root" and group "root". This could be dangerous.
Capturing on 'xeth0'
Frame 1: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits) on 
interface 0
 Interface id: 0 (xeth0)
 Interface name: xeth0
 Encapsulation type: Ethernet (1)
 Arrival Time: May  8, 2021 16:56:20.581072322 CEST
 [Time shift for this packet: 0.0 seconds]
 Epoch Time: 1620485780.581072322 seconds
 [Time delta from previous captured frame: 0.0 seconds]
 [Time delta from previous displayed frame: 0.0 seconds]
 [Time since reference or first frame: 0.0 seconds]
 Frame Number: 1
 Frame Length: 346 bytes (2768 bits)
 Capture Length: 346 bytes (2768 bits)
 [Frame is marked: False]
 [Frame is ignored: False]
 [Protocols in frame: eth:ethertype:ip:udp:bootp]
Ethernet II, Src: bc:a5:11:9f:e1:23, Dst: ff:ff:ff:ff:ff:ff
 Destination: ff:ff:ff:ff:ff:ff
 Address: ff:ff:ff:ff:ff:ff
  ..1.     = LG bit: Locally administered address 
(this is NOT the factory default)
  ...1     = IG bit: Group address 
(multicast/broadcast)
 Source: bc:a5:11:9f:e1:23
 Address: bc:a5:11:9f:e1:23
  ..0.     = LG bit: Globally unique address 
(factory default)
  ...0     = IG bit: Individual address (unicast)
 Type: IPv4 (0x0800)
 Frame check sequence: 0x80091000 incorrect, should be 0x63ff5c43
 [Expert Info (Error/Checksum): Bad checksum [should be 0x63ff5c43]]
 [Bad checksum [should be 0x63ff5c43]]
 [Severity level: Error]
 [Group: Checksum]
 [FCS Status: Bad]
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
 0100  = Version: 4
  0101 = Header Length: 20 bytes (5)
 Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
  00.. = Differentiated Services Codepoint: Default (0)
  ..00 = Explicit Congestion Notification: Not ECN-Capable 
Transport (0)
 Total Length: 328
 Identification: 0x (0)
 Flags: 0x
 0...    = Reserved bit: Not set
 .0..    = Don't fragment: Not set
 ..0.    = More fragments: Not set
 Fragment offset: 0
 Time to live: 64
 Protocol: UDP (17)
 Header checksum: 0x79a6 [validation disabled]
 [Header checksum status: Unverified]
 Source: 0.0.0.0
 Destination: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
 Source Port: 68
 Destination Port: 67
 Length: 308
 Checksum: 0xd82b [unverified]
 [Checksum Status: Unverified]
  
[etc]




That seemingly magic number 0x80091000 instead of the expected FCS is
pretty suspicious. Leaking tag?  Or what?


I merely verified via
"bridge fdb"t that the entries in the forwarding table now use the
vlan as forwarding ID together with the target MAC address. Before
that they were using a fixed and very strange forwarding ID (4031 on
the 8380) together with a MAC-address. At the moment I do not have
access to these devices (in summer house) only a buggy DLink DGS
1210-10P, that does not want to bridge between ports with OpenWRT.
I added some interesting debug possibility in my "pie" branch. copy
debugfs.c over and you can use

|cat /sys/kernel/debug/rtl838x/drop_counters|

to see why the switch drops packets.




root@OpenWrt:/# cat /sys/kernel/debug/rtl838x/drop_counters
ALE_TX_GOOD_PKTS: 74
MAC_RX_DROP: 0
ACL_FWD_DROP: 0
HW_ATTACK_PREVENTION_DROP: 0
RMA_DROP: 0
VLAN_IGR_FLTR_DROP: 0
INNER_OUTER_CFI_EQUAL_1_DROP: 0
PORT_MOVE_DROP: 0
NEW_SA_DROP: 0
MAC_LIMIT_SYS_DROP: 0
MAC_LIMIT_VLAN_DROP: 0
MAC_LIMIT_PORT_DROP: 0
SWITCH_MAC_DROP: 0
ROUTING_EXCEPTION_DROP: 0
DA_LKMISS_DROP: 0
RSPAN_DROP: 0
ACL

Fwd: realtek: Setup all VLANs with default configurations

[Birger Koblitz]

I tested the latest master on my 3 Zyxel devices, one for each SoC 
generation, the GS1900-10HP, the GS1900-48 and the XGS-1210-10. They got 
their IP addresses via DHCP on port 1 using the default network setup. I 
then tested pinging, multicast (VLC) and iperf between different 
non-management ports (2 and 3) and for multicast verified that nothing 
could be seen on the router's CPU-Port nor the management PC. I did not 
test anything specific to VLAN. I merely verified via "bridge fdb"t that 
the entries in the forwarding table now use the vlan as forwarding ID 
together with the target MAC address. Before that they were using a 
fixed and very strange forwarding ID (4031 on the 8380) together with a 
MAC-address. At the moment I do not have access to these devices (in 
summer house) only a buggy DLink DGS 1210-10P, that does not want to 
bridge between ports with OpenWRT.
I added some interesting debug possibility in my "pie" branch. copy 
debugfs.c over and you can use


|cat /sys/kernel/debug/rtl838x/drop_counters|

to see why the switch drops packets.
To debug the issues in master you could comment out the things done in 
dsa.c:rtl83xx_vlan_setup(). The only critical one for the multicast is 
the setup of the vlans in the loop below

// Initialize all vlans 0-4095

Birger

||

On 08/05/2021 15:32, Bjørn Mork wrote:

Birger Koblitz  writes:


Dear Russel,

depending on how a particular device was configured previously by
u-boot, this commit might have enabled proper vlan-filtering for the
first time on your device.  The default vlan-configuration has port 1
configured as management port with vlan-id 100. So your DHCP server
would need to answer with this vlan-id. Could you check that
- before the commit, the device was actually filtering vlans
- after the commit you have a correct vlan configuration on the device
   talking to the switch on port 1 and that this corresponds to the
  vlan configuration of that port

Does the latest master work for you?

I see the same issues Russell reports.  With a config like:

root@OpenWrt:/# bridge vlan
port  vlan-id
lan1  1 PVID Egress Untagged
   100
lan2  1 PVID Egress Untagged
   100
lan3  1 PVID Egress Untagged
lan4  1 PVID Egress Untagged
lan5  1 PVID Egress Untagged
lan6  1 PVID Egress Untagged
lan7  1 PVID Egress Untagged
lan8  1 PVID Egress Untagged
switch1
   100
root@OpenWrt:/# ifconfig switch.100
switch.100 Link encap:Ethernet  HWaddr BE:A5:11:9F:E1:23
   inet addr:192.168.100.1  Bcast:192.168.100.255  Mask:255.255.255.0
   inet6 addr: fe80::bca5:11ff:fe9f:e123/64 Scope:Link
   inet6 addr: fd49:b68c:340b::1/60 Scope:Global
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:0 (0.0 B)  TX bytes:1360 (1.3 KiB)



Looks like packets coming into port lan2 tagged with vlan id 100 are
dropped:

root@OpenWrt:/# ping 192.168.100.111
PING 192.168.100.111 (192.168.100.111): 56 data bytes
^C
--- 192.168.100.111 ping statistics ---
7 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:/# ip ne sh
192.168.100.111 dev switch.100  FAILED


The other end, connected to lan2, sees the tagged arps and replies. So I
believe these must be dropped on ingress to the switch:

17055   May  8, 2021 15:23:00.973571758 CESTbe:a5:11:9f:e1:23   
ff:ff:ff:ff:ff:ff   100 ARP Who has 192.168.100.111? Tell 
192.168.100.1
17056   May  8, 2021 15:23:00.973594729 CEST34:97:f6:5d:03:11   
be:a5:11:9f:e1:23   100 ARP 192.168.100.111 is at 34:97:f6:5d:03:11
17057   May  8, 2021 15:23:01.593254696 CEST80:e8:6f:97:78:01   
01:80:c2:00:00:00   STP Conf. Root = 32768/37/80:e8:6f:97:78:00 
 Cost = 0  Port = 0x8001
17058   May  8, 2021 15:23:02.013561194 CESTbe:a5:11:9f:e1:23   
ff:ff:ff:ff:ff:ff   100 ARP Who has 192.168.100.111? Tell 
192.168.100.1
17059   May  8, 2021 15:23:02.013572143 CEST34:97:f6:5d:03:11   
be:a5:11:9f:e1:23   100 ARP 192.168.100.111 is at 34:97:f6:5d:03:11


Reverting the two commits

  cde31976e375 ("realtek: Add support for Layer 2 Multicast")
  4342d27ec90c ("realtek: Setup all VLANs with default configurations")

fixes the problem.  I guess 4342d27ec90c is the critical one.  Just
reverting both to avoid having to manually fixup anything for this
simple test.


With exactly the same config as above:

root@OpenWrt:/# ping 192.168.100.111
PING 192.168.100.111 (192.168.100.111): 56 data bytes
64 bytes from 192.168.100.111: seq=0 ttl=64 time=1.714 ms
64 bytes from 192.168.100.111: seq=1 ttl=64 time=0.866 ms
^C
--- 192.1

Re: realtek: Setup all VLANs with default configurations

[Birger Koblitz]

Dear Russel,

depending on how a particular device was configured previously by 
u-boot, this commit might have enabled proper vlan-filtering for the 
first time on your device.  The default vlan-configuration has port 1 
configured as management port with vlan-id 100. So your DHCP server 
would need to answer with this vlan-id. Could you check that

- before the commit, the device was actually filtering vlans
- after the commit you have a correct vlan configuration on the device 
talking to the switch on port 1 and that this corresponds to the vlan 
configuration of that port


Cheers,
  Birger

On 08/05/2021 01:55, Russell Senior wrote:

The recent commit 4342d27ec90cd0988fd3e62ccefbe66f2e691372 to OpenWrt
seems to have broken the network on my Netgear GS108T v3. After about
300-500 seconds of uptime, the interface (in my case, switch.1
configured as WAN) stops receiving traffic. Nothing in dmesg or syslog
at the time of failure. From tcpdump -i switch.1 I can see the device
ARP'ing for the gateway address (which it received by DHCP) but not
seeing anything come back. Rolling back to the commit immediately
before and I don't see the problem and can ping the gateway
indefinitely.

Thanks!




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 1/3] realtek: revert to "standard" management configuration

[Birger Koblitz]

This has my full support, even as a developer I had trouble getting Realtek 
devices to work in the default configuration.
For OpenWRT users it is very confusing that these devices do not have a 
standard setup and the user first has to learn about VLANs to make use of the 
devices.

Birger

On 12.04.21 14:27, Bjørn Mork wrote:
> The default management interface should be easy to find for users
> doing "blind" installations without console access.  There are
> already multiple examples in the forum of advanced early adopters
> having problems locating the management interface after installing
> OpenWrt.
> 
> Requiring tagged VLAN configration to access the initial management
> interface creates unnecessary hassle at best. Errors on the other
> end are close to impossible to debug without console access, even
> for advanced users.  Less advanced users might have problems with
> the concept of VLAN tagging.
> 
> Limiting management access to a single arbitrary port among up to
> 52 possible LAN ports makes this even more difficult, for no
> reason at all. Users might have reasons to use a different port
> for management.  And they might even have difficulties using the
> OpenWrt selected one. The port might be the wrong type for their
> management link (e.g copper instead of fibre).  Or they might
> depend on PoE power from a device which they can't reconfigure.
> 
> User expectations will be based on
> - OpenWrt defaults for other devices
> - stock firmware default for the device in question
> - common default behaviour of similar devices
> 
> All 3 cases point to a static IP address accessible on the native
> VLAN of any LAN port.  A switch does not have any WAN port.  All
> ports are LAN ports.
> 
> This changes the default network configuration in line with these
> expectations.
> 
> Cc: John Crispin 
> Signed-off-by: Bjørn Mork 
> ---
>  .../realtek/base-files/etc/board.d/02_network  | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/target/linux/realtek/base-files/etc/board.d/02_network 
> b/target/linux/realtek/base-files/etc/board.d/02_network
> index 1e199db5897f..44f1f0a7a5c1 100644
> --- a/target/linux/realtek/base-files/etc/board.d/02_network
> +++ b/target/linux/realtek/base-files/etc/board.d/02_network
> @@ -22,27 +22,23 @@ for lan in /sys/class/net/lan*; do
>   lan_list="$lan_list $(basename $lan)"
>  done
>  ucidef_set_bridge_device switch
> -ucidef_set_interface_wan "$lan_list"
> -ucidef_set_interface "lan" ifname "lan1:t" protocol "static" vlan 100
> +ucidef_set_interface_lan "$lan_list"
>  
>  lan_mac=""
> -wan_mac=""
>  label_mac=""
>  case $board in
>  *)
> - wan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
> + lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
>   label_mac=$lan_mac
>   ;;
>  esac
>  
> -lan_mac=$(macaddr_setbit_la $wan_mac)
> -
>  ucidef_set_interface_macaddr "lan" $lan_mac
> -ucidef_set_interface_macaddr "wan" $wan_mac
> -ucidef_set_bridge_mac "$wan_mac"
> -ucidef_set_network_device_mac eth0 $wan_mac
> +ucidef_set_bridge_mac "$lan_mac"
> +ucidef_set_network_device_mac eth0 $lan_mac
>  for lan in $lan_list; do
>   ucidef_set_network_device_mac $lan $lan_mac
> + lan_mac=$(macaddr_setbit_la $lan_mac)
>   lan_mac=$(macaddr_add $lan_mac 1)
>  done
>  [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 4/6] realtek: enable HWMON for SFP sensors

[Birger Koblitz]

Tested and is necessary to e.g. read out temperatures from an SFP module.
Please merge,
  Birger

On 09/03/2021 22:12, Bjørn Mork wrote:

Signed-off-by: Bjørn Mork 
---
  target/linux/realtek/config-5.4 | 1 +
  1 file changed, 1 insertion(+)

diff --git a/target/linux/realtek/config-5.4 b/target/linux/realtek/config-5.4
index 2fbd904376fc..ed8c6023377f 100644
--- a/target/linux/realtek/config-5.4
+++ b/target/linux/realtek/config-5.4
@@ -82,6 +82,7 @@ CONFIG_HAS_DMA=y
  CONFIG_HAS_IOMEM=y
  CONFIG_HAS_IOPORT_MAP=y
  # CONFIG_HIGH_RES_TIMERS is not set
+CONFIG_HWMON=y
  CONFIG_HZ=250
  CONFIG_HZ_250=y
  CONFIG_HZ_PERIODIC=y



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 6/6] realtek: enable SerDes NWAY and SGMII negotiation

[Birger Koblitz]

ACK, please merge,
  Birger

On 09/03/2021 22:12, Bjørn Mork wrote:

This allows copper SFPs to negotiate speeds lower than 1gig.

Signed-off-by: Bjørn Mork 
---
  .../drivers/net/dsa/rtl83xx/common.c  |  4 +-
  .../files-5.4/drivers/net/dsa/rtl83xx/dsa.c   | 41 ++-
  2 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/common.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/common.c
index 197a96f8ad13..6940afa7f2a1 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/common.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/common.c
@@ -368,8 +368,8 @@ static int __init rtl83xx_mdio_probe(struct 
rtl838x_switch_priv *priv)
  
  	/* Enable PHY control via SoC */

if (priv->family_id == RTL8380_FAMILY_ID) {
-   /* Enable PHY control via SoC */
-   sw_w32_mask(0, BIT(15), RTL838X_SMI_GLB_CTRL);
+   /* Enable SerDes NWAY and PHY control via SoC */
+   sw_w32_mask(BIT(7), BIT(15), RTL838X_SMI_GLB_CTRL);
} else {
/* Disable PHY polling via SoC */
sw_w32_mask(BIT(7), 0, RTL839X_SMI_GLB_CTRL);
diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c
index 512f5351bf17..f7b9aca7a7c0 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c
@@ -344,6 +344,44 @@ static int rtl83xx_phylink_mac_link_state(struct 
dsa_switch *ds, int port,
return 1;
  }
  
+

+static void rtl83xx_config_interface(int port, phy_interface_t interface)
+{
+   u32 old, int_shift, sds_shift;
+
+   switch (port) {
+   case 24:
+   int_shift = 0;
+   sds_shift = 5;
+   break;
+   case 26:
+   int_shift = 3;
+   sds_shift = 0;
+   break;
+   default:
+   return;
+   }
+
+   old = sw_r32(RTL838X_SDS_MODE_SEL);
+   switch (interface) {
+   case PHY_INTERFACE_MODE_1000BASEX:
+   if ((old >> sds_shift & 0x1f) == 4)
+   return;
+   sw_w32_mask(0x7 << int_shift, 1 << int_shift, 
RTL838X_INT_MODE_CTRL);
+   sw_w32_mask(0x1f << sds_shift, 4 << sds_shift, 
RTL838X_SDS_MODE_SEL);
+   break;
+   case PHY_INTERFACE_MODE_SGMII:
+   if ((old >> sds_shift & 0x1f) == 2)
+   return;
+   sw_w32_mask(0x7 << int_shift, 2 << int_shift, 
RTL838X_INT_MODE_CTRL);
+   sw_w32_mask(0x1f << sds_shift, 2 << sds_shift, 
RTL838X_SDS_MODE_SEL);
+   break;
+   default:
+   return;
+   }
+   pr_debug("configured port %d for interface %s\n", port, 
phy_modes(interface));
+}
+
  static void rtl83xx_phylink_mac_config(struct dsa_switch *ds, int port,
unsigned int mode,
const struct phylink_link_state *state)
@@ -377,10 +415,11 @@ static void rtl83xx_phylink_mac_config(struct dsa_switch 
*ds, int port,
reg = sw_r32(priv->r->mac_force_mode_ctrl(port));
/* Auto-Negotiation does not work for MAC in RTL8390 */
if (priv->family_id == RTL8380_FAMILY_ID) {
-   if (mode == MLO_AN_PHY) {
+   if (mode == MLO_AN_PHY || phylink_autoneg_inband(mode)) {
pr_debug("PHY autonegotiates\n");
reg |= BIT(2);
sw_w32(reg, priv->r->mac_force_mode_ctrl(port));
+   rtl83xx_config_interface(port, state->interface);
return;
}
}



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 3/6] realtek: need to handle PHY_INTERFACE_MODE_NA for sfps

[Birger Koblitz]

Tested and it indeed fixes the problem that SFPs report this mode when 
configures their serdes.

Please apply,
 Birger

On 09/03/2021 22:12, Bjørn Mork wrote:

Signed-off-by: Bjørn Mork 
---
  target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c
index e0832c42b887..512f5351bf17 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/dsa.c
@@ -245,6 +245,7 @@ static void rtl83xx_phylink_validate(struct dsa_switch *ds, 
int port,
pr_debug("In %s port %d", __func__, port);
  
  	if (!phy_interface_mode_is_rgmii(state->interface) &&

+   state->interface != PHY_INTERFACE_MODE_NA &&
state->interface != PHY_INTERFACE_MODE_1000BASEX &&
state->interface != PHY_INTERFACE_MODE_MII &&
state->interface != PHY_INTERFACE_MODE_REVMII &&



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] rtl83xx-poe: add package

[Birger Koblitz]

Run tested by me on a DGS1210-10P.
Please merge,
  Birger

On 09/03/2021 22:18, Bjørn Mork wrote:

From: John Crispin 

Signed-off-by: John Crispin 
Signed-off-by: Bjørn Mork 
---
This is John's simple PoE daemon for the realtek devices, which has been
cycling around in assorted repos since last year.  It's well tested by
now.  I've been running this with constant polling from cacti for a
few months now without any issues.

I believe this should be included in master to make it easier to find
and install for new users.



Bjørn


  package/rtl83xx-poe/Makefile |  29 +++
  package/rtl83xx-poe/files/bin/poe.lua| 316 +++
  package/rtl83xx-poe/files/etc/config/poe |  10 +
  package/rtl83xx-poe/files/etc/init.d/poe |  18 ++
  4 files changed, 373 insertions(+)
  create mode 100644 package/rtl83xx-poe/Makefile
  create mode 100755 package/rtl83xx-poe/files/bin/poe.lua
  create mode 100644 package/rtl83xx-poe/files/etc/config/poe
  create mode 100755 package/rtl83xx-poe/files/etc/init.d/poe

diff --git a/package/rtl83xx-poe/Makefile b/package/rtl83xx-poe/Makefile
new file mode 100644
index ..195b1eb20949
--- /dev/null
+++ b/package/rtl83xx-poe/Makefile
@@ -0,0 +1,29 @@
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=rtl83xx-poe
+PKG_RELEASE:=2
+
+PKG_LICENSE:=GPL-2.0+
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/rtl83xx-poe
+  SECTION:=utils
+  CATEGORY:=Utilities
+  DEPENDS:=+libubox-lua +libubus-lua +libuci-lua +lua-rs232
+  TITLE:=PoE daemon for realtek switches
+endef
+
+define Package/rtl83xx-poe/description
+ This package contains an utility to allow triggering the PoE state of realtek 
switch ports.
+endef
+
+define Build/Compile
+
+endef
+
+define Package/rtl83xx-poe/install
+   $(CP) ./files/* $(1)/
+endef
+
+$(eval $(call BuildPackage,rtl83xx-poe))
diff --git a/package/rtl83xx-poe/files/bin/poe.lua 
b/package/rtl83xx-poe/files/bin/poe.lua
new file mode 100755
index ..86dafe13cd01
--- /dev/null
+++ b/package/rtl83xx-poe/files/bin/poe.lua
@@ -0,0 +1,316 @@
+#!/usr/bin/lua
+local rs = require "luars232"
+
+port_name = "/dev/ttyS1"
+out = io.stderr
+nseq = 0
+
+budget = 65.0
+port_power = {0, 0, 0, 0, 0, 0, 0, 0 }
+
+if arg[1] ~= nil then
+   budget = tonumber(arg[1])
+end
+for i = 1, 8 do
+   port_power[i] = arg[i + 1]
+end
+
+function initSerial(p)
+   local e, p = rs.open(p)
+   if e ~= rs.RS232_ERR_NOERROR then
+   -- handle error
+   out:write(string.format("can't open serial port '%s', error: 
'%s'\n",
+   port_name, rs.error_tostring(e)))
+   return
+   end
+
+   assert(p:set_baud_rate(rs.RS232_BAUD_19200) == rs.RS232_ERR_NOERROR)
+   assert(p:set_data_bits(rs.RS232_DATA_8) == rs.RS232_ERR_NOERROR)
+   assert(p:set_parity(rs.RS232_PARITY_NONE) == rs.RS232_ERR_NOERROR)
+   assert(p:set_stop_bits(rs.RS232_STOP_1) == rs.RS232_ERR_NOERROR)
+   assert(p:set_flow_control(rs.RS232_FLOW_OFF)  == rs.RS232_ERR_NOERROR)
+
+   out:write(string.format("OK, port open with values '%s'\n", 
tostring(p)))
+
+   return p
+end
+
+function receive(pCon)
+   local reply = {}
+   local retries = 0
+
+   while table.getn(reply) < 12 and retries < 4 do
+   -- Read up to 12 byte response, timeout 400ms
+   err, data_read, size = pCon:read(12, 400)
+   assert(err == rs.RS232_ERR_NOERROR)
+-- io.write(string.format("-> [%2d]:", string.len(data_read)))
+   for i = 1, string.len(data_read) do
+   table.insert(reply, string.byte(string.sub(data_read, 
i, i)))
+-- io.write(string.format(" %02x", reply[i]))
+   end
+-- io.write("\n")
+   retries = retries + 1
+   end
+   if table.getn(reply) ~= 12 then
+   print ("Unexpected length!")
+   return(nil)
+   end
+   local sum = 0
+   for i = 1, 11 do
+   sum = sum + reply[i]
+   end
+   if sum % 256 ~= reply[12] then
+   print ("Checksum error!")
+   return(nil)
+   end
+   return(reply)
+end
+
+function sendCommand(pCon, cmd)
+   nseq = nseq + 1
+   cmd[2] = nseq % 256
+
+   while table.getn(cmd) < 11 do
+   table.insert(cmd, 0xff)
+   end
+   local c_string = ""
+   local sum = 0
+-- io.write("send  ")
+   for i = 1, 11 do
+   sum = sum + cmd[i]
+-- io.write(string.format(" %02x", cmd[i]))
+   c_string = c_string .. string.char(cmd[i])
+   end
+-- io.write(string.format(" %02x\n", sum % 256))
+   c_string = c_string .. string.char(sum % 256)
+   err, len_written = pCon:write(c_string)
+   assert(err == rs.RS232_ERR_NOERROR)
+
+   local reply = receive(pCon)
+   if reply then
+-- io.write("recv  ")
+-- dumpReply(reply)
+   if 

Re: [PATCH 2/6] realtek: re-enable sfp driver for ZyXEL GS1900-10HP

[Birger Koblitz]

ACK. Please apply.

Birger

On 09/03/2021 22:12, Bjørn Mork wrote:

There is no need to define a static link or a phy for the sfp
ports.  Using phy-mode and managed properties to  describe the
link to the sfp phy.

We have to keep the now unconnected virtual "phys" because the
switch  driver uses their "phy-is-integrated" property to figure
out which ports to enable as fibre ports.

Signed-off-by: Bjørn Mork 
---
  .../realtek/dts/rtl8380_zyxel_gs1900-10hp.dts | 24 +--
  1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts 
b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
index 92d0e25fc477..c16028788ea4 100644
--- a/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
+++ b/target/linux/realtek/dts/rtl8380_zyxel_gs1900-10hp.dts
@@ -17,7 +17,7 @@
};
  
  	sfp0: sfp-p9 {

-   compatible = "_sff,sfp";
+   compatible = "sff,sfp";
i2c-bus = <>;
los-gpio = < 27 GPIO_ACTIVE_HIGH>;
tx-fault-gpio = < 22 GPIO_ACTIVE_HIGH>;
@@ -36,7 +36,7 @@
};
  
  	sfp1: sfp-p10 {

-   compatible = "_sff,sfp";
+   compatible = "sff,sfp";
i2c-bus = <>;
los-gpio = < 33 GPIO_ACTIVE_HIGH>;
tx-fault-gpio = < 28 GPIO_ACTIVE_HIGH>;
@@ -55,29 +55,17 @@
port@24 {
reg = <24>;
label = "lan9";
-   phy-mode = "rgmii-id";
-   phy-handle = <>;
+   phy-mode = "1000base-x";
+   managed = "in-band-status";
sfp = <>;
-
-   fixed-link {
-   speed = <1000>;
-   full-duplex;
-   pause;
-   };
};
  
  		port@26 {

reg = <26>;
label = "lan10";
-   phy-mode = "rgmii-id";
-   phy-handle = <>;
+   phy-mode = "1000base-x";
+   managed = "in-band-status";
sfp = <>;
-
-   fixed-link {
-   speed = <1000>;
-   full-duplex;
-   pause;
-   };
};
};
  };



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 1/6] realtek: fix link-state interrupt

[Birger Koblitz]

Indeed, this fixes a stupid typo that prevents the IRQ to be correctly 
configured.

Please apply.

Birger

On 09/03/2021 22:12, Bjørn Mork wrote:

This bug was the root cause for the failing sfp driver.

Signed-off-by: Bjørn Mork 
---
  .../realtek/files-5.4/drivers/net/dsa/rtl83xx/common.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/common.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/common.c
index 698f2892ea1e..197a96f8ad13 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/common.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/common.c
@@ -555,7 +555,6 @@ static int __init rtl83xx_sw_probe(struct platform_device 
*pdev)
int err = 0, i;
struct rtl838x_switch_priv *priv;
struct device *dev = >dev;
-   u64 irq_mask;
u64 bpdu_mask;
  
  	pr_debug("Probing RTL838X switch device\n");

@@ -650,9 +649,9 @@ static int __init rtl83xx_sw_probe(struct platform_device 
*pdev)
  
  	/* Enable link and media change interrupts. Are the SERDES masks needed? */

sw_w32_mask(0, 3, priv->r->isr_glb_src);
-   
-   priv->r->set_port_reg_le(irq_mask, priv->r->isr_port_link_sts_chg);
-   priv->r->set_port_reg_le(irq_mask, priv->r->imr_port_link_sts_chg);
+
+   priv->r->set_port_reg_le(priv->irq_mask, 
priv->r->isr_port_link_sts_chg);
+   priv->r->set_port_reg_le(priv->irq_mask, 
priv->r->imr_port_link_sts_chg);
  
  	priv->link_state_irq = platform_get_irq(pdev, 0);

pr_info("LINK state irq: %d\n", priv->link_state_irq);



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 1/2] realtek: Add generic zyxel_gs1900 image definition

[Birger Koblitz]

Hi,

On 25.02.21 07:56, Stefan Lippers-Hollmann wrote:
> Hi
>
> I'm wondering if this attempt to deal the gs1900 switch family really
> improves the situation for these devices. While IMAGE_SIZE and
> UIMAGE_MAGIC might indeed by rather generic to most (all?) members of
At least for the GS1900-48 the UIMAGE_MAGIC is indeed still  0x8380
and not 0x839whatever because of the RTL8393 SoC.

> the gs1900 family, SOC might not be (GS1900-24, GS1900-24E, GS1900-24HP
> are RTL8382M, GS1900-48 and GS1900-48HP are RTL8393 - admittedly, I do
> not know how different the resulting DTS would need to be, as these
> devices are not supported yet) and zyxel-vers is different for every
> single model (aside from GS1900-8HPv1 && GS1900-8HPv2):
The .dts for each device are very similar, they only differ in the number of
ports and whether there are SFP ports, but they need to include a SoC
specific .dtsi for small differences like CPU-speed. These changes might become
bigger in the future however, because upstream seems to favor explicit
definitions in the .dtsi over auto-detection in the drivers. Also we might need
to use regmap to map registers whose addresses seem to get randomly shuffled
for the Ethernt and Switch functionality between SoC revisions. At the moment
this is handled by SoC-specific function and register address tables in the 
drivers,
but with regmap they would go into the SoC .dtsi.

Birger

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] Realtek: fix build issues

[Birger Koblitz]

This fixes the build problems for the REALTEK target by adding a proper 
configuration
option for the phy module.

Signed-off-by: Birger Koblitz https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: 20.xx: state of the DSA

[Birger Koblitz]

Hi,

It is not necessary to enable swconfig for this target. I initially enabled it 
because luci was checking for
the swconfig binary in order to show switch information at all. This is no 
longer necessary.

Birger

On 20.11.20 06:12, Rosen Penev wrote:
> On Thu, Nov 19, 2020 at 8:37 PM Rosen Penev  wrote:
> rtl838x/config-5.4:CONFIG_SWCONFIG=y


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: fix switch port numbering for RT-AC65P/RT-AC85P

[Birger Koblitz]

Dear all, 

I acknowledge this patch on the RT-AC85P. For me in the setup without the 
patch, port numbers above the LEDs are correctly linked to respective physical 
port numbers, but the naming under Luci is incorrect, e.g. LAN1 corresponds to 
physical port 4.

Birger 

On 10 December 2019 14:25:00 CET, Birger Koblitz  wrote:
>Dear all,
>
>I'll check this this evening. Maybe I got the numbers backwards. The
>router's leds are labelled in the sequence 4 to 1 while the ports are
>numbered 1-4 at the back...
>
>Birger 
>
>
>On 10 December 2019 14:16:55 CET, "Gábor Varga" 
>wrote:
>>Dear Adrian,
>>
>>of course no, I have only Asus RT-AC65P router. As I see, the two
>>devices
>>are identical, but hopefully Birger can confirm (or not) this. When
>the
>>port numbering are different on two devices, than I send a new patch.
>>
>>Thanks,
>>
>>Gabor Varga
>>
>>Adrian Schmutzler  ezt írta (időpont: 2019.
>>dec.
>>10., K, 12:39):
>>
>>> Hi,
>>>
>>> have you verified this for both devices (rt-ac65p and rt-ac85p)?
>>>
>>> I've added Birger Koblitz to recipients (RT-AC85P author).
>>>
>>> Best
>>>
>>> Adrian
>>>
>>> > -Original Message-
>>> > From: openwrt-devel
>>[mailto:openwrt-devel-boun...@lists.openwrt.org] On
>>> > Behalf Of varga...@gmail.com
>>> > Sent: Montag, 9. Dezember 2019 23:04
>>> > To: openwrt-devel@lists.openwrt.org
>>> > Cc: yn...@true.cz; gch981...@gmail.com; Gabor Varga
>>
>>> > Subject: [OpenWrt-Devel] [PATCH] ramips: fix switch port numbering
>>for
>>> RT-
>>> > AC65P/RT-AC85P
>>> >
>>> > From: Gabor Varga 
>>> >
>>> > The switch LAN port numbers are in reversed order with original
>>config.
>>> > With this patch they are fixed.
>>> >
>>> > Signed-off-by: Gabor Varga 
>>> > ---
>>> >  .../linux/ramips/mt7621/base-files/etc/board.d/02_network  | 7
>>+--
>>> >  1 file changed, 5 insertions(+), 2 deletions(-)
>>> >
>>> > diff --git
>>a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
>>> > b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
>>> > index 420780a101..42cdb4d57f 100755
>>> > --- a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
>>> > +++ b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
>>> > @@ -37,6 +37,11 @@ ramips_setup_interfaces()
>>> >   ucidef_add_switch "switch0" \
>>> >   "0:lan" "1:lan" "2:lan" "3:lan" "4:wan"
>>"6@eth0"
>>> >   ;;
>>> > + asus,rt-ac65p|\
>>> > + asus,rt-ac85p)
>>> > + ucidef_add_switch "switch0" \
>>> > + "1:lan:1" "2:lan:2" "3:lan:3" "4:lan:4"
>>"0:wan"
>>> "6@eth0"
>>> > + ;;
>>> >   alfa-network,quad-e4g|\
>>> >   netgear,r6220|\
>>> >   netgear,r6260|\
>>> > @@ -64,8 +69,6 @@ ramips_setup_interfaces()
>>> >   ucidef_add_switch "switch0" \
>>> >   "1:lan" "2:lan" "3:lan" "4:lan" "0:wan"
>>"6@eth0"
>>> >   ;;
>>> > - asus,rt-ac65p|\
>>> > - asus,rt-ac85p|\
>>> >   dlink,dir-860l-b1|\
>>> >   elecom,wrc-1167ghbk2-s|\
>>> >   elecom,wrc-1900gst|\
>>> > --
>>> > 2.24.0
>>> >
>>> >
>>> > ___
>>> > openwrt-devel mailing list
>>> > openwrt-devel@lists.openwrt.org
>>> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: fix switch port numbering for RT-AC65P/RT-AC85P

[Birger Koblitz]

Dear all,

I'll check this this evening. Maybe I got the numbers backwards. The router's 
leds are labelled in the sequence 4 to 1 while the ports are numbered 1-4 at 
the back...

Birger 


On 10 December 2019 14:16:55 CET, "Gábor Varga"  wrote:
>Dear Adrian,
>
>of course no, I have only Asus RT-AC65P router. As I see, the two
>devices
>are identical, but hopefully Birger can confirm (or not) this. When the
>port numbering are different on two devices, than I send a new patch.
>
>Thanks,
>
>Gabor Varga
>
>Adrian Schmutzler  ezt írta (időpont: 2019.
>dec.
>10., K, 12:39):
>
>> Hi,
>>
>> have you verified this for both devices (rt-ac65p and rt-ac85p)?
>>
>> I've added Birger Koblitz to recipients (RT-AC85P author).
>>
>> Best
>>
>> Adrian
>>
>> > -Original Message-
>> > From: openwrt-devel
>[mailto:openwrt-devel-boun...@lists.openwrt.org] On
>> > Behalf Of varga...@gmail.com
>> > Sent: Montag, 9. Dezember 2019 23:04
>> > To: openwrt-devel@lists.openwrt.org
>> > Cc: yn...@true.cz; gch981...@gmail.com; Gabor Varga
>
>> > Subject: [OpenWrt-Devel] [PATCH] ramips: fix switch port numbering
>for
>> RT-
>> > AC65P/RT-AC85P
>> >
>> > From: Gabor Varga 
>> >
>> > The switch LAN port numbers are in reversed order with original
>config.
>> > With this patch they are fixed.
>> >
>> > Signed-off-by: Gabor Varga 
>> > ---
>> >  .../linux/ramips/mt7621/base-files/etc/board.d/02_network  | 7
>+--
>> >  1 file changed, 5 insertions(+), 2 deletions(-)
>> >
>> > diff --git
>a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
>> > b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
>> > index 420780a101..42cdb4d57f 100755
>> > --- a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
>> > +++ b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
>> > @@ -37,6 +37,11 @@ ramips_setup_interfaces()
>> >   ucidef_add_switch "switch0" \
>> >   "0:lan" "1:lan" "2:lan" "3:lan" "4:wan"
>"6@eth0"
>> >   ;;
>> > + asus,rt-ac65p|\
>> > + asus,rt-ac85p)
>> > + ucidef_add_switch "switch0" \
>> > + "1:lan:1" "2:lan:2" "3:lan:3" "4:lan:4"
>"0:wan"
>> "6@eth0"
>> > + ;;
>> >   alfa-network,quad-e4g|\
>> >   netgear,r6220|\
>> >   netgear,r6260|\
>> > @@ -64,8 +69,6 @@ ramips_setup_interfaces()
>> >   ucidef_add_switch "switch0" \
>> >   "1:lan" "2:lan" "3:lan" "4:lan" "0:wan"
>"6@eth0"
>> >   ;;
>> > - asus,rt-ac65p|\
>> > - asus,rt-ac85p|\
>> >   dlink,dir-860l-b1|\
>> >   elecom,wrc-1167ghbk2-s|\
>> >   elecom,wrc-1900gst|\
>> > --
>> > 2.24.0
>> >
>> >
>> > ___
>> > openwrt-devel mailing list
>> > openwrt-devel@lists.openwrt.org
>> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: use gpio_hog instead of gpio-export

[Birger Koblitz]

Thanks Adrian for taking this up again!

Birger

On 5 November 2019 16:12:02 CET, Adrian Schmutzler 
 wrote:
>From: Birger Koblitz 
>
>The gpio-export functionality is a hack for missing kernel
>functionality, which was rejected in upstream kernel long time ago,
>for details see this email
>http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
>discussion in PR#1366 or
>https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.
>
>This patch converts all DTS files with settings that normally do
>not need user interaction, e.g. power for external USB ports, to
>gpio_hog. The only remaining gpio-export will be in
>qca9558_openmesh_om5p-ac-v2.dts
>
>Signed-off-by: Birger Koblitz 
>[rebased, renamed nodes, do not change openmesh, removed redundant
>status=okay, updated commit message]
>Signed-off-by: Adrian Schmutzler 
>
>---
>
>This is a resubmission of the patch initially created by Birger
>Koblitz. It should be limited to conversion that do not require
>the user setting the value.
>---
> .../dts/ar7161_buffalo_wzr-hp-ag300h.dts  | 19 ++--
> .../ath79/dts/ar7241_tplink_tl-mr3x20.dtsi| 15 +-
> .../ath79/dts/ar7241_tplink_tl-wr842n-v1.dts  | 19 +---
> .../ath79/dts/ar7242_buffalo_wzr-bhr.dtsi | 20 ++---
> .../dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts  | 20 ++---
> .../ath79/dts/ar9341_tplink_tl-wr842n-v2.dts  | 19 ++--
> .../ath79/dts/qca9558_devolo_dvl1750e.dts | 15 +-
> .../ath79/dts/qca9558_tplink_archer-c7.dtsi   | 30 +--
> .../dts/qca9558_tplink_tl-wdr4900-v2.dts  | 28 +
> .../ath79/dts/qca9558_tplink_tl-wr1043nd.dtsi | 20 +
> .../ath79/dts/qca9561_tplink_archer-c5x.dtsi  | 30 +--
> .../ath79/dts/qca9563_dlink_dir-859-a1.dts| 20 +
> .../ath79/dts/qca9563_tplink_archer-c7-v4.dts | 30 +--
> .../dts/qca9563_tplink_archer-x7-v5.dtsi  | 17 +--
> .../dts/qca9563_tplink_tl-wr1043nd-v4.dts | 16 +-
> 15 files changed, 145 insertions(+), 173 deletions(-)
>
>diff --git a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
>b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
>index f51bc0f771..23f1845876 100644
>--- a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
>+++ b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
>@@ -120,16 +120,6 @@
>   };
>   };
> 
>-  gpio-export {
>-  compatible = "gpio-export";
>-
>-  gpio_usb_power {
>-  gpio-export,name = "buffalo:power:usb";
>-  gpio-export,output = <1>;
>-  gpios = < 2 GPIO_ACTIVE_HIGH>;
>-  };
>-  };
>-
>   flash {
>   compatible = "mtd-concat";
> 
>@@ -172,6 +162,15 @@
>   };
> };
> 
>+ {
>+  usb_power {
>+  gpio-hog;
>+  line-name = "buffalo:power:usb";
>+  gpios = <2 GPIO_ACTIVE_HIGH>;
>+  output-high;
>+  };
>+};
>+
> _phy {
>   status = "okay";
> };
>diff --git a/target/linux/ath79/dts/ar7241_tplink_tl-mr3x20.dtsi
>b/target/linux/ath79/dts/ar7241_tplink_tl-mr3x20.dtsi
>index 04403637b6..333ee17ceb 100644
>--- a/target/linux/ath79/dts/ar7241_tplink_tl-mr3x20.dtsi
>+++ b/target/linux/ath79/dts/ar7241_tplink_tl-mr3x20.dtsi
>@@ -3,15 +3,14 @@
> #include "ar7241_tplink.dtsi"
> 
> / {
>-  gpio-export {
>-  compatible = "gpio-export";
>-  #size-cells = <0>;
>+};
> 
>-  gpio_usb_power {
>-  gpio-export,name = "tp-link:power:usb";
>-  gpio-export,output = <1>;
>-  gpios = < 6 GPIO_ACTIVE_HIGH>;
>-  };
>+ {
>+  usb_power {
>+  gpio-hog;
>+  line-name = "tp-link:power:usb";
>+  gpios = <6 GPIO_ACTIVE_HIGH>;
>+  output-high;
>   };
> };
> 
>diff --git a/target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts
>b/target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts
>index 162b5f2838..ee468df244 100644
>--- a/target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts
>+++ b/target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts
>@@ -66,15 +66,16 @@
>   linux,default-trigger = "phy0tpt";
>   };
>   };
>+};
> 
>-  gpio-export {
>-  compatible = "gpio-export";
>+ {
>+  status = "okay";
> 
>

Re: [OpenWrt-Devel] [PATCH] ramips: add support for Asus RT-AC65P

[Birger Koblitz]

No. I think this is a bug. 

Birger

On 25 October 2019 12:26:34 CEST, Adrian Schmutzler  
wrote:
>Hi,
>
>> +led_power: power {
>> +label = "rt-ac85p:blue:power";
>> +gpios = < 4 GPIO_ACTIVE_LOW>;
>> +linux,default-trigger = "phy0tpt";
>> +};
>
>just found this, set for RT-AC65P and RT-AC85P. Any reason why the
>power led has a phy0tpt trigger (two WiFi LEDs with phyXradio are
>present, too)?
>
>Best
>
>Adrian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v6] ramips: add support for Edimax RG21S

[Birger Koblitz]

ramips: add support for Edimax RG21S

SoC:MediaTek MT7621AT dual-core @ 880MHz
RAM:256M (Nanya NT5CC128M)
FLASH:  16MB (Macronix MX25L12835F)
WiFi:   - 2.4GHz MediaTek MT7615N bgn
- 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:No
BTN:Reset, WPS
LED:4 red LEDs, indistinguishable when casing closed
UART:   UART is present as Pads marked J1 on the PCB.
3.3V - RX - GND - TX / 57600-8N1
3.3V is the square pad

Installation

Update the factory image via the OEM web-interface
(by default:http://192.168.1.1)
The sysupgrade image can be installed via TFTP from
the U-Boot bootloader. Connect ethernet port 2.

Signed-off-by: Birger Koblitz 

---

v3: Update to DEVICE_VENDOR / DEVICE_MODEL in mt7621.mk
renamed .dts according to new conventions
Removed memory node from .dts
Correct image size
Whitespace fixes
v4: Added wifi0/1 labels to wifi nodes
Model name corrected in dts
Comments removed from .dts
v5: Corrected MT7615N PCI IDs
Unnecessary kernel-modules removed from image
v6: Removed unnecessary mtd-mac-address in .dts
Rebased to latest master
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index b4634e0928..1a009a1429 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -333,6 +333,10 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan" "4:wan" "6@eth0"
;;
+   edimax,rg21s)
+   ucidef_add_switch "switch0" \
+   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+   ;;
gehua,ghl-r-001)
ucidef_add_switch "switch0" \
"0:lan" "1:lan" "2:lan" "4:wan" "6@eth0"
@@ -609,6 +613,10 @@ ramips_setup_macs()
netgear,r6850)
wan_mac=$(macaddr_add "$(cat /sys/class/net/eth0/address)" 2)
;;
+   edimax,rg21s)
+   lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
+   wan_mac=$(mtd_get_mac_ascii u-boot-env wanaddr)
+   ;;
hiwifi,hc5661|\
hiwifi,hc5661a|\
hiwifi,hc5761|\
diff --git a/target/linux/ramips/dts/mt7621_edimax_rg21s.dts 
b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
new file mode 100644
index 00..aeb247fb82
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "edimax,rg21s", "mediatek,mt7621-soc";
+   model = "Edimax RG21S";
+
+   aliases {
+   led-boot = _power;
+   led-failsafe = _power;
+   led-running = _power;
+   led-upgrade = _power;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   palmbus: palmbus@1E00 {
+   i2c@900 {
+   status = "okay";
+   };
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   gpios = < 16 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   wps {
+   label = "wps";
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: led_1 {
+   label = "rg21s:red:led1";
+   gpios = < 7 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_2 {
+   label = "rg21s:red:led2";
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_3 {
+   label = "rg21s:red:led3";
+   gpios = < 14 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_4 {
+   label = "rg21s:red:led4";
+   gpios = < 15 GPIO_ACTIVE_HIGH>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   m25p80@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+
+   partitions {
+   compatible = "fixed-partiti

[OpenWrt-Devel] [PATCH v7] ramips: add support for Asus RT-AC85P

[Birger Koblitz]

ramips: add support for Asus RT-AC85P

SoC:MediaTek MT7621AT dual-core @ 880MHz
RAM:256M (Winbond W632GG6KB-1)
FLASH:  128MB (Macronix MX30LF1G18AC-TI)
WiFi:   - 2.4GHz MediaTek MT7615N bgn
- 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:1 x USB 3.1 (Gen 1)
BTN:Reset, WPS
LED:- Power (blue)
- 5Ghz (blue)
- 2.4GHz (blue)
- Internet (blue)
- 4x LAN (blue)
(LAN/WAN leds are not controllable by GPIOs)
UART:   UART is present as Pads marked J4 on the PCB.
3.3V - TX - RX - GND / 57600-8N1
3.3V is the square pad
MAC:The MAC address on the router-label matches the MAC of
the 2.4 GHz WiFi.
LAN and WAN MAC are identical: MAC_LABEL+4
5 GHz WiFi MAC: also MAC_LABEL+4


Installation

Via U-Boot tftpd:
Switch on device, within 2s press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.

The images also work on the Asus RT-AC65P models as tested by Gabor.

Signed-off-by: Birger Koblitz 
Tested-by: Gabor Varga 

---

v2: Corrected sorting of entries in 02_network
Model name corrected in .dts
Whitespace fixes in .dts
wifi0/1 labels added to wifi nodes in .dts
Device name capitalized in mt7621.mk

v3: Added firmware backup to firmware2 partition before sysupgrade
Corrected modules included in image

v4: Corrected MT7615N PCI IDs

v5: Fixed indentation in platform.sh

v6: Rebased to latest master

v7: Removed unnecessary mtd-mac-address definitions
Fixed indentation mt7621_asus_rt-ac85p.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index b4634e0928..80e6a91c88 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -230,6 +230,18 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan" "1:wan" "6@eth0"
;;
+   asus,rt-ac85p|\
+   dlink,dir-860l-b1|\
+   elecom,wrc-1167ghbk2-s|\
+   elecom,wrc-1900gst|\
+   elecom,wrc-2533gst|\
+   huawei,hg255d|\
+   iodata,wn-ax1167gr|\
+   iodata,wn-gx300gr|\
+   iptime,a604m)
+   ucidef_add_switch "switch0" \
+   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+   ;;
asus,rt-n15|\
belkin,f9k1109v1|\
sitecom,wl-351)
@@ -297,17 +309,6 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5" 
"6@eth0"
;;
-   dlink,dir-860l-b1|\
-   elecom,wrc-1167ghbk2-s|\
-   elecom,wrc-1900gst|\
-   elecom,wrc-2533gst|\
-   huawei,hg255d|\
-   iodata,wn-ax1167gr|\
-   iodata,wn-gx300gr|\
-   iptime,a604m)
-   ucidef_add_switch "switch0" \
-   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
-   ;;
dlink,dwr-118-a1)
ucidef_add_switch "switch0" \
"1:lan:2" "2:lan:3" "3:lan:1" "4:lan:0" "5:wan" "6@eth0"
@@ -551,6 +552,9 @@ ramips_setup_macs()
zbtlink,zbt-we3526)
wan_mac=$(mtd_get_mac_binary factory 0xe006)
;;
+   asus,rt-ac85p)
+   wan_mac=$(mtd_get_mac_ascii u-boot-env et1macaddr)
+   ;;
asus,rt-n56u)
lan_mac=$(macaddr_setbit_la "$(cat 
/sys/class/net/eth0/address)")
wan_mac=$(mtd_get_mac_binary factory 0x8004)
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 9889079db9..a62ded4b9d 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -18,9 +18,16 @@ platform_do_upgrade() {
mikrotik,rbm33g)
[ -z "$(rootfs_type)" ] && mtd erase firmware
;;
+   asus,rt-ac85p)
+   echo "Backing up firmware"
+   dd if=/dev/mtd4 bs=1024 count=4096  > /tmp/backup_firmware.bin
+   dd if=/dev/mtd5 bs=1024 count=52224 >> /tmp/backup_firmware.bin
+   mtd -e firmware2 write /tmp/backup_firmware.bin firmware2
+   ;;
esac

case "$board" in
+   asus,rt-ac85p|\
hiwifi,hc5962|\
ne

Re: [OpenWrt-Devel] [PATCH v6] ramips: add support for Asus RT-AC85P

[Birger Koblitz]

On 15.09.19 12:31, m...@adrianschmutzler.de wrote:
> Hi,
> 
> see additions to the newer-ending-story below.
Well, at least in fiction it made for an excellent book. Not sure in 
engineering never-ending stories are so great.



>> + {
>> +wifi0: wifi@0,0 {
>> +compatible = "pci14c3,7615";
>> +reg = <0x 0 0 0 0>;
>> +mediatek,mtd-eeprom = < 0x>;
>> +ieee80211-freq-limit = <240 250>;
>> +mtd-mac-address = < 0x4>;
> 
> With mtd-eeprom reading from 0x0, the MAC address at 0x4 should be read by 
> default. So, you should get the same result with the mtd-mac-address line 
> removed.
Indeed, this works, I get the correct MAC address by default.

> 
>> +};
>> +};
>> +
>> + {
>> +wifi1: wifi@0,0 {
>> +compatible = "pci14c3,7615";
>> +reg = <0x 0 0 0 0>;
>> +mediatek,mtd-eeprom = < 0x8000>;
>> +ieee80211-freq-limit = <500 600>;
>> +mtd-mac-address = < 0x8004>;
> 
> See above: address is mtd-eeprom +4, so try to remove it.
Here as well.


>> +
>> + {
>> +status = "disabled";
> 
> Indent is wrong here.
Oops.

> 
> Best
> 
> Adrian
> 

will send a v7.

Best,
  Birger


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v6] ramips: add support for Asus RT-AC85P

[Birger Koblitz]

ramips: add support for Asus RT-AC85P

SoC:MediaTek MT7621AT dual-core @ 880MHz
RAM:256M (Winbond W632GG6KB-1)
FLASH:  128MB (Macronix MX30LF1G18AC-TI)
WiFi:   - 2.4GHz MediaTek MT7615N bgn
- 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:1 x USB 3.1 (Gen 1)
BTN:Reset, WPS
LED:- Power (blue)
- 5Ghz (blue)
- 2.4GHz (blue)
- Internet (blue)
- 4x LAN (blue)
(LAN/WAN leds are not controllable by GPIOs)
UART:   UART is present as Pads marked J4 on the PCB.
3.3V - TX - RX - GND / 57600-8N1
3.3V is the square pad
MAC:The MAC address on the router-label matches the MAC of
the 2.4 GHz WiFi.
LAN and WAN MAC are identical: MAC_LABEL+4
5 GHz WiFi MAC: also MAC_LABEL+4


Installation

Via U-Boot tftpd:
Switch on device, within 2s press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.

The images also work on the Asus RT-AC65P models as tested by Gabor.

Signed-off-by: Birger Koblitz 
Tested-by: Gabor Varga 

---

v2: Corrected sorting of entries in 02_network
Model name corrected in .dts
Whitespace fixes in .dts
wifi0/1 labels added to wifi nodes in .dts
Device name capitalized in mt7621.mk

v3: Added firmware backup to firmware2 partition before sysupgrade
Corrected modules included in image

v4: Corrected MT7615N PCI IDs

v5: Fixed indentation in platform.sh

v6: Rebased to latest master


diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index b4634e0928..80e6a91c88 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -230,6 +230,18 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan" "1:wan" "6@eth0"
;;
+   asus,rt-ac85p|\
+   dlink,dir-860l-b1|\
+   elecom,wrc-1167ghbk2-s|\
+   elecom,wrc-1900gst|\
+   elecom,wrc-2533gst|\
+   huawei,hg255d|\
+   iodata,wn-ax1167gr|\
+   iodata,wn-gx300gr|\
+   iptime,a604m)
+   ucidef_add_switch "switch0" \
+   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+   ;;
asus,rt-n15|\
belkin,f9k1109v1|\
sitecom,wl-351)
@@ -297,17 +309,6 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5" 
"6@eth0"
;;
-   dlink,dir-860l-b1|\
-   elecom,wrc-1167ghbk2-s|\
-   elecom,wrc-1900gst|\
-   elecom,wrc-2533gst|\
-   huawei,hg255d|\
-   iodata,wn-ax1167gr|\
-   iodata,wn-gx300gr|\
-   iptime,a604m)
-   ucidef_add_switch "switch0" \
-   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
-   ;;
dlink,dwr-118-a1)
ucidef_add_switch "switch0" \
"1:lan:2" "2:lan:3" "3:lan:1" "4:lan:0" "5:wan" "6@eth0"
@@ -551,6 +552,9 @@ ramips_setup_macs()
zbtlink,zbt-we3526)
wan_mac=$(mtd_get_mac_binary factory 0xe006)
;;
+   asus,rt-ac85p)
+   wan_mac=$(mtd_get_mac_ascii u-boot-env et1macaddr)
+   ;;
asus,rt-n56u)
lan_mac=$(macaddr_setbit_la "$(cat 
/sys/class/net/eth0/address)")
wan_mac=$(mtd_get_mac_binary factory 0x8004)
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 9889079db9..a62ded4b9d 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -18,9 +18,16 @@ platform_do_upgrade() {
mikrotik,rbm33g)
[ -z "$(rootfs_type)" ] && mtd erase firmware
;;
+   asus,rt-ac85p)
+   echo "Backing up firmware"
+   dd if=/dev/mtd4 bs=1024 count=4096  > /tmp/backup_firmware.bin
+   dd if=/dev/mtd5 bs=1024 count=52224 >> /tmp/backup_firmware.bin
+   mtd -e firmware2 write /tmp/backup_firmware.bin firmware2
+   ;;
esac

case "$board" in
+   asus,rt-ac85p|\
hiwifi,hc5962|\
netgear,r6220|\
netgear,r6260|\
diff --git a/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts 
b/targ

[OpenWrt-Devel] [PATCH v5] ramips: add support for Asus RT-AC85P

[Birger Koblitz]

ramips: add support for Asus RT-AC85P

SoC:MediaTek MT7621AT dual-core @ 880MHz
RAM:256M (Winbond W632GG6KB-1)
FLASH:  128MB (Macronix MX30LF1G18AC-TI)
WiFi:   - 2.4GHz MediaTek MT7615N bgn
- 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:1 x USB 3.1 (Gen 1)
BTN:Reset, WPS
LED:- Power (blue)
- 5Ghz (blue)
- 2.4GHz (blue)
- Internet (blue)
- 4x LAN (blue)
(LAN/WAN leds are not controllable by GPIOs)
UART:   UART is present as Pads marked J4 on the PCB.
3.3V - TX - RX - GND / 57600-8N1
3.3V is the square pad
MAC:The MAC address on the router-label matches the MAC of
the 2.4 GHz WiFi.
LAN and WAN MAC are identical: MAC_LABEL+4
5 GHz WiFi MAC: also MAC_LABEL+4


Installation

Via U-Boot tftpd:
Switch on device, within 2s press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.

The images also work on the Asus RT-AC65P models as tested by Gabor.

Signed-off-by: Birger Koblitz 
Tested-by: Gabor Varga 

---

v2: Corrected sorting of entries in 02_network
Model name corrected in .dts
Whitespace fixes in .dts
wifi0/1 labels added to wifi nodes in .dts
Device name capitalized in mt7621.mk

v3: Added firmware backup to firmware2 partition before sysupgrade
Corrected modules included in image

v4: Corrected MT7615N PCI IDs

v5: Fixed indentation in platform.sh

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index 2f9a02256e..ab90041d92 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -231,6 +231,17 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan" "1:wan" "6@eth0"
;;
+   asus,rt-ac85p|\
+   dlink,dir-860l-b1|\
+   elecom,wrc-1167ghbk2-s|\
+   elecom,wrc-1900gst|\
+   elecom,wrc-2533gst|\
+   huawei,hg255d|\
+   iodata,wn-ax1167gr|\
+   iodata,wn-gx300gr)
+   ucidef_add_switch "switch0" \
+   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+   ;;
asus,rt-n15|\
belkin,f9k1109v1|\
sitecom,wl-351)
@@ -298,16 +309,6 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5" 
"6@eth0"
;;
-   dlink,dir-860l-b1|\
-   elecom,wrc-1167ghbk2-s|\
-   elecom,wrc-1900gst|\
-   elecom,wrc-2533gst|\
-   huawei,hg255d|\
-   iodata,wn-ax1167gr|\
-   iodata,wn-gx300gr)
-   ucidef_add_switch "switch0" \
-   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
-   ;;
dlink,dwr-118-a1)
ucidef_add_switch "switch0" \
"1:lan:2" "2:lan:3" "3:lan:1" "4:lan:0" "5:wan" "6@eth0"
@@ -531,6 +532,9 @@ ramips_setup_macs()
lan_mac=$(mtd_get_mac_binary factory 57344)
wan_mac=$(mtd_get_mac_binary factory 57350)
;;
+   asus,rt-ac85p)
+   wan_mac=$(mtd_get_mac_ascii u-boot-env et1macaddr)
+   ;;
asus,rt-n56u)
lan_mac=$(macaddr_setbit_la "$(cat 
/sys/class/net/eth0/address)")
wan_mac=$(mtd_get_mac_binary factory 32772)
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index a65492a309..cd9d8ae650 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -18,9 +18,16 @@ platform_do_upgrade() {
mikrotik,rbm33g)
[ -z "$(rootfs_type)" ] && mtd erase firmware
;;
+   asus,rt-ac85p)
+   echo "Backing up firmware"
+   dd if=/dev/mtd4 bs=1024 count=4096  > /tmp/backup_firmware.bin
+   dd if=/dev/mtd5 bs=1024 count=52224 >> /tmp/backup_firmware.bin
+   mtd -e firmware2 write /tmp/backup_firmware.bin firmware2
+   ;;
esac

case "$board" in
+   asus,rt-ac85p|\
hiwifi,hc5962|\
netgear,r6220|\
netgear,r6350|\
diff --git a/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
b/target/linux/ramips/dts/mt7621_asus_rt-ac

[OpenWrt-Devel] [PATCH v2] ramips: use gpio_hog instead of gpio-exp

[Birger Koblitz]

ramips: use gpio_hog instead of gpio-export

The `gpio-export` functionality is a hack for
missing kernel functionality, which was rejected in upstream kernel long
time
ago, for details see this email
http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
discussion in PR#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.

This patch converts all ramips .dts(i) files which were
using export-gpio for powering USB/SATA ports to using gpio_hog instead

Signed-off-by: Birger Koblitz 

---

v2: Limited conversion to only usb ports/hubs and sata

diff --git a/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
b/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
index 3e54ffdad2..c573b38284 100644
--- a/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
+++ b/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
@@ -53,16 +53,16 @@
linux,code = ;
};
};
+};

-   gpio_export {
-   compatible = "gpio-export";
-   #size-cells = <0>;
+ {
+   status = "okay";

-   enable-leds {
-   gpio-export,name = "enable-leds";
-   gpio-export,output = <1>;
-   gpios = < 10 GPIO_ACTIVE_HIGH>;
-   };
+   enable-leds {
+   gpio-hog;
+   line-name = "enable-leds";
+   gpios = <10 GPIO_ACTIVE_HIGH>;
+   output-high;
};
 };

diff --git a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
index 707bc1c3d3..7af90c6908 100644
--- a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
+++ b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
@@ -63,21 +63,17 @@
linux,default-trigger = "usbport";
};
};
-
-   gpio_export {
-   compatible = "gpio-export";
-   #size-cells = <0>;
-
-   usb {
-   gpio-export,name = "usb";
-   gpio-export,output = <0>;
-   gpios = < 14 GPIO_ACTIVE_LOW>;
-   };
-   };
 };

  {
status = "okay";
+
+   usb {
+   gpio-hog;
+   line-name = "usb";
+   gpios = <14 GPIO_ACTIVE_LOW>;
+   output-low;
+   };
 };

  {
diff --git a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
index 26b23aa6d1..17ec47b9d5 100644
--- a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
+++ b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
@@ -61,21 +61,17 @@
linux,default-trigger = "usbport";
};
};
-
-   gpio_export {
-   compatible = "gpio-export";
-   #size-cells = <0>;
-
-   usb {
-   gpio-export,name = "usb";
-   gpio-export,output = <1>;
-   gpios = < 14 GPIO_ACTIVE_HIGH>;
-   };
-   };
 };

  {
status = "okay";
+
+   usb {
+   gpio-hog;
+   line-name = "usb";
+   gpios = <14 GPIO_ACTIVE_HIGH>;
+   output-high;
+   };
 };

  {
diff --git a/target/linux/ramips/dts/mt7620a_dovado_tiny-ac.dts
b/target/linux/ramips/dts/mt7620a_dovado_tiny-ac.dts
index e36af1dc7f..acb3524e3d 100644
--- a/target/linux/ramips/dts/mt7620a_dovado_tiny-ac.dts
+++ b/target/linux/ramips/dts/mt7620a_dovado_tiny-ac.dts
@@ -39,16 +39,16 @@
linux,code = ;
};
};
+};

-   gpio_export {
-   compatible = "gpio-export";
-   #size-cells = <0>;
+ {
+   status = "okay";

-   usbpower {
-   gpio-export,name = "usbpower";
-   gpio-export,output = <1>;
-   gpios = < 5 GPIO_ACTIVE_HIGH>;
-   };
+   usbpower {
+   gpio-hog;
+   line-name = "usbpower";
+   gpios = <5 GPIO_ACTIVE_HIGH>;
+   output-high;
};
 };

@@ -56,10 +56,6 @@
status = "okay";
 };

- {
-   status = "okay";
-};
-
  {
status = "okay";
 };
diff --git a/target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts
b/target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts
index 5c90aa1549..d329c3380c 100644
--- a/target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts
+++ b/target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts
@@ -66,22 +66,17 @@
linux,default-trigger = "usbport";
 

Re: [OpenWrt-Devel] [PATCH v3] ramips: add Asus RT-AC85P

[Birger Koblitz]

Hi,

On 23.08.19 11:04, Gábor Varga wrote:
> Hi!
>
> Although it looks like the Asus RT-AC85P and the Asus RT-AC65P models
> are identical, but I have separated them into two dts and have
> introduced the HW version into the names (for the new versions in the
> future).

Are you sure that is necessary? AFAIK there are no different versions of
the routers around and Asus seems to have a policy of constantly
churning out new router models without upgrading existing routers to new
revisions.


>
> I have an alternative installation method via SSH:
>
> Note: The user/password for SSH is identical with the one used in the
> Web-interface.
>
> 1. Complete the initial setup wizard.
> 2. Activate SSH under "Administration" -> "System".
> 3. Transfer the OpenWrt factory image via scp:
>  > scp openwrt-ramips-mt7621-asus_rt-ac65p-r01-squashfs-factory.bin
> admin@192.168.50.1:/tmp
> 4. Connect via SSH to the router.
>  > ssh admin@192.168.50.1 
> 5. Write the OpenWrt image to flash.
>  > mtd-write -i
> /tmp/openwrt-ramips-mt7621-asus_rt-ac65p-r01-squashfs-factory.bin -d linux
> 6. Reboot the router
>  > reboot
>
> Another thing: I don't know, if it's good method to replace the second
> firmware partition with OpenWrt image during sysupgrade. When we don't
> do that, than we have always a factory firmware on the secondary
> firmware partition, so the back to the factory firmware would be much
> easier.

I don't have a strong opinion on this. Both ways have their advantages.
If during sysupgrade both copies of the FW are written, then this is
consistent with the original software's behavior and additionally, the
outcome is independent of the OpenWRT initial installation method. When
using tftp (or the Web-GUI should someone figure out the exact format)
both copies are written, only ssh and serial port allow to install only
one copy. Not copying over the previous OpenWRT image to the second
partition during sysupgrade allows having a copy of the factory firmware
around (but which needs to be written to the first partition again to be
booted).

Cheers,

  Birger




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v5] ramips: add support for Edimax RG21S

[Birger Koblitz]

ramips: add support for Edimax RG21S

SoC:MediaTek MT7621AT dual-core @ 880MHz
RAM:256M (Nanya NT5CC128M)
FLASH:  16MB (Macronix MX25L12835F)
WiFi:   - 2.4GHz MediaTek MT7615N bgn
- 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:No
BTN:Reset, WPS
LED:4 red LEDs, indistinguishable when casing closed
UART:   UART is present as Pads marked J1 on the PCB.
3.3V - RX - GND - TX / 57600-8N1
3.3V is the square pad

Installation

Update the factory image via the OEM web-interface
(by default:http://192.168.1.1)
The sysupgrade image can be installed via TFTP from
the U-Boot bootloader. Connect ethernet port 2.

Signed-off-by: Birger Koblitz 

---

v3: Update to DEVICE_VENDOR / DEVICE_MODEL in mt7621.mk
renamed .dts according to new conventions
Removed memory node from .dts
Correct image size
Whitespace fixes
v4: Added wifi0/1 labels to wifi nodes
Model name corrected in dts
Comments removed from .dts
v5: Corrected MT7615N PCI IDs
Unnecessary kernel-modules removed from image

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index c0de9d4e50..91685508db 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -336,6 +336,10 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan" "4:wan" "6@eth0"
;;
+   edimax,rg21s)
+   ucidef_add_switch "switch0" \
+   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+   ;;
gehua,ghl-r-001)
ucidef_add_switch "switch0" \
"0:lan" "1:lan" "2:lan" "4:wan" "6@eth0"
@@ -594,6 +598,10 @@ ramips_setup_macs()
edimax,br-6478ac-v2)
wan_mac=$(macaddr_add "$(cat /sys/class/net/eth0/address)" 2)
;;
+   edimax,rg21s)
+   lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
+   wan_mac=$(mtd_get_mac_ascii u-boot-env wanaddr)
+   ;;
elecom,wrc-1167ghbk2-s|\
elecom,wrc-1900gst|\
elecom,wrc-2533gst|\
diff --git a/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
new file mode 100644
index 00..dfccae102b
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "edimax,rg21s", "mediatek,mt7621-soc";
+   model = "Edimax RG21S";
+
+   aliases {
+   led-boot = _power;
+   led-failsafe = _power;
+   led-running = _power;
+   led-upgrade = _power;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   palmbus: palmbus@1E00 {
+   i2c@900 {
+   status = "okay";
+   };
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   gpios = < 16 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   wps {
+   label = "wps";
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: led_1 {
+   label = "rg21s:red:led1";
+   gpios = < 7 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_2 {
+   label = "rg21s:red:led2";
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_3 {
+   label = "rg21s:red:led3";
+   gpios = < 14 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_4 {
+   label = "rg21s:red:led4";
+   gpios = < 15 GPIO_ACTIVE_HIGH>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   m25p80@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1

[OpenWrt-Devel] [PATCH v5] ramips: add support for Edimax RG21S

[Birger Koblitz]

ramips: add support for Asus RT-AC85P

SoC:MediaTek MT7621AT dual-core @ 880MHz
RAM:256M (Winbond W632GG6KB-1)
FLASH:  128MB (Macronix MX30LF1G18AC-TI)
WiFi:   - 2.4GHz MediaTek MT7615N bgn
- 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:1 x USB 3.1 (Gen 1)
BTN:Reset, WPS
LED:- Power (blue)
- 5Ghz (blue)
- 2.4GHz (blue)
- Internet (blue)
- 4x LAN (blue)
(LAN/WAN leds are not controllable by GPIOs)
UART:   UART is present as Pads marked J4 on the PCB.
3.3V - TX - RX - GND / 57600-8N1
3.3V is the square pad
MAC:The MAC address on the router-label matches the MAC of
the 2.4 GHz WiFi.
LAN and WAN MAC are identical: MAC_LABEL+4
5 GHz WiFi MAC: also MAC_LABEL+4


Installation

Via U-Boot tftpd:
Switch on device, within 2s press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.

The images also work on the Asus RT-AC65P models as tested by Gabor.

Signed-off-by: Birger Koblitz 
Tested-by: Gabor Varga 

---

v2: Corrected sorting of entries in 02_network
Model name corrected in .dts
Whitespace fixes in .dts
wifi0/1 labels added to wifi nodes in .dts
Device name capitalized in mt7621.mk

v3: Added firmware backup to firmware2 partition before sysupgrade
Corrected modules included in image

v4: Corrected MT7615N PCI IDs

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index c0de9d4e50..91685508db 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -336,6 +336,10 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan" "4:wan" "6@eth0"
;;
+   edimax,rg21s)
+   ucidef_add_switch "switch0" \
+   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+   ;;
gehua,ghl-r-001)
ucidef_add_switch "switch0" \
"0:lan" "1:lan" "2:lan" "4:wan" "6@eth0"
@@ -594,6 +598,10 @@ ramips_setup_macs()
edimax,br-6478ac-v2)
wan_mac=$(macaddr_add "$(cat /sys/class/net/eth0/address)" 2)
;;
+   edimax,rg21s)
+   lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
+   wan_mac=$(mtd_get_mac_ascii u-boot-env wanaddr)
+   ;;
elecom,wrc-1167ghbk2-s|\
elecom,wrc-1900gst|\
elecom,wrc-2533gst|\
diff --git a/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
new file mode 100644
index 00..dfccae102b
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "edimax,rg21s", "mediatek,mt7621-soc";
+   model = "Edimax RG21S";
+
+   aliases {
+   led-boot = _power;
+   led-failsafe = _power;
+   led-running = _power;
+   led-upgrade = _power;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   palmbus: palmbus@1E00 {
+   i2c@900 {
+   status = "okay";
+   };
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   gpios = < 16 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   wps {
+   label = "wps";
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: led_1 {
+   label = "rg21s:red:led1";
+   gpios = < 7 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_2 {
+   label = "rg21s:red:led2";
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_3 {
+   label = "rg21s:red:led3";
+   gpios = < 14 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_4 {
+   label = "rg21s:red:led4";
+   gpios = &

[OpenWrt-Devel] [PATCH v4] ramips: add support for Asus RT-AC85P

[Birger Koblitz]

ramips: add support for Asus RT-AC85P

SoC:MediaTek MT7621AT dual-core @ 880MHz
RAM:256M (Winbond W632GG6KB-1)
FLASH:  128MB (Macronix MX30LF1G18AC-TI)
WiFi:   - 2.4GHz MediaTek MT7615N bgn
- 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:1 x USB 3.1 (Gen 1)
BTN:Reset, WPS
LED:- Power (blue)
- 5Ghz (blue)
- 2.4GHz (blue)
- Internet (blue)
- 4x LAN (blue)
(LAN/WAN leds are not controllable by GPIOs)
UART:   UART is present as Pads marked J4 on the PCB.
3.3V - TX - RX - GND / 57600-8N1
3.3V is the square pad
MAC:The MAC address on the router-label matches the MAC of
the 2.4 GHz WiFi.
LAN and WAN MAC are identical: MAC_LABEL+4
5 GHz WiFi MAC: also MAC_LABEL+4


Installation

Via U-Boot tftpd:
Switch on device, within 2s press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.

The images also work on the Asus RT-AC65P models as tested by Gabor.

Signed-off-by: Birger Koblitz 
Tested-by: Gabor Varga 

---

v2: Corrected sorting of entries in 02_network
Model name corrected in .dts
Whitespace fixes in .dts
wifi0/1 labels added to wifi nodes in .dts
Device name capitalized in mt7621.mk

v3: Added firmware backup to firmware2 partition before sysupgrade
Corrected modules included in image

v4: Corrected MT7615N PCI IDs

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index 2f9a02256e..ab90041d92 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -231,6 +231,17 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan" "1:wan" "6@eth0"
;;
+   asus,rt-ac85p|\
+   dlink,dir-860l-b1|\
+   elecom,wrc-1167ghbk2-s|\
+   elecom,wrc-1900gst|\
+   elecom,wrc-2533gst|\
+   huawei,hg255d|\
+   iodata,wn-ax1167gr|\
+   iodata,wn-gx300gr)
+   ucidef_add_switch "switch0" \
+   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+   ;;
asus,rt-n15|\
belkin,f9k1109v1|\
sitecom,wl-351)
@@ -298,16 +309,6 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5" 
"6@eth0"
;;
-   dlink,dir-860l-b1|\
-   elecom,wrc-1167ghbk2-s|\
-   elecom,wrc-1900gst|\
-   elecom,wrc-2533gst|\
-   huawei,hg255d|\
-   iodata,wn-ax1167gr|\
-   iodata,wn-gx300gr)
-   ucidef_add_switch "switch0" \
-   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
-   ;;
dlink,dwr-118-a1)
ucidef_add_switch "switch0" \
"1:lan:2" "2:lan:3" "3:lan:1" "4:lan:0" "5:wan" "6@eth0"
@@ -531,6 +532,9 @@ ramips_setup_macs()
lan_mac=$(mtd_get_mac_binary factory 57344)
wan_mac=$(mtd_get_mac_binary factory 57350)
;;
+   asus,rt-ac85p)
+   wan_mac=$(mtd_get_mac_ascii u-boot-env et1macaddr)
+   ;;
asus,rt-n56u)
lan_mac=$(macaddr_setbit_la "$(cat 
/sys/class/net/eth0/address)")
wan_mac=$(mtd_get_mac_binary factory 32772)
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index a65492a309..cd9d8ae650 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -18,9 +18,16 @@ platform_do_upgrade() {
mikrotik,rbm33g)
[ -z "$(rootfs_type)" ] && mtd erase firmware
;;
+   asus,rt-ac85p)
+   echo "Backing up firmware"
+   dd if=/dev/mtd4 bs=1024 count=4096  > /tmp/backup_firmware.bin
+   dd if=/dev/mtd5 bs=1024 count=52224 >> /tmp/backup_firmware.bin
+   mtd -e firmware2 write /tmp/backup_firmware.bin firmware2
+   ;;
esac

case "$board" in
+   asus,rt-ac85p|\
hiwifi,hc5962|\
netgear,r6220|\
netgear,r6350|\
diff --git a/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
b/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
new file mode 100644
index 0

[OpenWrt-Devel] [PATCH v5] ramips: add support for Edimax RG21S

[Birger Koblitz]

ramips: add Edimax RG21S

SoC:    MediaTek MT7621AT dual-core @ 880MHz
RAM:    256M (Nanya NT5CC128M)
FLASH:    16MB (Macronix MX25L12835F)
WiFi:    - 2.4GHz MediaTek MT7615N bgn
    - 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:    No
BTN:    Reset, WPS
LED:    4 red LEDs, indistinguishable when casing closed
UART:     UART is present as Pads marked J1 on the PCB.
    3.3V - RX - GND - TX / 57600-8N1
    3.3V is the square pad

Installation

Update the factory image via the OEM web-interface
(by default:http://192.168.1.1)
The sysupgrade image can be installed via TFTP from
the U-Boot bootloader. Connect ethernet port 2.

Signed-off-by: Birger Koblitz 

---

v3: Update to DEVICE_VENDOR / DEVICE_MODEL in mt7621.mk
    renamed .dts according to new conventions
    Removed memory node from .dts
    Correct image size
    Whitespace fixes
v4: Added wifi0/1 labels to wifi nodes
    Model name corrected in dts
    Comments removed from .dts
v5: Corrected MT7615N PCI IDs
    Unnecessary kernel-modules removed from image

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index c0de9d4e50..91685508db 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -336,6 +336,10 @@ ramips_setup_interfaces()
     ucidef_add_switch "switch0" \
         "0:lan" "4:wan" "6@eth0"
     ;;
+    edimax,rg21s)
+        ucidef_add_switch "switch0" \
+            "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+        ;;
 gehua,ghl-r-001)
     ucidef_add_switch "switch0" \
         "0:lan" "1:lan" "2:lan" "4:wan" "6@eth0"
@@ -594,6 +598,10 @@ ramips_setup_macs()
 edimax,br-6478ac-v2)
     wan_mac=$(macaddr_add "$(cat /sys/class/net/eth0/address)" 2)
     ;;
+    edimax,rg21s)
+        lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
+        wan_mac=$(mtd_get_mac_ascii u-boot-env wanaddr)
+        ;;
 elecom,wrc-1167ghbk2-s|\
 elecom,wrc-1900gst|\
 elecom,wrc-2533gst|\
diff --git a/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
new file mode 100644
index 00..dfccae102b
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+    compatible = "edimax,rg21s", "mediatek,mt7621-soc";
+    model = "Edimax RG21S";
+
+    aliases {
+        led-boot = _power;
+        led-failsafe = _power;
+        led-running = _power;
+        led-upgrade = _power;
+    };
+
+    chosen {
+        bootargs = "console=ttyS0,57600";
+    };
+
+    palmbus: palmbus@1E00 {
+        i2c@900 {
+            status = "okay";
+        };
+    };
+
+    keys {
+        compatible = "gpio-keys";
+
+        reset {
+            label = "reset";
+            gpios = < 16 GPIO_ACTIVE_LOW>;
+            linux,code = ;
+        };
+
+        wps {
+            label = "wps";
+            gpios = < 18 GPIO_ACTIVE_LOW>;
+            linux,code = ;
+        };
+    };
+
+    leds {
+        compatible = "gpio-leds";
+
+        led_power: led_1 {
+            label = "rg21s:red:led1";
+            gpios = < 7 GPIO_ACTIVE_HIGH>;
+        };
+
+        led_2 {
+            label = "rg21s:red:led2";
+            gpios = < 12 GPIO_ACTIVE_HIGH>;
+        };
+
+        led_3 {
+            label = "rg21s:red:led3";
+            gpios = < 14 GPIO_ACTIVE_HIGH>;
+        };
+
+        led_4 {
+            label = "rg21s:red:led4";
+            gpios = < 15 GPIO_ACTIVE_HIGH>;
+        };
+    };
+};
+
+ {
+    status = "okay";
+};
+
+ {
+    status = "okay";
+
+    m25p80@0 {
+        compatible = "jedec,spi-nor";
+        reg = <0>;
+        spi-max-frequency = <1000>;
+
+        partitions {
+            compatible = "fixed-partitions";
+            #address-cells = <1>;
+            #size-cells = <1>;
+
+            partition@0 {
+                label = "u-boot";
+                reg = <0x0 0x3>;
+                read-only;
+            };
+
+            partition@3 {
+                label = "u-boot-env";
+                reg = <0x3 0x1>;
+                read-only;
+            };
+
+            factory: partition@4 {
+                label = "factory";
+                reg = <0x4 0x1>;
+                read-only;
+  

Re: [OpenWrt-Devel] [PATCH v4] ramips: add support for Edimax RG21S

[Birger Koblitz]

Dear Daniel,

thanks for spotting this. Indeed, the correct PCI device-id of the
MT7615N is 7615. 

Interestingly, the kernel module did not care. I'll submit a new v5
patch for the Edimax RG21S and also a new patch for the ASUS RT-AC85p
where I made the same mistake.

Birger


On 22.08.19 16:47, Daniel Golle wrote:
> Hi,
>
> I believe the PCI-IDs of the devices in your device tree are wrong,
> see below:
>
> On Sun, Jul 21, 2019 at 07:43:51AM +0200, Birger Koblitz wrote:
>> ramips: add Edimax RG21S
>>
>> SoC: MediaTek MT7621AT dual-core @ 880MHz
>> RAM: 256M (Nanya NT5CC128M)
>> FLASH:   16MB (Macronix MX25L12835F)
>> WiFi:- 2.4GHz MediaTek MT7615N bgn
>>  - 5GHz MediaTek MT7615N nac
>> Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
>> USB: No
>> BTN: Reset, WPS
>> LED: 4 red LEDs, indistinguishable when casing closed
>> UART:UART is present as Pads marked J1 on the PCB.
>>  3.3V - RX - GND - TX / 57600-8N1
>>  3.3V is the square pad
>>
>> Installation
>> 
>> Update the factory image via the OEM web-interface
>> (by default:http://192.168.1.1)
>> The sysupgrade image can be installed via TFTP from
>> the U-Boot bootloader. Connect ethernet port 2.
>>
>> Signed-off-by: Birger Koblitz 
>>
>> ---
>>
>> v3: Update to DEVICE_VENDOR / DEVICE_MODEL in mt7621.mk
>> renamed .dts according to new conventions
>> Removed memory node from .dts
>> Correct image size
>> Whitespace fixes
>> v4: Added wifi0/1 labels to wifi nodes
>> Model name corrected in dts
>> Comments removed from .dts
>>
>> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
>> b/target/linux/ramips/base-files/etc/board.d/02_network
>> index a2b7d1cf33..252d2f4e50 100755
>> --- a/target/linux/ramips/base-files/etc/board.d/02_network
>> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
>> @@ -329,6 +329,10 @@ ramips_setup_interfaces()
>>  ucidef_add_switch "switch1" \
>>  "1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "6@eth0"
>>  ;;
>> +edimax,rg21s)
>> +ucidef_add_switch "switch0" \
>> +"1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
>> +;;
>>  gehua,ghl-r-001)
>>  ucidef_add_switch "switch0" \
>>  "0:lan" "1:lan" "2:lan" "4:wan" "6@eth0"
>> @@ -587,6 +591,10 @@ ramips_setup_macs()
>>  lan_mac=$(cat /sys/class/net/eth0/address)
>>  wan_mac=$(macaddr_add "$lan_mac" 2)
>>  ;;
>> +edimax,rg21s)
>> +lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
>> +wan_mac=$(mtd_get_mac_ascii u-boot-env wanaddr)
>> +;;
>>  elecom,wrc-1167ghbk2-s|\
>>  elecom,wrc-1900gst|\
>>  elecom,wrc-2533gst|\
>> diff --git a/target/linux/ramips/dts/mt7621_edimax_rg21s.dts 
>> b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
>> new file mode 100644
>> index 00..80b644b7a7
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
>> @@ -0,0 +1,157 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>> +/dts-v1/;
>> +
>> +#include "mt7621.dtsi"
>> +
>> +#include 
>> +#include 
>> +
>> +/ {
>> +compatible = "edimax,rg21s", "mediatek,mt7621-soc";
>> +model = "Edimax RG21S";
>> +
>> +aliases {
>> +led-boot = _power;
>> +led-failsafe = _power;
>> +led-running = _power;
>> +led-upgrade = _power;
>> +};
>> +
>> +chosen {
>> +bootargs = "console=ttyS0,57600";
>> +};
>> +
>> +palmbus: palmbus@1E00 {
>> +i2c@900 {
>> +status = "okay";
>> +};
>> +};
>> +
>> +keys {
>> +compatible = "gpio-keys";
>> +
>> +reset {
>> +label = "reset";
>> +gpios = < 16 GPIO_ACTIVE_LOW>;
>> +linux,code = ;
>> +};
>> +
>> +wps {
>> +label = "wps

[OpenWrt-Devel] [PATCH v2] lantiq: use gpio_hog instead of gpio-export

[Birger Koblitz]

lantiq: use gpio_hog instead of gpio-export

The `gpio-export` functionality is a hack for
missing kernel functionality, which was rejected in upstream kernel long
time
ago, for details see this email
http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
discussion in PR#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.

This patch converts all remaining lantiq .dts(i) files which were
using export-gpio, not making use of the change-direction functionality
and not used from user-space to using gpio_hog instead

Signed-off-by: Birger Koblitz 

---

v2: - Not converting annexa/b export in DM200.dts
    - Not converting power_led_blink export in ASL56026.dts


diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/ARV7519PW.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/ARV7519PW.dts
index e9c418e482..571a142fa7 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/ARV7519PW.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/ARV7519PW.dts
@@ -108,17 +108,16 @@
         gpios = < 29 GPIO_ACTIVE_LOW>;
     };
 };
+};
 
-    /* is there another way to "reserve" the GPIO? */
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
+ {
+    status = "okay";
 
-        switch {
-            gpio-export,name = "switch";
-            gpio-export,output = <1>;
-            gpios = < 19 GPIO_ACTIVE_HIGH>;
-        };
+    switch {
+        gpio-hog;
+        line-name = "switch";
+        gpios = <19 GPIO_ACTIVE_HIGH>;
+        output-high;
 };
 };
 
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/GIGASX76X.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/GIGASX76X.dts
index a9a5cbae2f..6b4ab7f918 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/GIGASX76X.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/GIGASX76X.dts
@@ -28,17 +28,6 @@
     };
 };
 
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        switch {
-            gpio-export,name = "switch";
-            gpio-export,output = <1>;
-            gpios = < 19 GPIO_ACTIVE_HIGH>;
-        };
-    };
-
 usb_vbus: regulator-usb-vbus {
     compatible = "regulator-fixed";
 
@@ -52,6 +41,17 @@
 };
 };
 
+ {
+    status = "okay";
+
+    switch {
+        gpio-hog;
+        line-name = "switch";
+        gpios = <19 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
+};
+
  {
 pinctrl-names = "default";
 pinctrl-0 = <_default>;
@@ -64,10 +64,6 @@
 };
 };
 
- {
-    status = "okay";
-};
-
  {
 phy-mode = "rmii";
 };
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/H201L.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/H201L.dts
index 9b640e0327..fe0e5af0c1 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/H201L.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/H201L.dts
@@ -84,27 +84,6 @@
     };
 };
 
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        switch {
-            gpio-export,name = "switch";
-            gpio-export,output = <1>;
-            gpios = < 38 GPIO_ACTIVE_HIGH>;
-        };
-        usb {
-            gpio-export,name = "usb";
-            gpio-export,output = <1>;
-            gpios = < 28 GPIO_ACTIVE_HIGH>;
-        };
-        wifi {
-            gpio-export,name = "wifi";
-            gpio-export,output = <1>;
-            gpios = < 7 GPIO_ACTIVE_HIGH>;
-        };
-    };
-
 usb_vbus: regulator-usb-vbus {
     compatible = "regulator-fixed";
 
@@ -118,6 +97,31 @@
 };
 };
 
+ {
+    status = "okay";
+
+    switch {
+        gpio-hog;
+        line-name = "switch";
+        gpios = <38 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
+
+    usb {
+        gpio-hog;
+        line-name = "usb";
+        gpios = <28 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
+
+    wifi {
+        gpio-hog;
+        line-name = "wifi";
+        gpios = <7 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
+};
+
  {
 pinctrl-names = "default";
 pinctrl-0 = <_default>;
@@ -165,7 +169,6 @@
 status = "okay";
 };
 
-
  {
 status = "okay";
 vbus-supply = <_vbus>;
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/P2601HNFX.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/P2601HNFX.dts
index 62e5e70169..9abc5745e4 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/P2601HNFX.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/P2601HNFX.dts
@@ -85,16 +85,16 @@
         gpios = < 10 GPIO_ACTIVE_LOW>;
     };
 };
+};
 
-   

Re: [OpenWrt-Devel] [PATCH] ath79: use gpio_hog instead of gpio-export

[Birger Koblitz]

Hi Adrian,

On 11.08.19 21:15, m...@adrianschmutzler.de wrote:
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
>> On Behalf Of Birger Koblitz
>> Sent: Sonntag, 11. August 2019 13:11
>> To: m...@adrianschmutzler.de
>> Cc: 'OpenWrt Development List' 
>> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: use gpio_hog instead of gpio-
>> export
>>
>> Dear Adrian,
>>
>> I'll resubmit a patch taking your comments into account. I am using a script
>> that parses the DTS ...
> So that means that duplicate  is also treated with automatically (as 
> I've seen with some devices)?

The script is able to catch some cases, others are not so easy. I
believe there is a case where the original .dts already has duplicates.

Also the idea was to keep the sequence of the gpios definitions in the
original .dts.

If the original dts moves from chip 0 to chip 1 and back to chip 0 with
the definition of gpios being exported, then this will give duplicates
for gpio0 at the moment.

I could sort the gpios so that it is guaranteed that there are no
duplicate gpio definitions but this would destroy the original authors
intention as to which gpio belongs to which other one. 

>
>> This should also prevent the double naming of the nodes. I am actually
>> surprised the DTS compiler did not complain... Things like
>>
>> -    compatible = "yuncore,a770", "qca,qca9531";
>> +    compatible = "yuncore,a770", "qca,qca9533";
>>
>> are probably due to trailing white-space in the original, I'll stop the 
>> script from
>> touching that.
> Well, in this particular case it was not only whitespace, but the qca 
> changing from 9531 to 9533...

Ouch, this was an accident with commit
5e9086b7b11976ba75014b257139ddc4b2885a8a

don't know how I messed that up...

>
>
> Adrian

Thanks for the comments,

  Birger


As an afterthought, here comes the current script, I know that it is
ugly, but it shows what is done and how:

#!/usr/bin/ruby
unless ARGV.length == 1
  puts "Usage: convertHog.rb "
  exit
end

line_num = 0
in_root = 0
in_export = false
in_node = false
in_comment = false
last_empty = false
in_node_comment = false
node = -1
node_name = Array.new
node_output = Array.new
node_is_output = Array.new
node_chip = Array.new
node_num = Array.new
node_active = Array.new
node_comment = Array.new
node_prefix = Array.new
gpio_found = Array.new
gpio_stack = ""
remove_next_empty = false
DEBUG = false

f = File.open(ARGV[0])
f.each do |line|
  line_num += 1
  if line.match(/\/\s*\{/) then
    print "Found beginning\n" if DEBUG
    in_root += 1
    print "\n" if last_empty
    print "#{line}"
    last_empty = false
    next
  end
 
  if line.match(/{/) then
    in_root +=1
  end
 
  if line.match(/}/) then
    in_root -=1
  end
 
  if line.match(/^\s*$/) then
    print "last empty\n" if DEBUG
    if not remove_next_empty then
  last_empty = true
  next
    end
  end
   
 
  print "#{line_num} root #{in_root} " if DEBUG
 
  if (in_root > 0) and line.match(/gpio[_\-]export\s*\{/) then
    print "Found export\n" if DEBUG
    in_export = true
    next
  end
 
  if in_export then
    last_empty = false
   
    if not in_node then
  if line.match(/^\s*\/\*\s*$/) then
    in_comment = true;
  end
  if line.match(/^\s*\*\/\s*$/) then
    in_comment = false;
    print "#{line}"
    next
  end
    end
   
    if in_comment then
  print "#{line}"
  next
    end
   
    if line.match(/\w+\s*\{/)
  print "Found node\n" if DEBUG
  in_node = true;
  node += 1
    end
 
    if line.match(/\}\s*;/) then
  if in_node
    in_node = false
  else
    in_export = false
  end
    end
   
    if in_node then
  line.match(/gpio\-export,name\s*=\s*"([\w\d\-:]+:)?([\w\d\-]+)"/)
{ |m|
    if m.length == 2 then
  print "Found export #{m[1]}\n" if DEBUG
  node_name[node] = m[1]
    else
  print "Found export #{m[2]}\n"  if DEBUG
  node_name[node] = m[2]
  node_prefix[node] = m[1]
    end
  }
  line.match(/gpio\-export,output\s*=\s*<(\d)>\s*;/) { |m|
    print "Found output #{m[1]}\n" if DEBUG
    node_output[node] = m[1]
    node_is_output[node] = true
  }
 
line.match(/gpios\s*\=\s*\<\(\d*)\s+(\d+)\s+GPIO_ACTIVE_(\w+)\s*\>\s*;/i)
{ |m|
    print "Found gpio #{m[1]}, #{m[2]}, #{m[3]}\n" if DEBUG
    node_chip[node] = m[1]
    node_num[node] = m[2]
    node_active[node] = m[3]
    gpio_found[m[1].to_i] = true
  }
  line.match(/\/\*(.*)\*\//){ |m|
    print "Found comme

Re: [OpenWrt-Devel] [PATCH] ramips: use gpio_hog instead of gpio-export

[Birger Koblitz]

Dear Martin and Enrico,

thanks for your comments.

On 11.08.19 13:38, Martin Blumenstingl wrote:
> On Sun, Aug 11, 2019 at 1:00 PM Birger Koblitz  wrote:
>> I'll go through the patches and remove anything that sounds like it
>> might need user space configuration (i.e. not power the USB bus or the
>> like).
> upstream GPIO maintainers prefer dedicated properties instead of a GPIO hog.
>
> some USB controller drivers support a "vbus-supply" property, which
> can be used together with a GPIO regulator
> in case of the VBUS supply it means the GPIO will be turned off if the
> USB port is "disabled" (for example by unloading the kernel USB
> controller driver).
>
> I'm not saying that you have to switch over to something other than GPIO hogs.
> switching to an upstream solution is a good starting point!
> just be aware that this may not be the final solution

this is understood. gpio-hog is only the second best solution, where
gpio-export is only the third best solution for the general case but in
some cases at the moment the only reasonable one.


>
>> Is anyone working on converting the use-cases which require user space
>> switching to libgpiod or any other solution?
> how do you identify the "use-cases which require use space switching"?

I believe this discussion has happened already, e.g. here:

https://github.com/openwrt/openwrt/pull/1366

and I don't think you need a final answer to this question in order to
start migrating to gpio_hog where it is easily possible.

@Enrico: It is clear that in some cases definitely we need to have a
possibility to manipulate gpios from user-space.


Cheers

   Birger



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ath79: use gpio_hog instead of gpio-export

[Birger Koblitz]

Dear Adrian,

I'll resubmit a patch taking your comments into account. I am using a
script that parses the DTS and I will use more of the original line-name
to name the node, i.e.

"tp-link:power:usb" -> power-usb
"tp-link:reset:sr"  -> reset-sr

This should also prevent the double naming of the nodes. I am actually
surprised the DTS compiler did not complain... Things like

-    compatible = "yuncore,a770", "qca,qca9531";
+    compatible = "yuncore,a770", "qca,qca9533";

are probably due to trailing white-space in the original, I'll stop the
script from touching that.

Cheers,

  Birger


On 10.08.19 22:20, m...@adrianschmutzler.de wrote:
> Hi,
>
>> +    usb {
>> +        gpio-hog;
>> +        line-name = "tp-link:power:usb";
>> +        gpios = <6 GPIO_ACTIVE_HIGH>;
>> +        output-high;
>>  };
>>  };
> As stated earlier, I would prefer calling those blocks usb-power, usb1-power, 
> etc..
>
>> diff --git a/target/linux/ath79/dts/qca9531_yuncore_a770.dts
>> b/target/linux/ath79/dts/qca9531_yuncore_a770.dts
>> index da5b6dc7db..18ad6307a1 100644
>> --- a/target/linux/ath79/dts/qca9531_yuncore_a770.dts
>> +++ b/target/linux/ath79/dts/qca9531_yuncore_a770.dts
>> @@ -8,7 +8,7 @@
>>
>>  / {
>>  model = "YunCore A770";
>> -    compatible = "yuncore,a770", "qca,qca9531";
>> +    compatible = "yuncore,a770", "qca,qca9533";
> This should be removed.
>
>> diff --git a/target/linux/ath79/dts/qca9561_tplink_archer-c5x.dtsi
>> b/target/linux/ath79/dts/qca9561_tplink_archer-c5x.dtsi
>> index 6d32fa3fc4..378c87c9ee 100644
>> --- a/target/linux/ath79/dts/qca9561_tplink_archer-c5x.dtsi
>> +++ b/target/linux/ath79/dts/qca9561_tplink_archer-c5x.dtsi
>> @@ -54,22 +54,23 @@
>>          gpios = < 21 GPIO_ACTIVE_LOW>;
>>      };
>>  };
>> +};
>>
>> -    gpio-export {
>> -        compatible = "gpio-export";
>> -
>> -        gpio_shift_register_oe {
>> -            gpio-export,name = "tp-link:oe:sr";
>> -            gpio-export,output = <0>;
>> -            gpios = < 16 GPIO_ACTIVE_HIGH>;
>> -        };
>> + {
>> +    status = "okay";
>>
>> -        gpio_shift_register_reset {
>> -            gpio-export,name = "tp-link:reset:sr";
>> -            gpio-export,output = <1>;
>> -            gpios = < 19 GPIO_ACTIVE_HIGH>;
>> -        };
>> +    sr {
>> +        gpio-hog;
>> +        line-name = "tp-link:oe:sr";
>> +        gpios = <16 GPIO_ACTIVE_HIGH>;
>> +        output-low;
>> +    };
>>
>> +    sr {
>> +        gpio-hog;
>> +        line-name = "tp-link:reset:sr";
>> +        gpios = <19 GPIO_ACTIVE_HIGH>;
>> +        output-high;
>>  };
> Those two should have different node names.
>
>> diff --git a/target/linux/ath79/dts/qca9563_tplink_archer-c7-v4.dts
>> b/target/linux/ath79/dts/qca9563_tplink_archer-c7-v4.dts
>> index f4add2fe31..d892d0e960 100644
>> --- a/target/linux/ath79/dts/qca9563_tplink_archer-c7-v4.dts
>> +++ b/target/linux/ath79/dts/qca9563_tplink_archer-c7-v4.dts
>> @@ -41,22 +41,6 @@
>>      };
>>  };
>>
>> -    gpio-export {
>> -        compatible = "gpio-export";
>> -
>> -        gpio_shift_register_oe {
>> -            gpio-export,name = "tp-link:oe:sr";
>> -            gpio-export,output = <0>;
>> -            gpios = < 1 GPIO_ACTIVE_LOW>;    // 74HC595 /OE (Output
>> Enable)
>> -        };
>> -
>> -        gpio_shift_register_reset {
>> -            gpio-export,name = "tp-link:reset:sr";
>> -            gpio-export,output = <1>;
>> -            gpios = < 21 GPIO_ACTIVE_LOW>;    // 74HC595 /SRCLR (Serial
>> Clear)
>> -        };
>> -    };
>> -
>>  leds {
>>      compatible = "gpio-leds";
>>
>> @@ -148,15 +132,29 @@
>>
>>  };
>>
>> - {
>> + {
>>  status = "okay";
>> +
>> +    sr {
>> +        gpio-hog;
>> +        line-name = "tp-link:oe:sr";
>> +        gpios = <1 GPIO_ACTIVE_LOW>;
>> +        output-low;
>> +    };
>> +
>> +    sr {
>> +        gpio-hog;
>> +        line-name = "tp-link:reset:sr";
>> +        gpios = <21 GPIO_ACTIVE_LOW>;
>> +        output-high;
>> +    };
>>  };
> Same here.
>
> Rest looks good, I haven't checked for duplicate  definitions (you seem 
> to have addressed some).
>
> Best
>
> Adrian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: use gpio_hog instead of gpio-export

[Birger Koblitz]

Dear Mathias and Piotr,

thank you for your comments. I had incorrectly assumed that a gpio_hog
could still be switched on/off from user space and that the only thing
not possible was changing the direction.

I'll go through the patches and remove anything that sounds like it
might need user space configuration (i.e. not power the USB bus or the
like).

Is anyone working on converting the use-cases which require user space
switching to libgpiod or any other solution?

Cheers,

  Birger


On 11.08.19 12:06, Piotr Dymacz wrote:
> Hi Mathias, Birger,
>
> On 11.08.2019 11:36, Mathias Kresin wrote:
>> 02/08/2019 11:58, Birger Koblitz:
>>> ramips: use gpio_hog instead of gpio-export
>>>
>>> The `gpio-export` functionality is a hack for
>>> missing kernel functionality, which was rejected in upstream kernel
>>> long
>>> time
>>> ago, for details see this email
>>> http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
>>>
>>> discussion in PR#1366 or
>>> https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.
>>>
>>> This patch converts all remaining ramips .dts(i) files which were
>>> using export-gpio and not making use of the change-direction
>>> functionality
>>> to using gpio_hog instead
>>>
>>> Signed-off-by: Birger Koblitz 
>>>
>>> ---
>>>
>>> diff --git a/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
>>> b/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
>>> index 4097dc6140..ea0d9801c1 100644
>>> --- a/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
>>> +++ b/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
>>> @@ -21,39 +21,6 @@
>>>       bootargs = "console=ttyS0,115200";
>>>   };
>>>   -    gpio-export {
>>> -        compatible = "gpio-export";
>>> -        #size-cells = <0>;
>>> -
>>> -        modem-enable {
>>> -            gpio-export,name = "modem-enable";
>>> -            gpio-export,output = <1>;
>>> -            gpios = < 12 GPIO_ACTIVE_HIGH>;
>>> -        };
>>> -
>>> -        modem-rf-enable {
>>> -            gpio-export,name = "modem-rf-enable";
>>> -            gpio-export,output = <1>;
>>> -            gpios = < 12 GPIO_ACTIVE_HIGH>;
>>> -        };
>>> -
>>> -        sim-select {
>>> -            gpio-export,name = "sim-select";
>>> -            gpio-export,output = <0>;
>>> -            gpios = < 13 GPIO_ACTIVE_HIGH>;
>>> -        };
>>> -
>>> -        sim1-detect {
>>> -            gpio-export,name = "sim1-detect";
>>> -            gpios = < 9 GPIO_ACTIVE_HIGH>;
>>> -        };
>>> -
>>> -        sim2-detect {
>>> -            gpio-export,name = "sim2-detect";
>>> -            gpios = < 1 GPIO_ACTIVE_HIGH>;
>>> -        };
>>> -    };
>>> -
>>
>> Hey Birger,
>>
>> similar to my comment for the lantiq version, this doesn't work as well.
>>
>> AFAIR, the Tube e4g has two sim card slots and the "sim-select" gpio is
>> supposed to be used from the userspace, to select which sim card slot
>> should be used.
>>
>> If we hog the gpio, it can't be manipulated from the userspace anymore.
>>
>> I haven't had a closer look at the patch. There might be similar issues
>> for other boards.
>>
>> @Piotr can confirm what I might to remember?
>
> Yes, you're correct.
>
> Also, the "modem-enable" should be available in user space as in case
> of some modems (without "SIM power down" feature support), only this
> approach works when changing SIM cards/slots:
>
> put the modem in reset -> switch SIM slot -> enable modem
>
> (still, there is a way to perform modem reset using AT command but
> IMHO it's not as convenient as toggling PERST# pin)
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v3] ramips: add Asus RT-AC85P

[Birger Koblitz]

ramips: add Asus RT-AC85P

SoC:    MediaTek MT7621AT dual-core @ 880MHz
RAM:    256M (Winbond W632GG6KB-1)
FLASH:    128MB (Macronix MX30LF1G18AC-TI)
WiFi:    - 2.4GHz MediaTek MT7615N bgn
    - 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:    1 x USB 3.1 (Gen 1)
BTN:    Reset, WPS
LED:    - Power (blue)
    - 5Ghz (blue)
    - 2.4GHz (blue)
    - Internet (blue)
    - 4x LAN (blue)
    (LAN/WAN leds are not controllable by GPIOs)
UART:     UART is present as Pads marked J4 on the PCB.
    3.3V - TX - RX - GND / 57600-8N1
    3.3V is the square pad
MAC:    The MAC address on the router-label matches the MAC of
    the 2.4 GHz WiFi.
    LAN and WAN MAC are identical: MAC_LABEL+4
    5 GHz WiFi MAC: also MAC_LABEL+4
   

Installation

Via U-Boot tftpd:
Switch on device, within 2s press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.

The images also work on the Asus RT-AC65P models as tested by Gabor.

Signed-off-by: Birger Koblitz 
Tested-by: Gabor Varga 

---

v2: Corrected sorting of entries in 02_network
    Model name corrected in .dts
    Whitespace fixes in .dts
    wifi0/1 labels added to wifi nodes in .dts
    Device name capitalized in mt7621.mk

v3: Added firmware backup to firmware2 partition before sysupgrade
    Corrected modules included in image

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index 2f9a02256e..ab90041d92 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -231,6 +231,17 @@ ramips_setup_interfaces()
     ucidef_add_switch "switch0" \
         "0:lan" "1:wan" "6@eth0"
     ;;
+    asus,rt-ac85p|\
+    dlink,dir-860l-b1|\
+    elecom,wrc-1167ghbk2-s|\
+    elecom,wrc-1900gst|\
+    elecom,wrc-2533gst|\
+    huawei,hg255d|\
+    iodata,wn-ax1167gr|\
+    iodata,wn-gx300gr)
+        ucidef_add_switch "switch0" \
+            "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+        ;;
 asus,rt-n15|\
 belkin,f9k1109v1|\
 sitecom,wl-351)
@@ -298,16 +309,6 @@ ramips_setup_interfaces()
     ucidef_add_switch "switch0" \
         "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5" "6@eth0"
     ;;
-    dlink,dir-860l-b1|\
-    elecom,wrc-1167ghbk2-s|\
-    elecom,wrc-1900gst|\
-    elecom,wrc-2533gst|\
-    huawei,hg255d|\
-    iodata,wn-ax1167gr|\
-    iodata,wn-gx300gr)
-        ucidef_add_switch "switch0" \
-            "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
-        ;;
 dlink,dwr-118-a1)
     ucidef_add_switch "switch0" \
         "1:lan:2" "2:lan:3" "3:lan:1" "4:lan:0" "5:wan" "6@eth0"
@@ -531,6 +532,9 @@ ramips_setup_macs()
     lan_mac=$(mtd_get_mac_binary factory 57344)
     wan_mac=$(mtd_get_mac_binary factory 57350)
     ;;
+    asus,rt-ac85p)
+        wan_mac=$(mtd_get_mac_ascii u-boot-env et1macaddr)
+        ;;
 asus,rt-n56u)
     lan_mac=$(macaddr_setbit_la "$(cat /sys/class/net/eth0/address)")
     wan_mac=$(mtd_get_mac_binary factory 32772)
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index a65492a309..cd9d8ae650 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -18,9 +18,16 @@ platform_do_upgrade() {
 mikrotik,rbm33g)
     [ -z "$(rootfs_type)" ] && mtd erase firmware
     ;;
+   asus,rt-ac85p)
+        echo "Backing up firmware"
+        dd if=/dev/mtd4 bs=1024 count=4096  > /tmp/backup_firmware.bin
+        dd if=/dev/mtd5 bs=1024 count=52224 >> /tmp/backup_firmware.bin
+        mtd -e firmware2 write /tmp/backup_firmware.bin firmware2
+        ;;
 esac
 
 case "$board" in
+    asus,rt-ac85p|\
 hiwifi,hc5962|\
 netgear,r6220|\
 netgear,r6350|\
diff --git a/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
b/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
new file mode 100644
index 00..7aea207fad
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+    compatible = "asus,rt-ac85p", "mediatek,mt7621-soc";
+    model = "Asus RT-AC85P";
+
+    aliases {
+        led-boot = _p

[OpenWrt-Devel] [PATCH] ramips: use gpio_hog instead of gpio-export

[Birger Koblitz]

ramips: use gpio_hog instead of gpio-export

The `gpio-export` functionality is a hack for
missing kernel functionality, which was rejected in upstream kernel long
time
ago, for details see this email
http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
discussion in PR#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.

This patch converts all remaining ramips .dts(i) files which were
using export-gpio and not making use of the change-direction functionality
to using gpio_hog instead

Signed-off-by: Birger Koblitz 

---

diff --git a/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
b/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
index 4097dc6140..ea0d9801c1 100644
--- a/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
+++ b/target/linux/ramips/dts/mt7620a_alfa-network_tube-e4g.dts
@@ -21,39 +21,6 @@
     bootargs = "console=ttyS0,115200";
 };
 
-    gpio-export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        modem-enable {
-            gpio-export,name = "modem-enable";
-            gpio-export,output = <1>;
-            gpios = < 12 GPIO_ACTIVE_HIGH>;
-        };
-
-        modem-rf-enable {
-            gpio-export,name = "modem-rf-enable";
-            gpio-export,output = <1>;
-            gpios = < 12 GPIO_ACTIVE_HIGH>;
-        };
-
-        sim-select {
-            gpio-export,name = "sim-select";
-            gpio-export,output = <0>;
-            gpios = < 13 GPIO_ACTIVE_HIGH>;
-        };
-
-        sim1-detect {
-            gpio-export,name = "sim1-detect";
-            gpios = < 9 GPIO_ACTIVE_HIGH>;
-        };
-
-        sim2-detect {
-            gpio-export,name = "sim2-detect";
-            gpios = < 1 GPIO_ACTIVE_HIGH>;
-        };
-    };
-
 keys {
     compatible = "gpio-keys";
 
@@ -98,26 +65,61 @@
 };
 };
 
- {
+ {
 status = "okay";
-};
 
- {
-    mtd-mac-address = < 0x28>;
+    modem-enable {
+        gpio-hog;
+        line-name = "modem-enable";
+        gpios = <12 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
 };
 
  {
 status = "okay";
+
+    modem-rf-enable {
+        gpio-hog;
+        line-name = "modem-rf-enable";
+        gpios = <12 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
+
+    sim-select {
+        gpio-hog;
+        line-name = "sim-select";
+        gpios = <13 GPIO_ACTIVE_HIGH>;
+        output-low;
+    };
+
+    sim1-detect {
+        gpio-hog;
+        line-name = "sim1-detect";
+        gpios = <9 GPIO_ACTIVE_HIGH>;
+        input;
+    };
 };
 
- {
+ {
 status = "okay";
+
+    sim2-detect {
+        gpio-hog;
+        line-name = "sim2-detect";
+        gpios = <1 GPIO_ACTIVE_HIGH>;
+        input;
+    };
 };
 
- {
+ {
 status = "okay";
 };
 
+ {
+    mtd-mac-address = < 0x28>;
+};
+
  {
 mediatek,port4 = "ephy";
 };
diff --git a/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
b/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
index 3e54ffdad2..c573b38284 100644
--- a/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
+++ b/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
@@ -53,16 +53,16 @@
         linux,code = ;
     };
 };
+};
 
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
+ {
+    status = "okay";
 
-        enable-leds {
-            gpio-export,name = "enable-leds";
-            gpio-export,output = <1>;
-            gpios = < 10 GPIO_ACTIVE_HIGH>;
-        };
+    enable-leds {
+        gpio-hog;
+        line-name = "enable-leds";
+        gpios = <10 GPIO_ACTIVE_HIGH>;
+        output-high;
 };
 };
 
diff --git a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
index 707bc1c3d3..7af90c6908 100644
--- a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
+++ b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
@@ -63,21 +63,17 @@
         linux,default-trigger = "usbport";
     };
 };
-
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        usb {
-            gpio-export,name = "usb";
-            gpio-export,output = <0>;
-            gpios = < 14 GPIO_ACTIVE_LOW>;
-        };
-    };
 };
 
  {
 status = "okay";
+
+    usb {
+        gpio-hog;
+        line-name = "usb";
+        gpios = <14 GPIO_ACTIVE_LOW>;
+        output-low;
+    };
 };
 
  {
diff --git a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
index 26b23aa6d1..17ec47b9d5 10064

[OpenWrt-Devel] [PATCH] lantiq: use gpio_hog instead of gpio-export

[Birger Koblitz]

lantiq: use gpio_hog instead of gpio-export

The `gpio-export` functionality is a hack for
missing kernel functionality, which was rejected in upstream kernel long
time
ago, for details see this email
http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
discussion in PR#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.

This patch converts all remaining lantiq .dts(i) files which were
using export-gpio and not making use of the change-direction functionality
to using gpio_hog instead

Signed-off-by: Birger Koblitz 

---

diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/ARV7519PW.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/ARV7519PW.dts
index e9c418e482..c597febeeb 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/ARV7519PW.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/ARV7519PW.dts
@@ -110,15 +110,16 @@
 };
 
 /* is there another way to "reserve" the GPIO? */
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
+};
 
-        switch {
-            gpio-export,name = "switch";
-            gpio-export,output = <1>;
-            gpios = < 19 GPIO_ACTIVE_HIGH>;
-        };
+ {
+    status = "okay";
+
+    switch {
+        gpio-hog;
+        line-name = "switch";
+        gpios = <19 GPIO_ACTIVE_HIGH>;
+        output-high;
 };
 };
 
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/ASL56026.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/ASL56026.dts
index 1c7f03c355..5d801d14ec 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/ASL56026.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/ASL56026.dts
@@ -58,16 +58,16 @@
         gpios = < 18 GPIO_ACTIVE_HIGH>;
     };
 };
+};
 
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
+ {
+    status = "okay";
 
-        power_led_blink {
-            gpio-export,name = "power_led_blink";
-            gpio-export,output = <0>;
-            gpios = < 16 GPIO_ACTIVE_LOW>;
-        };
+    power_led_blink {
+        gpio-hog;
+        line-name = "power_led_blink";
+        gpios = <16 GPIO_ACTIVE_LOW>;
+        output-low;
 };
 };
 
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/DM200.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/DM200.dts
index 4796123c20..0b21b67504 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/DM200.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/DM200.dts
@@ -37,22 +37,6 @@
     };
 };
 
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        annexa {
-            gpio-export,name = "annexa";
-            gpio-export,output = <0>;
-            gpios = < 12 GPIO_ACTIVE_HIGH>;
-        };
-        annexb {
-            gpio-export,name = "annexb";
-            gpio-export,output = <0>;
-            gpios = < 15 GPIO_ACTIVE_HIGH>;
-        };
-    };
-
 leds {
     compatible = "gpio-leds";
 
@@ -85,6 +69,24 @@
 };
 };
 
+ {
+    status = "okay";
+
+    annexa {
+        gpio-hog;
+        line-name = "annexa";
+        gpios = <12 GPIO_ACTIVE_HIGH>;
+        output-low;
+    };
+
+    annexb {
+        gpio-hog;
+        line-name = "annexb";
+        gpios = <15 GPIO_ACTIVE_HIGH>;
+        output-low;
+    };
+};
+
  {
 lantiq,phys = <>;
 
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/GIGASX76X.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/GIGASX76X.dts
index a9a5cbae2f..6b4ab7f918 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/GIGASX76X.dts
+++ b/target/linux/lantiq/files/arch/mips/boot/dts/GIGASX76X.dts
@@ -28,17 +28,6 @@
     };
 };
 
-    gpio_export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        switch {
-            gpio-export,name = "switch";
-            gpio-export,output = <1>;
-            gpios = < 19 GPIO_ACTIVE_HIGH>;
-        };
-    };
-
 usb_vbus: regulator-usb-vbus {
     compatible = "regulator-fixed";
 
@@ -52,6 +41,17 @@
 };
 };
 
+ {
+    status = "okay";
+
+    switch {
+        gpio-hog;
+        line-name = "switch";
+        gpios = <19 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
+};
+
  {
 pinctrl-names = "default";
 pinctrl-0 = <_default>;
@@ -64,10 +64,6 @@
 };
 };
 
- {
-    status = "okay";
-};
-
  {
 phy-mode = "rmii";
 };
diff --git a/target/linux/lantiq/files/arch/mips/boot/dts/H201L.dts
b/target/linux/lantiq/files/arch/mips/boot/dts/H201L.dts
index 9b640e0327..fe0e5af0c1 100644
--- a/target/linux/lantiq/files/arch/mips/boot/dts/H201L.dts
+++ b/target/lin

[OpenWrt-Devel] [PATCH] ath79: use gpio_hog instead of gpio-export

[Birger Koblitz]

ath79: use gpio_hog instead of gpio-export

The `gpio-export` functionality is a hack for
missing kernel functionality, which was rejected in upstream kernel long
time
ago, for details see this email
http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
discussion in PR#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.

This patch converts all remaining ath79 .dts files which were
using export-gpio to using gpio_hog instead

Signed-off-by: Birger Koblitz 

---

diff --git a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
index df22eb8dc4..822858aab7 100644
--- a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
+++ b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dts
@@ -121,16 +121,6 @@
     };
 };
 
-    gpio-export {
-        compatible = "gpio-export";
-
-        gpio_usb_power {
-            gpio-export,name = "buffalo:power:usb";
-            gpio-export,output = <1>;
-            gpios = < 2 GPIO_ACTIVE_HIGH>;
-        };
-    };
-
 flash {
     compatible = "mtd-concat";
 
@@ -173,6 +163,17 @@
 };
 };
 
+ {
+    status = "okay";
+
+    usb {
+        gpio-hog;
+        line-name = "buffalo:power:usb";
+        gpios = <2 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
+};
+
 _phy {
 status = "okay";
 };
diff --git a/target/linux/ath79/dts/ar7241_tplink_tl-mr3x20.dtsi
b/target/linux/ath79/dts/ar7241_tplink_tl-mr3x20.dtsi
index 04403637b6..de0deb3f3c 100644
--- a/target/linux/ath79/dts/ar7241_tplink_tl-mr3x20.dtsi
+++ b/target/linux/ath79/dts/ar7241_tplink_tl-mr3x20.dtsi
@@ -3,15 +3,16 @@
 #include "ar7241_tplink.dtsi"
 
 / {
-    gpio-export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        gpio_usb_power {
-            gpio-export,name = "tp-link:power:usb";
-            gpio-export,output = <1>;
-            gpios = < 6 GPIO_ACTIVE_HIGH>;
-        };
+};
+
+ {
+    status = "okay";
+
+    usb {
+        gpio-hog;
+        line-name = "tp-link:power:usb";
+        gpios = <6 GPIO_ACTIVE_HIGH>;
+        output-high;
 };
 };
 
diff --git a/target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts
b/target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts
index 282446b1e1..829f1fe0e7 100644
--- a/target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts
+++ b/target/linux/ath79/dts/ar7241_tplink_tl-wr842n-v1.dts
@@ -66,15 +66,16 @@
         linux,default-trigger = "phy0tpt";
     };
 };
+};
 
-    gpio-export {
-        compatible = "gpio-export";
+ {
+    status = "okay";
 
-        gpio_usb_power {
-            gpio-export,name = "tp-link:power:usb";
-            gpio-export,output = <1>;
-            gpios = < 6 GPIO_ACTIVE_HIGH>;
-        };
+    usb {
+        gpio-hog;
+        line-name = "tp-link:power:usb";
+        gpios = <6 GPIO_ACTIVE_HIGH>;
+        output-high;
 };
 };
 
@@ -155,10 +156,6 @@
 mtd-mac-address-increment = <1>;
 };
 
- {
-    status = "okay";
-};
-
  {
 status = "okay";
 };
diff --git a/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
b/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
index 70ce41b84d..aee37729b1 100644
--- a/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
+++ b/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
@@ -58,17 +58,6 @@
     };
 };
 
-    gpio-export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        gpio_usb_power {
-            gpio-export,name = "buffalo:usb-power";
-            gpio-export,output = <1>;
-            gpios = < 16 GPIO_ACTIVE_HIGH>;
-        };
-    };
-
 virtual_flash {
     compatible = "mtd-concat";
     devices = < >;
@@ -110,6 +99,17 @@
 };
 };
 
+ {
+    status = "okay";
+
+    usb-power {
+        gpio-hog;
+        line-name = "buffalo:usb-power";
+        gpios = <16 GPIO_ACTIVE_HIGH>;
+        output-high;
+    };
+};
+
  {
 status = "okay";
 cs-gpios = <0>, <0>;
diff --git a/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
b/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
index 97bfd0f842..9f04025598 100644
--- a/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
+++ b/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
@@ -110,17 +110,6 @@
     };
 };
 
-    gpio-export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        gpio_usb_power {
-            gpio-export,name = "buffalo:usb-power";
-            gpio-export,output = <1>;
-            gpios = < 13 GPIO_ACTIVE_HIGH>;
-        };
-    };
-