{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":4307256,"defaultBranch":"master","name":"linux","ownerLogin":"lunn","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2012-05-12T14:58:05.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/1658412?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1724687426.0","currentOid":""},"activityList":{"items":[{"before":null,"after":"c1a90c0ffcd0f8fe0f4e124bdc243d66f1b0033c","ref":"refs/heads/b4/v6-11-rc4-net-next-mdio-gpio","pushedAt":"2024-08-26T15:50:26.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: mdio-gpio: remove support for platform data\n\nThere are no more board files defining platform data for this driver so\nremove the header and drop the support.\n\nSigned-off-by: Bartosz Golaszewski \n[Minor rework because of change to hard coded phy-mask]\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"net: mdio-gpio: remove support for platform data"}},{"before":null,"after":"db5976dcfcee45b460fc59b10fc29abcfd9adb3d","ref":"refs/heads/v6.8.0-net-next-mv88e6xxx-leds-v5","pushedAt":"2024-04-06T18:36:55.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"arm: boot: dts: mvebu: linksys-mamba: Add Ethernet LEDs\n\nList the front panel Ethernet LEDs in the switch section of the\ndevice tree. They can then be controlled via /sys/class/led/\n\nThe node contains a label property to influence the name of the LED.\nWithout it, all the LEDs get the name lan:white, which classes, and so\nsome get a number appended. lan:white_1, lan:white_2, etc. Using the\nlabel the LEDs are named lan1:front, lan2:front, lan3:front, where\nlanX indicates the interface name, and front indicates they are on the\nfront of the box.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"arm: boot: dts: mvebu: linksys-mamba: Add Ethernet LEDs"}},{"before":null,"after":"c85ce1c8e3761fc366533410f0318b01314ba819","ref":"refs/heads/v6.8.0-net-next-mv88e6xxx-leds-v4","pushedAt":"2024-03-17T21:38:59.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"arm: boot: dts: mvebu: linksys-mamba: Add Ethernet LEDs\n\nList the front panel Ethernet LEDs in the switch section of the\ndevice tree. They can then be controlled via /sys/class/led/\n\nThe node contains a label property to influence the name of the LED.\nWithout it, all the LEDs get the name lan:white, which classes, and so\nsome get a number appended. lan:white_1, lan:white_2, etc. Using the\nlabel the LEDs are named lan1:front, lan2:front, lan3:front, where\nlanX indicates the interface name, and front indicates they are on the\nfront of the box.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"arm: boot: dts: mvebu: linksys-mamba: Add Ethernet LEDs"}},{"before":null,"after":"2088ad953d30cc3613d60096613d8fb34ea49fa1","ref":"refs/heads/b4/keee-u32-cleanup","pushedAt":"2024-02-17T19:15:28.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: ethtool: eee: Remove legacy _u32 from keee\n\nAll MAC drivers have been converted to use the link mode members of\nkeee. So remove the _u32 values, and the code in the ethtool core to\nconvert the legacy _u32 values to link modes.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"net: ethtool: eee: Remove legacy _u32 from keee"}},{"before":"58cf408e733fe5ddc15af405fca732e0e7e17550","after":"d72860deb3423c4d48fcb48eff749505b8a32301","ref":"refs/heads/v6.8-rc1-net-next-keee","pushedAt":"2024-02-01T23:58:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: intel: igc: Use linkmode helpers for EEE\n\nMake use of the existing linkmode helpers for converting PHY EEE\nregister values into links modes, now that ethtool_keee uses link\nmodes, rather than u32 values.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"net: intel: igc: Use linkmode helpers for EEE"}},{"before":"ea59ec92e8ed800951f8b75b1288b37bdea36764","after":"58cf408e733fe5ddc15af405fca732e0e7e17550","ref":"refs/heads/v6.8-rc1-net-next-keee","pushedAt":"2024-01-31T01:12:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: ethernet:ixgbe: Convert EEE to use linkmodes\n\nConvert the tables to make use of ETHTOOL link mode bits, rather than\nthe old u32 SUPPORTED speeds. Make use of the linkmode helps to set\nbits and compare linkmodes. As a result, the _u32 members of keee are\nno longer used, a step towards removing them.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"net: ethernet:ixgbe: Convert EEE to use linkmodes"}},{"before":"61f886ecef60d4c3d49e387e4d0bdb102cd712b0","after":"ea59ec92e8ed800951f8b75b1288b37bdea36764","ref":"refs/heads/v6.8-rc1-net-next-keee","pushedAt":"2024-01-31T00:17:53.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: ethernet:ixgbe: Convert EEE to use linkmodes\n\nConvert the tables to make use of ETHTOOL link mode bits, rather than\nthe old u32 SUPPORTED speeds. Make use of the linkmode helps to set\nbits and compare linkmodes. As a result, the _u32 members of keee are\nno longer used, a step towards removing them.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"net: ethernet:ixgbe: Convert EEE to use linkmodes"}},{"before":null,"after":"61f886ecef60d4c3d49e387e4d0bdb102cd712b0","ref":"refs/heads/v6.8-rc1-net-next-keee","pushedAt":"2024-01-30T01:44:47.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: usb: ax88179_178a: Use linkmode helpers for EEE\n\nMake use of the existing linkmode helpers for converting PHY EEE\nregister values into links modes, now that ethtool_keee uses link\nmodes, rather than u32 values.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"net: usb: ax88179_178a: Use linkmode helpers for EEE"}},{"before":null,"after":"5d9c481bbe2fc447edf620644d5476812d21a350","ref":"refs/heads/v6.8-rc1-net-next-mv88e6xxx-leds-v4","pushedAt":"2024-01-29T23:38:26.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"dsa: qca8k: Use netdev_leds common code for LEDs\n\nRather than parse the device tree in the qca8k driver, make use of the\ncommon code for netdevs with LEDs.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"dsa: qca8k: Use netdev_leds common code for LEDs"}},{"before":"9a48ae1a616c32799d10fcde6a9eea1bbade8496","after":"486f4e1d88acdcdc8a07925b9fcb6f4d0585feb6","ref":"refs/heads/v6.7-rc6-net-next-mv88e6xxx-leds-v3","pushedAt":"2024-01-08T23:57:09.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"dsa: qca8k: Use netdev_leds common code for LEDs\n\nRather than parse the device tree in the qca8k driver, make use of the\ncommon code for netdevs with LEDs.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"dsa: qca8k: Use netdev_leds common code for LEDs"}},{"before":null,"after":"9a48ae1a616c32799d10fcde6a9eea1bbade8496","ref":"refs/heads/v6.7-rc6-net-next-mv88e6xxx-leds-v3","pushedAt":"2024-01-05T15:47:45.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"dsa: qca8k: Use netdev_leds common code for LEDs\n\nRather than parse the device tree in the qca8k driver, make use of the\ncommon code for netdevs with LEDs.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"dsa: qca8k: Use netdev_leds common code for LEDs"}},{"before":null,"after":"f53b44745216770b0b090aa7a1def08f267575ac","ref":"refs/heads/v6.7-rc2-net-next-mv88e6xxx-leds-v2","pushedAt":"2023-12-03T16:03:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"dsa: qca8k: Use DSA common code for LEDs\n\nRather than parse the device tree in the qca8k driver, make use of the\ncommon code in the DSA core.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"dsa: qca8k: Use DSA common code for LEDs"}},{"before":"d67635694438025b12dfacb6990b641ed2a55633","after":"b5ea7f3ded72b6f28af16a972148dacd4a9505b6","ref":"refs/heads/v6.7-rc2-net-next-mv88e6xxx-leds","pushedAt":"2023-11-27T13:10:55.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"dsa: qca8k: Use DSA common code for LEDs\n\nRather than parse the device tree in the qca8k driver, make use of the\ncommon code in the DSA core.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"dsa: qca8k: Use DSA common code for LEDs"}},{"before":null,"after":"d67635694438025b12dfacb6990b641ed2a55633","ref":"refs/heads/v6.7-rc2-net-next-mv88e6xxx-leds","pushedAt":"2023-11-27T02:39:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"dsa: qca8k: Use DSA common code for LEDs\n\nRather than parse the device tree in the qca8k driver, make use of the\ncommon code in the DSA core.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"dsa: qca8k: Use DSA common code for LEDs"}},{"before":null,"after":"d4defc0c22bf94e62a7579f9a8c95b73033b4d81","ref":"refs/heads/v6.6-rc7-net-next-mod-desc","pushedAt":"2023-10-27T23:31:43.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: mdio: fill in missing MODULE_DESCRIPTION()s\n\nW=1 builds now warn if module is built without a MODULE_DESCRIPTION().\nFill them in based on the Kconfig text, or similar.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"net: mdio: fill in missing MODULE_DESCRIPTION()s"}},{"before":null,"after":"c432e314bbaf80820bd52715f09f05c2799fada4","ref":"refs/heads/v6.4-rc4-net-next-ethtool-eee-v5","pushedAt":"2023-10-12T21:33:57.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: phylink: Remove unused phylink_init_eee()\n\nThis is not used in tree, and the phylib equivalent phy_init_eee() is\nabout to be removed.\n\nReviewed-by: Russell King (Oracle) \nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"net: phylink: Remove unused phylink_init_eee()"}},{"before":null,"after":"40054d0637fbeb066836b2190f4e9d3e76c32ec0","ref":"refs/heads/v6.4-rc6-net-next-ethtool-eee-v7","pushedAt":"2023-10-12T21:29:59.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: fec: Fixup EEE\n\nThe enabling/disabling of EEE in the MAC should happen as a result of\nauto negotiation. So move the enable/disable into\nfec_enet_adjust_link() which gets called by phylib when there is a\nchange in link status.\n\nfec_enet_set_eee() now just stores away the LPI timer value.\nEverything else is passed to phylib, so it can correctly setup the\nPHY.\n\nfec_enet_get_eee() relies on phylib doing most of the work,\nthe MAC driver just adds the LPI timer value.\n\nCall phy_support_eee() if the quirk is present to indicate the MAC\nactually supports EEE.\n\nSigned-off-by: Andrew Lunn \n---\nv2: Only call fec_enet_eee_mode_set for those that support EEE","shortMessageHtmlLink":"net: fec: Fixup EEE"}},{"before":null,"after":"e9c922a80c23db1d7f497bf1b486d38a48422fbc","ref":"refs/heads/v6.5-rc4-net-next-led-bindings","pushedAt":"2023-08-26T03:25:10.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"drivers: leds: ledtrig-netdev: Implement firmware binding\n\nRead the configuration of the blink pattern from device tree. This is\ndone when the LED trigger is activated. The user can change the\nconfiguration afterwards. However, the LED subsystem does not store\nany persistent state per trigger. If another trigger is activated, and\nthen a return to the netdev trigger is made, any user configuration is\nlost and the defaults in firmware will be restored.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"drivers: leds: ledtrig-netdev: Implement firmware binding"}},{"before":"d79f5ea64c82a21ba45e2a5c2a5353fb4f0d627f","after":"004c4e9fcc7f615126cfce62d342f45305062704","ref":"refs/heads/v6.5-rc4-net-next-marvell-leds-v3","pushedAt":"2023-08-08T00:38:56.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"leds: trig-netdev: Disable offload on deactivation of trigger\n\nEnsure that the offloading of blinking is stopped when the trigger is\ndeactivated. Calling led_set_brightness() is documented as stopping\noffload and setting the LED to a constant brightness.\n\nSuggested-by: Daniel Golle \nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"leds: trig-netdev: Disable offload on deactivation of trigger"}},{"before":null,"after":"d79f5ea64c82a21ba45e2a5c2a5353fb4f0d627f","ref":"refs/heads/v6.5-rc4-net-next-marvell-leds-v3","pushedAt":"2023-08-07T22:29:27.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: phy: marvell: Add support for offloading LED blinking\n\nAdd the code needed to indicate if a given blinking pattern can be\noffloaded, to offload a pattern and to try to return the current\npattern.\n\nReviewed-by: Simon Horman \nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"net: phy: marvell: Add support for offloading LED blinking"}},{"before":null,"after":"b177d10868a4961363000ac9da35e4ec27ae9684","ref":"refs/heads/v6.3.0-rc5-net-leds","pushedAt":"2023-06-14T00:34:13.023Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: phy: Manual remove LEDs to ensure correct ordering\n\nIf the core is left to remove the LEDs via devm_, it is performed too\nlate, after the PHY driver is removed from the PHY. This results in\ndereferencing a NULL pointer when the LED core tries to turn the LED\noff before destroying the LED.\n\nManually unregister the LEDs at a safe point in phy_remove.\n\nCc: stable@vger.kernel.org\nReported-by: Florian Fainelli \nCloses: https://lore.kernel.org/netdev/5558742d-232b-4417-9bea-6369434f8983@lunn.ch/T/\nSuggested-by: Florian Fainelli \nFixes: 01e5b728e9e4 (\"net: phy: Add a binding for PHY LEDs\")\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"net: phy: Manual remove LEDs to ensure correct ordering"}},{"before":null,"after":"2eeaba0449416a152121251b29bf5621d46f5c97","ref":"refs/heads/v6.1.31-scu4","pushedAt":"2023-06-03T18:10:48.211Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: sfp: fix state loss when updating state_hw_mask\n\nAndrew reports that the SFF modules on one of the ZII platforms do not\nindicate link up due to the SFP code believing that LOS indicating that\nthere is no signal being received from the remote end, but in fact the\nLOS signal is showing that there is signal.\n\nWhat makes SFF modules different from SFPs is they typically have an\ninverted LOS, which uncovered this issue. When we read the hardware\nstate, we mask it with state_hw_mask so we ignore anything we're not\ninterested in. However, we don't re-read when state_hw_mask changes,\nleading to sfp->state being stale.\n\nArrange for a software poll of the module state after we have parsed\nthe EEPROM in sfp_sm_mod_probe() and updated state_*_mask. This will\ngenerate any necessary events for signal changes for the state\nmachine as well as updating sfp->state.\n\nReported-by: Andrew Lunn \nTested-by: Andrew Lunn \nFixes: 8475c4b70b04 (\"net: sfp: re-implement soft state polling setup\")\nSigned-off-by: Russell King (Oracle) ","shortMessageHtmlLink":"net: sfp: fix state loss when updating state_hw_mask"}},{"before":"c60ee6ed7e664a425ce612fc68bcbc0a79d75aa5","after":"0f2cce048c55cca3b857038c9e41ff289739424a","ref":"refs/heads/leds-offload-support-reduced-auto-netdev","pushedAt":"2023-05-25T14:25:30.707Z","pushType":"push","commitsCount":4,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"dsa: Create port LEDs based on DT binding\n\nAllow LEDs to be described in each ports DT subnode. Parse these when\nsetting up the ports, currently supporting brightness and link.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"dsa: Create port LEDs based on DT binding"}},{"before":"f1ffe7d8f875fe17f996d112a87846ad06e9eab3","after":"c60ee6ed7e664a425ce612fc68bcbc0a79d75aa5","ref":"refs/heads/leds-offload-support-reduced-auto-netdev","pushedAt":"2023-05-01T12:10:06.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"dt-binding: leds: Add netdev trigger properties\n\nThe netdev LED trigger can be used to indicate a number of network\nconditions, including link, transmit activity and receive activity.\nWhen there is a well defined expected meaning, e.g. a label on the\ncase next to the LED, DT properties can be used to configure the\ntrigger to this meaning.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"dt-binding: leds: Add netdev trigger properties"}},{"before":"95771ae239994ead436141b910fabce1e1376c11","after":"f1ffe7d8f875fe17f996d112a87846ad06e9eab3","ref":"refs/heads/leds-offload-support-reduced-auto-netdev","pushedAt":"2023-05-01T00:46:39.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"dt-binding: leds: Add netdev trigger properties\n\nThe netdev LED trigger can be used to indicate a number of network\nconditions, including link, transmit activity and receive activity.\nWhen there is a well defined expected meaning, e.g. a label on the\ncase next to the LED, DT properties can be used to configure the\ntrigger to this meaning.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"dt-binding: leds: Add netdev trigger properties"}},{"before":null,"after":"95771ae239994ead436141b910fabce1e1376c11","ref":"refs/heads/leds-offload-support-reduced-auto-netdev","pushedAt":"2023-04-30T18:58:01.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"DEBUG PRINTS for Marvell PHY\n\nNot to be merged.","shortMessageHtmlLink":"DEBUG PRINTS for Marvell PHY"}},{"before":null,"after":"22f16af6fd80efa023ad3545ae6b1cf34516d51a","ref":"refs/heads/v6.3-rc6-net-next-zii","pushedAt":"2023-04-16T18:45:14.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"platform: x86: scu: Mark the eeprom length as le16\n\nBy annotating the 16 bit EEPROM length we can get warnings when\naccessing it and not taking into account it is little endian. Fix up\none harmless such access.","shortMessageHtmlLink":"platform: x86: scu: Mark the eeprom length as le16"}},{"before":"6429f658c82fbe35826e8e3b8a5eb588093912e6","after":"885b4a813cb9f8cdfbdc3f86cc46babcf13dc3d9","ref":"refs/heads/v6.3-rc2-net-next-phy-leds","pushedAt":"2023-04-13T22:21:29.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"Documentation: LEDs: Describe good names for network LEDs\n\nNetwork LEDs can exist in both the MAC and the PHY. Naming is\ndifficult because the netdev name is neither stable or unique, do to\ncommands like ip link set name eth42 dev eth0, and network\nnamesspaces.\n\nGive some example names where the MAC and the PHY have unique names\nbased on device tree nodes, or PCI bus addresses.\n\nSince the LED can be used for anything which Linux supports for LEDs,\navoid using names like activity or link, rather describe the location\non the RJ-45, of what the RJ-45 is expected to be used for, WAN/LAN\netc.\n\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"Documentation: LEDs: Describe good names for network LEDs"}},{"before":"14c8b0ccb80d5ef154d134ba63a009c83a650eee","after":"a4c535d7f7302ada329838cfe78b888ab1caf4d4","ref":"refs/heads/v6.3-rc2-net-next-rap","pushedAt":"2023-04-09T14:13:09.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: bridge: switchdev: Disable tx fwd offload when netfilter IP enabled\n\nThe bridge can offload transmit forwarding to the hardware. The\nhardware is passed a single frame, and it will then decided on the\negress interface. For multicast/broadcast frames, the switch will send\nthe frame out multiple interfaces.\n\nThis however breaks in the present of netfilter and\nnet.bridge.bridge-nf-call-iptables = 1.\n\nOne problem is that netfilter only sees a single frame for multicast &\nbroadcast frames. The egress interface may also be incorrect. As a\nresult, rules which drop frames based on the egress interface may not\ncorrectly match, or if they do match, drop multicast/broadcast frames\nfor all egress ports, not a single port.\n\nA second issue is that the result of evaluating if a frames transmit\nforward path can be offloaded to the switch is stored in the skbuf\nbridge control block data structure. However, when calling into\nnetfilter iptables, br_validate_ipv4() zeros the IPCB(skb), i.e. IP\ncontrol block. However, the bridge and IP control block occupy the\nsame space in the skb. As a result, the decision to offload the\ntransmit forward path is lost. The switch will then not offload, but\nthe bridge only sends a single frame for broadcast/multicast, and as a\nresult, protocols like DHCP and ARP break.\n\nExtend the rules for when transmit frame forward path offload can be\nused such that it is disabled when netfilter iptables are active.\n\nFixes: 472111920f1c (\"net: bridge: switchdev: allow the TX data plane forwarding to be offloaded\")\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"net: bridge: switchdev: Disable tx fwd offload when netfilter IP enabled"}},{"before":null,"after":"14c8b0ccb80d5ef154d134ba63a009c83a650eee","ref":"refs/heads/v6.3-rc2-net-next-rap","pushedAt":"2023-04-08T22:43:00.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"lunn","name":"Andrew Lunn","path":"/lunn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1658412?s=80&v=4"},"commit":{"message":"net: bridge: switchdev: Disable tx fwd offload when netfilter IP enabled\n\nThe bridge can offload transmit forwarding to the hardware. The\nhardware is passed a single frame, and it will then decided on the\negress interface. For multicast/broadcast frames, the switch will send\nthe frame out multiple interfaces.\n\nThis however breaks in the present of netfilter and\nnet.bridge.bridge-nf-call-iptables = 1.\n\nOne problem is that netfilter only sees a single frame for multicast &\nbroadcast frames. The egress interface may also be incorrect. As a\nresult, rules which drop frames based on the egress interface may not\ncorrectly match, or if they do match, drop multicast/broadcast frames\nfor all egress ports, not a single port.\n\nA second issue is that the result of evaluating if a frames transmit\nforward path can be offloaded to the switch is stored in the skbuf\nbridge control block data structure. However, when calling into\nnetfilter iptables, br_validate_ipv4() zeros the IPCB(skb), i.e. IP\ncontrol block. However, the bridge and IP control block occupy the\nsame space in the skb. As a result, the decision to offload the\ntransmit forward path is lost. The switch will then not offload, but\nthe bridge only sends a single frame for broadcast/multicast, and as a\nresult, protocols like DHCP and ARP break.\n\nExtend the rules for when transmit frame forward path offload can be\nused such that it is disabled when netfilter iptables are active.\n\nFixes: 472111920f1c (\"net: bridge: switchdev: allow the TX data plane forwarding to be offloaded\")\nSigned-off-by: Andrew Lunn ","shortMessageHtmlLink":"net: bridge: switchdev: Disable tx fwd offload when netfilter IP enabled"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEpG9hHwA","startCursor":null,"endCursor":null}},"title":"Activity ยท lunn/linux"}