[LEDE-DEV] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.

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

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
SOC: Broadcom BCM6368 (2 * Broadcom BMIPS4350 V3.1 / 400 MHz)
Flash size: 32MB (split 16/16 dual boot)
RAM size: 64MB
Wireless: BCM432x 802.11a/b/g/n(pci)
Ethernet: Broadcom BCM53115
USB: 1 x USB 2.0

Known issues:
 - Unable to detect 53115 switch. This appear to be a problem with
probing for the PHY using MDIO and results in error 5. Doesn't seem to
be a problem with the configuration, and could use someone with
experience to have a look at it.
 - Uses the b43 driver as using the OpenWRT/LEDE broadcom-wl driver
fails to load the firmware for the 4322, so 802.11n is not supported.
The factory build uses a newer broadcom-wl driver.
 - No support for the cable port

More info on the device and the research can be found at:
http://www.actiontec.com/212.html

Same FCC ID as:
https://wikidevi.com/wiki/Actiontec_V1000H_(Telus)

Signed-off-by: Anthony Sepa <anthonysepa@yahoo.ca>
---
 target/linux/brcm63xx/dts/r1000h.dts               | 89 ++++++++++++++++++++++
 target/linux/brcm63xx/image/bcm63xx.mk             | 16 ++++
 .../brcm63xx/patches-4.4/578-board_R1000H.patch    | 63 +++++++++++++++
 3 files changed, 168 insertions(+)
 create mode 100644 target/linux/brcm63xx/dts/r1000h.dts
 create mode 100644 target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch

Hi,

Please Cc me for brcm63xx patches, this makes it easier for me to
apply them (especially if they get mangled by patchwork).

On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
<lede-dev@lists.infradead.org> wrote:
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.
>
> ---------- Forwarded message ----------
> From: Anthony Sepa <anthonysepa@yahoo.ca>
> To: lede-dev@lists.infradead.org
> Cc: Anthony Sepa <anthonysepa@yahoo.ca>
> Date: Sun, 12 Feb 2017 09:45:06 -0400
> Subject: [PATCH] This patch adds support for the Actiontec R1000H gateway to the brcm63xx targets.

Please use "[PATCH] brcm63xx: <foo>" as the subject.

> SOC: Broadcom BCM6368 (2 * Broadcom BMIPS4350 V3.1 / 400 MHz)
> Flash size: 32MB (split 16/16 dual boot)

You usually can use all 32MB and force it to not dual boot by giving
it large enough images (>= 16MB).

> RAM size: 64MB
> Wireless: BCM432x 802.11a/b/g/n(pci)
> Ethernet: Broadcom BCM53115
> USB: 1 x USB 2.0
>
> Known issues:
>  - Unable to detect 53115 switch. This appear to be a problem with
> probing for the PHY using MDIO and results in error 5. Doesn't seem to
> be a problem with the configuration, and could use someone with
> experience to have a look at it.

Currently MDIO connected switches/devices aren't supported yet.

>  - Uses the b43 driver as using the OpenWRT/LEDE broadcom-wl driver
> fails to load the firmware for the 4322, so 802.11n is not supported.

You probably just need to supply an sprom, see how other boards use
.use_fallback_sprom = 1 etc.

