* [BUG] sun8i-a83t-bananapi-m3: Ethernet unstable since d7c5f6863550 ("ARM: dts: sun8i: a83t: bananapi-m3: Add AXP813 regulator nodes")
From: Corentin Labbe @ 2017-12-28 20:20 UTC (permalink / raw)
To: linux-arm-kernel
Hello
Since d7c5f6863550 ("ARM: dts: sun8i: a83t: bananapi-m3: Add AXP813 regulator nodes"), my BPIM3 does not have stable ethernet.
from 50% to 100% packet loss.
According to the logs (below), vcc-ephy is disabled during boot
With the following hack, https://paste.pound-python.org/show/6BlmwcE60z0o4GrbAMUU/ (which is a badly d7c5f6863550 revert)
the situation is better (ping with 0% loss), but the bandwitch is unstable low.
So the problem is clearly that the PHY is badly powered.
Regards
[ 4.840336] sunxi-rsb 1f03400.rsb: RSB running at 3000000 Hz
[ 4.847252] axp20x-rsb sunxi-rsb-3a3: AXP20x variant AXP813 found
[ 4.856307] axp20x-rsb sunxi-rsb-3a3: Looking up vin1-supply from device tree
[ 4.856331] axp20x-rsb sunxi-rsb-3a3: Looking up vin1-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.856351] dcdc1: supplied by regulator-dummy
[ 4.860802] regulator-dummy: could not add device link regulator.1 err -2
[ 4.861006] vcc-3v3: 3300 mV
[ 4.861264] axp20x-rsb sunxi-rsb-3a3: Looking up vin2-supply from device tree
[ 4.861281] axp20x-rsb sunxi-rsb-3a3: Looking up vin2-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.861291] dcdc2: supplied by regulator-dummy
[ 4.865854] regulator-dummy: could not add device link regulator.2 err -2
[ 4.866041] vdd-cpua: 700 <--> 1100 mV at 900 mV
[ 4.866251] axp20x-rsb sunxi-rsb-3a3: Looking up vin3-supply from device tree
[ 4.866264] axp20x-rsb sunxi-rsb-3a3: Looking up vin3-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.866274] dcdc3: supplied by regulator-dummy
[ 4.870717] regulator-dummy: could not add device link regulator.3 err -2
[ 4.870814] vdd-cpub: 700 <--> 1100 mV at 900 mV
[ 4.871017] axp20x-rsb sunxi-rsb-3a3: Looking up vin4-supply from device tree
[ 4.871029] axp20x-rsb sunxi-rsb-3a3: Looking up vin4-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.871040] dcdc4: supplied by regulator-dummy
[ 4.875524] regulator-dummy: could not add device link regulator.4 err -2
[ 4.875633] vdd-gpu: 700 <--> 1100 mV at 900 mV
[ 4.875832] axp20x-rsb sunxi-rsb-3a3: Looking up vin5-supply from device tree
[ 4.875845] axp20x-rsb sunxi-rsb-3a3: Looking up vin5-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.875857] dcdc5: supplied by regulator-dummy
[ 4.880299] regulator-dummy: could not add device link regulator.5 err -2
[ 4.880413] vcc-dram: Bringing 1180000uV into 1200000-1200000uV
[ 4.886402] vcc-dram: ramp_delay not set
[ 4.886418] vcc-dram: 1200 mV
[ 4.886643] axp20x-rsb sunxi-rsb-3a3: Looking up vin6-supply from device tree
[ 4.886655] axp20x-rsb sunxi-rsb-3a3: Looking up vin6-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.886669] dcdc6: supplied by regulator-dummy
[ 4.891110] regulator-dummy: could not add device link regulator.6 err -2
[ 4.891216] vdd-sys: 900 mV
[ 4.891495] axp20x-rsb sunxi-rsb-3a3: Looking up vin7-supply from device tree
[ 4.891508] axp20x-rsb sunxi-rsb-3a3: Looking up vin7-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.891521] dcdc7: supplied by regulator-dummy
[ 4.895995] regulator-dummy: could not add device link regulator.7 err -2
[ 4.896102] dcdc7: at 1000 mV
[ 4.896324] axp20x-rsb sunxi-rsb-3a3: Looking up aldoin-supply from device tree
[ 4.896336] axp20x-rsb sunxi-rsb-3a3: Looking up aldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.896348] aldo1: supplied by regulator-dummy
[ 4.900790] regulator-dummy: could not add device link regulator.8 err -2
[ 4.900936] vcc-1v8: 1800 mV
[ 4.901142] axp20x-rsb sunxi-rsb-3a3: Looking up aldoin-supply from device tree
[ 4.901155] axp20x-rsb sunxi-rsb-3a3: Looking up aldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.901169] aldo2: supplied by regulator-dummy
[ 4.905638] regulator-dummy: could not add device link regulator.9 err -2
[ 4.905734] dram-pll: 1800 mV
[ 4.905959] axp20x-rsb sunxi-rsb-3a3: Looking up aldoin-supply from device tree
[ 4.905972] axp20x-rsb sunxi-rsb-3a3: Looking up aldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.905986] aldo3: supplied by regulator-dummy
[ 4.910428] regulator-dummy: could not add device link regulator.10 err -2
[ 4.910536] avcc: 3000 mV
[ 4.910813] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply from device tree
[ 4.910827] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.910842] dldo1: supplied by regulator-dummy
[ 4.915313] regulator-dummy: could not add device link regulator.11 err -2
[ 4.915448] vcc-wifi: Bringing 2900000uV into 3300000-3300000uV
[ 4.921405] vcc-wifi: ramp_delay not set
[ 4.921414] vcc-wifi: 3300 mV
[ 4.921627] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply from device tree
[ 4.921640] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.921654] dldo2: supplied by regulator-dummy
[ 4.926118] regulator-dummy: could not add device link regulator.12 err -2
[ 4.926208] dldo2: at 2900 mV
[ 4.926422] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply from device tree
[ 4.926435] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.926451] dldo3: supplied by regulator-dummy
[ 4.930892] regulator-dummy: could not add device link regulator.13 err -2
[ 4.930983] vcc-pd: Bringing 2900000uV into 2500000-2500000uV
[ 4.936787] vcc-pd: ramp_delay not set
[ 4.936801] vcc-pd: 2500 mV
[ 4.937018] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply from device tree
[ 4.937030] axp20x-rsb sunxi-rsb-3a3: Looking up dldoin-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.937045] dldo4: supplied by regulator-dummy
[ 4.941486] regulator-dummy: could not add device link regulator.14 err -2
[ 4.941579] dldo4: at 3300 mV
[ 4.941785] axp20x-rsb sunxi-rsb-3a3: Looking up eldoin-supply from device tree
[ 4.941822] eldo1: supplied by vcc-3v3
[ 4.945598] vcc-3v3: could not add device link regulator.15 err -2
[ 4.945763] eldo1: at 700 mV
[ 4.945994] axp20x-rsb sunxi-rsb-3a3: Looking up eldoin-supply from device tree
[ 4.946013] eldo2: supplied by vcc-3v3
[ 4.949763] vcc-3v3: could not add device link regulator.16 err -2
[ 4.949849] eldo2: at 700 mV
[ 4.950067] axp20x-rsb sunxi-rsb-3a3: Looking up eldoin-supply from device tree
[ 4.950083] eldo3: supplied by vcc-3v3
[ 4.953866] vcc-3v3: could not add device link regulator.17 err -2
[ 4.953964] eldo3: at 1600 mV
[ 4.954190] axp20x-rsb sunxi-rsb-3a3: Looking up fldoin-supply from device tree
[ 4.954208] fldo1: supplied by vcc-dram
[ 4.958043] vcc-dram: could not add device link regulator.18 err -2
[ 4.958143] vdd12-hsic: override min_uV, 1080000 -> 1100000
[ 4.958149] vdd12-hsic: override max_uV, 1320000 -> 1300000
[ 4.958159] vdd12-hsic: 1100 <--> 1300 mV at 1250 mV
[ 4.958419] axp20x-rsb sunxi-rsb-3a3: Looking up fldoin-supply from device tree
[ 4.958440] fldo2: supplied by vcc-dram
[ 4.962275] vcc-dram: could not add device link regulator.19 err -2
[ 4.962447] vdd-cpus: 700 <--> 1100 mV at 900 mV
[ 4.962686] axp20x-rsb sunxi-rsb-3a3: Looking up ips-supply from device tree
[ 4.962700] axp20x-rsb sunxi-rsb-3a3: Looking up ips-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.962721] rtc-ldo: supplied by regulator-dummy
[ 4.967375] regulator-dummy: could not add device link regulator.20 err -2
[ 4.967425] vcc-rtc: 1800 mV
[ 4.967626] axp20x-rsb sunxi-rsb-3a3: Looking up ips-supply from device tree
[ 4.967638] axp20x-rsb sunxi-rsb-3a3: Looking up ips-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.967658] ldo-io0: supplied by regulator-dummy
[ 4.972273] regulator-dummy: could not add device link regulator.21 err -2
[ 4.972404] ldo-io0: at 3300 mV
[ 4.972622] axp20x-rsb sunxi-rsb-3a3: Looking up ips-supply from device tree
[ 4.972635] axp20x-rsb sunxi-rsb-3a3: Looking up ips-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.972656] ldo-io1: supplied by regulator-dummy
[ 4.977297] regulator-dummy: could not add device link regulator.22 err -2
[ 4.977435] ldo-io1: at 3300 mV
[ 4.977659] axp20x-rsb sunxi-rsb-3a3: Looking up swin-supply from device tree
[ 4.977679] sw: supplied by vcc-3v3
[ 4.981167] vcc-3v3: could not add device link regulator.23 err -2
[ 4.981295] vcc-ephy: at 3300 mV
[ 4.981576] axp20x-rsb sunxi-rsb-3a3: Looking up drivevbus-supply from device tree
[ 4.981590] axp20x-rsb sunxi-rsb-3a3: Looking up drivevbus-supply property in node /soc/rsb at 1f03400/pmic at 3a3 failed
[ 4.981614] drivevbus: supplied by regulator-dummy
[ 4.986436] regulator-dummy: could not add device link regulator.24 err -2
[ 4.986539] usb0-vbus: no parameters
[ 4.987174] axp20x-rsb sunxi-rsb-3a3: AXP20X driver loaded
[ 4.996209] ac100-rtc ac100-rtc: registered as rtc0
[ 5.001098] ac100-rtc ac100-rtc: RTC enabled
[ 5.006016] sun4i-usb-phy 1c19400.phy: Looking up usb0_vbus-supply from device tree
[ 5.006033] sun4i-usb-phy 1c19400.phy: Looking up usb0_vbus-supply property in node /soc/phy at 1c19400 failed
[ 5.006142] phy phy-1c19400.phy.0: Looking up phy-supply from device tree
[ 5.006153] phy phy-1c19400.phy.0: Looking up phy-supply property in node /soc/phy at 1c19400 failed
[ 5.006270] sun4i-usb-phy 1c19400.phy: Looking up usb1_vbus-supply from device tree
[ 5.006312] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb1_vbus... Deferring probe
[ 5.020051] sun8i-a83t-pinctrl 1c20800.pinctrl: initialized sunXi PIO driver
[ 5.028283] console [ttyS0] disabled
[ 5.052157] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 42, base_baud = 1500000) is a U6_16550A
[ 5.061250] console [ttyS0] enabled
[ 5.068271] bootconsole [earlycon0] disabled
[ 5.078429] sunxi-mmc 1c0f000.mmc: Looking up vmmc-supply from device tree
[ 5.078551] sunxi-mmc 1c0f000.mmc: Looking up vqmmc-supply from device tree
[ 5.078565] sunxi-mmc 1c0f000.mmc: Looking up vqmmc-supply property in node /soc/mmc at 1c0f000 failed
[ 5.079422] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[ 5.109476] sunxi-mmc 1c0f000.mmc: base:0x(ptrval) irq:24
[ 5.115503] sunxi-mmc 1c10000.mmc: Looking up vmmc-supply from device tree
[ 5.115609] sunxi-mmc 1c10000.mmc: Looking up vqmmc-supply from device tree
[ 5.116352] sunxi-mmc 1c10000.mmc: allocated mmc-pwrseq
[ 5.144835] sunxi-mmc 1c10000.mmc: base:0x(ptrval) irq:25
[ 5.150842] sunxi-mmc 1c11000.mmc: Looking up vmmc-supply from device tree
[ 5.150976] sunxi-mmc 1c11000.mmc: Looking up vqmmc-supply from device tree
[ 5.157776] mmc0: host does not support reading read-only switch, assuming write-enable
[ 5.168115] mmc0: new high speed SDHC card at address 59b4
[ 5.175753] mmcblk0: mmc0:59b4 00000 14.9 GiB
[ 5.180362] sunxi-mmc 1c11000.mmc: base:0x(ptrval) irq:26
[ 5.180849] usb1-vbus: 5000 mV
[ 5.181218] reg-fixed-voltage reg-usb1-vbus: usb1-vbus supplying 5000000uV
[ 5.181674] sun4i-usb-phy 1c19400.phy: Looking up usb0_vbus-supply from device tree
[ 5.181689] sun4i-usb-phy 1c19400.phy: Looking up usb0_vbus-supply property in node /soc/phy at 1c19400 failed
[ 5.181825] phy phy-1c19400.phy.0: Looking up phy-supply from device tree
[ 5.181834] phy phy-1c19400.phy.0: Looking up phy-supply property in node /soc/phy at 1c19400 failed
[ 5.181941] sun4i-usb-phy 1c19400.phy: Looking up usb1_vbus-supply from device tree
[ 5.182203] phy phy-1c19400.phy.1: Looking up phy-supply from device tree
[ 5.182215] phy phy-1c19400.phy.1: Looking up phy-supply property in node /soc/phy at 1c19400 failed
[ 5.182320] sun4i-usb-phy 1c19400.phy: Looking up usb2_vbus-supply from device tree
[ 5.182330] sun4i-usb-phy 1c19400.phy: Looking up usb2_vbus-supply property in node /soc/phy at 1c19400 failed
[ 5.182418] phy phy-1c19400.phy.2: Looking up phy-supply from device tree
[ 5.182427] phy phy-1c19400.phy.2: Looking up phy-supply property in node /soc/phy at 1c19400 failed
[ 5.183355] ehci-platform 1c1a000.usb: EHCI Host Controller
[ 5.189212] ehci-platform 1c1a000.usb: new USB bus registered, assigned bus number 1
[ 5.189548] ehci-platform 1c1a000.usb: irq 28, io mem 0x01c1a000
[ 5.212983] ehci-platform 1c1a000.usb: USB 2.0 started, EHCI 1.00
[ 5.219425] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 5.226470] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 5.233887] mmcblk0: p1
[ 5.238179] usb usb1: Product: EHCI Host Controller
[ 5.243188] usb usb1: Manufacturer: Linux 4.15.0-rc4-next-20171222+ ehci_hcd
[ 5.250260] usb usb1: SerialNumber: 1c1a000.usb
[ 5.255686] hub 1-0:1.0: USB hub found
[ 5.259513] hub 1-0:1.0: 1 port detected
[ 5.263822] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 5.269572] console [netcon0] enabled
[ 5.273325] netconsole: network logging started
[ 5.278597] ac100-rtc ac100-rtc: setting system clock to 2017-12-28 20:39:02 UTC (1514493542)
[ 5.287486] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 5.293314] vdd-gpu: disabling
[ 5.296485] vcc-ephy: disabling
[ 5.301896] EXT4-fs (mmcblk0p1): couldn't mount as ext3 due to feature incompatibilities
[ 5.311055] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 5.321221] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 5.343195] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
[ 5.351451] VFS: Mounted root (ext4 filesystem) readonly on device 179:1.
[ 5.367566] devtmpfs: mounted
[ 5.372472] Freeing unused kernel memory: 1024K
[ 5.377759] mmc2: new DDR MMC card at address 0001
[ 5.379726] mmcblk2: mmc2:0001 8WPD3R 7.28 GiB
[ 5.381258] mmcblk2boot0: mmc2:0001 8WPD3R partition 1 4.00 MiB
[ 5.382822] mmcblk2boot1: mmc2:0001 8WPD3R partition 2 4.00 MiB
[ 5.470371] mmc1: new high speed SDIO card at address 0001
[ 5.633004] usb 1-1: new high-speed USB device number 2 using ehci-platform
[ 5.834539] usb 1-1: New USB device found, idVendor=1a40, idProduct=0101
[ 5.841615] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 5.849030] usb 1-1: Product: USB 2.0 Hub
[ 5.854281] hub 1-1:1.0: USB hub found
[ 5.858757] hub 1-1:1.0: 4 ports detected
[ 6.183024] usb 1-1.1: new high-speed USB device number 3 using ehci-platform
[ 6.356172] usb 1-1.1: New USB device found, idVendor=05e3, idProduct=0718
[ 6.363586] usb 1-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=2
[ 6.371011] usb 1-1.1: Product: USB Storage
[ 6.375406] usb 1-1.1: SerialNumber: 000000000033
[ 6.381855] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[ 6.401248] scsi host0: usb-storage 1-1.1:1.0
[ 7.466681] scsi 0:0:0:0: Direct-Access USB TO I DE/SATA Device 0016 PQ: 0 ANSI: 4
[ 7.484140] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 7.490789] sd 0:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B)
[ 7.503041] sd 0:0:0:0: [sda] 0-byte physical blocks
[ 7.513103] sd 0:0:0:0: [sda] Test WP failed, assume Write Enabled
[ 7.526422] sd 0:0:0:0: [sda] Asking for cache data failed
[ 7.531936] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 7.559074] sd 0:0:0:0: [sda] Attached SCSI disk
[ 14.564013] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 14.695046] axp20x-gpio axp20x-gpio: AXP209 pinctrl and GPIO driver loaded
[ 14.781019] dwmac-sun8i 1c30000.ethernet: PTP uses main clock
[ 14.781082] dwmac-sun8i 1c30000.ethernet: Looking up phy-supply from device tree
[ 14.913317] dwmac-sun8i 1c30000.ethernet: Current syscon value is not the default 1ce6 (expect 0)
[ 14.913365] dwmac-sun8i 1c30000.ethernet: Chain mode enabled
[ 14.913373] dwmac-sun8i 1c30000.ethernet: No HW DMA feature register supported
[ 14.913381] dwmac-sun8i 1c30000.ethernet: Normal descriptors
[ 14.913388] dwmac-sun8i 1c30000.ethernet: RX Checksum Offload Engine supported
[ 14.913395] dwmac-sun8i 1c30000.ethernet: COE Type 2
[ 14.913402] dwmac-sun8i 1c30000.ethernet: TX Checksum insertion supported
[ 14.913726] libphy: stmmac: probed
[ 15.838616] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 15.838978] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 15.838993] cfg80211: failed to load regulatory.db
[ 15.971608] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430a0-sdio.bin for chip 0x00a9a6(43430) rev 0x000000
[ 15.972039] usbcore: registered new interface driver brcmfmac
[ 15.972147] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430a0-sdio.bin failed with error -2
[ 16.983325] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[ 17.642892] EXT4-fs (mmcblk0p1): re-mounted. Opts: (null)
[ 17.993291] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[ 25.292693] RTL8211E Gigabit Ethernet stmmac-0:01: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=stmmac-0:01, irq=POLL)
[ 25.297646] dwmac-sun8i 1c30000.ethernet eth0: No MAC Management Counters available
[ 25.297669] dwmac-sun8i 1c30000.ethernet eth0: PTP not supported by HW
[ 30.503958] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[ 39.675382] random: crng init done
^ permalink raw reply
* [PATCH 2/2] media: don't include drivers/media/i2c at cflags
From: Mauro Carvalho Chehab @ 2017-12-28 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fada1935590f66dc6784981e0d557ca09013c847.1514488526.git.mchehab@s-opensource.com>
Most of the I2C headers got moved a long time ago to
include/media/i2c. Stop including them at the patch.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
drivers/media/i2c/cx25840/Makefile | 2 --
drivers/media/pci/bt8xx/Makefile | 1 -
drivers/media/pci/cx23885/Makefile | 1 -
drivers/media/pci/cx25821/Makefile | 2 --
drivers/media/pci/cx88/Makefile | 2 --
drivers/media/pci/ivtv/Makefile | 1 -
drivers/media/pci/saa7134/Makefile | 1 -
drivers/media/pci/saa7164/Makefile | 3 ---
drivers/media/platform/Makefile | 2 --
drivers/media/platform/sti/c8sectpfe/Makefile | 1 -
drivers/media/usb/cx231xx/Makefile | 1 -
drivers/media/usb/em28xx/Makefile | 1 -
drivers/media/usb/hdpvr/Makefile | 4 ----
drivers/media/usb/pvrusb2/Makefile | 1 -
drivers/media/usb/stk1160/Makefile | 2 --
drivers/media/usb/tm6000/Makefile | 1 -
drivers/media/usb/usbvision/Makefile | 1 -
17 files changed, 27 deletions(-)
diff --git a/drivers/media/i2c/cx25840/Makefile b/drivers/media/i2c/cx25840/Makefile
index 898eb13340ae..ac545812fc6a 100644
--- a/drivers/media/i2c/cx25840/Makefile
+++ b/drivers/media/i2c/cx25840/Makefile
@@ -2,5 +2,3 @@ cx25840-objs := cx25840-core.o cx25840-audio.o cx25840-firmware.o \
cx25840-vbi.o cx25840-ir.o
obj-$(CONFIG_VIDEO_CX25840) += cx25840.o
-
-ccflags-y += -Idrivers/media/i2c
diff --git a/drivers/media/pci/bt8xx/Makefile b/drivers/media/pci/bt8xx/Makefile
index ab0ea64d3910..7f1c3beb1bbc 100644
--- a/drivers/media/pci/bt8xx/Makefile
+++ b/drivers/media/pci/bt8xx/Makefile
@@ -7,6 +7,5 @@ obj-$(CONFIG_VIDEO_BT848) += bttv.o
obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o
ccflags-y += -Idrivers/media/dvb-frontends
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/common
ccflags-y += -Idrivers/media/tuners
diff --git a/drivers/media/pci/cx23885/Makefile b/drivers/media/pci/cx23885/Makefile
index 3f37dcadbaaf..130f0aa29ac6 100644
--- a/drivers/media/pci/cx23885/Makefile
+++ b/drivers/media/pci/cx23885/Makefile
@@ -8,7 +8,6 @@ cx23885-objs := cx23885-cards.o cx23885-video.o cx23885-vbi.o \
obj-$(CONFIG_VIDEO_CX23885) += cx23885.o
obj-$(CONFIG_MEDIA_ALTERA_CI) += altera-ci.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
ccflags-y += -Idrivers/media/dvb-frontends
diff --git a/drivers/media/pci/cx25821/Makefile b/drivers/media/pci/cx25821/Makefile
index d14d65b1b042..94633d02ac7f 100644
--- a/drivers/media/pci/cx25821/Makefile
+++ b/drivers/media/pci/cx25821/Makefile
@@ -5,5 +5,3 @@ cx25821-y := cx25821-core.o cx25821-cards.o cx25821-i2c.o \
obj-$(CONFIG_VIDEO_CX25821) += cx25821.o
obj-$(CONFIG_VIDEO_CX25821_ALSA) += cx25821-alsa.o
-
-ccflags-y += -Idrivers/media/i2c
diff --git a/drivers/media/pci/cx88/Makefile b/drivers/media/pci/cx88/Makefile
index dea0e7ac32e8..d0f45d652d6e 100644
--- a/drivers/media/pci/cx88/Makefile
+++ b/drivers/media/pci/cx88/Makefile
@@ -10,7 +10,5 @@ obj-$(CONFIG_VIDEO_CX88_ALSA) += cx88-alsa.o
obj-$(CONFIG_VIDEO_CX88_BLACKBIRD) += cx88-blackbird.o
obj-$(CONFIG_VIDEO_CX88_DVB) += cx88-dvb.o
obj-$(CONFIG_VIDEO_CX88_VP3054) += cx88-vp3054-i2c.o
-
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
ccflags-y += -Idrivers/media/dvb-frontends
diff --git a/drivers/media/pci/ivtv/Makefile b/drivers/media/pci/ivtv/Makefile
index 08987a5d55fc..5de95dbe3256 100644
--- a/drivers/media/pci/ivtv/Makefile
+++ b/drivers/media/pci/ivtv/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv.o
obj-$(CONFIG_VIDEO_IVTV_ALSA) += ivtv-alsa.o
obj-$(CONFIG_VIDEO_FB_IVTV) += ivtvfb.o
-ccflags-y += -I$(srctree)/drivers/media/i2c
ccflags-y += -I$(srctree)/drivers/media/tuners
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
diff --git a/drivers/media/pci/saa7134/Makefile b/drivers/media/pci/saa7134/Makefile
index 959f2766b093..82ac7f31221b 100644
--- a/drivers/media/pci/saa7134/Makefile
+++ b/drivers/media/pci/saa7134/Makefile
@@ -12,7 +12,6 @@ obj-$(CONFIG_VIDEO_SAA7134_ALSA) += saa7134-alsa.o
obj-$(CONFIG_VIDEO_SAA7134_DVB) += saa7134-dvb.o
-ccflags-y += -I$(srctree)/drivers/media/i2c
ccflags-y += -I$(srctree)/drivers/media/tuners
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
ccflags-y += -I$(srctree)/drivers/media/usb/go7007
diff --git a/drivers/media/pci/saa7164/Makefile b/drivers/media/pci/saa7164/Makefile
index 54840d659a5d..dea076744ec9 100644
--- a/drivers/media/pci/saa7164/Makefile
+++ b/drivers/media/pci/saa7164/Makefile
@@ -5,8 +5,5 @@ saa7164-objs := saa7164-cards.o saa7164-core.o saa7164-i2c.o saa7164-dvb.o \
obj-$(CONFIG_VIDEO_SAA7164) += saa7164.o
-ccflags-y += -I$(srctree)/drivers/media/i2c
ccflags-y += -I$(srctree)/drivers/media/tuners
ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
-
-ccflags-y += $(extra-cflags-y) $(extra-cflags-m)
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 003b0bb2cddf..347fba8177b5 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -82,8 +82,6 @@ obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel/
obj-$(CONFIG_VIDEO_STM32_DCMI) += stm32/
-ccflags-y += -I$(srctree)/drivers/media/i2c
-
obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/
obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec/
diff --git a/drivers/media/platform/sti/c8sectpfe/Makefile b/drivers/media/platform/sti/c8sectpfe/Makefile
index 927dd930c943..34d69472b6f0 100644
--- a/drivers/media/platform/sti/c8sectpfe/Makefile
+++ b/drivers/media/platform/sti/c8sectpfe/Makefile
@@ -4,7 +4,6 @@ c8sectpfe-y += c8sectpfe-core.o c8sectpfe-common.o c8sectpfe-dvb.o \
obj-$(CONFIG_DVB_C8SECTPFE) += c8sectpfe.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/common
ccflags-y += -Idrivers/media/dvb-frontends/
ccflags-y += -Idrivers/media/tuners/
diff --git a/drivers/media/usb/cx231xx/Makefile b/drivers/media/usb/cx231xx/Makefile
index 79cf46eb151a..c023d97407de 100644
--- a/drivers/media/usb/cx231xx/Makefile
+++ b/drivers/media/usb/cx231xx/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_VIDEO_CX231XX) += cx231xx.o
obj-$(CONFIG_VIDEO_CX231XX_ALSA) += cx231xx-alsa.o
obj-$(CONFIG_VIDEO_CX231XX_DVB) += cx231xx-dvb.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
ccflags-y += -Idrivers/media/dvb-frontends
ccflags-y += -Idrivers/media/usb/dvb-usb
diff --git a/drivers/media/usb/em28xx/Makefile b/drivers/media/usb/em28xx/Makefile
index c3d3570584e1..8a224007d755 100644
--- a/drivers/media/usb/em28xx/Makefile
+++ b/drivers/media/usb/em28xx/Makefile
@@ -11,6 +11,5 @@ obj-$(CONFIG_VIDEO_EM28XX_ALSA) += em28xx-alsa.o
obj-$(CONFIG_VIDEO_EM28XX_DVB) += em28xx-dvb.o
obj-$(CONFIG_VIDEO_EM28XX_RC) += em28xx-rc.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
ccflags-y += -Idrivers/media/dvb-frontends
diff --git a/drivers/media/usb/hdpvr/Makefile b/drivers/media/usb/hdpvr/Makefile
index 9b8d1463c526..644dd99ffce3 100644
--- a/drivers/media/usb/hdpvr/Makefile
+++ b/drivers/media/usb/hdpvr/Makefile
@@ -1,7 +1,3 @@
hdpvr-objs := hdpvr-control.o hdpvr-core.o hdpvr-video.o hdpvr-i2c.o
obj-$(CONFIG_VIDEO_HDPVR) += hdpvr.o
-
-ccflags-y += -Idrivers/media/i2c
-
-ccflags-y += $(extra-cflags-y) $(extra-cflags-m)
diff --git a/drivers/media/usb/pvrusb2/Makefile b/drivers/media/usb/pvrusb2/Makefile
index 552e4f12c496..9facf6873404 100644
--- a/drivers/media/usb/pvrusb2/Makefile
+++ b/drivers/media/usb/pvrusb2/Makefile
@@ -17,6 +17,5 @@ pvrusb2-objs := pvrusb2-i2c-core.o \
obj-$(CONFIG_VIDEO_PVRUSB2) += pvrusb2.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
ccflags-y += -Idrivers/media/dvb-frontends
diff --git a/drivers/media/usb/stk1160/Makefile b/drivers/media/usb/stk1160/Makefile
index 613471528749..8e6c22fb1803 100644
--- a/drivers/media/usb/stk1160/Makefile
+++ b/drivers/media/usb/stk1160/Makefile
@@ -6,5 +6,3 @@ stk1160-y := stk1160-core.o \
stk1160-ac97.o
obj-$(CONFIG_VIDEO_STK1160) += stk1160.o
-
-ccflags-y += -Idrivers/media/i2c
diff --git a/drivers/media/usb/tm6000/Makefile b/drivers/media/usb/tm6000/Makefile
index 62f8528daef2..744c039e621a 100644
--- a/drivers/media/usb/tm6000/Makefile
+++ b/drivers/media/usb/tm6000/Makefile
@@ -10,6 +10,5 @@ obj-$(CONFIG_VIDEO_TM6000) += tm6000.o
obj-$(CONFIG_VIDEO_TM6000_ALSA) += tm6000-alsa.o
obj-$(CONFIG_VIDEO_TM6000_DVB) += tm6000-dvb.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
ccflags-y += -Idrivers/media/dvb-frontends
diff --git a/drivers/media/usb/usbvision/Makefile b/drivers/media/usb/usbvision/Makefile
index 9b3a5581df42..494d030b4979 100644
--- a/drivers/media/usb/usbvision/Makefile
+++ b/drivers/media/usb/usbvision/Makefile
@@ -2,5 +2,4 @@ usbvision-objs := usbvision-core.o usbvision-video.o usbvision-i2c.o usbvision-
obj-$(CONFIG_VIDEO_USBVISION) += usbvision.o
-ccflags-y += -Idrivers/media/i2c
ccflags-y += -Idrivers/media/tuners
--
2.14.3
^ permalink raw reply related
* [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Russell King - ARM Linux @ 2017-12-28 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228100416.GD2626@kwain>
On Thu, Dec 28, 2017 at 11:04:16AM +0100, Antoine Tenart wrote:
> Hi Russell,
>
> On Wed, Dec 27, 2017 at 11:20:00PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Dec 27, 2017 at 11:42:52PM +0100, Antoine Tenart wrote:
> > >
> > > What do you suggest to describe this in the dt, to enable a port using
> > > the current PPv2 driver?
> >
> > I don't - I'm merely pointing out that you're bodging support for the
> > SFP cage rather than productively discussing phylink for mvpp2.
> >
> > As far as I remember, the discussion stalled at this point:
> >
> > - You think there's modes that mvpp2 supports that are not supportable
> > if you use phylink.
> >
> > - I've described what phylink supports, and I've asked you for details
> > about what you can't support.
>
> That's not what I remembered. You had some valid points, and others
> related to PHY modes the driver wasn't supporting before the phylink
> transition. My understanding of this was that you wanted a full
> featured support while I only wanted to convert the already supported
> modes.
You are mistaken - you can get a full refresher on where things were
at via https://patchwork.kernel.org/patch/9963971/
There are two points in that thread where discussion stopped awaiting
input:
1. I asked for details about what mvpp2.c supports that phylink does
not (as you indicated that there were certain things that mvpp2
supports that phylink does not.) I'm still awaiting a response.
2. 25th Sept, you indicated that you would get someone to test
an issue related to in-band AN. No results of that testing have
been forthcoming.
Consequently, the ball is in your court on both these issues.
I am not after a full featured support, what I'm after is ensuring
that phylink is (a) used correctly and (b) implementations using it
are correct. Part of that is ensuring that users don't introduce
unexpected failure conditions.
So, when you do this in the validate() callback:
+ phylink_set(mask, 1000baseX_Full);
and then do this in the mac_config() callback:
+ if (!phy_interface_mode_is_rgmii(port->phy_interface) &&
+ port->phy_interface != PHY_INTERFACE_MODE_SGMII)
+ return;
and this in the link_state() callback:
+ if (!phy_interface_mode_is_rgmii(port->phy_interface) &&
+ port->phy_interface != PHY_INTERFACE_MODE_SGMII)
+ return 0;
the result is that phylink thinks that you support 1000base-X modes,
and it will call mac_config() asking for 1000base-X, but you silently
ignore that, leaving the hardware configured in whatever state it was.
That leads to a silent failure as far as the user is concerned.
So, if you do not intend to support 1000base-X initially, don't
allow it in the validate callback until you do.
It gets worse, because the return in link_state() means that phylink
thinks that the link is up if it has requested 1000base-X, which it
won't be unless you've properly configured it.
It's this kind of unreliability that I was concerned about in your
patch. I'm not demanding "full featured implementation" but I do
want you to use it correctly.
> You're probably right about not wanting this dt patch. The non-dt
> patches still are relevant regardless of phylink being supported in the
> PPv2 driver. I'll send a v2 without the dt parts.
Thanks.
> > What I'm most concerned about, given the bindings for comphy that
> > have been merged, is that Free Electrons is pushing forward seemingly
> > with no regard to the requirement that the serdes lanes are dynamically
> > reconfigurable, and that's a basic requirement for SFP, and for the
> > 88x3310 PHYs on the Macchiatobin platform.
>
> The main idea behind the comphy driver is to provide a way to
> reconfigure the serdes lanes at runtime. Could you develop what are
> blocking points to properly support SFP, regarding the current comphy
> support?
If it supports serdes lane mode reconfiguration (iow, switching between
1000base-X, 2500base-X, SGMII, 10G-KR), then that's all that's required.
Note that you need comphy to switch between SGMII / 10G-KR to support
the 88x3310 fully too.
Having looked deeper at this, it seems it does have the capability of
doing what's required, sorry for the noise.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [RFC PATCH clk] clk: si5351: _si5351_clkout_reset_pll() can be static
From: Stephen Boyd @ 2017-12-28 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227042513.GA56372@ivb42>
On 12/27, kbuild test robot wrote:
>
> Fixes: b26ff127c52c ("clk: si5351: Apply PLL soft reset before enabling the outputs")
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.16
From: Stephen Boyd @ 2017-12-28 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228082524.GA13649@wens.csie.org>
On 12/28, Chen-Yu Tsai wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.16
>
> for you to fetch changes up to e952ca3c6b2ffdfbf9618e4bd3e9aad1ff3f5eb4:
>
> clk: sunxi-ng: sun8i: a83t: Use sigma-delta modulation for audio PLL (2017-12-08 10:08:32 +0100)
>
Thanks. Pulled.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Russell King - ARM Linux @ 2017-12-28 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228182739.GH2626@kwain>
On Thu, Dec 28, 2017 at 07:27:39PM +0100, Antoine Tenart wrote:
> Hi Florian,
>
> On Thu, Dec 28, 2017 at 07:02:09AM -0800, Florian Fainelli wrote:
> > On 12/28/2017 02:05 AM, Antoine Tenart wrote:
> > > On Thu, Dec 28, 2017 at 08:46:23AM +0100, Andrew Lunn wrote:
> > >> On Wed, Dec 27, 2017 at 10:24:01PM +0000, Russell King - ARM Linux wrote:
> > >>> On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
> > >>>>
> > >>>> +&cps_eth2 {
> > >>>> + /* CPS Lane 5 */
> > >>>> + status = "okay";
> > >>>> + phy-mode = "2500base-x";
> > >>>> + /* Generic PHY, providing serdes lanes */
> > >>>> + phys = <&cps_comphy5 2>;
> > >>>> +};
> > >>>> +
> > >>>
> > >>> This is wrong. This lane is connected to a SFP cage which can support
> > >>> more than just 2500base-X. Tying it in this way to 2500base-X means
> > >>> that this port does not support conenctions at 1000base-X, despite
> > >>> that's one of the most popular and more standardised speeds.
> > >>>
> > >>
> > >> I agree with Russell here. SFP modules are hot pluggable, and support
> > >> a range of interface modes. You need to query what the SFP module is
> > >> in order to know how to configure the SERDES interface. The phylink
> > >> infrastructure does that for you.
> > >
> > > Sure, I understand. We'll be able to support such interfaces only when
> > > the phylink PPv2 support lands in.
> >
> > Should we expect PHYLINK support to make it as the first patch in your
> > v2 of this patch series, or is someone else doing that?
>
> No, the phylink patch conflicts with Marcin's ACPI series and we agreed
> to let him get his series merged first. And I will probably work on a
> few other topics before having the chance to work on it. So it'll
> probably be me doing that, but not right now.
ACPI is going to be a problem with phylink for a while. There's patches
queued in net-next which convert phylink and SFP mostly to the fwnode
and property based systems, but phylib and i2c do not seem to have the
necessary bits to be able to deal with those.
Specifically, in DT we have "of_find_i2c_adapter_by_node()" but afaics
there is no equivalent in ACPI - which means in an ACPI based system
we have no way to determine the I2C bus associated with a SFP socket,
which is a rather fundamental issue for SFP modules.
For phylib side, there's "of_phy_attach()" but again there is no
equivalent in ACPI. This should not be that much of a problem, because
network drivers using the DT phylib calls (eg, "of_phy_connect()") are
already restricted by this. That may have been solved by Marcin's
series, but I've not seen it to know.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] clk: pxa: unbreak lookup of CLK_POUT
From: Stephen Boyd @ 2017-12-28 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171226133036.11432-1-grinberg@compulab.co.il>
On 12/26, Igor Grinberg wrote:
> Since switching to clk drivers, the CLK_POUT cannot be searched for by
> clk_get() API and thus it returns with ENOENT.
> Register it with the clk_lookup and thus unbreak the users of it.
>
> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH -next] clk: meson-axg: fix return value check in axg_clkc_probe()
From: Stephen Boyd @ 2017-12-28 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514428849-61681-1-git-send-email-weiyongjun1@huawei.com>
On 12/28, Wei Yongjun wrote:
> In case of error, the function devm_ioremap() returns NULL pointer
> not ERR_PTR(). The IS_ERR() test in the return value check should be
> replaced with NULL test.
>
> Fixes: 78b4af312f91 ("clk: meson-axg: add clock controller drivers")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH -next] clk: meson-axg: make local symbol axg_gp0_params_table static
From: Stephen Boyd @ 2017-12-28 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514431110-98277-1-git-send-email-weiyongjun1@huawei.com>
On 12/28, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> drivers/clk/meson/axg.c:260:25: warning:
> symbol 'axg_gp0_params_table' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Antoine Tenart @ 2017-12-28 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <462da70b-ba7d-6299-3e21-b619d3c4c7e6@gmail.com>
Hi Florian,
On Thu, Dec 28, 2017 at 07:02:09AM -0800, Florian Fainelli wrote:
> On 12/28/2017 02:05 AM, Antoine Tenart wrote:
> > On Thu, Dec 28, 2017 at 08:46:23AM +0100, Andrew Lunn wrote:
> >> On Wed, Dec 27, 2017 at 10:24:01PM +0000, Russell King - ARM Linux wrote:
> >>> On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
> >>>>
> >>>> +&cps_eth2 {
> >>>> + /* CPS Lane 5 */
> >>>> + status = "okay";
> >>>> + phy-mode = "2500base-x";
> >>>> + /* Generic PHY, providing serdes lanes */
> >>>> + phys = <&cps_comphy5 2>;
> >>>> +};
> >>>> +
> >>>
> >>> This is wrong. This lane is connected to a SFP cage which can support
> >>> more than just 2500base-X. Tying it in this way to 2500base-X means
> >>> that this port does not support conenctions at 1000base-X, despite
> >>> that's one of the most popular and more standardised speeds.
> >>>
> >>
> >> I agree with Russell here. SFP modules are hot pluggable, and support
> >> a range of interface modes. You need to query what the SFP module is
> >> in order to know how to configure the SERDES interface. The phylink
> >> infrastructure does that for you.
> >
> > Sure, I understand. We'll be able to support such interfaces only when
> > the phylink PPv2 support lands in.
>
> Should we expect PHYLINK support to make it as the first patch in your
> v2 of this patch series, or is someone else doing that?
No, the phylink patch conflicts with Marcin's ACPI series and we agreed
to let him get his series merged first. And I will probably work on a
few other topics before having the chance to work on it. So it'll
probably be me doing that, but not right now.
This isn't an issue regarding the PPv2 and PHY patches of this series,
but yes we probably won't get the fourth network interface supported on
the mcbin during this release.
Thanks!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH net-next 1/6] phy: add 2.5G SGMII mode to the phy_mode enum
From: Antoine Tenart @ 2017-12-28 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <91838ce5-a1a8-c41a-36e8-bef7adaf82fd@gmail.com>
Hi Florian,
On Thu, Dec 28, 2017 at 06:16:51AM -0800, Florian Fainelli wrote:
>
> And since you are respinning, please make sure you update phy_modes() in
> the same header file as well as
> Documentation/devicetree/bindings/net/ethernet.txt with the newly added
> PHY interface mode.
You're right. Thanks for pointing this out!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH net-next v9 0/2] add UniPhier AVE ethernet support
From: David Miller @ 2017-12-28 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514444292-20643-1-git-send-email-hayashi.kunihiko@socionext.com>
From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date: Thu, 28 Dec 2017 15:58:10 +0900
> This series adds support for Socionext AVE ethernet controller implemented
> on UniPhier SoCs. This driver supports RGMII/RMII modes.
Series applied.
^ permalink raw reply
* [PATCH 2/2] perf: arm_spe: Delete an unnecessary return statement in __arm_spe_pmu_dev_probe()
From: SF Markus Elfring @ 2017-12-28 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8a92bb8f-4295-6912-19a4-9103226a3c62@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 28 Dec 2017 17:34:54 +0100
The script "checkpatch.pl" pointed information out like the following.
WARNING: void function return statements are not generally useful
Thus remove such a statement in the affected function.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/perf/arm_spe_pmu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index 27fac8907d1d..b30654f75a8c 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -1033,7 +1033,6 @@ static void __arm_spe_pmu_dev_probe(void *info)
spe_pmu->max_record_sz, spe_pmu->align, spe_pmu->features);
spe_pmu->features |= SPE_PMU_FEAT_DEV_PROBED;
- return;
}
static void __arm_spe_pmu_reset_local(void)
--
2.15.1
^ permalink raw reply related
* [PATCH 1/2] perf: arm_spe: Delete an error message for a failed memory allocation in arm_spe_pmu_device_dt_probe()
From: SF Markus Elfring @ 2017-12-28 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8a92bb8f-4295-6912-19a4-9103226a3c62@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 28 Dec 2017 17:27:23 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/perf/arm_spe_pmu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index 8ce262fc2561..27fac8907d1d 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -1166,9 +1166,7 @@ static int arm_spe_pmu_device_dt_probe(struct platform_device *pdev)
spe_pmu = devm_kzalloc(dev, sizeof(*spe_pmu), GFP_KERNEL);
- if (!spe_pmu) {
- dev_err(dev, "failed to allocate spe_pmu\n");
+ if (!spe_pmu)
return -ENOMEM;
- }
spe_pmu->handle = alloc_percpu(typeof(*spe_pmu->handle));
if (!spe_pmu->handle)
--
2.15.1
^ permalink raw reply related
* [PATCH 0/2] Perf-ARM SPE: Adjustments for two function implementations
From: SF Markus Elfring @ 2017-12-28 17:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 28 Dec 2017 17:56:54 +0100
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an error message for a failed memory allocation
in arm_spe_pmu_device_dt_probe()
Delete an unnecessary return statement in __arm_spe_pmu_dev_probe()
drivers/perf/arm_spe_pmu.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH v2 0/2] sun8i-a83t: Add touchscreen support on TBS A711
From: Mylene JOSSERAND @ 2017-12-28 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228163336.28131-1-mylene.josserand@free-electrons.com>
Hello,
Le Thu, 28 Dec 2017 17:33:34 +0100,
Myl?ne Josserand <mylene.josserand@free-electrons.com> a ?crit :
> Hello everyone,
>
> This is a V2 of the patch series that adds touchscreen support
> (FocalTech EDT-FT5x06 Polytouch) for TBS A711 (Allwinner sun8i-a83t SoC).
> Based on last linux-next (next-20171222).
>
> Changes since v1:
> - Remove patches 01 and 02 as Chen-Yu Tsai sent a similar patch:
> https://patchwork.kernel.org/patch/10111431/
> and it is merged on last next-20171222.
> (See commit f066f46ce5a5 "ARM: dts: sun8i: a83t: Add I2C device nodes and pinmux settings")
> - Update regulator according to Dmitry Torokhov's review: remove "optional"
> suffix while retrieving the regulator, rename it into "vcc" instead of
> "power" and add bindings documentation.
I notice that I forgot the second review of Dmitry about reset/wake
gpios so I will send a V3 with the modifications.
Thanks,
Myl?ne
> - Update device tree according to Maxime Ripard's review: remove the
> label and rename the node.
> - Squash patch 03 with patch 05 to add I2C0 and touchscreen's node
> in one patch (see patch 02).
>
> Patch 01: Add support for regulator in the FocalTech touchscreen driver
> because A711 tablet is using a regulator to power-up the touchscreen.
> Patch 02: Add i2c0 and touchscreen's node for A711 TBS tablet.
>
> Thank you in advance for any review.
> Best regards,
> Myl?ne
>
> Myl?ne Josserand (2):
> Input: edt-ft5x06 - Add support for regulator
> arm: dts: sun8i: a83t: a711: Add touchscreen node
>
> .../bindings/input/touchscreen/edt-ft5x06.txt | 1 +
> arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 16 +++++++++++
> drivers/input/touchscreen/edt-ft5x06.c | 33 ++++++++++++++++++++++
> 3 files changed, 50 insertions(+)
>
^ permalink raw reply
* [PATCH v6 8/8] x86/kernel: jump_table: use relative references
From: Steven Rostedt @ 2017-12-28 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9Gza=RN_v_H-G7m7-qKg9B4Xf4GFvd_H-Gut-V3eabmA@mail.gmail.com>
On Thu, 28 Dec 2017 16:26:07 +0000
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 28 December 2017 at 16:19, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Wed, 27 Dec 2017 08:50:33 +0000
> > Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >
> >> static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
> >> {
> >> - return entry->code;
> >> + return (jump_label_t)&entry->code + entry->code;
> >
> > I'm paranoid about doing arithmetic on abstract types. What happens in
> > the future if jump_label_t becomes a pointer? You will get a different
> > result.
> >
>
> In general, I share your concern. In this case, however, jump_label_t
> is typedef'd three lines up and is never used anywhere else.
I would agree if this was in a .c file, but it's in a header file,
which causes me to be more paranoid.
>
> > Could we switch these calculations to something like:
> >
> > return (jump_label_t)((long)&entrty->code + entry->code);
> >
>
> jump_label_t is local to this .h file, so it can be defined as u32 or
> u64 depending on the word size. I don't mind adding the extra cast,
> but I am not sure if your paranoia is justified in this particular
> case. Perhaps we should just use 'unsigned long' throughout?
Actually, that may be better. Have the return value be jump_label_t,
but the cast be "unsigned long". That way it should always work.
static inline jump_label_t jump_entry_code(...)
{
return (unsigned long)&entry->code + entry->code;
}
-- Steve
^ permalink raw reply
* [PATCH v2 2/2] arm: dts: sun8i: a83t: a711: Add touchscreen node
From: Mylène Josserand @ 2017-12-28 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228163336.28131-1-mylene.josserand@free-electrons.com>
Tha A711 tablet has a FocalTech EDT-FT5x06 Polytouch touchscreen.
It is connected via I2C0. The reset line is PD5, the interrupt
line is PL7 and the VCC supply is the ldo_io0 regulator.
Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
---
arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
index a021ee6da396..7840f9aa9094 100644
--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
@@ -105,6 +105,22 @@
status = "okay";
};
+&i2c0 {
+ clock-frequency = <400000>;
+ status = "okay";
+
+ touchscreen at 38 {
+ compatible = "edt,edt-ft5x06";
+ reg = <0x38>;
+ interrupt-parent = <&r_pio>;
+ interrupts = <0 7 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&pio 3 5 GPIO_ACTIVE_LOW>;
+ vcc-supply = <®_ldo_io0>;
+ touchscreen-size-x = <1024>;
+ touchscreen-size-y = <600>;
+ };
+};
+
&mmc0 {
vmmc-supply = <®_dcdc1>;
pinctrl-names = "default";
--
2.11.0
^ permalink raw reply related
* [PATCH v2 1/2] Input: edt-ft5x06 - Add support for regulator
From: Mylène Josserand @ 2017-12-28 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228163336.28131-1-mylene.josserand@free-electrons.com>
Add the support of regulator to use it as VCC source.
Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
---
.../bindings/input/touchscreen/edt-ft5x06.txt | 1 +
drivers/input/touchscreen/edt-ft5x06.c | 33 ++++++++++++++++++++++
2 files changed, 34 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
index 025cf8c9324a..48e975b9c1aa 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
@@ -30,6 +30,7 @@ Required properties:
Optional properties:
- reset-gpios: GPIO specification for the RESET input
- wake-gpios: GPIO specification for the WAKE input
+ - vcc-supply: Regulator that supplies the touchscreen
- pinctrl-names: should be "default"
- pinctrl-0: a phandle pointing to the pin settings for the
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index c53a3d7239e7..5ee14a25a382 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -39,6 +39,7 @@
#include <linux/input/mt.h>
#include <linux/input/touchscreen.h>
#include <linux/of_device.h>
+#include <linux/regulator/consumer.h>
#define WORK_REGISTER_THRESHOLD 0x00
#define WORK_REGISTER_REPORT_RATE 0x08
@@ -91,6 +92,7 @@ struct edt_ft5x06_ts_data {
struct touchscreen_properties prop;
u16 num_x;
u16 num_y;
+ struct regulator *vcc;
struct gpio_desc *reset_gpio;
struct gpio_desc *wake_gpio;
@@ -993,6 +995,23 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
tsdata->max_support_points = chip_data->max_support_points;
+ tsdata->vcc = devm_regulator_get(&client->dev, "vcc");
+ if (IS_ERR(tsdata->vcc)) {
+ error = PTR_ERR(tsdata->vcc);
+ dev_err(&client->dev, "failed to request regulator: %d\n",
+ error);
+ return error;
+ };
+
+ if (tsdata->vcc) {
+ error = regulator_enable(tsdata->vcc);
+ if (error < 0) {
+ dev_err(&client->dev, "failed to enable vcc: %d\n",
+ error);
+ return error;
+ }
+ }
+
tsdata->reset_gpio = devm_gpiod_get_optional(&client->dev,
"reset", GPIOD_OUT_HIGH);
if (IS_ERR(tsdata->reset_gpio)) {
@@ -1122,20 +1141,34 @@ static int edt_ft5x06_ts_remove(struct i2c_client *client)
static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
+ struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
if (device_may_wakeup(dev))
enable_irq_wake(client->irq);
+ if (tsdata->vcc)
+ regulator_disable(tsdata->vcc);
+
return 0;
}
static int __maybe_unused edt_ft5x06_ts_resume(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
+ struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
+ int ret;
if (device_may_wakeup(dev))
disable_irq_wake(client->irq);
+ if (tsdata->vcc) {
+ ret = regulator_enable(tsdata->vcc);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable vcc: %d\n", ret);
+ return ret;
+ }
+ }
+
return 0;
}
--
2.11.0
^ permalink raw reply related
* [PATCH v2 0/2] sun8i-a83t: Add touchscreen support on TBS A711
From: Mylène Josserand @ 2017-12-28 16:33 UTC (permalink / raw)
To: linux-arm-kernel
Hello everyone,
This is a V2 of the patch series that adds touchscreen support
(FocalTech EDT-FT5x06 Polytouch) for TBS A711 (Allwinner sun8i-a83t SoC).
Based on last linux-next (next-20171222).
Changes since v1:
- Remove patches 01 and 02 as Chen-Yu Tsai sent a similar patch:
https://patchwork.kernel.org/patch/10111431/
and it is merged on last next-20171222.
(See commit f066f46ce5a5 "ARM: dts: sun8i: a83t: Add I2C device nodes and pinmux settings")
- Update regulator according to Dmitry Torokhov's review: remove "optional"
suffix while retrieving the regulator, rename it into "vcc" instead of
"power" and add bindings documentation.
- Update device tree according to Maxime Ripard's review: remove the
label and rename the node.
- Squash patch 03 with patch 05 to add I2C0 and touchscreen's node
in one patch (see patch 02).
Patch 01: Add support for regulator in the FocalTech touchscreen driver
because A711 tablet is using a regulator to power-up the touchscreen.
Patch 02: Add i2c0 and touchscreen's node for A711 TBS tablet.
Thank you in advance for any review.
Best regards,
Myl?ne
Myl?ne Josserand (2):
Input: edt-ft5x06 - Add support for regulator
arm: dts: sun8i: a83t: a711: Add touchscreen node
.../bindings/input/touchscreen/edt-ft5x06.txt | 1 +
arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 16 +++++++++++
drivers/input/touchscreen/edt-ft5x06.c | 33 ++++++++++++++++++++++
3 files changed, 50 insertions(+)
--
2.11.0
^ permalink raw reply
* [PATCH v6 8/8] x86/kernel: jump_table: use relative references
From: Ard Biesheuvel @ 2017-12-28 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228111926.28e82877@gandalf.local.home>
On 28 December 2017 at 16:19, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 27 Dec 2017 08:50:33 +0000
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
>> static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
>> {
>> - return entry->code;
>> + return (jump_label_t)&entry->code + entry->code;
>
> I'm paranoid about doing arithmetic on abstract types. What happens in
> the future if jump_label_t becomes a pointer? You will get a different
> result.
>
In general, I share your concern. In this case, however, jump_label_t
is typedef'd three lines up and is never used anywhere else.
> Could we switch these calculations to something like:
>
> return (jump_label_t)((long)&entrty->code + entry->code);
>
jump_label_t is local to this .h file, so it can be defined as u32 or
u64 depending on the word size. I don't mind adding the extra cast,
but I am not sure if your paranoia is justified in this particular
case. Perhaps we should just use 'unsigned long' throughout?
>> +}
>> +
>> +static inline jump_label_t jump_entry_target(const struct jump_entry *entry)
>> +{
>> + return (jump_label_t)&entry->target + entry->target;
>> }
>>
>> static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
>> {
>> - return (struct static_key *)((unsigned long)entry->key & ~1UL);
>> + unsigned long key = (unsigned long)&entry->key + entry->key;
>> +
>> + return (struct static_key *)(key & ~1UL);
>> }
>>
>> static inline bool jump_entry_is_branch(const struct jump_entry *entry)
>> @@ -99,7 +106,7 @@ static inline void jump_entry_set_module_init(struct jump_entry *entry)
>> entry->code = 0;
>> }
>>
>> -#define jump_label_swap NULL
>> +void jump_label_swap(void *a, void *b, int size);
>>
>> #else /* __ASSEMBLY__ */
>>
>> @@ -114,8 +121,8 @@ static inline void jump_entry_set_module_init(struct jump_entry *entry)
>> .byte STATIC_KEY_INIT_NOP
>> .endif
>> .pushsection __jump_table, "aw"
>> - _ASM_ALIGN
>> - _ASM_PTR .Lstatic_jump_\@, \target, \key
>> + .balign 4
>> + .long .Lstatic_jump_\@ - ., \target - ., \key - .
>> .popsection
>> .endm
>>
>> @@ -130,8 +137,8 @@ static inline void jump_entry_set_module_init(struct jump_entry *entry)
>> .Lstatic_jump_after_\@:
>> .endif
>> .pushsection __jump_table, "aw"
>> - _ASM_ALIGN
>> - _ASM_PTR .Lstatic_jump_\@, \target, \key + 1
>> + .balign 4
>> + .long .Lstatic_jump_\@ - ., \target - ., \key - . + 1
>> .popsection
>> .endm
>>
>> diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
>> index e56c95be2808..cc5034b42335 100644
>> --- a/arch/x86/kernel/jump_label.c
>> +++ b/arch/x86/kernel/jump_label.c
>> @@ -52,22 +52,24 @@ static void __jump_label_transform(struct jump_entry *entry,
>> * Jump label is enabled for the first time.
>> * So we expect a default_nop...
>> */
>> - if (unlikely(memcmp((void *)entry->code, default_nop, 5)
>> - != 0))
>> - bug_at((void *)entry->code, __LINE__);
>> + if (unlikely(memcmp((void *)jump_entry_code(entry),
>> + default_nop, 5) != 0))
>> + bug_at((void *)jump_entry_code(entry),
>
> You have the functions already made before this patch. Perhaps we
> should have a separate patch to use them (here and elsewhere) before
> you make the conversion to using relative references. It will help out
> in debugging and bisects. To know if the use of functions is an issue,
> or the conversion of relative references is an issue.
>
> I suggest splitting this into two patches.
>
Fair enough.
>> + __LINE__);
>> } else {
>> /*
>> * ...otherwise expect an ideal_nop. Otherwise
>> * something went horribly wrong.
>> */
>> - if (unlikely(memcmp((void *)entry->code, ideal_nop, 5)
>> - != 0))
>> - bug_at((void *)entry->code, __LINE__);
>> + if (unlikely(memcmp((void *)jump_entry_code(entry),
>> + ideal_nop, 5) != 0))
>> + bug_at((void *)jump_entry_code(entry),
>> + __LINE__);
>> }
>>
>> code.jump = 0xe9;
>> - code.offset = entry->target -
>> - (entry->code + JUMP_LABEL_NOP_SIZE);
>> + code.offset = jump_entry_target(entry) -
>> + (jump_entry_code(entry) + JUMP_LABEL_NOP_SIZE);
>> } else {
>> /*
>> * We are disabling this jump label. If it is not what
>> @@ -76,14 +78,18 @@ static void __jump_label_transform(struct jump_entry *entry,
>> * are converting the default nop to the ideal nop.
>> */
>> if (init) {
>> - if (unlikely(memcmp((void *)entry->code, default_nop, 5) != 0))
>> - bug_at((void *)entry->code, __LINE__);
>> + if (unlikely(memcmp((void *)jump_entry_code(entry),
>> + default_nop, 5) != 0))
>> + bug_at((void *)jump_entry_code(entry),
>> + __LINE__);
>> } else {
>> code.jump = 0xe9;
>> - code.offset = entry->target -
>> - (entry->code + JUMP_LABEL_NOP_SIZE);
>> - if (unlikely(memcmp((void *)entry->code, &code, 5) != 0))
>> - bug_at((void *)entry->code, __LINE__);
>> + code.offset = jump_entry_target(entry) -
>> + (jump_entry_code(entry) + JUMP_LABEL_NOP_SIZE);
>> + if (unlikely(memcmp((void *)jump_entry_code(entry),
>> + &code, 5) != 0))
>> + bug_at((void *)jump_entry_code(entry),
>> + __LINE__);
>> }
>> memcpy(&code, ideal_nops[NOP_ATOMIC5], JUMP_LABEL_NOP_SIZE);
>> }
>> @@ -97,10 +103,13 @@ static void __jump_label_transform(struct jump_entry *entry,
>> *
>> */
>> if (poker)
>> - (*poker)((void *)entry->code, &code, JUMP_LABEL_NOP_SIZE);
>> + (*poker)((void *)jump_entry_code(entry), &code,
>> + JUMP_LABEL_NOP_SIZE);
>> else
>> - text_poke_bp((void *)entry->code, &code, JUMP_LABEL_NOP_SIZE,
>> - (void *)entry->code + JUMP_LABEL_NOP_SIZE);
>> + text_poke_bp((void *)jump_entry_code(entry), &code,
>> + JUMP_LABEL_NOP_SIZE,
>> + (void *)jump_entry_code(entry) +
>> + JUMP_LABEL_NOP_SIZE);
>> }
>>
>> void arch_jump_label_transform(struct jump_entry *entry,
>> @@ -140,4 +149,20 @@ __init_or_module void arch_jump_label_transform_static(struct jump_entry *entry,
>> __jump_label_transform(entry, type, text_poke_early, 1);
>> }
>>
>> +void jump_label_swap(void *a, void *b, int size)
>> +{
>> + long delta = (unsigned long)a - (unsigned long)b;
>> + struct jump_entry *jea = a;
>> + struct jump_entry *jeb = b;
>> + struct jump_entry tmp = *jea;
>> +
>> + jea->code = jeb->code - delta;
>> + jea->target = jeb->target - delta;
>> + jea->key = jeb->key - delta;
>> +
>> + jeb->code = tmp.code + delta;
>> + jeb->target = tmp.target + delta;
>> + jeb->key = tmp.key + delta;
>> +}
>> +
>> #endif
>> diff --git a/tools/objtool/special.c b/tools/objtool/special.c
>> index 84f001d52322..98ae55b39037 100644
>> --- a/tools/objtool/special.c
>> +++ b/tools/objtool/special.c
>> @@ -30,9 +30,9 @@
>> #define EX_ORIG_OFFSET 0
>> #define EX_NEW_OFFSET 4
>>
>> -#define JUMP_ENTRY_SIZE 24
>> +#define JUMP_ENTRY_SIZE 12
>> #define JUMP_ORIG_OFFSET 0
>> -#define JUMP_NEW_OFFSET 8
>> +#define JUMP_NEW_OFFSET 4
>>
>> #define ALT_ENTRY_SIZE 13
>> #define ALT_ORIG_OFFSET 0
>
^ permalink raw reply
* [PATCH v6 8/8] x86/kernel: jump_table: use relative references
From: Steven Rostedt @ 2017-12-28 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227085033.22389-9-ard.biesheuvel@linaro.org>
On Wed, 27 Dec 2017 08:50:33 +0000
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
> {
> - return entry->code;
> + return (jump_label_t)&entry->code + entry->code;
I'm paranoid about doing arithmetic on abstract types. What happens in
the future if jump_label_t becomes a pointer? You will get a different
result.
Could we switch these calculations to something like:
return (jump_label_t)((long)&entrty->code + entry->code);
> +}
> +
> +static inline jump_label_t jump_entry_target(const struct jump_entry *entry)
> +{
> + return (jump_label_t)&entry->target + entry->target;
> }
>
> static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
> {
> - return (struct static_key *)((unsigned long)entry->key & ~1UL);
> + unsigned long key = (unsigned long)&entry->key + entry->key;
> +
> + return (struct static_key *)(key & ~1UL);
> }
>
> static inline bool jump_entry_is_branch(const struct jump_entry *entry)
> @@ -99,7 +106,7 @@ static inline void jump_entry_set_module_init(struct jump_entry *entry)
> entry->code = 0;
> }
>
> -#define jump_label_swap NULL
> +void jump_label_swap(void *a, void *b, int size);
>
> #else /* __ASSEMBLY__ */
>
> @@ -114,8 +121,8 @@ static inline void jump_entry_set_module_init(struct jump_entry *entry)
> .byte STATIC_KEY_INIT_NOP
> .endif
> .pushsection __jump_table, "aw"
> - _ASM_ALIGN
> - _ASM_PTR .Lstatic_jump_\@, \target, \key
> + .balign 4
> + .long .Lstatic_jump_\@ - ., \target - ., \key - .
> .popsection
> .endm
>
> @@ -130,8 +137,8 @@ static inline void jump_entry_set_module_init(struct jump_entry *entry)
> .Lstatic_jump_after_\@:
> .endif
> .pushsection __jump_table, "aw"
> - _ASM_ALIGN
> - _ASM_PTR .Lstatic_jump_\@, \target, \key + 1
> + .balign 4
> + .long .Lstatic_jump_\@ - ., \target - ., \key - . + 1
> .popsection
> .endm
>
> diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
> index e56c95be2808..cc5034b42335 100644
> --- a/arch/x86/kernel/jump_label.c
> +++ b/arch/x86/kernel/jump_label.c
> @@ -52,22 +52,24 @@ static void __jump_label_transform(struct jump_entry *entry,
> * Jump label is enabled for the first time.
> * So we expect a default_nop...
> */
> - if (unlikely(memcmp((void *)entry->code, default_nop, 5)
> - != 0))
> - bug_at((void *)entry->code, __LINE__);
> + if (unlikely(memcmp((void *)jump_entry_code(entry),
> + default_nop, 5) != 0))
> + bug_at((void *)jump_entry_code(entry),
You have the functions already made before this patch. Perhaps we
should have a separate patch to use them (here and elsewhere) before
you make the conversion to using relative references. It will help out
in debugging and bisects. To know if the use of functions is an issue,
or the conversion of relative references is an issue.
I suggest splitting this into two patches.
-- Steve
> + __LINE__);
> } else {
> /*
> * ...otherwise expect an ideal_nop. Otherwise
> * something went horribly wrong.
> */
> - if (unlikely(memcmp((void *)entry->code, ideal_nop, 5)
> - != 0))
> - bug_at((void *)entry->code, __LINE__);
> + if (unlikely(memcmp((void *)jump_entry_code(entry),
> + ideal_nop, 5) != 0))
> + bug_at((void *)jump_entry_code(entry),
> + __LINE__);
> }
>
> code.jump = 0xe9;
> - code.offset = entry->target -
> - (entry->code + JUMP_LABEL_NOP_SIZE);
> + code.offset = jump_entry_target(entry) -
> + (jump_entry_code(entry) + JUMP_LABEL_NOP_SIZE);
> } else {
> /*
> * We are disabling this jump label. If it is not what
> @@ -76,14 +78,18 @@ static void __jump_label_transform(struct jump_entry *entry,
> * are converting the default nop to the ideal nop.
> */
> if (init) {
> - if (unlikely(memcmp((void *)entry->code, default_nop, 5) != 0))
> - bug_at((void *)entry->code, __LINE__);
> + if (unlikely(memcmp((void *)jump_entry_code(entry),
> + default_nop, 5) != 0))
> + bug_at((void *)jump_entry_code(entry),
> + __LINE__);
> } else {
> code.jump = 0xe9;
> - code.offset = entry->target -
> - (entry->code + JUMP_LABEL_NOP_SIZE);
> - if (unlikely(memcmp((void *)entry->code, &code, 5) != 0))
> - bug_at((void *)entry->code, __LINE__);
> + code.offset = jump_entry_target(entry) -
> + (jump_entry_code(entry) + JUMP_LABEL_NOP_SIZE);
> + if (unlikely(memcmp((void *)jump_entry_code(entry),
> + &code, 5) != 0))
> + bug_at((void *)jump_entry_code(entry),
> + __LINE__);
> }
> memcpy(&code, ideal_nops[NOP_ATOMIC5], JUMP_LABEL_NOP_SIZE);
> }
> @@ -97,10 +103,13 @@ static void __jump_label_transform(struct jump_entry *entry,
> *
> */
> if (poker)
> - (*poker)((void *)entry->code, &code, JUMP_LABEL_NOP_SIZE);
> + (*poker)((void *)jump_entry_code(entry), &code,
> + JUMP_LABEL_NOP_SIZE);
> else
> - text_poke_bp((void *)entry->code, &code, JUMP_LABEL_NOP_SIZE,
> - (void *)entry->code + JUMP_LABEL_NOP_SIZE);
> + text_poke_bp((void *)jump_entry_code(entry), &code,
> + JUMP_LABEL_NOP_SIZE,
> + (void *)jump_entry_code(entry) +
> + JUMP_LABEL_NOP_SIZE);
> }
>
> void arch_jump_label_transform(struct jump_entry *entry,
> @@ -140,4 +149,20 @@ __init_or_module void arch_jump_label_transform_static(struct jump_entry *entry,
> __jump_label_transform(entry, type, text_poke_early, 1);
> }
>
> +void jump_label_swap(void *a, void *b, int size)
> +{
> + long delta = (unsigned long)a - (unsigned long)b;
> + struct jump_entry *jea = a;
> + struct jump_entry *jeb = b;
> + struct jump_entry tmp = *jea;
> +
> + jea->code = jeb->code - delta;
> + jea->target = jeb->target - delta;
> + jea->key = jeb->key - delta;
> +
> + jeb->code = tmp.code + delta;
> + jeb->target = tmp.target + delta;
> + jeb->key = tmp.key + delta;
> +}
> +
> #endif
> diff --git a/tools/objtool/special.c b/tools/objtool/special.c
> index 84f001d52322..98ae55b39037 100644
> --- a/tools/objtool/special.c
> +++ b/tools/objtool/special.c
> @@ -30,9 +30,9 @@
> #define EX_ORIG_OFFSET 0
> #define EX_NEW_OFFSET 4
>
> -#define JUMP_ENTRY_SIZE 24
> +#define JUMP_ENTRY_SIZE 12
> #define JUMP_ORIG_OFFSET 0
> -#define JUMP_NEW_OFFSET 8
> +#define JUMP_NEW_OFFSET 4
>
> #define ALT_ENTRY_SIZE 13
> #define ALT_ORIG_OFFSET 0
^ permalink raw reply
* [PATCH 0/3] [v11] pinctrl: qcom: add support for sparse GPIOs
From: Stephen Boyd @ 2017-12-28 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda5FQg3W4rnxihVB9y2yv-oF1CwBzFJsKB8cxzQ+zoHNg@mail.gmail.com>
On 12/28, Linus Walleij wrote:
> On Wed, Dec 27, 2017 at 3:01 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>
> > The different approaches come down to expressing
> > which pins are available through the gpio valid mask, or through
> > the npins field of the msm pinctrl driver. Also, my approach
> > covers more than just GPIOs, it covers irqs and adjusts the
> > pinctrl pin request function so that pinctrl can't request
> > unavailable pins.
>
> I agree, this is better.
Thanks for the feedback. I'll update and resend my patch to the
list.
>
> Would even patch 1 be needed after this? Maybe I should
> revert that too. Leaving that code in has the upside of showing
> the actual initial directions of GPIO lines even if they have
> not been requested, in e.g. debugfs.
>
Patch 1 is still needed. Without that patch, we'll be poking each
GPIO to figure out the direction at boot without checking any
valid mask or calling the request APIs. I don't see the part in
debugfs where we show the direction of a GPIO if it hasn't been
requested. Don't we skip over the unrequested GPIOs because of
this code in gpiolib_dbg_show()?
if (!test_bit(FLAG_REQUESTED, &gdesc->flags)) {
...
continue;
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v6 5/8] kernel: tracepoints: add support for relative references
From: Steven Rostedt @ 2017-12-28 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227085033.22389-6-ard.biesheuvel@linaro.org>
On Wed, 27 Dec 2017 08:50:30 +0000
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> To avoid the need for relocating absolute references to tracepoint
> structures at boot time when running relocatable kernels (which may
> take a disproportionate amount of space), add the option to emit
> these tables as relative references instead.
>
I gave this patch a quick skim over. It appears to not modify anything
when CONFIG_HAVE_PREL32_RELOCATIONS is not defined. I haven't
thoroughly reviewed it or tested it. But if it doesn't break anything,
I'm fine giving you an ack.
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* [PATCH 2/2] tee: optee: check type of registered shared memory
From: Jens Wiklander @ 2017-12-28 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171228153857.30086-1-jens.wiklander@linaro.org>
Checks the memory type of the pages to be registered as shared memory.
Only normal cached memory is allowed.
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
---
drivers/tee/optee/call.c | 44 ++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
index d61c14b788f2..47b12b7fd02d 100644
--- a/drivers/tee/optee/call.c
+++ b/drivers/tee/optee/call.c
@@ -16,6 +16,7 @@
#include <linux/device.h>
#include <linux/err.h>
#include <linux/errno.h>
+#include <linux/mm.h>
#include <linux/slab.h>
#include <linux/tee_drv.h>
#include <linux/types.h>
@@ -535,6 +536,41 @@ void optee_free_pages_list(void *list, size_t num_entries)
free_pages_exact(list, get_pages_list_size(num_entries));
}
+static bool is_normal_memory(pgprot_t p)
+{
+#if defined(CONFIG_ARM)
+ return (pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEALLOC;
+#elif defined(CONFIG_ARM64)
+ return (pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL);
+#else
+#error "Unuspported architecture"
+#endif
+}
+
+static int __check_mem_type(struct vm_area_struct *vma, unsigned long end)
+{
+ while (vma && is_normal_memory(vma->vm_page_prot)) {
+ if (vma->vm_end >= end)
+ return 0;
+ vma = vma->vm_next;
+ }
+
+ return -EINVAL;
+}
+
+static int check_mem_type(unsigned long start, size_t num_pages)
+{
+ struct mm_struct *mm = current->mm;
+ int rc;
+
+ down_read(&mm->mmap_sem);
+ rc = __check_mem_type(find_vma(mm, start),
+ start + num_pages * PAGE_SIZE);
+ up_read(&mm->mmap_sem);
+
+ return rc;
+}
+
int optee_shm_register(struct tee_context *ctx, struct tee_shm *shm,
struct page **pages, size_t num_pages,
unsigned long start)
@@ -543,11 +579,15 @@ int optee_shm_register(struct tee_context *ctx, struct tee_shm *shm,
struct optee_msg_arg *msg_arg;
u64 *pages_list;
phys_addr_t msg_parg;
- int rc = 0;
+ int rc;
if (!num_pages)
return -EINVAL;
+ rc = check_mem_type(start, num_pages);
+ if (rc)
+ return rc;
+
pages_list = optee_allocate_pages_list(num_pages);
if (!pages_list)
return -ENOMEM;
@@ -614,7 +654,7 @@ int optee_shm_register_supp(struct tee_context *ctx, struct tee_shm *shm,
* We don't want to register supplicant memory in OP-TEE.
* Instead information about it will be passed in RPC code.
*/
- return 0;
+ return check_mem_type(start, num_pages);
}
int optee_shm_unregister_supp(struct tee_context *ctx, struct tee_shm *shm)
--
2.14.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox