APPLIED: [SRU][X/raspi2] Support for the RaspberryPi 3 B Plus board
kleber.souza at canonical.com
Fri Aug 24 11:06:49 UTC 2018
On 08/01/18 16:49, Paolo Pisati wrote:
> BugLink: http://bugs.launchpad.net/bugs/1784025
> The RaspberryPi 3 B Plus is the latest addition in the family of RaspberryPi
> boards, and this patchset includes all the necessary bits (dts, lan driver and
> wifi driver) to enable this board in our 4.4 Xenial raspi2 kernel.
> How to test:
> Build this kernel and boot a rpi3bplus with it: the board should boot fine, and
> ethernet lan and wifi should work.
> Regression potential:
> To ease the regression analysis, we can logically split the patchset in 3
> different set of patches.
> 1) the dts files (patches 0001 to 0006)
> Patch 0001 contains the pi3bplus board dts files + the lan dts fragment - these
> are new files, and don't modify any other dts in the tree.
> Patches 0002 to 0005 are the fixup modifcation to make the above dts file work
> in our 4.4 kernel.
> Patch 006 is a fix for the bcm2708_common, a device tree used in every rpi board
> dtb - it's a small fix, and the same modification is present in the 4.9+
> Raspberry respository too (see
> aroud lines 353-354) - unfortunately they squashed that fix, so i couldn't pick
> the specific commit.
> The only regression potential here is patch 0006, but since it's a small fix,
> and it's even carried upstream, i mark it as low.
> 2) the lan driver (patches 0008 to 0018)
> The rpi3bplus comes with a brand new gigabit capable ethernet adapter, driven by
> the lan 7515 chip, a chip mainly used in usb to ethernet dongle. Unfortunately,
> the lan7515 driver shipped in our Xenial tree was not working: the driver would
> attach, the interface shows up, packets could be sent, but the host os never
> received any input packets - sniffing the cable confirmed that the chip was
> generating traffic and receiving reply packets too.
> After some debugging i found that no interrupt was generated once packet
> arrived, and that was due to upstream 23374573a899528a4b10d76276646f69b7ae1572
> "lan78xx: Correctly indicate invalid OTP", reverting this would bring my
> ethernet back to life (patch 0008).
> "lan78xx: Correctly indicate invalid OTP" originated around 4.17, way after a
> complete overhaul of the phy code wad done for all the usbnet driver - after
> more debugging i found that the 4.4 driver ships a workaround to enable phy
> interrupts (see lan78xx_open()), so i'm thinking there's some correlation
> between the phy overhaul and this commit, but without the datasheet i can't tell
> what those bits in that register are actually doing - for now i just reverted
> this patch locally and made the driver work again.
> All the other patches (0009 to 0018) are backports of features added to the
> driver by the Raspberry Foundation to make the driver better integrate in a dts
> There's literally no regression potential here, since the driver was not working
> in the first place, (and i actually made it work again).
> 3) the wifi driver (patches 0019 to 0026)
> The wifi chip used in the rpi3bplus is very different from the one used in the
> original rpi3 board (Broadcom BCM43438 vs Cypress CYW43455), but it uses the
> same driver and i had to backport several fixes from upstream to make it work:
> all the commits fix isolated bugs, and can be easily reviewed.
> There's some regression potential here, but all code comes from upstream fixes,
> so i mark it as low.
> When possible i picked up the upstream version of the same patch (instead of the
> one carried in the RaspberryPi branch - https://github.com/raspberrypi/linux
> rpi-4.9.y), and except for these 6 commits:
> "BCM270X_DT: Add Pi 3+ dts files"
> "lan78xx: Enable LEDs if no valid EEPROM or OTP"
> "lan78xx: Read initial EEE status from DT"
> "lan78xx: Change LEDs to include 10Mb activity"
> "lan78xx: Ignore DT MAC address if already valid"
> "lan78xx: Move enabling of EEE into PHY init code"
> all the remaining patches (20 out of 26) came from upstream - patches marked
> with 'cherry-picked...' are clean cherry picks, while the one with
> 'backported...' required a varying degree of rework to make it apply (and
> I'm proposing this for inclusion in the Xenial raspi2 kernel.
> 1: https://www.raspberrypi.org/blog/raspberry-pi-3-model-bplus-sale-now-35/
> The following changes since commit a9108920671adf3c81eb1cf5f35586c831b4b94a:
> UBUNTU: Ubuntu-raspi2-4.4.0-1092.100 (2018-06-12 21:35:39 +0000)
> are available in the git repository at:
> git://git.launchpad.net/~p-pisati/ubuntu/+source/linux x-raspi2-3bplus
> for you to fetch changes up to b2af40a9594d86d39206e7c909de0134cc516933:
> brcmfmac: sdio: Increase the default timeouts a bit (2018-08-01 12:43:49 +0200)
> Alexander Graf (1):
> lan78xx: Connect phy early
> Dave Stevenson (1):
> net: lan78xx: Allow for VLAN headers in timeout.
> Hante Meuleman (2):
> brcmfmac: Disable runtime pm for USB.
> brcmfmac: Return actual error by fwil.
> Paolo Pisati (12):
> UBUNTU: SAUCE: dts: remove i2c_dsi reference (4.9+ only)
> UBUNTU: SAUCE: dts: use 0 instead of GPIO_ACTIVE_LOW
> UBUNTU: SAUCE: dts: remove the hdmi node since it's part of the vc4 overlay
> UBUNTU: SAUCE: dts: use the virtgpio driver
> UBUNTU: SAUCE: fix address & size of reg cell for usb1
> UBUNTU: modules: remove lan78xx and microchip phy check
> UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP"
> brcmfmac: Fix double free on exception at module load.
> brcmfmac: only lock and unlock fws if fws is not null
> brcmfmac: Fix warn trace on module unload while in ibss mode
> brcmfmac: fix p2p scan abort null pointer exception
> brcmf: Fix null pointer exception in bcdc_hdrpull
> Phil Elwell (9):
> BCM270X_DT: Add Pi 3+ dts files
> lan78xx: Read MAC address from DT if present
> lan78xx: Enable LEDs if no valid EEPROM or OTP
> lan78xx: Read initial EEE status from DT
> lan78xx: Change LEDs to include 10Mb activity
> lan78xx: Read LED states from Device Tree
> lan78xx: Ignore DT MAC address if already valid
> lan78xx: Don't reset the interface on open
> lan78xx: Move enabling of EEE into PHY init code
> Sjoerd Simons (1):
> brcmfmac: sdio: Increase the default timeouts a bit
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/bcm2708_common.dtsi | 2 +
> arch/arm/boot/dts/bcm2710-rpi-3-b-plus.dts | 210 +++++++++++++++++++++
> arch/arm/boot/dts/bcm283x-rpi-lan7515.dtsi | 36 ++++
> arch/arm/boot/dts/overlays/README | 8 +
> .../abi/4.4.0-1091.99/armhf/raspi2.modules | 2 -
> drivers/net/usb/lan78xx.c | 108 ++++++++---
> drivers/net/wireless/brcm80211/brcmfmac/bcdc.c | 3 +-
> drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 9 +-
> drivers/net/wireless/brcm80211/brcmfmac/core.c | 2 +
> drivers/net/wireless/brcm80211/brcmfmac/fwil.c | 3 +-
> drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c | 7 +-
> drivers/net/wireless/brcm80211/brcmfmac/p2p.c | 2 +-
> drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 4 +-
> drivers/net/wireless/brcm80211/brcmfmac/usb.c | 1 -
> 15 files changed, 360 insertions(+), 38 deletions(-)
> create mode 100644 arch/arm/boot/dts/bcm2710-rpi-3-b-plus.dts
> create mode 100644 arch/arm/boot/dts/bcm283x-rpi-lan7515.dtsi
Applied to xenial/raspi2 branch.
More information about the kernel-team