> The factory build uses a newer broadcom-wl driver.
>  - No support for the cable port
>
> More info on the device and the research can be found at:
> http://www.actiontec.com/212.html
>
> Same FCC ID as:
> https://wikidevi.com/wiki/Actiontec_V1000H_(Telus)
>
> Signed-off-by: Anthony Sepa <anthonysepa@yahoo.ca>
> ---
>  target/linux/brcm63xx/dts/r1000h.dts               | 89 ++++++++++++++++++++++
>  target/linux/brcm63xx/image/bcm63xx.mk             | 16 ++++
>  .../brcm63xx/patches-4.4/578-board_R1000H.patch    | 63 +++++++++++++++
>  3 files changed, 168 insertions(+)
>  create mode 100644 target/linux/brcm63xx/dts/r1000h.dts
>  create mode 100644 target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch
>
> diff --git a/target/linux/brcm63xx/dts/r1000h.dts b/target/linux/brcm63xx/dts/r1000h.dts
> new file mode 100644
> index 0000000..a3a8073
> --- /dev/null
> +++ b/target/linux/brcm63xx/dts/r1000h.dts
> @@ -0,0 +1,89 @@
> +/dts-v1/;
> +
> +#include "bcm6368.dtsi"
> +
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> +       model = "Actiontec R1000H";
> +       compatible = "actiontec,r1000h", "brcm,bcm6368";
> +
> +       chosen {
> +               bootargs = "root=/dev/mtdblock2 rootfstype=squashfs ubi.mtd=ubi_dev noinitrd console=ttyS0,115200";

What's up with the ubi partiton? Where does this come from?

> +       };
> +
> +       gpio-keys-polled {
> +               compatible = "gpio-keys-polled";
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +               poll-interval = <20>;
> +               debounce-interval = <60>;
> +
> +               reset {
> +                       label = "reset";
> +                       gpios = <&gpio1 2 1>;
> +                       linux,code = <KEY_RESTART>;
> +               };

Please add an empty line between nodes (I know that many boards don't,
I plan to fix it eventually).

> +               wps {
> +                       label = "wps";
> +                       gpios = <&gpio1 3 1>;
> +                       linux,code = <KEY_WPS_BUTTON>;
> +               };
> +       };
> +
> +       gpio-leds {
> +               compatible = "gpio-leds";
> +
> +               inet_green {
> +                       label = "R1000H:green:inet";
> +                       gpios = <&gpio0 5 0>;
> +               };

Same here etc.

> +               usb_green {
> +                       label = "R1000H:green:usb";
> +                       gpios = <&gpio0 21 1>;
> +               };
> +               power_green {
> +                       label = "R1000H:green:power";
> +                       gpios = <&gpio0 22 0>;
> +                       default-state = "on";
> +               };
> +               wps_green {
> +                       label = "R1000H:green:wps";
> +                       gpios = <&gpio0 23 1>;
> +               };
> +               power_red {
> +                       label = "R1000H:red:power";
> +                       gpios = <&gpio0 24 0>;
> +               };
> +               wps_red {
> +                       label = "R1000H:red:wps";
> +                       gpios = <&gpio0 30 1>;
> +               };
> +               inet_red {
> +                       label = "R1000H:red:inet";
> +                       gpios = <&gpio0 31 0>;
> +               };
> +       };
> +};
> +
> +&pflash {
> +       status = "ok";
> +
> +       linux,part-probe = "bcm63xxpart";
> +
> +       CFE@0 {
> +               reg = <0x000000 0x020000>;

Please make this partition read-only.

> +       };
> +       linux@20000 {
> +               reg = <0x020000 0x07e0000>;
> +       };
> +       ubi_dev@800000 {
> +               reg = <0x0800000 0x0800000>;
> +       };

Same again, what's up with the ubi?

> +       factory@1000000 {
> +               reg = <0x1000000 0x0fe0000>;
> +       };

So this is the second image? As mentioned above, you should be able to
use the full flash, unless actiontec did something strange.

> +       nvram@1fe0000 {
> +               reg = <0x1fe0000 0x20000>;
> +       };
> +};
> diff --git a/target/linux/brcm63xx/image/bcm63xx.mk b/target/linux/brcm63xx/image/bcm63xx.mk
> index 0749c29..947259b 100644
> --- a/target/linux/brcm63xx/image/bcm63xx.mk
> +++ b/target/linux/brcm63xx/image/bcm63xx.mk
> @@ -1,3 +1,4 @@
> +
>  #
>  # BCM33XX/BCM63XX Profiles
>  #
> @@ -174,6 +175,21 @@ define Device/96368MVWG-generic
>  endef
>  TARGET_DEVICES += 96368MVWG-generic
>
> +### Actiontec ###
> +define Device/R1000H
> +  $(Device/bcm63xx)
> +  FILESYSTEMS := squashfs
> +  DEVICE_TITLE := Actiontec R1000H
> +  DEVICE_DTS := r1000h
> +  CFE_BOARD_ID := 96368MVWG
> +  CFE_CHIP_ID := 6368
> +  FLASH_MB := 8

In your patch notes you say, 32, here you say 8. So how much is it?

> +  IMAGE_OFFSET := 0x20000
> +  DEVICE_PACKAGES := \
> +    $(USB2_PACKAGES)
> +endef
> +TARGET_DEVICES += R1000H
> +
>  ### ADB ###
>  define Device/A4001N
>    $(Device/bcm63xx)
> diff --git a/target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch b/target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch
> new file mode 100644
> index 0000000..c9c919a
> --- /dev/null
> +++ b/target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch
> @@ -0,0 +1,63 @@
> +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> +@@ -2200,6 +2200,44 @@
> +               .type                           = SPROM_BCM4318,
> +               .pci_bus                        = 0,
> +               .pci_dev                        = 1,
> ++      },
> ++};
> ++
> ++static struct board_info __initdata board_R1000H = {
> ++      .name                           = "R1000H",
> ++      .expected_cpu_id                = 0x6368,
> ++
> ++      .has_uart0                      = 1,
> ++      .has_uart1                      = 1,
> ++      .has_pci                        = 1,
> ++      .has_ohci0                      = 1,
> ++      .has_ehci0                      = 1,
> ++      .has_usbd                       = 1,
> ++      .usbd = {
> ++              .use_fullspeed          = 0,
> ++              .port_no                = 0,
> ++      },

I don't see any usb device port. Did I miss it? If not, please drop
the .has_usbd etc.

> ++
> ++      .has_enetsw                     = 1,
> ++      .enetsw = {
> ++              .used_ports = {
> ++                      [4] = {
> ++                              .used  = 1,
> ++                              .phy_id  = 0xff,
> ++                              .bypass_link = 1,
> ++                              .force_speed = 1000,
> ++                              .force_duplex_full = 1,
> ++                              .name  = "RGMII",
> ++                      },
> ++                      [5] = {
> ++                              .used  = 1,
> ++                              .phy_id  = 0xff,
> ++                              .bypass_link = 1,
> ++                              .force_speed = 1000,
> ++                              .force_duplex_full = 1,
> ++                              .name  = "RGMII",
> ++                      },

Does it really use both ports. Is one the wan port? is it the cable
port? Anyways, you should give them unique names.

> ++              },
> +       },
> + };
> +
> +@@ -2701,6 +2739,7 @@
> +       &board_HG622,
> +       &board_HG655b,
> +       &board_P870HW51A_V2,
> ++      &board_R1000H,
> +       &board_VH4032N,
> +       &board_VR3025u,
> +       &board_VR3025un,
> +@@ -2802,6 +2841,7 @@
> +       { .compatible = "sfr,nb6-ser-r0", .data = &board_nb6, },
> + #endif
> + #ifdef CONFIG_BCM63XX_CPU_6368
> ++      { .compatible = "actiontec,r1000h", .data = &board_R1000H, },
> +       { .compatible = "adb,av4202n", .data = &board_AV4202N, },
> +       { .compatible = "brcm,bcm96368mvngr", .data = &board_96368mvngr, },
> +       { .compatible = "brcm,bcm96368mvwg", .data = &board_96368mvwg, },

I don't see you modifying
target/linux/brcm63xx/base-files/etc/board.d/02_network, please add it
at the appropriate place.

You also might want to add it to 01_leds for its usb-led.


Regards
Jonas

Hi,

please don't drop the mailing list.

On 18 February 2017 at 21:41, Anthony Sepa <anthonysepa@yahoo.ca> wrote:
>
>
> On Fri, Feb 17, 2017 at 10:07 AM Jonas Gorski <jonas.gorski@gmail.com>
> wrote:
>>
>> Hi,
>>
>> Please Cc me for brcm63xx patches, this makes it easier for me to
>> apply them (especially if they get mangled by patchwork).
>>
>> On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
>> <lede-dev@lists.infradead.org> wrote:
>> > The sender domain has a DMARC Reject/Quarantine policy which disallows
>> > sending mailing list messages using the original "From" header.
>> >
>> > To mitigate this problem, the original message has been wrapped
>> > automatically by the mailing list software.
>> >
>> > ---------- Forwarded message ----------
>> > From: Anthony Sepa <anthonysepa@yahoo.ca>
>> > To: lede-dev@lists.infradead.org
>> > Cc: Anthony Sepa <anthonysepa@yahoo.ca>
>> > Date: Sun, 12 Feb 2017 09:45:06 -0400
>> > Subject: [PATCH] This patch adds support for the Actiontec R1000H
>> > gateway to the brcm63xx targets.
>>
>> Please use "[PATCH] brcm63xx: <foo>" as the subject.
>>
>> > SOC: Broadcom BCM6368 (2 * Broadcom BMIPS4350 V3.1 / 400 MHz)
>> > Flash size: 32MB (split 16/16 dual boot)
>>
>> You usually can use all 32MB and force it to not dual boot by giving
>> it large enough images (>= 16MB).
>
>
> What is the preferred path to take when creating a build for a dual boot
> device? Is it better to try and preserve the dual boot functionality or
> ignore it? From a user point of view the second partition can be saved with
> the factory firmware for ease of restoring to the old firmware. But it is a
> time bomb waiting to happen, because as soon as LEDE updates the primary
> partition the CFE may decide to boot the secondary as being "newer". See my
> comments later about setting the ram to 32MB.

Dual booting isn't supported, the system/code is expecting to boot
from the first image offset.

Generally CFE works this way:

on boot:

check image tag on image0 offset
check image tag on image1 offset

if any is invalid, boot the other (or none if no valid available)
else boot the one based on the configuration (oldest, newest)

on flashing:

if the image is smaller than the dual image size => override oldest image
if the image is larger than the dual image size => flash at image0 offset

With setting FLASH_MB to the actual flash size, LEDE will create an
image that is larger than the dual image size, thus force CFE to
always flash to image0/boot from there.

>> > RAM size: 64MB
>> > Wireless: BCM432x 802.11a/b/g/n(pci)
>> > Ethernet: Broadcom BCM53115
>> > USB: 1 x USB 2.0
>> >
>> > Known issues:
>> >  - Unable to detect 53115 switch. This appear to be a problem with
>> > probing for the PHY using MDIO and results in error 5. Doesn't seem to
>> > be a problem with the configuration, and could use someone with
>> > experience to have a look at it.
>>
>> Currently MDIO connected switches/devices aren't supported yet.
>
>
> I noticed. Are they supported in the 4.9 kernel? I have a buildroot
> environment using the 4.9 kernel and I was trying to figure out how to
> create a proper DTS file to get the switch working. But the documentation
> was hard to follow and in some cases had the wrong syntax so I gave up.

No they aren't. This has a few extra dependencies before this can be done.

>>
>>
>> >  - Uses the b43 driver as using the OpenWRT/LEDE broadcom-wl driver
>> > fails to load the firmware for the 4322, so 802.11n is not supported.
>>
>> You probably just need to supply an sprom, see how other boards use
>> .use_fallback_sprom = 1 etc.
>
>
> This was a left over from the template I was trying to follow. The
> wl-broadcom and b43 drivers work great.

Okay, even better.

(snip)

>> > +
>> > +&pflash {
>> > +       status = "ok";
>> > +
>> > +       linux,part-probe = "bcm63xxpart";
>> > +
>> > +       CFE@0 {
>> > +               reg = <0x000000 0x020000>;
>>
>> Please make this partition read-only.
>
>
> Sure. But how does someone update the CFE? For example the CFE parameters
> are here. In my CFE the parameter "p=" is used to switch booted partitions,
> etc.

This is currently not supported in LEDE, so no point in having it writable.

>>
>> > +       };
>> > +       linux@20000 {
>> > +               reg = <0x020000 0x07e0000>;
>> > +       };
>> > +       ubi_dev@800000 {
>> > +               reg = <0x0800000 0x0800000>;
>> > +       };
>>
>> Same again, what's up with the ubi?
>>
>>
>> > +       factory@1000000 {
>> > +               reg = <0x1000000 0x0fe0000>;
>> > +       };
>>
>> So this is the second image? As mentioned above, you should be able to
>> use the full flash, unless actiontec did something strange.
>
>
> I used the second partition for a Buildroot environment because I wanted to
> test the 4.9 kernel. I left the second partition so people could save the
> original firmware on the device. That and using the CFE parameters allows
> switching between images.

Usually you can just download the original firmware from the
manufacturer website, or it is included with the device on a CD. And
since LEDE doesn't support dual booting, I see no real point in
keeping it.

So please drop it and allow using the full flash.

>>
>> > +       nvram@1fe0000 {
>> > +               reg = <0x1fe0000 0x20000>;
>> > +       };
>> > +};
>> > diff --git a/target/linux/brcm63xx/image/bcm63xx.mk
>> > b/target/linux/brcm63xx/image/bcm63xx.mk
>> > index 0749c29..947259b 100644
>> > --- a/target/linux/brcm63xx/image/bcm63xx.mk
>> > +++ b/target/linux/brcm63xx/image/bcm63xx.mk
>> > @@ -1,3 +1,4 @@
>> > +
>> >  #
>> >  # BCM33XX/BCM63XX Profiles
>> >  #
>> > @@ -174,6 +175,21 @@ define Device/96368MVWG-generic
>> >  endef
>> >  TARGET_DEVICES += 96368MVWG-generic
>> >
>> > +### Actiontec ###
>> > +define Device/R1000H
>> > +  $(Device/bcm63xx)
>> > +  FILESYSTEMS := squashfs
>> > +  DEVICE_TITLE := Actiontec R1000H
>> > +  DEVICE_DTS := r1000h
>> > +  CFE_BOARD_ID := 96368MVWG
>> > +  CFE_CHIP_ID := 6368
>> > +  FLASH_MB := 8
>>
>> In your patch notes you say, 32, here you say 8. So how much is it?
>
>
> From my look at the code this is more for padding the file to a minimum of
> FLASH_MB / 2. So, if I change this to 32MB the system creates a large 16MB
> file full of nothingness. Along with the problems of such a large file, the
> system will create a JFFS in the space that the CFE thinks is a static
> squashfs and on the second boot the CFE will CRC check it and fail. I hadn't
> thought of this until now and I tested it.
>
> In fact I need this (/2) to be smaller than the actual squashfs. If for any
> reason the squashfs ends up being smaller than this (/2) then the CFE will
> refuse to load the image on the second boot.
>
> I removed it to allow for the default (4) but if the default ever gets
> changed to something too big the images will fail. So I added it back as
> FLASH_MB := 4 since it is required to be small.

Look at target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc -
this will fixup the image tag on first boot and set the rootfs size to
0, effectively disabling the crc check from CFE.

This should make it work even when using large images.

>> > +  IMAGE_OFFSET := 0x20000
>> > +  DEVICE_PACKAGES := \
>> > +    $(USB2_PACKAGES)
>> > +endef
>> > +TARGET_DEVICES += R1000H
>> > +
>> >  ### ADB ###
>> >  define Device/A4001N
>> >    $(Device/bcm63xx)
>> > diff --git a/target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch
>> > b/target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch
>> > new file mode 100644
>> > index 0000000..c9c919a
>> > --- /dev/null
>> > +++ b/target/linux/brcm63xx/patches-4.4/578-board_R1000H.patch
>> > @@ -0,0 +1,63 @@
>> > +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
>> > ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
>> > +@@ -2200,6 +2200,44 @@
>> > +               .type                           = SPROM_BCM4318,
>> > +               .pci_bus                        = 0,
>> > +               .pci_dev                        = 1,
>> > ++      },
>> > ++};
>> > ++
>> > ++static struct board_info __initdata board_R1000H = {
>> > ++      .name                           = "R1000H",
>> > ++      .expected_cpu_id                = 0x6368,
>> > ++
>> > ++      .has_uart0                      = 1,
>> > ++      .has_uart1                      = 1,
>> > ++      .has_pci                        = 1,
>> > ++      .has_ohci0                      = 1,
>> > ++      .has_ehci0                      = 1,
>> > ++      .has_usbd                       = 1,
>> > ++      .usbd = {
>> > ++              .use_fullspeed          = 0,
>> > ++              .port_no                = 0,
>> > ++      },
>>
>> I don't see any usb device port. Did I miss it? If not, please drop
>> the .has_usbd etc.
>
>
> Yeah, there is a USB port.

I see an USB *host* (Type A) port, but I do not see a USB *device*
(Type B) port.

>
>>
>> > ++
>> > ++      .has_enetsw                     = 1,
>> > ++      .enetsw = {
>> > ++              .used_ports = {
>> > ++                      [4] = {
>> > ++                              .used  = 1,
>> > ++                              .phy_id  = 0xff,
>> > ++                              .bypass_link = 1,
>> > ++                              .force_speed = 1000,
>> > ++                              .force_duplex_full = 1,
>> > ++                              .name  = "RGMII",
>> > ++                      },
>> > ++                      [5] = {
>> > ++                              .used  = 1,
>> > ++                              .phy_id  = 0xff,
>> > ++                              .bypass_link = 1,
>> > ++                              .force_speed = 1000,
>> > ++                              .force_duplex_full = 1,
>> > ++                              .name  = "RGMII",
>> > ++                      },
>>
>> Does it really use both ports. Is one the wan port? is it the cable
>> port? Anyways, you should give them unique names.
>>
>
>  The stock firmware has:
>     {bp_ucPhyType0,              .u.uc = BP_ENET_EXTERNAL_SWITCH},
>     {bp_ucPhyAddress,            .u.uc = 0x0},
>     {bp_usConfigType,            .u.us = BP_ENET_CONFIG_MMAP},
>     {bp_ulPortMap,               .u.ul = 0x20}, 32
>     {bp_ulPhyId5,                .u.ul = 0xff},
>     {bp_ucPhyType1,              .u.uc = BP_ENET_EXTERNAL_SWITCH},
>     {bp_ucPhyAddress,            .u.uc = 0x0},
>     {bp_usConfigType,            .u.us = BP_ENET_CONFIG_MDIO_PSEUDO_PHY},
>     {bp_ulPortMap,               .u.ul = 0x3f}, 63
>     {bp_ulPhyId0,                .u.ul = 0x00},
>     {bp_ulPhyId1,                .u.ul = 0x01},
>     {bp_ulPhyId2,                .u.ul = 0x02},
>     {bp_ulPhyId3,                .u.ul = 0x03},
>     {bp_ulPhyId4,                .u.ul = 0x04},
>     {bp_ulPhyId5,                .u.ul = 0x11},
>
> I'm not sure how to properly map this to the DTS, and if I have only one
> port the logic somewhere stops the information from getting to the b53
> driver.
>
> It looks to me like there are two switches a MMAP (bcm63xx) and MDIO (which
> is the 53115). The second is not supported. But I'd like the information to
> be in the file for later when it becomes supported. Plus as mentioned if I
> leave only the port5 MMAP switch the system will never register it with b53
> driver. Does it matter?

The internal switch isn't registered if there is only one external
port, because then it is basically a simple ethernet device. A two
port switch would be basically just a vlan filter device, so it's
easier to just pass everything through. Also, like in your case, if
there is an external switch behind the single port, it is less
confusing if there is only one switch visible to the system
(eventually).

Looking at the stock firmware code, you only want port 5, and port 4
isn't used at all.

And it seems the cable port is connected to the RGMII port (5) of the
external switch.

(snip rest)

Regards
Jonas

On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
<lede-dev@lists.infradead.org> wrote:
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.

You don't need this and I think you were already instructed on other
ML not to do so.

Just include proper From: as the first e-mail of your e-mail body.
Actually git format-patch can even do that for you.

On Thu, 2017-02-23 at 21:35 +0100, Rafał Miłecki wrote:
> On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
> <lede-dev@lists.infradead.org> wrote:
> > 
> > The sender domain has a DMARC Reject/Quarantine policy which disallows
> > sending mailing list messages using the original "From" header.
> > 
> > To mitigate this problem, the original message has been wrapped
> > automatically by the mailing list software.
> You don't need this and I think you were already instructed on other
> ML not to do so.
> 
> Just include proper From: as the first e-mail of your e-mail body.
> Actually git format-patch can even do that for you.

He didn't do that bit. That's the stupid list configuration. Anthony's
problem was that he was posting from a mail domain with stupid
settings. The list's stupidity is a reaction to that.

Personally, I think we're better off just *rejecting* posts from people
with such broken domains. But I only provide the hosting; I'm not
actively playing BoFH and enforcing my opinions on the list config...

On 23 February 2017 at 21:48, David Woodhouse <dwmw2@infradead.org> wrote:
> On Thu, 2017-02-23 at 21:35 +0100, Rafał Miłecki wrote:
>> On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
>> <lede-dev@lists.infradead.org> wrote:
>> >
>> > The sender domain has a DMARC Reject/Quarantine policy which disallows
>> > sending mailing list messages using the original "From" header.
>> >
>> > To mitigate this problem, the original message has been wrapped
>> > automatically by the mailing list software.
>> You don't need this and I think you were already instructed on other
>> ML not to do so.
>>
>> Just include proper From: as the first e-mail of your e-mail body.
>> Actually git format-patch can even do that for you.
>
> He didn't do that bit. That's the stupid list configuration. Anthony's
> problem was that he was posting from a mail domain with stupid
> settings. The list's stupidity is a reaction to that.
>
> Personally, I think we're better off just *rejecting* posts from people
> with such broken domains. But I only provide the hosting; I'm not
> actively playing BoFH and enforcing my opinions on the list config...

Thanks for the explanation!

On 23 February 2017 at 23:01, Anthony Sepa <anthonysepa@yahoo.ca> wrote:
> Is there anything I can do to fix it? I can switch to my gmail account? I
> was using my yahoo out of habit. I was posting using git send-mail, is that
> causing the problem? Should I change to just using email?

Well, using GMail will for sure let you post patches easily. Please
note you don't need to change your e-mail used in git commits. Also
using git send-email is perfectly fine.

This is what I use for my git configuration:
git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser foo@gmail.com

This allows you easily send patches using
git send-email --no-chain-reply-to \
--from "Foo <foo@gmail.com>" \
--to "Bar <bar@qux.org>" \
0001-x.patch

On Thu, Feb 23, 2017 at 09:48:10PM +0100, David Woodhouse wrote:
> On Thu, 2017-02-23 at 21:35 +0100, Rafał Miłecki wrote:
> > On 12 February 2017 at 14:48, Anthony Sepa via Lede-dev
> > <lede-dev@lists.infradead.org> wrote:
> > > 
> > > The sender domain has a DMARC Reject/Quarantine policy which disallows
> > > sending mailing list messages using the original "From" header.
> > > 
> > > To mitigate this problem, the original message has been wrapped
> > > automatically by the mailing list software.
> > You don't need this and I think you were already instructed on other
> > ML not to do so.
> > 
> > Just include proper From: as the first e-mail of your e-mail body.
> > Actually git format-patch can even do that for you.
> 
> He didn't do that bit. That's the stupid list configuration. Anthony's
> problem was that he was posting from a mail domain with stupid
> settings. The list's stupidity is a reaction to that.
> 
> Personally, I think we're better off just *rejecting* posts from people
> with such broken domains.

Well, it may be stupid, but not really "broken", because it's done
intentionally by Yahoo:

    $ dig +short yahoo.ca TXT
    "v=spf1 redirect=_spf.mail.yahoo.com"
    $ dig +short _spf.mail.yahoo.com TXT
    "v=spf1 ptr:yahoo.com ptr:yahoo.net ?all"
    $ dig +short _dmarc.yahoo.ca TXT
    "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_rua@yahoo.com;"

Long story short, Yahoo uses SPF to only allow yahoo mail servers to send
emails with a "From:" field in a @yahoo.whatever domain.
Google does the same thing for gmail, but they are just more permissive (for now?).

See also https://www.ietf.org/mail-archive/web/ietf/current/msg87153.html


David, you could configure the mailing list to avoid the annoying wrapping
of the original message, and just change the From field.  This may be less
confusing (but maybe this already got discussed elsewhere?)

Baptiste