[PATCH v5 01/11] dt-bindings: usb: convert usb-device.txt to YAML schema
Convert usb-device.txt to YAML schema usb-device.yaml
Signed-off-by: Chunfeng Yun
---
v5: changes suggested by Rob:
1. limit the pattern length
2. remove properties description for hard wired USB devices in usb-hcd.yaml
depends on series:
https://patchwork.kernel.org/project/linux-usb/list/?series=399561
[v6,00/19] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema
v4: no changes, update dependent series:
https://patchwork.kernel.org/project/linux-usb/list/?series=399561
[v6,00/19] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema
v3:
1. remove $nodenmae and items key word for compatilbe;
2. add additionalProperties;
The followings are suggested by Rob:
3. merge the following patch
[v2,1/4] dt-bindings: usb: convert usb-device.txt to YAML schema
[v2,2/4] dt-bindings: usb: add properties for hard wired devices
4. define the unit-address for hard-wired device in usb-hcd.yaml,
also define its 'reg' and 'compatible';
5. This series is base on Serge's series:
https://patchwork.kernel.org/project/linux-usb/cover/2020090853.14112-1-sergey.se...@baikalelectronics.ru/
[v4,00/18] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema
v2 changes suggested by Rob:
1. modify pattern to support any USB class
2. convert usb-device.txt into usb-device.yaml
---
.../devicetree/bindings/usb/usb-device.txt| 102 --
.../devicetree/bindings/usb/usb-device.yaml | 124 ++
.../devicetree/bindings/usb/usb-hcd.yaml | 19 +++
3 files changed, 143 insertions(+), 102 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt
create mode 100644 Documentation/devicetree/bindings/usb/usb-device.yaml
diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt
b/Documentation/devicetree/bindings/usb/usb-device.txt
deleted file mode 100644
index 036be172b1ae..
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ /dev/null
@@ -1,102 +0,0 @@
-Generic USB Device Properties
-
-Usually, we only use device tree for hard wired USB device.
-The reference binding doc is from:
-http://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps
-
-Four types of device-tree nodes are defined: "host-controller nodes"
-representing USB host controllers, "device nodes" representing USB devices,
-"interface nodes" representing USB interfaces and "combined nodes"
-representing simple USB devices.
-
-A combined node shall be used instead of a device node and an interface node
-for devices of class 0 or 9 (hub) with a single configuration and a single
-interface.
-
-A "hub node" is a combined node or an interface node that represents a USB
-hub.
-
-
-Required properties for device nodes:
-- compatible: "usbVID,PID", where VID is the vendor id and PID the product id.
- The textual representation of VID and PID shall be in lower case hexadecimal
- with leading zeroes suppressed. The other compatible strings from the above
- standard binding could also be used, but a device adhering to this binding
- may leave out all except for "usbVID,PID".
-- reg: the number of the USB hub port or the USB host-controller port to which
- this device is attached. The range is 1-255.
-
-
-Required properties for device nodes with interface nodes:
-- #address-cells: shall be 2
-- #size-cells: shall be 0
-
-
-Required properties for interface nodes:
-- compatible: "usbifVID,PID.configCN.IN", where VID is the vendor id, PID is
- the product id, CN is the configuration value and IN is the interface
- number. The textual representation of VID, PID, CN and IN shall be in lower
- case hexadecimal with leading zeroes suppressed. The other compatible
- strings from the above standard binding could also be used, but a device
- adhering to this binding may leave out all except for
- "usbifVID,PID.configCN.IN".
-- reg: the interface number and configuration value
-
-The configuration component is not included in the textual representation of
-an interface-node unit address for configuration 1.
-
-
-Required properties for combined nodes:
-- compatible: "usbVID,PID", where VID is the vendor id and PID the product id.
- The textual representation of VID and PID shall be in lower case hexadecimal
- with leading zeroes suppressed. The other compatible strings from the above
- standard binding could also be used, but a device adhering to this binding
- may leave out all except for "usbVID,PID".
-- reg: the number of the USB hub port or the USB host-controller port to which
- this device is attached. The range is 1-255.
-
-
-Required properties for hub nodes with device nodes:
-- #address-cells: shall be 1
-- #size-cells: shall be 0
-
-
-Required properties for host-controller nodes with device nodes:
-- #address-cells: shall be 1
-- #size-cells: shall be 0
-
-
-Example:
-
-&usb1 {/* host controller */
- #address-cells = <1>;
- #size-cells = <0>;
-
- hub@
[PATCH v5 07/11] dt-bindings: phy: convert MIPI DSI PHY binding to YAML schema
Convert MIPI DSI PHY binding to YAML schema mediatek,dsi-phy.yaml
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Signed-off-by: Chunfeng Yun
Reviewed-by: Rob Herring
Reviewed-by: Chun-Kuang Hu
---
v5: add Reviewed-by Rob & Chun-Kuang
v4:
1. add maintainer Philipp add support mt8183 suggested by Chun-Kuang
2. use keyword multipleOf suggested by Rob
3. fix typo of 'MIPI' in title
v3: new patch
---
.../display/mediatek/mediatek,dsi.txt | 18 +---
.../bindings/phy/mediatek,dsi-phy.yaml| 85 +++
2 files changed, 86 insertions(+), 17 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
index f06f24d405a5..8238a86686be 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
@@ -22,23 +22,7 @@ Required properties:
MIPI TX Configuration Module
-The MIPI TX configuration module controls the MIPI D-PHY.
-
-Required properties:
-- compatible: "mediatek,-mipi-tx"
-- the supported chips are mt2701, 7623, mt8173 and mt8183.
-- reg: Physical base address and length of the controller's registers
-- clocks: PLL reference clock
-- clock-output-names: name of the output clock line to the DSI encoder
-- #clock-cells: must be <0>;
-- #phy-cells: must be <0>.
-
-Optional properties:
-- drive-strength-microamp: adjust driving current, should be 3000 ~ 6000. And
- the step is 200.
-- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
- unspecified default values shall be used.
-- nvmem-cell-names: Should be "calibration-data"
+See phy/mediatek,dsi-phy.yaml
Example:
diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
new file mode 100644
index ..71d4acea1f66
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,dsi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MIPI Display Serial Interface (DSI) PHY binding
+
+maintainers:
+ - Chun-Kuang Hu
+ - Philipp Zabel
+ - Chunfeng Yun
+
+description: The MIPI DSI PHY supports up to 4-lane output.
+
+properties:
+ $nodename:
+pattern: "^dsi-phy@[0-9a-f]+$"
+
+ compatible:
+enum:
+ - mediatek,mt2701-mipi-tx
+ - mediatek,mt7623-mipi-tx
+ - mediatek,mt8173-mipi-tx
+ - mediatek,mt8183-mipi-tx
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: PLL reference clock
+
+ clock-output-names:
+maxItems: 1
+
+ "#phy-cells":
+const: 0
+
+ "#clock-cells":
+const: 0
+
+ nvmem-cells:
+maxItems: 1
+description: A phandle to the calibration data provided by a nvmem device,
+ if unspecified, default values shall be used.
+
+ nvmem-cell-names:
+items:
+ - const: calibration-data
+
+ drive-strength-microamp:
+description: adjust driving current
+multipleOf: 200
+minimum: 2000
+maximum: 6000
+default: 4600
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-output-names
+ - "#phy-cells"
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+dsi-phy@10215000 {
+compatible = "mediatek,mt8173-mipi-tx";
+reg = <0x10215000 0x1000>;
+clocks = <&clk26m>;
+clock-output-names = "mipi_tx0_pll";
+drive-strength-microamp = <4000>;
+nvmem-cells= <&mipi_tx_calibration>;
+nvmem-cell-names = "calibration-data";
+#clock-cells = <0>;
+#phy-cells = <0>;
+};
+
+...
--
2.18.0
[PATCH v5 08/11] dt-bindings: usb: convert mediatek,musb.txt to YAML schema
Convert mediatek,musb.txt to YAML schema mediatek,musb.yaml
Cc: Min Guo
Signed-off-by: Chunfeng Yun
Reviewed-by: Rob Herring
---
v4~v5: no changes
v3: add Reviewed-by Rob
v2: new patch
---
.../devicetree/bindings/usb/mediatek,musb.txt | 57 -
.../bindings/usb/mediatek,musb.yaml | 113 ++
2 files changed, 113 insertions(+), 57 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt
create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.yaml
diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.txt
b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
deleted file mode 100644
index 5eedb0296562..
--- a/Documentation/devicetree/bindings/usb/mediatek,musb.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-MediaTek musb DRD/OTG controller
-
-Required properties:
- - compatible : should be one of:
- "mediatek,mt2701-musb"
- ...
- followed by "mediatek,mtk-musb"
- - reg : specifies physical base address and size of
- the registers
- - interrupts : interrupt used by musb controller
- - interrupt-names : must be "mc"
- - phys: PHY specifier for the OTG phy
- - dr_mode : should be one of "host", "peripheral" or "otg",
- refer to usb/generic.txt
- - clocks : a list of phandle + clock-specifier pairs, one for
- each entry in clock-names
- - clock-names : must contain "main", "mcu", "univpll"
- for clocks of controller
-
-Optional properties:
- - power-domains : a phandle to USB power domain node to control USB's
- MTCMOS
-
-Required child nodes:
- usb connector node as defined in bindings/connector/usb-connector.yaml
-Optional properties:
- - id-gpios: input GPIO for USB ID pin.
- - vbus-gpios : input GPIO for USB VBUS pin.
- - vbus-supply : reference to the VBUS regulator, needed when supports
- dual-role mode
- - usb-role-switch : use USB Role Switch to support dual-role switch, see
- usb/generic.txt.
-
-Example:
-
-usb2: usb@1120 {
- compatible = "mediatek,mt2701-musb",
-"mediatek,mtk-musb";
- reg = <0 0x1120 0 0x1000>;
- interrupts = ;
- interrupt-names = "mc";
- phys = <&u2port2 PHY_TYPE_USB2>;
- dr_mode = "otg";
- clocks = <&pericfg CLK_PERI_USB0>,
-<&pericfg CLK_PERI_USB0_MCU>,
-<&pericfg CLK_PERI_USB_SLV>;
- clock-names = "main","mcu","univpll";
- power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
- usb-role-switch;
- connector{
- compatible = "gpio-usb-b-connector", "usb-b-connector";
- type = "micro";
- id-gpios = <&pio 44 GPIO_ACTIVE_HIGH>;
- vbus-supply = <&usb_vbus>;
- };
-};
diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml
b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml
new file mode 100644
index ..790efe8b6274
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/mediatek,musb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MUSB DRD/OTG Controller Device Tree Bindings
+
+maintainers:
+ - Min Guo
+
+properties:
+ $nodename:
+pattern: '^usb@[0-9a-f]+$'
+
+ compatible:
+items:
+ - enum:
+ - mediatek,mt2701-musb
+ - const: mediatek,mtk-musb
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ interrupt-names:
+items:
+ - const: mc
+
+ clocks:
+items:
+ - description: The main/core clock
+ - description: The system bus clock
+ - description: The 48Mhz clock
+
+ clock-names:
+items:
+ - const: main
+ - const: mcu
+ - const: univpll
+
+ phys:
+maxItems: 1
+
+ usb-role-switch:
+$ref: /schemas/types.yaml#/definitions/flag
+description: Support role switch. See usb/generic.txt
+type: boolean
+
+ dr_mode:
+enum:
+ - host
+ - otg
+ - peripheral
+
+ power-domains:
+description: A phandle to USB power domain node to control USB's MTCMOS
+maxItems: 1
+
+ connector:
+$ref: /connector/usb-connector.yaml#
+description: Connector for dual role switch
+type: object
+
+dependencies:
+ usb-role-switch: [ 'connector' ]
+ connector: [ 'usb-role-switch' ]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - phys
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+#include
+
+
[PATCH v5 09/11] dt-bindings: usb: convert mediatek,mtk-xhci.txt to YAML schema
Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml
Signed-off-by: Chunfeng Yun
---
v5: changes suggested by Rob
1. refer to usb-xhci.yaml instead of usb-hcd.yaml
2. remove unnecessary maxItems
3. add items for all phys may be supported
4. change pattern, and limit pattern length of patternProperties
v4: update it according to Rob's suggestion
1. modify dictionary of phys
2. fix endentation in "mediatek,syscon-wakeup" items
3. remove reference to usb-hcd.yaml
v3:
1. fix yamllint warning
2. remove pinctrl* properties supported by default suggested by Rob
3. drop unused labels
4. modify description of mediatek,syscon-wakeup
5. remove type of imod-interval-ns
v2: new patch
---
.../bindings/usb/mediatek,mtk-xhci.txt| 121
.../bindings/usb/mediatek,mtk-xhci.yaml | 178 ++
2 files changed, 178 insertions(+), 121 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
deleted file mode 100644
index 42d8814f903a..
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
+++ /dev/null
@@ -1,121 +0,0 @@
-MT8173 xHCI
-
-The device node for Mediatek SOC USB3.0 host controller
-
-There are two scenarios: the first one only supports xHCI driver;
-the second one supports dual-role mode, and the host is based on xHCI
-driver. Take account of backward compatibility, we divide bindings
-into two parts.
-
-1st: only supports xHCI driver
-
-
-Required properties:
- - compatible : should be "mediatek,-xhci", "mediatek,mtk-xhci",
- soc-model is the name of SoC, such as mt8173, mt2712 etc, when using
- "mediatek,mtk-xhci" compatible string, you need SoC specific ones in
- addition, one of:
- - "mediatek,mt8173-xhci"
- - reg : specifies physical base address and size of the registers
- - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
- - interrupts : interrupt used by the controller
- - power-domains : a phandle to USB power domain node to control USB's
- mtcmos
- - vusb33-supply : regulator of USB avdd3.3v
-
- - clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock-names
- - clock-names : must contain
- "sys_ck": controller clock used by normal mode,
- the following ones are optional:
- "ref_ck": reference clock used by low power mode etc,
- "mcu_ck": mcu_bus clock for register access,
- "dma_ck": dma_bus clock for data transfer by DMA,
- "xhci_ck": controller clock
-
- - phys : see usb-hcd.yaml in the current directory
-
-Optional properties:
- - wakeup-source : enable USB remote wakeup;
- - mediatek,syscon-wakeup : phandle to syscon used to access the register
- of the USB wakeup glue layer between xHCI and SPM; it depends on
- "wakeup-source", and has two arguments:
- - the first one : register base address of the glue layer in syscon;
- - the second one : hardware version of the glue layer
- - 1 : used by mt8173 etc
- - 2 : used by mt2712 etc
- - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
- bit1 for u3port1, ... etc;
- - vbus-supply : reference to the VBUS regulator;
- - usb3-lpm-capable : supports USB3.0 LPM
- - pinctrl-names : a pinctrl state named "default" must be defined
- - pinctrl-0 : pin control group
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
- - imod-interval-ns: default interrupt moderation interval is 5000ns
-
-additionally the properties from usb-hcd.yaml (in the current directory) are
-supported.
-
-Example:
-usb30: usb@1127 {
- compatible = "mediatek,mt8173-xhci";
- reg = <0 0x1127 0 0x1000>,
- <0 0x11280700 0 0x0100>;
- reg-names = "mac", "ippc";
- interrupts = ;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
- clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>,
-<&pericfg CLK_PERI_USB0>,
-<&pericfg CLK_PERI_USB1>;
- clock-names = "sys_ck", "ref_ck";
- phys = <&phy_port0 PHY_TYPE_USB3>,
- <&phy_port1 PHY_TYPE_USB2>;
- vusb33-supply = <&mt6397_vusb_reg>;
- vbus-supply = <&usb_p1_vbus>;
- usb3-lpm-capable;
- mediatek,syscon-wakeup = <&pericfg 0x400 1>;
- wakeup-source;
- imod-interval-ns = <1>;
-};
-
-2nd: dual-role mode with xHCI driver
-
-
-In the case, xhci is added as subnode to mtu3. An example and the DT binding
-details of mtu3 can be found in:
-Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
-
-Required prop
[PATCH v5 04/11] dt-bindings: phy: convert phy-mtk-tphy.txt to YAML schema
Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml Signed-off-by: Chunfeng Yun Reviewed-by: Rob Herring --- v5: no changes v4: add Reviewed-by Rob v3: 1. fix dt_binding_check error in example after add mtu3.yaml Changes suggested by Rob: 2. fix wrong indentation 3. remove '|' due to no formatting to preserve 4. add a space after '#' 5. drop unused labels and status in examples 6. modify file mode v2: 1. modify description and compatible --- .../bindings/phy/mediatek,tphy.yaml | 260 ++ .../devicetree/bindings/phy/phy-mtk-tphy.txt | 162 --- 2 files changed, 260 insertions(+), 162 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/mediatek,tphy.yaml delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml new file mode 100644 index ..602e6ff45785 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -0,0 +1,260 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020 MediaTek +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/mediatek,tphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek T-PHY Controller Device Tree Bindings + +maintainers: + - Chunfeng Yun + +description: | + The T-PHY controller supports physical layer functionality for a number of + controllers on MediaTek SoCs, includes USB2.0, USB3.0, PCIe and SATA. + + Layout differences of banks between T-PHY V1 (mt8173/mt2701) and + T-PHY V2 (mt2712) when works on USB mode: + --- + Version 1: + portoffsetbank + shared 0xSPLLC + 0x0100FMREG + u2 port00x0800U2PHY_COM + u3 port00x0900U3PHYD + 0x0a00U3PHYD_BANK2 + 0x0b00U3PHYA + 0x0c00U3PHYA_DA + u2 port10x1000U2PHY_COM + u3 port10x1100U3PHYD + 0x1200U3PHYD_BANK2 + 0x1300U3PHYA + 0x1400U3PHYA_DA + u2 port20x1800U2PHY_COM + ... + + Version 2: + portoffsetbank + u2 port00xMISC + 0x0100FMREG + 0x0300U2PHY_COM + u3 port00x0700SPLLC + 0x0800CHIP + 0x0900U3PHYD + 0x0a00U3PHYD_BANK2 + 0x0b00U3PHYA + 0x0c00U3PHYA_DA + u2 port10x1000MISC + 0x1100FMREG + 0x1300U2PHY_COM + u3 port10x1700SPLLC + 0x1800CHIP + 0x1900U3PHYD + 0x1a00U3PHYD_BANK2 + 0x1b00U3PHYA + 0x1c00U3PHYA_DA + u2 port20x2000MISC + ... + + SPLLC shared by u3 ports and FMREG shared by u2 ports on V1 are put back + into each port; a new bank MISC for u2 ports and CHIP for u3 ports are + added on V2. + +properties: + $nodename: +pattern: "^t-phy@[0-9a-f]+$" + + compatible: +oneOf: + - items: + - enum: + - mediatek,mt2701-tphy + - mediatek,mt7623-tphy + - mediatek,mt7622-tphy + - mediatek,mt8516-tphy + - const: mediatek,generic-tphy-v1 + - items: + - enum: + - mediatek,mt2712-tphy + - mediatek,mt7629-tphy + - mediatek,mt8183-tphy + - const: mediatek,generic-tphy-v2 + - const: mediatek,mt2701-u3phy +deprecated: true + - const: mediatek,mt2712-u3phy +deprecated: true + - const: mediatek,mt8173-u3phy + + reg: +description: + Register shared by multiple ports, exclude port's private register. + It is needed for T-PHY V1, such as mt2701 and mt8173, but not for + T-PHY V2, such as mt2712. +maxItems: 1 + + "#address-cells": +enum: [1, 2] + + "#size-cells": +enum: [1, 2] + + # Used with non-empty value if optional 'reg' is not provided. + # The format of the value is an arbitrary number of triplets of + # (child-bus-address, parent-bus-address, length). + ranges: true + + mediatek,src-ref-clk-mhz: +description: + Frequency of reference clock for slew rate calibrate +default: 26 + + mediatek,src-coef: +description: + Coefficient for slew rate calibrate, depends on SoC process +$ref: /schemas/types.yaml#/definitions/uint32 +default: 28 + +# Required child node: +patternProperties: + "^usb-phy@[0-9a-f]+$": +type: object +description: + A sub-node is required for each port the controller provides. + Address range information including the usual 'reg' property + is used inside these nodes to describe the controller's topology. + +properties: + reg: +maxItems: 1 + + clocks: +minItems: 1 +
[PATCH v5 03/11] dt-bindings: phy: convert phy-mtk-xsphy.txt to YAML schema
Convert phy-mtk-xsphy.txt to YAML schema mediatek,xsphy.yaml Signed-off-by: Chunfeng Yun Reviewed-by: Rob Herring --- v5: no changes v4: add Reviewed-by Rob v3: 1. remove type for property with standard unit suffix suggested by Rob 2. remove '|' for descritpion 3. fix yamllint warning v2: 1. modify description and compatible definition suggested by Rob --- .../bindings/phy/mediatek,xsphy.yaml | 199 ++ .../devicetree/bindings/phy/phy-mtk-xsphy.txt | 109 -- 2 files changed, 199 insertions(+), 109 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt diff --git a/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml new file mode 100644 index ..598fd2b95c29 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml @@ -0,0 +1,199 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020 MediaTek +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/mediatek,xsphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek XS-PHY Controller Device Tree Bindings + +maintainers: + - Chunfeng Yun + +description: | + The XS-PHY controller supports physical layer functionality for USB3.1 + GEN2 controller on MediaTek SoCs. + + Banks layout of xsphy + -- + portoffsetbank + u2 port00xMISC + 0x0100FMREG + 0x0300U2PHY_COM + u2 port10x1000MISC + 0x1100FMREG + 0x1300U2PHY_COM + u2 port20x2000MISC + ... + u31 common 0x3000DIG_GLB + 0x3100PHYA_GLB + u31 port0 0x3400DIG_LN_TOP + 0x3500DIG_LN_TX0 + 0x3600DIG_LN_RX0 + 0x3700DIG_LN_DAIF + 0x3800PHYA_LN + u31 port1 0x3a00DIG_LN_TOP + 0x3b00DIG_LN_TX0 + 0x3c00DIG_LN_RX0 + 0x3d00DIG_LN_DAIF + 0x3e00PHYA_LN + ... + DIG_GLB & PHYA_GLB are shared by U31 ports. + +properties: + $nodename: +pattern: "^xs-phy@[0-9a-f]+$" + + compatible: +items: + - enum: + - mediatek,mt3611-xsphy + - mediatek,mt3612-xsphy + - const: mediatek,xsphy + + reg: +description: + Register shared by multiple U3 ports, exclude port's private register, + if only U2 ports provided, shouldn't use the property. +maxItems: 1 + + "#address-cells": +enum: [1, 2] + + "#size-cells": +enum: [1, 2] + + ranges: true + + mediatek,src-ref-clk-mhz: +description: + Frequency of reference clock for slew rate calibrate +default: 26 + + mediatek,src-coef: +description: + Coefficient for slew rate calibrate, depends on SoC process +$ref: /schemas/types.yaml#/definitions/uint32 +default: 17 + +# Required child node: +patternProperties: + "^usb-phy@[0-9a-f]+$": +type: object +description: + A sub-node is required for each port the controller provides. + Address range information including the usual 'reg' property + is used inside these nodes to describe the controller's topology. + +properties: + reg: +maxItems: 1 + + clocks: +items: + - description: Reference clock, (HS is 48Mhz, SS/P is 24~27Mhz) + + clock-names: +items: + - const: ref + + "#phy-cells": +const: 1 +description: | + The cells contain the following arguments. + + - description: The PHY type + enum: +- PHY_TYPE_USB2 +- PHY_TYPE_USB3 + + # The following optional vendor properties are only for debug or HQA test + mediatek,eye-src: +description: + The value of slew rate calibrate (U2 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 7 + + mediatek,eye-vrt: +description: + The selection of VRT reference voltage (U2 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 7 + + mediatek,eye-term: +description: + The selection of HS_TX TERM reference voltage (U2 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 7 + + mediatek,efuse-intr: +description: + The selection of Internal Resistor (U2/U3 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 63 + + mediatek,efuse-tx-imp: +description: + The selection of TX Impedance (U3 phy) +$ref: /schemas/types.yaml#/definitions/uint32 +minimum: 1 +maximum: 31 + + mediatek,efuse-rx-imp: +descripti
[PATCH v5 05/11] dt-bindings: phy: convert phy-mtk-ufs.txt to YAML schema
Convert phy-mtk-ufs.txt to YAML schema mediatek,ufs-phy.yaml
Cc: Stanley Chu
Signed-off-by: Chunfeng Yun
Reviewed-by: Rob Herring
Reviewed-by: Stanley Chu
---
v5: no changes
v4: add Reviewed-by Stanley
v3: add Reviewed-by Rob
v2: fix binding check warning of reg in example
---
.../bindings/phy/mediatek,ufs-phy.yaml| 64 +++
.../devicetree/bindings/phy/phy-mtk-ufs.txt | 38 ---
2 files changed, 64 insertions(+), 38 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt
diff --git a/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
b/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
new file mode 100644
index ..3a9be82e7f13
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,ufs-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Universal Flash Storage (UFS) M-PHY binding
+
+maintainers:
+ - Stanley Chu
+ - Chunfeng Yun
+
+description: |
+ UFS M-PHY nodes are defined to describe on-chip UFS M-PHY hardware macro.
+ Each UFS M-PHY node should have its own node.
+ To bind UFS M-PHY with UFS host controller, the controller node should
+ contain a phandle reference to UFS M-PHY node.
+
+properties:
+ $nodename:
+pattern: "^ufs-phy@[0-9a-f]+$"
+
+ compatible:
+const: mediatek,mt8183-ufsphy
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Unipro core control clock.
+ - description: M-PHY core control clock.
+
+ clock-names:
+items:
+ - const: unipro
+ - const: mp
+
+ "#phy-cells":
+const: 0
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+ufsphy: ufs-phy@11fa {
+compatible = "mediatek,mt8183-ufsphy";
+reg = <0x11fa 0xc000>;
+clocks = <&infracfg CLK_INFRA_UNIPRO_SCK>,
+ <&infracfg CLK_INFRA_UFS_MP_SAP_BCLK>;
+clock-names = "unipro", "mp";
+#phy-cells = <0>;
+};
+
+...
diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt
b/Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt
deleted file mode 100644
index 5789029a1d42..
--- a/Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-MediaTek Universal Flash Storage (UFS) M-PHY binding
-
-
-UFS M-PHY nodes are defined to describe on-chip UFS M-PHY hardware macro.
-Each UFS M-PHY node should have its own node.
-
-To bind UFS M-PHY with UFS host controller, the controller node should
-contain a phandle reference to UFS M-PHY node.
-
-Required properties for UFS M-PHY nodes:
-- compatible : Compatible list, contains the following controller:
- "mediatek,mt8183-ufsphy" for ufs phy
- persent on MT81xx chipsets.
-- reg: Address and length of the UFS M-PHY register set.
-- #phy-cells : This property shall be set to 0.
-- clocks : List of phandle and clock specifier pairs.
-- clock-names: List of clock input name strings sorted in the same
- order as the clocks property. Following clocks are
- mandatory.
- "unipro": Unipro core control clock.
- "mp": M-PHY core control clock.
-
-Example:
-
- ufsphy: phy@11fa {
- compatible = "mediatek,mt8183-ufsphy";
- reg = <0 0x11fa 0 0xc000>;
- #phy-cells = <0>;
-
- clocks = <&infracfg_ao INFRACFG_AO_UNIPRO_SCK_CG>,
-<&infracfg_ao INFRACFG_AO_UFS_MP_SAP_BCLK_CG>;
- clock-names = "unipro", "mp";
- };
-
- ufshci@1127 {
- ...
- phys = <&ufsphy>;
- };
--
2.18.0
[PATCH v5 02/11] dt-bindings: net: btusb: change reference file name
Due to usb-device.txt is converted into usb-device.yaml, so modify reference file names at the same time. Signed-off-by: Chunfeng Yun Acked-by: Rob Herring --- v5: add Acked-by Rob v2~v4: no changes --- Documentation/devicetree/bindings/net/btusb.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt index b1ad6ee68e90..a9c3f4277f69 100644 --- a/Documentation/devicetree/bindings/net/btusb.txt +++ b/Documentation/devicetree/bindings/net/btusb.txt @@ -4,7 +4,7 @@ Generic Bluetooth controller over USB (btusb driver) Required properties: - compatible : should comply with the format "usbVID,PID" specified in -Documentation/devicetree/bindings/usb/usb-device.txt +Documentation/devicetree/bindings/usb/usb-device.yaml At the time of writing, the only OF supported devices (more may be added later) are: -- 2.18.0
[PATCH v5 10/11] dt-bindings: usb: convert mediatek,mtu3.txt to YAML schema
Convert mediatek,mtu3.txt to YAML schema mediatek,mtu3.yaml
Signed-off-by: Chunfeng Yun
---
v5: changes suggested by Rob
1. remove unnecessary maxItems
2. define all phys supported
v4:
1. refer to usb-drd.yaml insstead of usb/generic.txt
the following ones suggested by Rob:
2. add the number of phys supported
3. fix indentation of wakeup
4. add examples for port and connector
v3:
1. fix yamllint warning
2. remove pinctrl* properties
3. remove unnecessary '|'
4. drop unused labels in example
v2: new patch
---
.../devicetree/bindings/usb/mediatek,mtu3.txt | 108 ---
.../bindings/usb/mediatek,mtu3.yaml | 287 ++
2 files changed, 287 insertions(+), 108 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
deleted file mode 100644
index a82ca438aec1..
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
+++ /dev/null
@@ -1,108 +0,0 @@
-The device node for Mediatek USB3.0 DRD controller
-
-Required properties:
- - compatible : should be "mediatek,-mtu3", "mediatek,mtu3",
- soc-model is the name of SoC, such as mt8173, mt2712 etc,
- when using "mediatek,mtu3" compatible string, you need SoC specific
- ones in addition, one of:
- - "mediatek,mt8173-mtu3"
- - reg : specifies physical base address and size of the registers
- - reg-names: should be "mac" for device IP and "ippc" for IP port control
- - interrupts : interrupt used by the device IP
- - power-domains : a phandle to USB power domain node to control USB's
- mtcmos
- - vusb33-supply : regulator of USB avdd3.3v
- - clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock-names
- - clock-names : must contain "sys_ck" for clock of controller,
- the following clocks are optional:
- "ref_ck", "mcu_ck" and "dma_ck";
- - phys : see usb-hcd.yaml in the current directory
- - dr_mode : should be one of "host", "peripheral" or "otg",
- refer to usb/generic.txt
-
-Optional properties:
- - #address-cells, #size-cells : should be '2' if the device has sub-nodes
- with 'reg' property
- - ranges : allows valid 1:1 translation between child's address space and
- parent's address space
- - extcon : external connector for vbus and idpin changes detection, needed
- when supports dual-role mode.
- it's considered valid for compatibility reasons, not allowed for
- new bindings, and use "usb-role-switch" property instead.
- - vbus-supply : reference to the VBUS regulator, needed when supports
- dual-role mode.
- it's considered valid for compatibility reasons, not allowed for
- new bindings, and put into a usb-connector node.
- see connector/usb-connector.yaml.
- - pinctrl-names : a pinctrl state named "default" is optional, and need be
- defined if auto drd switch is enabled, that means the property dr_mode
- is set as "otg", and meanwhile the property "mediatek,enable-manual-drd"
- is not set.
- - pinctrl-0 : pin control group
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
- - maximum-speed : valid arguments are "super-speed", "high-speed" and
- "full-speed"; refer to usb/generic.txt
- - usb-role-switch : use USB Role Switch to support dual-role switch, but
- not extcon; see usb/generic.txt.
- - enable-manual-drd : supports manual dual-role switch via debugfs; usually
- used when receptacle is TYPE-A and also wants to support dual-role
- mode.
- - wakeup-source: enable USB remote wakeup of host mode.
- - mediatek,syscon-wakeup : phandle to syscon used to access the register
- of the USB wakeup glue layer between SSUSB and SPM; it depends on
- "wakeup-source", and has two arguments:
- - the first one : register base address of the glue layer in syscon;
- - the second one : hardware version of the glue layer
- - 1 : used by mt8173 etc
- - 2 : used by mt2712 etc
- - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
- bit1 for u3port1, ... etc;
-
-additionally the properties from usb-hcd.yaml (in the current directory) are
-supported.
-
-Sub-nodes:
-The xhci should be added as subnode to mtu3 as shown in the following example
-if host mode is enabled. The DT binding details of xhci can be found in:
-Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
-
-The port would be added as subnode if use "usb-role-switch" property.
- see graph.txt
-
-Example:
-ssusb: usb@11271000 {
- compatible = "mediatek,mt8173-mtu3";
- reg = <0 0x11271000 0 0x3000>,
- <0 0x11280700 0 0x0100>;
- reg-names = "mac", "ippc";
- interrupts = ;
- phys = <&phy_port0 PH
[PATCH v5 06/11] dt-bindings: phy: convert HDMI PHY binding to YAML schema
Convert HDMI PHY binding to YAML schema mediatek,hdmi-phy.yaml
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Signed-off-by: Chunfeng Yun
Reviewed-by: Rob Herring
Reviewed-by: Chun-Kuang Hu
---
v5: add Reviewed-by Chun-Kuang
v4: add maintainer Philipp
v3: add Reviewed-by Rob
v2: fix binding check warning of reg in example
---
.../display/mediatek/mediatek,hdmi.txt| 18 +---
.../bindings/phy/mediatek,hdmi-phy.yaml | 92 +++
2 files changed, 93 insertions(+), 17 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
index 6b1c586403e4..b284ca51b913 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
@@ -53,23 +53,7 @@ Required properties:
HDMI PHY
-
-The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
-output and drives the HDMI pads.
-
-Required properties:
-- compatible: "mediatek,-hdmi-phy"
-- the supported chips are mt2701, mt7623 and mt8173
-- reg: Physical base address and length of the module's registers
-- clocks: PLL reference clock
-- clock-names: must contain "pll_ref"
-- clock-output-names: must be "hdmitx_dig_cts" on mt8173
-- #phy-cells: must be <0>
-- #clock-cells: must be <0>
-
-Optional properties:
-- mediatek,ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa
-- mediatek,ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c
+See phy/mediatek,hdmi-phy.yaml
Example:
diff --git a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
new file mode 100644
index ..4752517a1446
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/mediatek,hdmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek High Definition Multimedia Interface (HDMI) PHY binding
+
+maintainers:
+ - Chun-Kuang Hu
+ - Philipp Zabel
+ - Chunfeng Yun
+
+description: |
+ The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
+ output and drives the HDMI pads.
+
+properties:
+ $nodename:
+pattern: "^hdmi-phy@[0-9a-f]+$"
+
+ compatible:
+enum:
+ - mediatek,mt2701-hdmi-phy
+ - mediatek,mt7623-hdmi-phy
+ - mediatek,mt8173-hdmi-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: PLL reference clock
+
+ clock-names:
+items:
+ - const: pll_ref
+
+ clock-output-names:
+items:
+ - const: hdmitx_dig_cts
+
+ "#phy-cells":
+const: 0
+
+ "#clock-cells":
+const: 0
+
+ mediatek,ibias:
+description:
+ TX DRV bias current for < 1.65Gbps
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 0
+maximum: 63
+default: 0xa
+
+ mediatek,ibias_up:
+description:
+ TX DRV bias current for >= 1.65Gbps
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 0
+maximum: 63
+default: 0x1c
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - clock-output-names
+ - "#phy-cells"
+ - "#clock-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+hdmi_phy: hdmi-phy@10209100 {
+compatible = "mediatek,mt8173-hdmi-phy";
+reg = <0x10209100 0x24>;
+clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
+clock-names = "pll_ref";
+clock-output-names = "hdmitx_dig_cts";
+mediatek,ibias = <0xa>;
+mediatek,ibias_up = <0x1c>;
+#clock-cells = <0>;
+#phy-cells = <0>;
+};
+
+...
--
2.18.0
[PATCH v5 11/11] MAINTAINERS: update MediaTek PHY/USB entry
Due to the phy/usb bindings are converted into YAML schema and also renamed, update entries. Meanwhile add drivers/usb/host/mtk-xhci* files. Signed-off-by: Chunfeng Yun --- v3~v5: no changes v2: new patch --- MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e73636b75f29..360c6131b866 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2084,7 +2084,7 @@ M:Chunfeng Yun L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) L: linux-media...@lists.infradead.org (moderated for non-subscribers) S: Maintained -F: Documentation/devicetree/bindings/phy/phy-mtk-* +F: Documentation/devicetree/bindings/phy/mediatek,* F: drivers/phy/mediatek/ ARM/Microchip (AT91) SoC support @@ -11139,6 +11139,8 @@ L: linux-...@vger.kernel.org L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) L: linux-media...@lists.infradead.org (moderated for non-subscribers) S: Maintained +F: Documentation/devicetree/bindings/usb/mediatek,* +F: drivers/usb/host/xhci-mtk* F: drivers/usb/mtu3/ MEGACHIPS STDP-GE-B850V3-FW LVDS/DP++ BRIDGES -- 2.18.0
nouveau regression post v5.8, still present in v5.10
Something between v5.8 and v5.9 has resulted in periodically losing video. Unfortunately, I can't reliably reproduce it, it seems to happen every once in a long while---I can go weeks without an occurance, but it always seems to happen after my workstation has been idle long enough to screen blank and put the monitor to sleep. I'm using a single display (Dell 2405FPW) connected via DVI, running X (Xorg 1.20.x from Debian sid). I don't really do anything fancy, xterms, a browser or two, play the occasional video, but like I said, I can't reliably reproduce this. I've had it happen about 11 times since August. lspci -vv output is: 01:00.0 VGA compatible controller: NVIDIA Corporation G86 [Quadro NVS 290] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation G86 [Quadro NVS 290] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 Kernel driver in use: nouveau The last time this happened, this is what got logged: nouveau :01:00.0: disp: ERROR 5 [INVALID_STATE] 06 [] chid 1 mthd 0080 data 0001 nouveau :01:00.0: disp: Base 1: nouveau :01:00.0: disp:0084: nouveau :01:00.0: disp:0088: nouveau :01:00.0: disp:008c: nouveau :01:00.0: disp:0090: nouveau :01:00.0: disp:0094: nouveau :01:00.0: disp:00a0: 0060 -> 0070 nouveau :01:00.0: disp:00a4: -> f000 nouveau :01:00.0: disp:00c0: nouveau :01:00.0: disp:00c4: nouveau :01:00.0: disp:00c8: nouveau :01:00.0: disp:00cc: nouveau :01:00.0: disp:00e0: 4000 nouveau :01:00.0: disp:00e4: nouveau :01:00.0: disp:00e8: nouveau :01:00.0: disp:00ec: nouveau :01:00.0: disp:00fc: nouveau :01:00.0: disp:0100: fffe nouveau :01:00.0: disp:0104: nouveau :01:00.0: disp:0110: nouveau :01:00.0: disp:0114: nouveau :01:00.0: disp: Base 1 - Image 0: nouveau :01:00.0: disp:0800: 9500 nouveau :01:00.0: disp:0804: nouveau :01:00.0: disp:0808: 04b00780 nouveau :01:00.0: disp:080c: 7804 nouveau :01:00.0: disp:0810: cf00 nouveau :01:00.0: disp: Base 1 - Image 1: nouveau :01:00.0: disp:0c00: 9500 nouveau :01:00.0: disp:0c04: nouveau :01:00.0: disp:0c08: 04b00780 nouveau :01:00.0: disp:0c0c: 7804 nouveau :01:00.0: disp:0c10: cf00 nouveau :01:00.0: disp: ERROR 5 [INVALID_STATE] 06 [] chid 1 mthd 0080 data 0001 nouveau :01:00.0: disp: Base 1: nouveau :01:00.0: disp:0084: nouveau :01:00.0: disp:0088: nouveau :01:00.0: disp:008c: nouveau :01:00.0: disp:0090: nouveau :01:00.0: disp:0094: nouveau :01:00.0: disp:00a0: 0060 -> 0070 nouveau :01:00.0: disp:00a4: -> f000 nouveau :01:00.0: disp:00c0: nouveau :01:00.0: disp:00c4: nouveau :01:00.0: disp:00c8: nouveau :01:00.0: disp:00cc: nouveau :01:00.0: disp:00e0: 4000 nouveau :01:00.0: disp:00e4: nouveau :01:00.0: disp:00e8: nouveau :01:00.0: disp:00ec: nouveau :01:00.0: disp:00fc: nouveau :01:00.0: disp:0100: fffe nouveau :01:00.0: disp:0104: nouveau :01:00.0: disp:0110: nouveau :01:00.0: disp:0114: nouveau :01:00.0: disp: Base 1 - Image 0: nouveau :01:00.0: disp:0800: 9500 nouveau :01:00.0: disp:0804: nouveau :01:00.0: disp:0808: 04b00780 nouveau :01:00.0: disp:080c: 0
[PATCH v1 1/1] driver: watchdog: Remove mtk_wdt_stop() in probe() to prevent the system freeze and it doesn't reboot by watchdog problem
From: "freddy.hsin"
Before user space daemon start to access the watchdog device,
there is a time interval that watchdog is disabled in the
original flow. If the system freezing at this interval, it
cannot be rebooted by watchdog hardware automatically.
In order to solve this problem, the watchdog hardware should be
kept working, and start hrtimer in framework to ping it by
setting max_hw_heartbeat_ms and HW_RUNNING used in
watchdog_need_worker to determine whether the worker should be
started or not
Change-Id: I6a041b0922888a90011d7538ee804d80bc8d15ea
Signed-off-by: freddy.hsin
---
drivers/watchdog/mtk_wdt.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index d6a6393..62f08cd 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -195,6 +195,19 @@ static int mtk_wdt_set_timeout(struct watchdog_device
*wdt_dev,
return 0;
}
+static void mtk_wdt_init(struct watchdog_device *wdt_dev)
+{
+ struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
+ void __iomem *wdt_base;
+
+ wdt_base = mtk_wdt->wdt_base;
+
+ if (readl(wdt_base + WDT_MODE) & WDT_MODE_EN) {
+ set_bit(WDOG_HW_RUNNING, &wdt_dev->status);
+ mtk_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
+ }
+}
+
static int mtk_wdt_stop(struct watchdog_device *wdt_dev)
{
struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
@@ -266,16 +279,17 @@ static int mtk_wdt_probe(struct platform_device *pdev)
mtk_wdt->wdt_dev.timeout = WDT_MAX_TIMEOUT;
mtk_wdt->wdt_dev.max_timeout = WDT_MAX_TIMEOUT;
mtk_wdt->wdt_dev.min_timeout = WDT_MIN_TIMEOUT;
+ mtk_wdt->wdt_dev.max_hw_heartbeat_ms = (WDT_MAX_TIMEOUT - 1) * 1000;
mtk_wdt->wdt_dev.parent = dev;
+ watchdog_set_drvdata(&mtk_wdt->wdt_dev, mtk_wdt);
+
+ mtk_wdt_init(&mtk_wdt->wdt_dev);
+
watchdog_init_timeout(&mtk_wdt->wdt_dev, timeout, dev);
watchdog_set_nowayout(&mtk_wdt->wdt_dev, nowayout);
watchdog_set_restart_priority(&mtk_wdt->wdt_dev, 128);
- watchdog_set_drvdata(&mtk_wdt->wdt_dev, mtk_wdt);
-
- mtk_wdt_stop(&mtk_wdt->wdt_dev);
-
watchdog_stop_on_reboot(&mtk_wdt->wdt_dev);
err = devm_watchdog_register_device(dev, &mtk_wdt->wdt_dev);
if (unlikely(err))
--
1.7.9.5
driver: watchdog: Remove mtk_wdt_stop() in probe() to prevent the system freeze and it doesn't reboot by watchdog problem
Before user space daemon start to access the watchdog device, there is a time interval that watchdog is disabled in the original flow. If the system freezing at this interval, it cannot be rebooted by watchdog hardware automatically. In order to solve this problem, the watchdog hardware should be kept working, and start hrtimer in framework to ping it by setting max_hw_heartbeat_ms and HW_RUNNING used in watchdog_need_worker to determine whether the worker should be started or not
Re: [PATCH] arm64/smp: Remove unused irq variable in arch_show_interrupts()
On 2020/12/15 18:30, Geert Uytterhoeven wrote:
arch/arm64/kernel/smp.c: In function ‘arch_show_interrupts’:
arch/arm64/kernel/smp.c:808:16: warning: unused variable ‘irq’
[-Wunused-variable]
808 | unsigned int irq = irq_desc_get_irq(ipi_desc[i]);
|^~~
The removal of the last user forgot to remove the variable.
Fixes: 2f516e34383d0e97 ("arm64/smp: Use irq_desc_kstat_cpu() in
arch_show_interrupts()")
This is in mainline now and the commit id is 5089bc51f81f.
Signed-off-by: Geert Uytterhoeven
---
One more issue in irq-core-2020-12-14.
arch/arm64/kernel/smp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 3aef3bc22d3250b5..10b39328268687e3 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -805,7 +805,6 @@ int arch_show_interrupts(struct seq_file *p, int prec)
unsigned int cpu, i;
for (i = 0; i < NR_IPI; i++) {
- unsigned int irq = irq_desc_get_irq(ipi_desc[i]);
seq_printf(p, "%*s%u:%s", prec - 1, "IPI", i,
prec >= 4 ? " " : "");
for_each_online_cpu(cpu)
And I guess we have the same problem on 32-bit ARM. 'irq' in
show_ipi_list() is no longer used since commit 88c637748e31
("ARM: smp: Use irq_desc_kstat_cpu() in show_ipi_list()").
Thanks,
Zenghui
Re: [PATCH 3/3] overlayfs: Report writeback errors on upper
On Thu, Dec 24, 2020 at 2:13 PM Matthew Wilcox wrote: > > On Thu, Dec 24, 2020 at 11:32:55AM +0200, Amir Goldstein wrote: > > In current master, syncfs() on any file by any container user will > > result in full syncfs() of the upperfs, which is very bad for container > > isolation. This has been partly fixed by Chengguang Xu [1] and I expect > > his work will be merged soon. Overlayfs still does not do the writeback > > and syncfs() in overlay still waits for all upper fs writeback to complete, > > but at least syncfs() in overlay only kicks writeback for upper fs files > > dirtied by this overlay. > > > > [1] > > https://lore.kernel.org/linux-unionfs/cajfpegsbb4itxw8zyurfvnc63zg7ku7vzpsnuzhasyzh-d5...@mail.gmail.com/ > > > > Sharing the same SEEN flag among thousands of containers is also > > far from ideal, because effectively this means that any given workload > > in any single container has very little chance of observing the SEEN flag. > > Perhaps you misunderstand how errseq works. If each container samples > the errseq at startup, then they will all see any error which occurs > during their lifespan Meant to say "...very little chance of NOT observing the SEEN flag", but We are not in disagreement. My argument against sharing the SEEN flag refers to Vivek's patch of stacked errseq_sample()/errseq_check_and_advance() which does NOT sample errseq at overlayfs mount time. That is why my next sentence is: "I do agree with Matthew that overlayfs should sample errseq...". > (and possibly an error which occurred before they started up). > Right. And this is where the discussion of splitting the SEEN flag started. Some of us want to treat overlayfs mount time as a true epoc for errseq. The new container didn't write any files yet, so it should not care about writeback errors from the past. I agree that it may not be very critical, but as I wrote before, I think we should do our best to try and isolate container workloads. > > To this end, I do agree with Matthew that overlayfs should sample errseq > > and the best patchset to implement it so far IMO is Jeff's patchset [2]. > > This patch set was written to cater only "volatile" overlayfs mount, but > > there is no reason not to use the same mechanism for regular overlay > > mount. The only difference being that "volatile" overlay only checks for > > error since mount on syncfs() (because "volatile" overlay does NOT > > syncfs upper fs) and regular overlay checks and advances the overlay's > > errseq sample on syncfs (and does syncfs upper fs). > > > > Matthew, I hope that my explanation of the use case and Jeff's answer > > is sufficient to understand why the split of the SEEN flag is needed. > > > > [2] > > https://lore.kernel.org/linux-unionfs/20201213132713.66864-1-jlay...@kernel.org/ > > No, it still feels weird and wrong. > All right. Considering your reservations, I think perhaps the split of the SEEN flag can wait for a later time after more discussions and maybe not as suitable for stable as we thought. I think that for stable, it would be sufficient to adapt Surgun's original syncfs for volatile mount patch [1] to cover the non-volatile case: on mout: - errseq_sample() upper fs - on volatile mount, errseq_check() upper fs and fail mount on un-SEEN error on syncfs: - errseq_check() for volatile mount - errseq_check_and_advance() for non-volatile mount - errseq_set() overlay sb on upper fs error Now errseq_set() is not only a hack around __sync_filesystem ignoring return value of ->sync_fs(). It is really needed for per-overlay SEEN error isolation in the non-volatile case. Unless I am missing something, I think we do not strictly need Vivek's 1/3 patch [2] for stable, but not sure. Sargun, Do you agree with the above proposal? Will you make it into a patch? Vivek, Jefff, Do you agree that overlay syncfs observing writeback errors that predate overlay mount time is an issue that can be deferred (maybe forever)? BTW, in all the discussions we always assumed that stacked fsync() is correct WRT errseq, but in fact, fsync() can also observe an unseen error that predates overlay mount. In order to fix that, we will probably need to split the SEEN flag and some more errseq acrobatics, but again, not sure it is worth the effort. Thanks, Amir. [1] https://lore.kernel.org/linux-unionfs/20201202092720.41522-1-sar...@sargun.me/ [2] https://lore.kernel.org/linux-unionfs/20201222151752.ga3...@redhat.com/
[PATCH] dm snap : add sanity checks to snapshot_ctr
Similar to commit<70de2cbd>,there should be a check for argc and argv to
prevent Null pointer dereferencing
when the dm_get_device invoked twice on the same device path with differnt mode.
Signed-off-by: Defang Bo
---
drivers/md/dm-snap.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index 4668b2c..dccce8b 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -1258,6 +1258,13 @@ static int snapshot_ctr(struct dm_target *ti, unsigned
int argc, char **argv)
as.argc = argc;
as.argv = argv;
+
+ if (!strcmp(argv[0], argv[1])) {
+ ti->error = "Error setting metadata or data device";
+ r = -EINVAL;
+ goto bad;
+ }
+
dm_consume_args(&as, 4);
r = parse_snapshot_features(&as, s, ti);
if (r)
--
2.7.4
[PATCH -net] net: sched: prevent invalid Scell_log shift count
Check Scell_log shift size in red_check_params() and modify all callers
of red_check_params() to pass Scell_log.
This prevents a shift out-of-bounds as detected by UBSAN:
UBSAN: shift-out-of-bounds in ./include/net/red.h:252:22
shift exponent 72 is too large for 32-bit type 'int'
Fixes: 8afa10cbe281 ("net_sched: red: Avoid illegal values")
Signed-off-by: Randy Dunlap
Reported-by: syzbot+97c5bd9cc81eca63d...@syzkaller.appspotmail.com
Cc: Nogah Frankel
Cc: Jamal Hadi Salim
Cc: Cong Wang
Cc: Jiri Pirko
Cc: net...@vger.kernel.org
Cc: "David S. Miller"
Cc: Jakub Kicinski
---
include/net/red.h |4 +++-
net/sched/sch_choke.c |2 +-
net/sched/sch_gred.c |2 +-
net/sched/sch_red.c |2 +-
net/sched/sch_sfq.c |2 +-
5 files changed, 7 insertions(+), 5 deletions(-)
--- lnx-510.orig/include/net/red.h
+++ lnx-510/include/net/red.h
@@ -168,12 +168,14 @@ static inline void red_set_vars(struct r
v->qcount = -1;
}
-static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog)
+static inline bool red_check_params(u32 qth_min, u32 qth_max, u8 Wlog, u8
Scell_log)
{
if (fls(qth_min) + Wlog > 32)
return false;
if (fls(qth_max) + Wlog > 32)
return false;
+ if (Scell_log >= 32)
+ return false;
if (qth_max < qth_min)
return false;
return true;
--- lnx-510.orig/net/sched/sch_sfq.c
+++ lnx-510/net/sched/sch_sfq.c
@@ -647,7 +647,7 @@ static int sfq_change(struct Qdisc *sch,
}
if (ctl_v1 && !red_check_params(ctl_v1->qth_min, ctl_v1->qth_max,
- ctl_v1->Wlog))
+ ctl_v1->Wlog, ctl_v1->Scell_log))
return -EINVAL;
if (ctl_v1 && ctl_v1->qth_min) {
p = kmalloc(sizeof(*p), GFP_KERNEL);
--- lnx-510.orig/net/sched/sch_choke.c
+++ lnx-510/net/sched/sch_choke.c
@@ -362,7 +362,7 @@ static int choke_change(struct Qdisc *sc
ctl = nla_data(tb[TCA_CHOKE_PARMS]);
- if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+ if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog,
ctl->Scell_log))
return -EINVAL;
if (ctl->limit > CHOKE_MAX_QUEUE)
--- lnx-510.orig/net/sched/sch_gred.c
+++ lnx-510/net/sched/sch_gred.c
@@ -480,7 +480,7 @@ static inline int gred_change_vq(struct
struct gred_sched *table = qdisc_priv(sch);
struct gred_sched_data *q = table->tab[dp];
- if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog)) {
+ if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog,
ctl->Scell_log)) {
NL_SET_ERR_MSG_MOD(extack, "invalid RED parameters");
return -EINVAL;
}
--- lnx-510.orig/net/sched/sch_red.c
+++ lnx-510/net/sched/sch_red.c
@@ -250,7 +250,7 @@ static int __red_change(struct Qdisc *sc
max_P = tb[TCA_RED_MAX_P] ? nla_get_u32(tb[TCA_RED_MAX_P]) : 0;
ctl = nla_data(tb[TCA_RED_PARMS]);
- if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog))
+ if (!red_check_params(ctl->qth_min, ctl->qth_max, ctl->Wlog,
ctl->Scell_log))
return -EINVAL;
err = red_get_flags(ctl->flags, TC_RED_HISTORIC_FLAGS,
Re: [PATCH 2/3] usb: xhci-mtk: fix UAS issue by XHCI_BROKEN_STREAMS quirk
On Mon, 2020-12-21 at 12:35 -0700, Rob Herring wrote:
> On Thu, Dec 17, 2020 at 02:23:50PM +0800, Chunfeng Yun wrote:
> > On Thu, 2020-12-17 at 11:32 +0800, Nicolas Boichat wrote:
> > > On Thu, Dec 17, 2020 at 10:19 AM Chunfeng Yun
> > > wrote:
> > > >
> > > > On Wed, 2020-12-16 at 20:28 +0800, Nicolas Boichat wrote:
> > > > > On Wed, Dec 16, 2020 at 7:53 PM Chunfeng Yun
> > > > > wrote:
> > > > > >
> > > > > > The 0.96 xHCI controller on some platforms does not support
> > > > > > bulk stream even HCCPARAMS says supporting, due to MaxPSASize
> > > > > > is set a non-zero default value by mistake, here use
> > > > > > XHCI_BROKEN_STREAMS quirk to fix it.
> > > > > >
> > > > > > Fixes: 94a631d91ad3 ("usb: xhci-mtk: check hcc_params after adding
> > > > > > primary hcd")
> > > > > > Signed-off-by: Chunfeng Yun
> > > > > > ---
> > > > > > drivers/usb/host/xhci-mtk.c | 7 ++-
> > > > > > drivers/usb/host/xhci-mtk.h | 1 +
> > > > > > 2 files changed, 7 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/usb/host/xhci-mtk.c
> > > > > > b/drivers/usb/host/xhci-mtk.c
> > > > > > index 8f321f39ab96..08dab974d847 100644
> > > > > > --- a/drivers/usb/host/xhci-mtk.c
> > > > > > +++ b/drivers/usb/host/xhci-mtk.c
> > > > > > @@ -395,6 +395,9 @@ static void xhci_mtk_quirks(struct device *dev,
> > > > > > struct xhci_hcd *xhci)
> > > > > > xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
> > > > > > if (mtk->lpm_support)
> > > > > > xhci->quirks |= XHCI_LPM_SUPPORT;
> > > > > > +
> > > > > > + if (mtk->broken_streams)
> > > > > > + xhci->quirks |= XHCI_BROKEN_STREAMS;
> > > > > > }
> > > > > >
> > > > > > /* called during probe() after chip reset completes */
> > > > > > @@ -460,6 +463,8 @@ static int xhci_mtk_probe(struct
> > > > > > platform_device *pdev)
> > > > > > return ret;
> > > > > >
> > > > > > mtk->lpm_support = of_property_read_bool(node,
> > > > > > "usb3-lpm-capable");
> > > > > > + mtk->broken_streams =
> > > > > > + of_property_read_bool(node,
> > > > > > "mediatek,broken_streams_quirk");
> > > > >
> > > > > Would it be better to add a data field to struct of_device_id
> > > > > mtk_xhci_of_match, and enable this quirk on mediatek,mt8173-xhci only?
> > > > This is the common issue for all SoCs (before 2016.06) with 0.96 xHCI
> > > > when the controller don't support bulk stream. If enable this quirk only
> > > > for mt8173, then for other SoCs, the compatible need include
> > > > "mediatek,mt8173-xhci" in dts, this may be not flexible for some cases,
> > > > e.g. a new SoC has the broken stream as mt8173, but also has another
> > > > different quirk, the way you suggested will not handle it.
> > >
> > > It can, we do this regularly for many other components. One example:
> > > https://elixir.bootlin.com/linux/latest/source/drivers/i2c/busses/i2c-mt65xx.c#L402
> > >
> > Got it. Indeed works when add compatible private data.
> >
> > Due to many SoCs supports USB and not upstream, I'd prefer to avoid
> > adding new compatible in driver when support new SoCs, and leave the
> > code as simple as possible.
>
> No. The problem is adding new fixes requires updating the DT. That would
> be fine if you knew all possible issues and quirks up front. You may for
> some, but you won't catch them all.
Yes.
But all SoCs use the generic compatible "mediatek,mtk-xhci" except
mtk8173. as following:
compatible = "mediatek,mt-xhci", "mediatek,mtk-xhci";
It may be a little messy when the driver fill many compatibles after
supporting several tens or hundreds SoCs.
I'll think about it again.
>
> Save DT properties for per board quirks/features, not per SoC ones.
This is for USB IP quirks/feature, not board or SoC
Thanks
>
> >
> > > > And I plan to remove "mediatek,mt8173-xhci" in mtk_xhci_of_match after
> > > > converting the binding to YMAL.
> > > >
> > > > >
> > > > > (IMHO usb3-lpm-capable detection should also be done in the same way)
>
> I tend to agree, but am more tolerable of standard USB features than
> specific IP block quirks.
>
> Rob
[PATCH] drivers core: Free dma_range_map when driver probe failed
From: Limeng There will be memory leak if driver probe failed. Trace as below: backtrace: [<2415258f>] kmemleak_alloc+0x3c/0x50 [] __kmalloc+0x208/0x530 [<48bc7b3a>] of_dma_get_range+0xe4/0x1b0 [<41e39065>] of_dma_configure_id+0x58/0x27c [<6356866a>] platform_dma_configure+0x2c/0x40 .. [<0afcf9b5>] ret_from_fork+0x10/0x3c This issue is introduced by commit e0d072782c73("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset "). It doesn't free dma_range_map when driver probe failed and cause above memory leak. So, add code to free it in error path. Fixes: e0d072782c73("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset ") Cc: sta...@vger.kernel.org Signed-off-by: Meng Li --- drivers/base/dd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 148e81969e04..8e4871aa34bc 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -612,6 +612,7 @@ static int really_probe(struct device *dev, struct device_driver *drv) else if (drv->remove) drv->remove(dev); probe_failed: + kfree(dev->dma_range_map); if (dev->bus) blocking_notifier_call_chain(&dev->bus->p->bus_notifier, BUS_NOTIFY_DRIVER_NOT_BOUND, dev); -- 2.17.1
[PATCH v4] net: neighbor: fix a crash caused by mod zero
pneigh_enqueue() tries to obtain a random delay by mod
NEIGH_VAR(p, PROXY_DELAY). However, NEIGH_VAR(p, PROXY_DELAY)
migth be zero at that point because someone could write zero
to /proc/sys/net/ipv4/neigh/[device]/proxy_delay after the
callers check it.
This patch uses prandom_u32_max() to get a random delay instead
which avoids potential division by zero.
Signed-off-by: weichenchen
---
V4:
- Use prandom_u32_max() to get a random delay in
pneigh_enqueue().
V3:
- Callers need to pass the delay time to pneigh_enqueue()
now and they should guarantee it is not zero.
- Use READ_ONCE() to read NEIGH_VAR(p, PROXY_DELAY) in both
of the existing callers of pneigh_enqueue() and then pass
it to pneigh_enqueue().
V2:
- Use READ_ONCE() to prevent the complier from re-reading
NEIGH_VAR(p, PROXY_DELAY).
- Give a hint to the complier that delay <= 0 is unlikely
to happen.
V4 is quite concise and works well.
Thanks for Eric's and Jakub's advice.
---
net/core/neighbour.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 9500d28a43b0..277ed854aef1 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1569,10 +1569,8 @@ static void neigh_proxy_process(struct timer_list *t)
void pneigh_enqueue(struct neigh_table *tbl, struct neigh_parms *p,
struct sk_buff *skb)
{
- unsigned long now = jiffies;
-
- unsigned long sched_next = now + (prandom_u32() %
- NEIGH_VAR(p, PROXY_DELAY));
+ unsigned long sched_next = jiffies +
+ prandom_u32_max(NEIGH_VAR(p, PROXY_DELAY));
if (tbl->proxy_queue.qlen > NEIGH_VAR(p, PROXY_QLEN)) {
kfree_skb(skb);
--
2.20.1 (Apple Git-117)
Re: [PATCH v2 2/2] drm/bridge: anx7625: disable regulators when power off
On Wed, Dec 9, 2020 at 12:43 PM Hsin-Yi Wang wrote:
>
> On Mon, Nov 23, 2020 at 11:47 AM Hsin-Yi Wang wrote:
> >
> > When suspending the driver, anx7625_power_standby() will be called to
> > turn off reset-gpios and enable-gpios. However, power supplies are not
> > disabled. To save power, the driver can get the power supply regulators
> > and turn off them in anx7625_power_standby().
> >
> > Signed-off-by: Hsin-Yi Wang
>
> Gentle ping on the patch
>
After some testing, the powering sequence has some issue and would
cause i2c failures. The powering sequence needs to be rechecked.
> > ---
> > Change:
> > v2: none
> > ---
> > drivers/gpu/drm/bridge/analogix/anx7625.c | 25 +++
> > drivers/gpu/drm/bridge/analogix/anx7625.h | 1 +
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > index 65cc05982f82..eb9c4cc2504a 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > @@ -11,6 +11,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -875,12 +876,20 @@ static int sp_tx_edid_read(struct anx7625_data *ctx,
> > static void anx7625_power_on(struct anx7625_data *ctx)
> > {
> > struct device *dev = &ctx->client->dev;
> > + int ret;
> >
> > if (!ctx->pdata.low_power_mode) {
> > DRM_DEV_DEBUG_DRIVER(dev, "not low power mode!\n");
> > return;
> > }
> >
> > + ret = regulator_bulk_enable(ARRAY_SIZE(ctx->pdata.supplies),
> > + ctx->pdata.supplies);
> > + if (ret < 0) {
> > + DRM_DEV_DEBUG_DRIVER(dev, "cannot enable regulators %d\n",
> > ret);
> > + return;
> > + }
> > +
> > /* Power on pin enable */
> > gpiod_set_value(ctx->pdata.gpio_p_on, 1);
> > usleep_range(1, 11000);
> > @@ -894,6 +903,7 @@ static void anx7625_power_on(struct anx7625_data *ctx)
> > static void anx7625_power_standby(struct anx7625_data *ctx)
> > {
> > struct device *dev = &ctx->client->dev;
> > + int ret;
> >
> > if (!ctx->pdata.low_power_mode) {
> > DRM_DEV_DEBUG_DRIVER(dev, "not low power mode!\n");
> > @@ -904,6 +914,12 @@ static void anx7625_power_standby(struct anx7625_data
> > *ctx)
> > usleep_range(1000, 1100);
> > gpiod_set_value(ctx->pdata.gpio_p_on, 0);
> > usleep_range(1000, 1100);
> > +
> > + ret = regulator_bulk_disable(ARRAY_SIZE(ctx->pdata.supplies),
> > +ctx->pdata.supplies);
> > + if (ret < 0)
> > + DRM_DEV_DEBUG_DRIVER(dev, "cannot disable regulators %d\n",
> > ret);
> > +
> > DRM_DEV_DEBUG_DRIVER(dev, "power down\n");
> > }
> >
> > @@ -1742,6 +1758,15 @@ static int anx7625_i2c_probe(struct i2c_client
> > *client,
> > platform->client = client;
> > i2c_set_clientdata(client, platform);
> >
> > + pdata->supplies[0].supply = "vdd10";
> > + pdata->supplies[1].supply = "vdd18";
> > + pdata->supplies[2].supply = "vdd33";
> > + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(pdata->supplies),
> > + pdata->supplies);
> > + if (ret) {
> > + DRM_DEV_ERROR(dev, "fail to get power supplies: %d\n", ret);
> > + return ret;
> > + }
> > anx7625_init_gpio(platform);
> >
> > atomic_set(&platform->power_status, 0);
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
> > b/drivers/gpu/drm/bridge/analogix/anx7625.h
> > index 193ad86c5450..e4a086b3a3d7 100644
> > --- a/drivers/gpu/drm/bridge/analogix/anx7625.h
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
> > @@ -350,6 +350,7 @@ struct s_edid_data {
> > struct anx7625_platform_data {
> > struct gpio_desc *gpio_p_on;
> > struct gpio_desc *gpio_reset;
> > + struct regulator_bulk_data supplies[3];
> > struct drm_bridge *panel_bridge;
> > int intp_irq;
> > u32 low_power_mode;
> > --
> > 2.29.2.454.gaff20da3a2-goog
> >
[PATCH v2 1/3] perf probe: Fix memory leak in synthesize_sdt_probe_command()
From: Arnaldo Carvalho de Melo
In synthesize_sdt_probe_command(), it gets argument array from
argv_split() but forgets to free it. This patch calls argv_free() to
free the argument array to avoid memory leak.
Fixes: 3b1f8311f696 ("perf probe: Add sdt probes arguments into the uprobe cmd
string")
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Leo Yan
Cc: sta...@vger.kernel.org
---
tools/perf/util/probe-file.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index 064b63a6a3f3..bbecb449ea94 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -791,7 +791,7 @@ static char *synthesize_sdt_probe_command(struct sdt_note
*note,
const char *sdtgrp)
{
struct strbuf buf;
- char *ret = NULL, **args;
+ char *ret = NULL;
int i, args_count, err;
unsigned long long ref_ctr_offset;
@@ -813,12 +813,19 @@ static char *synthesize_sdt_probe_command(struct sdt_note
*note,
goto out;
if (note->args) {
- args = argv_split(note->args, &args_count);
+ char **args = argv_split(note->args, &args_count);
+
+ if (args == NULL)
+ goto error;
for (i = 0; i < args_count; ++i) {
- if (synthesize_sdt_probe_arg(&buf, i, args[i]) < 0)
+ if (synthesize_sdt_probe_arg(&buf, i, args[i]) < 0) {
+ argv_free(args);
goto error;
+ }
}
+
+ argv_free(args);
}
out:
--
2.17.1
[PATCH v2 3/3] perf arm64: Add argument support for SDT
Now the two OP formats are used for SDT marker argument in Arm64 ELF,
one format is general register xNUM (e.g. x1, x2, etc), another is for
using stack pointer to access local variables (e.g. [sp], [sp, 8]).
This patch adds support SDT marker argument for Arm64, it parses OP and
converts to uprobe compatible format.
Signed-off-by: Leo Yan
Acked-by: Masami Hiramatsu
---
tools/perf/arch/arm64/util/perf_regs.c | 94 ++
1 file changed, 94 insertions(+)
diff --git a/tools/perf/arch/arm64/util/perf_regs.c
b/tools/perf/arch/arm64/util/perf_regs.c
index 54efa12fdbea..2518cde18b34 100644
--- a/tools/perf/arch/arm64/util/perf_regs.c
+++ b/tools/perf/arch/arm64/util/perf_regs.c
@@ -1,4 +1,12 @@
// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include
+
+#include "../../../util/debug.h"
+#include "../../../util/event.h"
#include "../../../util/perf_regs.h"
const struct sample_reg sample_reg_masks[] = {
@@ -37,3 +45,89 @@ const struct sample_reg sample_reg_masks[] = {
SMPL_REG(pc, PERF_REG_ARM64_PC),
SMPL_REG_END
};
+
+/* %xNUM */
+#define SDT_OP_REGEX1 "^(x[1-2]?[0-9]|3[0-1])$"
+
+/* [sp], [sp, NUM] */
+#define SDT_OP_REGEX2 "^\\[sp(, )?([0-9]+)?\\]$"
+
+static regex_t sdt_op_regex1, sdt_op_regex2;
+
+static int sdt_init_op_regex(void)
+{
+ static int initialized;
+ int ret = 0;
+
+ if (initialized)
+ return 0;
+
+ ret = regcomp(&sdt_op_regex1, SDT_OP_REGEX1, REG_EXTENDED);
+ if (ret)
+ goto error;
+
+ ret = regcomp(&sdt_op_regex2, SDT_OP_REGEX2, REG_EXTENDED);
+ if (ret)
+ goto free_regex1;
+
+ initialized = 1;
+ return 0;
+
+free_regex1:
+ regfree(&sdt_op_regex1);
+error:
+ pr_debug4("Regex compilation error.\n");
+ return ret;
+}
+
+/*
+ * SDT marker arguments on Arm64 uses %xREG or [sp, NUM], currently
+ * support these two formats.
+ */
+int arch_sdt_arg_parse_op(char *old_op, char **new_op)
+{
+ int ret, new_len;
+ regmatch_t rm[5];
+
+ ret = sdt_init_op_regex();
+ if (ret < 0)
+ return ret;
+
+ if (!regexec(&sdt_op_regex1, old_op, 3, rm, 0)) {
+ /* Extract xNUM */
+ new_len = 2;/* % NULL */
+ new_len += (int)(rm[1].rm_eo - rm[1].rm_so);
+
+ *new_op = zalloc(new_len);
+ if (!*new_op)
+ return -ENOMEM;
+
+ scnprintf(*new_op, new_len, "%%%.*s",
+ (int)(rm[1].rm_eo - rm[1].rm_so), old_op + rm[1].rm_so);
+ } else if (!regexec(&sdt_op_regex2, old_op, 5, rm, 0)) {
+ /* [sp], [sp, NUM] or [sp,NUM] */
+ new_len = 7;/* + ( % s p ) NULL */
+
+ /* If the arugment is [sp], need to fill offset '0' */
+ if (rm[2].rm_so == -1)
+ new_len += 1;
+ else
+ new_len += (int)(rm[2].rm_eo - rm[2].rm_so);
+
+ *new_op = zalloc(new_len);
+ if (!*new_op)
+ return -ENOMEM;
+
+ if (rm[2].rm_so == -1)
+ scnprintf(*new_op, new_len, "+0(%%sp)");
+ else
+ scnprintf(*new_op, new_len, "+%.*s(%%sp)",
+ (int)(rm[2].rm_eo - rm[2].rm_so),
+ old_op + rm[2].rm_so);
+ } else {
+ pr_debug4("Skipping unsupported SDT argument: %s\n", old_op);
+ return SDT_ARG_SKIP;
+ }
+
+ return SDT_ARG_VALID;
+}
--
2.17.1
[PATCH v2 2/3] perf probe: Fixup Arm64 SDT arguments
Arm64 ELF section '.note.stapsdt' uses string format "-4@[sp, NUM]" if
the probe is to access data in stack, e.g. below is an example for
dumping Arm64 ELF file and shows the argument format:
Arguments: -4@[sp, 12] -4@[sp, 8] -4@[sp, 4]
Comparing against other archs' argument format, Arm64's argument
introduces an extra space character in the middle of square brackets,
due to argv_split() uses space as splitter, the argument is wrongly
divided into two items.
To support Arm64 SDT, this patch fixes up for this case, if any item
contains sub string "[sp", concatenates the two continuous items. And
adds the detailed explaination in comment.
Signed-off-by: Leo Yan
---
tools/perf/util/probe-file.c | 38 ++--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index bbecb449ea94..52273542e6ef 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -794,6 +794,8 @@ static char *synthesize_sdt_probe_command(struct sdt_note
*note,
char *ret = NULL;
int i, args_count, err;
unsigned long long ref_ctr_offset;
+ char *arg;
+ int arg_idx = 0;
if (strbuf_init(&buf, 32) < 0)
return NULL;
@@ -818,11 +820,43 @@ static char *synthesize_sdt_probe_command(struct sdt_note
*note,
if (args == NULL)
goto error;
- for (i = 0; i < args_count; ++i) {
- if (synthesize_sdt_probe_arg(&buf, i, args[i]) < 0) {
+ for (i = 0; i < args_count; ) {
+ /*
+* FIXUP: Arm64 ELF section '.note.stapsdt' uses string
+* format "-4@[sp, NUM]" if a probe is to access data in
+* the stack, e.g. below is an example for the SDT
+* Arguments:
+*
+* Arguments: -4@[sp, 12] -4@[sp, 8] -4@[sp, 4]
+*
+* Since the string introduces an extra space character
+* in the middle of square brackets, the argument is
+* divided into two items. Fixup for this case, if an
+* item contains sub string "[sp,", need to concatenate
+* the two items.
+*/
+ if (strstr(args[i], "[sp,") && (i+1) < args_count) {
+ err = asprintf(&arg, "%s %s", args[i],
args[i+1]);
+ i += 2;
+ } else {
+ err = asprintf(&arg, "%s", args[i]);
+ i += 1;
+ }
+
+ /* Failed to allocate memory */
+ if (err < 0) {
argv_free(args);
goto error;
}
+
+ if (synthesize_sdt_probe_arg(&buf, arg_idx, arg) < 0) {
+ free(arg);
+ argv_free(args);
+ goto error;
+ }
+
+ free(arg);
+ arg_idx++;
}
argv_free(args);
--
2.17.1
[PATCH v2 0/3] perf arm64: Support SDT
This patch is to enable SDT on Arm64. Since Arm64 SDT marker in ELF file is different from other archs, especially for using stack pointer (sp) to retrieve data for local variables, patch 01 is used to fixup the arguments for this special case. Patch 02 is to add argument support for Arm64 SDT. This patch set has been verified on Arm64/x86_64 platforms with a testing program usdt_test. The testing approach is described in the patch set v1 [1]. Changes from v1: * Added Arnaldo's patch for fixing memory leak (Arnaldo); * Refined patch "perf probe: Fixup Arm64 SDT arguments" to use asprintf() and check pointer is valid or not (Arnaldo); * Minor changes in patch "perf arm64: Add argument support for SDT" for the regular expression; * Added Masami's Ack tag for patch 03. [1] https://lore.kernel.org/patchwork/cover/1356212/ Arnaldo Carvalho de Melo (1): perf probe: Fix memory leak in synthesize_sdt_probe_command() Leo Yan (2): perf probe: Fixup Arm64 SDT arguments perf arm64: Add argument support for SDT tools/perf/arch/arm64/util/perf_regs.c | 94 ++ tools/perf/util/probe-file.c | 49 -- 2 files changed, 139 insertions(+), 4 deletions(-) -- 2.17.1
Re: [PATCH V6 03/13] soc: mediatek: add driver for dvfsrc support
On Thu, 2020-12-24 at 22:33 +0800, Chun-Kuang Hu wrote: Hi CK, > Hi, Henry: > > Henry Chen 於 2020年12月24日 週四 下午2:09寫道： > > > > Add dvfsrc driver for MT6873/MT8183/MT8192 > > Separate this patch for each SoC. OK, thanks. Henry > > Regards, > Chun-Kuang. > > > > > Signed-off-by: Henry Chen > > --- > > drivers/soc/mediatek/Kconfig| 12 + > > drivers/soc/mediatek/Makefile | 1 + > > drivers/soc/mediatek/mtk-dvfsrc.c | 538 > > > > include/linux/soc/mediatek/mtk_dvfsrc.h | 35 +++ > > 4 files changed, 586 insertions(+) > > create mode 100644 drivers/soc/mediatek/mtk-dvfsrc.c > > create mode 100644 include/linux/soc/mediatek/mtk_dvfsrc.h > >
Re: [PATCH V6 01/13] dt-bindings: soc: Add dvfsrc driver bindings
On Thu, 2020-12-24 at 10:01 -0700, Rob Herring wrote: > On Thu, 24 Dec 2020 14:08:42 +0800, Henry Chen wrote: > > Document the binding for enabling dvfsrc on MediaTek SoC. > > > > Signed-off-by: Henry Chen > > --- > > .../devicetree/bindings/soc/mediatek/dvfsrc.yaml | 68 > > ++ > > 1 file changed, 68 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/soc/mediatek/dvfsrc.yaml > > > > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > Documentation/devicetree/bindings/soc/mediatek/dvfsrc.example.dts:19:18: > fatal error: dt-bindings/soc/mtk,dvfsrc.h: No such file or directory >19 | #include > | ^~ > compilation terminated. > make[1]: *** [scripts/Makefile.lib:342: > Documentation/devicetree/bindings/soc/mediatek/dvfsrc.example.dt.yaml] Error 1 > make: *** [Makefile:1370: dt_binding_check] Error 2 > > See https://patchwork.ozlabs.org/patch/1420382 > > This check can fail if there are any dependencies. The base for a patch > series is generally the most recent rc1. > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit. > Hi Rob, Sorry for the check error, I will re-check and submit again. Thanks, Henry
[PATCH] psi: Add PSI_CPU_FULL state
From: zhouchengming
When I run a simple "perf bench sched pipe" test in a cgroup on my
machine, the output of "watch -d -n 1 cpu.pressure" of this cgroup
will report some avg10 10%-20%.
It's strange because there is not any other process in the cgroup.
Then I found that cpu contention/wait percentage came from outside
of the cgroup and the cpu idle latency, not wait for threads in
the cgroup.
So I think adding PSI_CPU_FULL state will be useful for container
workloads to distinguish between outside cgroup resource contention
and inside cgroup resource contention.
What's more, the PSI_CPU_FULL state includes the latency of the cpu
idle itself, so we can see the system sum latency introduced by cpu
idle state.
Signed-off-by: zhouchengming
---
include/linux/psi_types.h | 3 ++-
kernel/sched/psi.c| 9 +++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/include/linux/psi_types.h b/include/linux/psi_types.h
index b95f3211566a..0a23300d49af 100644
--- a/include/linux/psi_types.h
+++ b/include/linux/psi_types.h
@@ -50,9 +50,10 @@ enum psi_states {
PSI_MEM_SOME,
PSI_MEM_FULL,
PSI_CPU_SOME,
+ PSI_CPU_FULL,
/* Only per-CPU, to weigh the CPU in the global average: */
PSI_NONIDLE,
- NR_PSI_STATES = 6,
+ NR_PSI_STATES = 7,
};
enum psi_aggregators {
diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 967732c0766c..234047e368a5 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -224,7 +224,9 @@ static bool test_state(unsigned int *tasks, enum psi_states
state)
case PSI_MEM_FULL:
return tasks[NR_MEMSTALL] && !tasks[NR_RUNNING];
case PSI_CPU_SOME:
- return tasks[NR_RUNNING] > tasks[NR_ONCPU];
+ return tasks[NR_RUNNING] > tasks[NR_ONCPU] && tasks[NR_ONCPU];
+ case PSI_CPU_FULL:
+ return tasks[NR_RUNNING] && !tasks[NR_ONCPU];
case PSI_NONIDLE:
return tasks[NR_IOWAIT] || tasks[NR_MEMSTALL] ||
tasks[NR_RUNNING];
@@ -681,6 +683,9 @@ static void record_times(struct psi_group_cpu *groupc, int
cpu,
if (groupc->state_mask & (1 << PSI_CPU_SOME))
groupc->times[PSI_CPU_SOME] += delta;
+ if (groupc->state_mask & (1 << PSI_CPU_FULL))
+ groupc->times[PSI_CPU_FULL] += delta;
+
if (groupc->state_mask & (1 << PSI_NONIDLE))
groupc->times[PSI_NONIDLE] += delta;
}
@@ -1018,7 +1023,7 @@ int psi_show(struct seq_file *m, struct psi_group *group,
enum psi_res res)
group->avg_next_update = update_averages(group, now);
mutex_unlock(&group->avgs_lock);
- for (full = 0; full < 2 - (res == PSI_CPU); full++) {
+ for (full = 0; full < 2; full++) {
unsigned long avg[3];
u64 total;
int w;
--
2.11.0
INVESTMENT BTC FARM
GOOD NEWS TO YOU ALL !!! WE ARE HERE TO INTRODUCE BINARY TRADING TO YOU, A PLATFORM WHERE YOU INVEST A LITTLE AMOUNT OF MONEY AND EARN A FORTUNE (7 TIMES RETURN) IN LESS THAN 48 HOURS TO ALL YOU TRADERS THAT PRIORITIZE LOSING, WE CAN MAKE A FORTUNE AND HELP YOU GROW YOUR INVESTMENT. WITH OUR PREMIUM SIGNALS UP TO 95% WINNING ACCURACY PROFIT RETURN IS GUARANTEED. SETUP INVESTMENT TODAY LET OUR TEAM OF PROFESSIONALS TRADE FOR YOU TO EARN 700% PROFIT RETURN WITHIN 2 DAYS. Invest $ 500 earn $ 3,000 IN 48 HOURS Invest $ 1000 earn $ 6,000 IN 48 HOURS Invest $ 2000 earn $ 12,000 IN 48 HOURS Invest $ 3000 earn $ 18,000 IN 48 HOURS Invest $ 4000 earn $ 24,000 IN 48 HOURS Invest $ 5000 earn $ 30,000 IN 48 HOURS for more information email us now and with our team of professionals trade for you EMAIL: ulsterc...@gmail.com WHATSAPP : +1 647 477 6855 Invest with a professional trader like me and let me help you to grow up your capital just in 2 days and get your 7 times return of your invested funds your money is safe with me okay and you are 100% guaranteed invest today and start making profits for yourself. Thank you. Jonas Kim
Re: [PATCH] HID: Add Wireless Radio Control feature for Chicony devices
Pavel Machek 於 2020年12月25日 週五 上午3:06寫道： > > On Tue 2020-12-22 15:38:56, Jian-Hong Pan wrote: > > Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with > > "Wireless Radio Control" feature. For example, the wireless keyboard > > [04f2:1236] shipped with ASUS all-in-one desktop. > > > > After consulting Chicony for this hotkey, learned the device will send > > with 0x11 as the report ID and 0x1 as the value when the key is pressed > > down. > > Fun, how can airplane mode work on _wireless_ keyboard? :-). Hmm! It is a funny point for this USB wireless keyboard! But I guess this kind of combination (with the "desktop") will not be used on an airplane :) Jian-Hong Pan
Re: [PATCH v2, 3/3] mailbox: cmdq: add mt8192 support
On Thu, 2020-12-24 at 22:28 +0800, Chun-Kuang Hu wrote:
> Hi, Yongqiang:
>
> Yongqiang Niu 於 2020年12月24日 週四 上午8:55寫道：
> >
> > add mt8192 support
> >
> > Signed-off-by: Yongqiang Niu
> > ---
> > drivers/mailbox/mtk-cmdq-mailbox.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> > b/drivers/mailbox/mtk-cmdq-mailbox.c
> > index 75378e3..7f243e1 100644
> > --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> > @@ -607,6 +607,7 @@ static int cmdq_probe(struct platform_device *pdev)
> > {.compatible = "mediatek,mt8173-gce", .data = (void *)&gce_plat_v2},
> > {.compatible = "mediatek,mt8183-gce", .data = (void *)&gce_plat_v3},
> > {.compatible = "mediatek,mt6779-gce", .data = (void *)&gce_plat_v4},
> > + {.compatible = "mediatek,mt8192-gce", .data = (void *)&gce_plat_v4},
>
> In the view of hardware function, is mt8192-gce identical to
> mt6779-gce? If these two are identical, you need not to modify driver,
> and the compatible should be
>
> compatible = "mediatek,mt8192-gce", "mediatek,mt6779-gce";
>
> If they are not identical, what's the different?
>
> Regards,
> Chun-Kuang.
irq id is different
mt8192 dts
https://patchwork.kernel.org/project/linux-mediatek/patch/1608770889-9403-3-git-send-email-yongqiang@mediatek.com/
mt6779 dts
https://patchwork.kernel.org/project/linux-mediatek/patch/1574327552-11806-6-git-send-email-dennis-yc.hs...@mediatek.com/
and gce event id also different
https://patchwork.kernel.org/project/linux-mediatek/patch/1608770889-9403-2-git-send-email-yongqiang@mediatek.com/
https://patchwork.kernel.org/project/linux-mediatek/patch/1574327552-11806-2-git-send-email-dennis-yc.hs...@mediatek.com/
>
> > {}
> > };
> >
> > --
> > 1.8.1.1.dirty
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v1 1/2] perf probe: Fixup Arm64 SDT arguments
On Thu, Dec 24, 2020 at 10:51:39AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 23, 2020 at 02:39:04PM +0800, Leo Yan escreveu:
> > Arm64 ELF section '.note.stapsdt' uses string format "-4@[sp, NUM]" if
> > the probe is to access data in stack, e.g. below is an example for
> > dumping Arm64 ELF file and shows the argument format:
> >
> > Arguments: -4@[sp, 12] -4@[sp, 8] -4@[sp, 4]
> >
> > Comparing against other archs' argument format, Arm64's argument
> > introduces an extra space character in the middle of square brackets,
> > due to argv_split() uses space as splitter, the argument is wrongly
> > divided into two items.
> >
> > To support Arm64 SDT, this patch fixes up for this case, if any item
> > contains sub string "[sp", concatenates the two continuous items. And
> > adds the detailed explaination in comment.
> >
> > Signed-off-by: Leo Yan
> > ---
> > tools/perf/util/probe-file.c | 32 ++--
> > 1 file changed, 30 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
> > index 064b63a6a3f3..60878c859e60 100644
> > --- a/tools/perf/util/probe-file.c
> > +++ b/tools/perf/util/probe-file.c
> > @@ -794,6 +794,8 @@ static char *synthesize_sdt_probe_command(struct
> > sdt_note *note,
> > char *ret = NULL, **args;
> > int i, args_count, err;
> > unsigned long long ref_ctr_offset;
> > + char *arg;
> > + int arg_idx = 0;
> >
> > if (strbuf_init(&buf, 32) < 0)
> > return NULL;
> > @@ -815,8 +817,34 @@ static char *synthesize_sdt_probe_command(struct
> > sdt_note *note,
> > if (note->args) {
> > args = argv_split(note->args, &args_count);
> >
> > - for (i = 0; i < args_count; ++i) {
> > - if (synthesize_sdt_probe_arg(&buf, i, args[i]) < 0)
> > + for (i = 0; i < args_count; ) {
> > + /*
> > +* FIXUP: Arm64 ELF section '.note.stapsdt' uses string
> > +* format "-4@[sp, NUM]" if a probe is to access data in
> > +* the stack, e.g. below is an example for the SDT
> > +* Arguments:
> > +*
> > +* Arguments: -4@[sp, 12] -4@[sp, 8] -4@[sp, 4]
> > +*
> > +* Since the string introduces an extra space character
> > +* in the middle of square brackets, the argument is
> > +* divided into two items. Fixup for this case, if an
> > +* item contains sub string "[sp,", need to concatenate
> > +* the two items.
> > +*/
> > + if (strstr(args[i], "[sp,") && (i+1) < args_count) {
> > + arg = strcat(args[i], args[i+1]);
> > + i += 2;
> > + } else {
> > + arg = strdup(args[i]);
> > + i += 1;
> > + }
> > +
> > + err = synthesize_sdt_probe_arg(&buf, arg_idx, arg);
> > + free(arg);
>
> So you free here unconditionally because either you used something you
> got from argv_split() that strdup'ed all the entries in the array it
> returns, or that you strdup'ed in the else branch.
> But then you may not free all the things argv_split() returned, right?
Yes.
> Also, that strcat(args[i], args[i+1]), are you sure that is safe? strcat
> expects dest to have enough space for the concatenation, I don't see
> argv_split[] adding extra bytes, just a strdup().
Correct, will change to use asprintf().
> So probably you need asprintf() where you use strcat() and then, at the
> end of the loop, you need to free what argv_split() returned, using
> argv_free(), no?
>
> Also please check strdup() (and then asprintf) managed to allocate, else
> synthesize_sdt_probe_arg() will receive its 'desc' argument as NULL, do
> _another_ strdup on it and boom.
Will add checking for the pointer from strdup()/asprintf().
> Or am I missing something? :)
>
> I just looked ant synthesize_sdt_probe_command() is leaking the args it
> gets from argv_split()
>
> So this patch is needed, ack?
Below change is good for me. In the next respin, I will add this new
patch with your author name and send out.
Thanks a lot for the review, Masami & Arnaldo!
> diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
> index 064b63a6a3f311cd..bbecb449ea944395 100644
> --- a/tools/perf/util/probe-file.c
> +++ b/tools/perf/util/probe-file.c
> @@ -791,7 +791,7 @@ static char *synthesize_sdt_probe_command(struct sdt_note
> *note,
> const char *sdtgrp)
> {
> struct strbuf buf;
> - char *ret = NULL, **args;
> + char *ret = NULL;
> int i, args_count, err;
> unsigned long long ref_ctr_offset;
>
> @@ -813,12 +813,19 @@ static char *synthesiz
Re: [PATCH v4 10/11] dt-bindings: usb: convert mediatek,mtu3.txt to YAML schema
On Mon, 2020-12-21 at 12:26 -0700, Rob Herring wrote: > On Wed, Dec 16, 2020 at 05:30:11PM +0800, Chunfeng Yun wrote: > > Convert mediatek,mtu3.txt to YAML schema mediatek,mtu3.yaml > > > > Signed-off-by: Chunfeng Yun > > --- > > v4: > > 1. refer to usb-drd.yaml insstead of usb/generic.txt > > the following ones suggested by Rob: > > 2. add the number of phys supported > > 3. fix indentation of wakeup > > 4. add examples for port and connector > > > > v3: > > 1. fix yamllint warning > > 2. remove pinctrl* properties > > 3. remove unnecessary '|' > > 4. drop unused labels in example > > > > v2: new patch > > --- > > .../devicetree/bindings/usb/mediatek,mtu3.txt | 108 --- > > .../bindings/usb/mediatek,mtu3.yaml | 278 ++ > > 2 files changed, 278 insertions(+), 108 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.txt > > create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml > > [...] > > + > > + power-domains: > > +description: A phandle to USB power domain node to control USB's MTCMOS > > +maxItems: 1 > > + > > + clocks: > > +minItems: 1 > > +maxItems: 4 > > Don't need maxItems here. Ok, will remove it, and apply others > > > +items: > > + - description: Controller clock used by normal mode > > + - description: Reference clock used by low power mode etc > > + - description: Mcu bus clock for register access > > + - description: DMA bus clock for data transfer > > + > > + clock-names: > > +minItems: 1 > > +maxItems: 4 > > +items: > > + - const: sys_ck # required, the following ones are optional > > + - const: ref_ck > > + - const: mcu_ck > > + - const: dma_ck > > + > > + phys: > > +description: List of all the USB PHYs used > > +minItems: 0 > > +maxItems: 9 > > Need to define what each one is. Ok, will do it > > > + > > + vusb33-supply: > > +description: Regulator of USB AVDD3.3v > > + > > + vbus-supply: > > +deprecated: true > > +description: | > > + Regulator of USB VBUS5v, needed when supports dual-role mode. > > + Particularly, if use an output GPIO to control a VBUS regulator, > > should > > + model it as a regulator. See bindings/regulator/fixed-regulator.yaml > > + It's considered valid for compatibility reasons, not allowed for > > + new bindings, and put into a usb-connector node. > > + > > + dr_mode: > > +enum: [host, peripheral, otg] > > +default: otg > > + > > + maximum-speed: > > +enum: [super-speed-plus, super-speed, high-speed, full-speed] > > + > > + "#address-cells": > > +enum: [1, 2] > > + > > + "#size-cells": > > +enum: [1, 2] > > + > > + ranges: true > > + > > + extcon: > > +deprecated: true > > +description: | > > + Phandle to the extcon device detecting the IDDIG/VBUS state, neede > > + when supports dual-role mode. > > + It's considered valid for compatibility reasons, not allowed for > > + new bindings, and use "usb-role-switch" property instead. > > + > > + usb-role-switch: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: Support role switch. > > +type: boolean > > + > > + connector: > > +$ref: /connector/usb-connector.yaml# > > +description: > > + Connector for dual role switch, especially for "gpio-usb-b-connector" > > +type: object > > + > > + port: > > +description: > > + Any connector to the data bus of this controller should be modelled > > + using the OF graph bindings specified, if the "usb-role-switch" > > + property is used. See graph.txt > > +type: object > > + > > + enable-manual-drd: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: > > + supports manual dual-role switch via debugfs; usually used when > > + receptacle is TYPE-A and also wants to support dual-role mode. > > +type: boolean > > + > > + wakeup-source: > > +description: enable USB remote wakeup, see power/wakeup-source.txt > > +type: boolean > > + > > + mediatek,syscon-wakeup: > > +$ref: /schemas/types.yaml#/definitions/phandle-array > > +maxItems: 1 > > +description: > > + A phandle to syscon used to access the register of the USB wakeup > > glue > > + layer between xHCI and SPM, the field should always be 3 cells long. > > +items: > > + items: > > +- description: > > +The first cell represents a phandle to syscon > > +- description: > > +The second cell represents the register base address of the > > glue > > +layer in syscon > > +- description: > > +The third cell represents the hardware version of the glue > > layer, > > +1 is used by mt8173 etc, 2 is used by mt2712 etc > > + enum: [1, 2] > > + > > + mediatek,u3p-dis-msk: > > +$ref: /schemas/types.yaml#/def
[PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc
Currently hda on tegra30 fails to open a stream with an input/output error.
This is similar to the issue referenced in [1].
For example:
speaker-test -Dhw:0,3 -c 2
speaker-test 1.2.2
Playback device is hw:0,3
Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 16384
Period size range from 32 to 8192
Using max buffer size 16384
Periods = 4
was set period_size = 4096
was set buffer_size = 16384
0 - Front Left
Write error: -5,Input/output error
xrun_recovery failed: -5,Input/output error
Transfer failed: Input/output error
[1] states "Due to a legacy HW design problem", implying the issue applies to
all previous tegra-hda devices.
The tegra-hda device was introduced in tegra30 but only utilized in tegra124
until now.
For this reason it is unknown when this issue first manifested.
Applying the fix in [1] universally resolves this issue on tegra30.
Tested on the Ouya game console and the tf201 tablet.
[1] 60019d8c650d ("ALSA: hda/tegra: workaround playback failure on Tegra194")
Signed-off-by: Peter Geis
Tested-by: Ion Agorria
---
sound/pci/hda/hda_tegra.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
index 70164d1428d4..f8d61e677a09 100644
--- a/sound/pci/hda/hda_tegra.c
+++ b/sound/pci/hda/hda_tegra.c
@@ -388,8 +388,7 @@ static int hda_tegra_first_init(struct azx *chip, struct
platform_device *pdev)
* in powers of 2, next available ratio is 16 which can be
* used as a limiting factor here.
*/
- if (of_device_is_compatible(np, "nvidia,tegra194-hda"))
- chip->bus.core.sdo_limit = 16;
+ chip->bus.core.sdo_limit = 16;
/* codec detection */
if (!bus->codec_mask) {
--
2.25.1
[PATCH 1/2] clk: tegra30: Add hda clock default rates to clock driver
Current implementation defaults the hda clocks to clk_m.
This causes hda to run too slow to operate correctly.
Fix this by defaulting to pll_p and setting the frequency to the correct rate.
This matches upstream t124 and downstream t30.
Signed-off-by: Peter Geis
Tested-by: Ion Agorria
---
drivers/clk/tegra/clk-tegra30.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 37244a7e68c2..9cf249c344d9 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1256,6 +1256,8 @@ static struct tegra_clk_init_table init_table[]
__initdata = {
{ TEGRA30_CLK_I2S3_SYNC, TEGRA30_CLK_CLK_MAX, 2400, 0 },
{ TEGRA30_CLK_I2S4_SYNC, TEGRA30_CLK_CLK_MAX, 2400, 0 },
{ TEGRA30_CLK_VIMCLK_SYNC, TEGRA30_CLK_CLK_MAX, 2400, 0 },
+ { TEGRA30_CLK_HDA, TEGRA30_CLK_PLL_P, 10200, 0 },
+ { TEGRA30_CLK_HDA2CODEC_2X, TEGRA30_CLK_PLL_P, 4800, 0 },
/* must be the last entry */
{ TEGRA30_CLK_CLK_MAX, TEGRA30_CLK_CLK_MAX, 0, 0 },
};
--
2.25.1
[PATCH 0/2] fix tegra-hda on tegra30 devices
The following patches fix tegra-hda on legacy tegra devices. Two issues were discovered preventing tegra-hda from functioning: The hda clocks on tegra30 were assigned to clk_m and running at too low of a rate to function. The tegra-hda encounters an input/output error when opening a stream. Since the only mainline device that used tegra-hda previously was the t124, it is unknown exactly when this was broken. Fortunately a recent patch was submitted that fixed the issue only on t194 devices. We can apply it universally to the tegra-hda device to resolve the issues across the board. Note that downstream devices used the spdif device instead of hda for hdmi audio. The spdif device lacks a driver on mainline. Peter Geis (2): clk: tegra30: Add hda clock default rates to clock driver ALSA: hda/tegra: fix tegra-hda on tegra30 soc drivers/clk/tegra/clk-tegra30.c | 2 ++ sound/pci/hda/hda_tegra.c | 3 +-- 2 files changed, 3 insertions(+), 2 deletions(-) -- 2.25.1
Re: [PATCH v2] perf script: Fix overrun issue for dynamically-allocated pmu type number
Hi Arnaldo, Jiri,
On 12/11/2020 2:10 PM, Adrian Hunter wrote:
On 9/12/20 2:58 am, Jin Yao wrote:
When unpacking the event which is from dynamic pmu, the array
output[OUTPUT_TYPE_MAX] may be overrun. For example, type number of
SKL uncore_imc is 10, but OUTPUT_TYPE_MAX is 7 now (OUTPUT_TYPE_MAX =
PERF_TYPE_MAX + 1).
/* In builtin-script.c */
process_event()
{
unsigned int type = output_type(attr->type);
if (output[type].fields == 0)
return;
}
output[10] is overrun.
Create a type OUTPUT_TYPE_OTHER for dynamic pmu events, then
output_type(attr->type) will return OUTPUT_TYPE_OTHER here.
Note that if PERF_TYPE_MAX ever changed, then there would be a conflict
between old perf.data files that had a dynamicaliy allocated PMU number
that would then be the same as a fixed PERF_TYPE.
Example:
perf record --switch-events -C 0 -e
"{cpu-clock,uncore_imc/data_reads/,uncore_imc/data_writes/}:SD" -a -- sleep 1
perf script
Before:
swapper 0 [000] 1479253.987551: 277766
cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
swapper 0 [000] 1479253.987797: 246709
cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
swapper 0 [000] 1479253.988127: 329883
cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
swapper 0 [000] 1479253.988273: 146393
cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
swapper 0 [000] 1479253.988523: 249977
cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
swapper 0 [000] 1479253.988877: 354090
cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
swapper 0 [000] 1479253.989023: 145940
cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
swapper 0 [000] 1479253.989383: 359856
cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
swapper 0 [000] 1479253.989523: 140082
cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
After:
swapper 0 [000] 1397040.402011: 272384
cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
swapper 0 [000] 1397040.402011: 5396
uncore_imc/data_reads/:
swapper 0 [000] 1397040.402011:967
uncore_imc/data_writes/:
swapper 0 [000] 1397040.402259: 249153
cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
swapper 0 [000] 1397040.402259: 7231
uncore_imc/data_reads/:
swapper 0 [000] 1397040.402259: 1297
uncore_imc/data_writes/:
swapper 0 [000] 1397040.402508: 249108
cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
swapper 0 [000] 1397040.402508: 5333
uncore_imc/data_reads/:
swapper 0 [000] 1397040.402508: 1008
uncore_imc/data_writes/:
Signed-off-by: Jin Yao
Acked-by: Adrian Hunter
Can this patch be accepted? :)
Thanks
Jin Yao
---
v2:
Remove Fixes tag because this issue has always been here, not caused by
1405720d4f26 ("perf script: Add 'synth' event type for synthesized events").
No functional change in v2.
tools/perf/builtin-script.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 1c322c129185..5d8a64836228 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -183,6 +183,7 @@ struct output_option {
enum {
OUTPUT_TYPE_SYNTH = PERF_TYPE_MAX,
+ OUTPUT_TYPE_OTHER,
OUTPUT_TYPE_MAX
};
@@ -279,6 +280,18 @@ static struct {
.invalid_fields = PERF_OUTPUT_TRACE | PERF_OUTPUT_BPF_OUTPUT,
},
+
+ [OUTPUT_TYPE_OTHER] = {
+ .user_set = false,
+
+ .fields = PERF_OUTPUT_COMM | PERF_OUTPUT_TID |
+ PERF_OUTPUT_CPU | PERF_OUTPUT_TIME |
+ PERF_OUTPUT_EVNAME | PERF_OUTPUT_IP |
+ PERF_OUTPUT_SYM | PERF_OUTPUT_SYMOFFSET |
+ PERF_OUTPUT_DSO | PERF_OUTPUT_PERIOD,
+
+ .invalid_fields = PERF_OUTPUT_TRACE | PERF_OUTPUT_BPF_OUTPUT,
+ },
};
struct evsel_script {
@@ -339,8 +352,11 @@ static inline int output_type(unsigned int type)
case PERF_TYPE_SYNTH:
return OUTPUT_TYPE_SYNTH;
default:
- return type;
+ if (type < PERF_TYPE_MAX)
+ return type;
}
+
+ return OUTPUT_TYPE_OTHER;
}
static inline unsigned int attr_type(unsigned int
[PATCH v3] perf stat: Fix wrong skipping for per-die aggregation
Uncore becomes die-scope on Xeon Cascade Lake-AP and perf has supported --per-die aggregation yet. One issue is found in check_per_pkg() for uncore events running on AP system. On cascade Lake-AP, we have: S0-D0 S0-D1 S1-D0 S1-D1 But in check_per_pkg(), S0-D1 and S1-D1 are skipped because the mask bits for S0 and S1 have been set for S0-D0 and S1-D0. It doesn't check die_id. So the counting for S0-D1 and S1-D1 are set to zero. That's not correct. root@lkp-csl-2ap4 ~# ./perf stat -a -I 1000 -e llc_misses.mem_read --per-die -- sleep 5 1.001460963 S0-D0 11317376 Bytes llc_misses.mem_read 1.001460963 S0-D1 1 998016 Bytes llc_misses.mem_read 1.001460963 S1-D0 1 970496 Bytes llc_misses.mem_read 1.001460963 S1-D1 11291264 Bytes llc_misses.mem_read 2.003488021 S0-D0 11082048 Bytes llc_misses.mem_read 2.003488021 S0-D1 11919040 Bytes llc_misses.mem_read 2.003488021 S1-D0 1 890752 Bytes llc_misses.mem_read 2.003488021 S1-D1 12380800 Bytes llc_misses.mem_read 3.005613270 S0-D0 11126080 Bytes llc_misses.mem_read 3.005613270 S0-D1 12898176 Bytes llc_misses.mem_read 3.005613270 S1-D0 1 870912 Bytes llc_misses.mem_read 3.005613270 S1-D1 13388608 Bytes llc_misses.mem_read 4.007627598 S0-D0 11124608 Bytes llc_misses.mem_read 4.007627598 S0-D1 13884416 Bytes llc_misses.mem_read 4.007627598 S1-D0 1 921088 Bytes llc_misses.mem_read 4.007627598 S1-D1 14451840 Bytes llc_misses.mem_read 5.001479927 S0-D0 1 963328 Bytes llc_misses.mem_read 5.001479927 S0-D1 14831936 Bytes llc_misses.mem_read 5.001479927 S1-D0 1 895104 Bytes llc_misses.mem_read 5.001479927 S1-D1 15496640 Bytes llc_misses.mem_read >From above output, we can see S0-D1 and S1-D1 don't report the interval values, they are continued to grow. That's because check_per_pkg() wrongly decides to use zero counts for S0-D1 and S1-D1. So in check_per_pkg(), we should use hashmap(socket,die) to decide if the cpu counts needs to skip. Only considering socket is not enough. Now with this patch, root@lkp-csl-2ap4 ~# ./perf stat -a -I 1000 -e llc_misses.mem_read --per-die -- sleep 5 1.001617187 S0-D0 1 952768 Bytes llc_misses.mem_read 1.001617187 S0-D1 1 849152 Bytes llc_misses.mem_read 1.001617187 S1-D0 1 854912 Bytes llc_misses.mem_read 1.001617187 S1-D1 1 948672 Bytes llc_misses.mem_read 2.004138021 S0-D0 11200256 Bytes llc_misses.mem_read 2.004138021 S0-D1 1 899840 Bytes llc_misses.mem_read 2.004138021 S1-D0 1 898752 Bytes llc_misses.mem_read 2.004138021 S1-D1 11039424 Bytes llc_misses.mem_read 3.006463971 S0-D0 11029056 Bytes llc_misses.mem_read 3.006463971 S0-D1 1 894336 Bytes llc_misses.mem_read 3.006463971 S1-D0 1 905088 Bytes llc_misses.mem_read 3.006463971 S1-D1 11042880 Bytes llc_misses.mem_read 4.008831441 S0-D0 1 920576 Bytes llc_misses.mem_read 4.008831441 S0-D1 1 877248 Bytes llc_misses.mem_read 4.008831441 S1-D0 1 883968 Bytes llc_misses.mem_read 4.008831441 S1-D1 1 967168 Bytes llc_misses.mem_read 5.001441349 S0-D0 1 864704 Bytes llc_misses.mem_read 5.001441349 S0-D1 1 827456 Bytes llc_misses.mem_read 5.001441349 S1-D0 1 829632 Bytes llc_misses.mem_read 5.001441349 S1-D1 1 925760 Bytes llc_misses.mem_read On no-die system, die_id is 0, actually it's hashmap(socket,0), original behavior is not changed. Reported-by: Huang Ying Signed-off-by: Jin Yao --- v3: Since for some cpumap functions, the return type is changed from 'int' to 'struct aggr_cpu_id', the patch needs to be updated as well. before: d = cpu_map__get_die() after: d = cpu_map__get_die().die v3 is compiled ok with tmp.perf/core. v2: Use hashmap to check the used socket+die pair. tools/perf/util/evsel.c | 4 ++- tools/perf/util/evsel.h | 3 +- tools/perf/util/stat.c | 61 + 3 files changed, 60 insertions(+), 8 deletions(-) diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index c26ea82220bd..9715ed9b03f6 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/u
Re: [PATCH] bpf: fix: address of local auto-variable assigned to a function parameter.
On 12/24/20 12:01 AM, YANG LI wrote:
> Assigning local variable txq to the outputting parameter xdp->txq is not
> safe, txq will be released after the end of the function call.
> Then the result of using xdp is unpredictable.
txq can only be accessed in this devmap context. Was it actually hit
during runtime or is this report based on code analysis?
>
> Fix this error by defining the struct xdp_txq_info in function
> dev_map_run_prog() as a static type.
>
> Signed-off-by: YANG LI
> Reported-by: Abaci
> ---
> kernel/bpf/devmap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> index f6e9c68..af6f004 100644
> --- a/kernel/bpf/devmap.c
> +++ b/kernel/bpf/devmap.c
> @@ -454,7 +454,7 @@ static struct xdp_buff *dev_map_run_prog(struct
> net_device *dev,
>struct xdp_buff *xdp,
>struct bpf_prog *xdp_prog)
> {
> - struct xdp_txq_info txq = { .dev = dev };
> + static struct xdp_txq_info txq = { .dev = dev };
> u32 act;
>
> xdp_set_data_meta_invalid(xdp);
>
RE: [PATCH] usb: host: xhci: mvebu: make USB 3.0 PHY optional for Armada 3720
> > > > > > If not supported by ATF, then where to power on and off PHY since no other > place calls PHY APIs? Is it always on? > > > > Yes, in this case (when -EOPNOTSUPP is returned) SMC API is not > > supported by ATF, and PHY is always on. > > To make it clear, core/hcd.c function usb_add_hcd() when > hcd->skip_phy_initialization is false is calling > usb_phy_roothub_power_on() which calls phy_power_on(). If this call fails then > error is propagated back to the usb_add_hcd() and this function fails too. > > But on boards with older ATF (which do not support PHY power on SMC API) is > phy_power_on() returning error -EOPNOTSUPP and therefore whole USB > 3.0 initialization fails. > > This patch is adding init hook to detect if ATF supports PHY power on/off > functions and in case it does not support it, code sets XHCI_SKIP_PHY_INIT > flag > to instruct xhci-plat code to set > hcd->skip_phy_initialization flag to instruct core/hcd.c to skip calling > usb_phy_roothub_power_on() function as it is know that it would fail. Thanks for clarity, clear now. Peter
Spende
850.000,00 Euro wurden Ihnen gespendet
[git pull] vfs.git misc stuff
Assorted patches from previous cycle(s)... The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da: Linux 5.10-rc6 (2020-11-29 15:50:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc for you to fetch changes up to 2e2cbaf920d14de9a96180ddefd6861bcc46f07d: fix hostfs_open() use of ->f_path.dentry (2020-12-21 21:42:29 -0500) Al Viro (2): Make sure that make_create_in_sticky() never sees uninitialized value of dir_mode fix hostfs_open() use of ->f_path.dentry Eric Biggers (1): fs/namespace.c: WARN if mnt_count has become negative Hao Li (2): fs: Handle I_DONTCACHE in iput_final() instead of generic_drop_inode() fs: Kill DCACHE_DONTCACHE dentry even if DCACHE_REFERENCED is set fs/dcache.c | 9 - fs/hostfs/hostfs_kern.c | 2 +- fs/inode.c | 4 +++- fs/namei.c | 4 +++- fs/namespace.c | 9 ++--- fs/pnode.h | 2 +- include/linux/fs.h | 3 +-- 7 files changed, 23 insertions(+), 10 deletions(-)
Att
I don't know if you received my previous email, I know it may have come to you as a surprise and you will be curious to know why/how I selected you to receive a sum of 5,000,000.00 USD. Get back to me for more details.
Re: [PATCH] nfp: remove h from printk format specifier
On Thu, 2020-12-24 at 14:14 -0800, Tom Rix wrote:
> On 12/24/20 12:21 PM, Simon Horman wrote:
> > On Wed, Dec 23, 2020 at 12:20:53PM -0800, t...@redhat.com wrote:
> > > From: Tom Rix
> > >
> > > This change fixes the checkpatch warning described in this commit
> > > commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of
> > > unnecessary %h[xudi] and %hh[xudi]")
> > >
> > > Standard integer promotion is already done and %hx and %hhx is useless
> > > so do not encourage the use of %hh[xudi] or %h[xudi].
> > >
> > > Signed-off-by: Tom Rix
> > Hi Tom,
> >
> > This patch looks appropriate for net-next, which is currently closed.
> >
> > The changes look fine, but I'm curious to know if its intentionally that
> > the following was left alone in
> > ethernet/netronome/nfp/nfp_net_ethtool.c:nfp_net_get_nspinfo()
> >
> > snprintf(version, ETHTOOL_FWVERS_LEN, "%hu.%hu"
>
> I am limiting changes to logging functions, what is roughly in checkpatch.
>
> I can add this snprintf in if you want.
I'm a bit confused here Tom.
I thought your clang-tidy script was looking for anything marked with
__printf() that is using %h[idux] or %hh[idux].
Wouldn't snprintf qualify for this already?
include/linux/kernel.h-extern __printf(3, 4)
include/linux/kernel.h:int snprintf(char *buf, size_t size, const char *fmt,
...);
Kernel code doesn't use a signed char or short with %hx or %hu very often
but in case you didn't already know, any signed char/short emitted with
anything like %hx or %hu needs to be left alone as sign extension occurs so:
signed char foo = -1;
printk("%hx", foo);
emits but
printk("%x", foo);
emits
An example:
$ gcc -x c -
#include
#include
int main(int argc, char **argv)
{
signed short i = -1;
printf("hx: %hx\n", i);
printf("x: %x\n", i);
printf("hu: %hu\n", i);
printf("u: %u\n", i);
return 0;
}
$ ./a.out
hx:
x:
hu: 65535
u: 4294967295
$
Re: [git pull] drm fixes for 5.11-rc1
On Wed, Dec 23, 2020 at 6:29 PM Dave Airlie wrote: > > Xmas eve pull request present. Just some fixes that trickled in this > past week. Mostly amdgpu fixes, with a dma-buf/mips build fix and some > misc komeda fixes. Well, I already pulled and pushed out my merge, but only noticed afterwards that clang complains about this, and I think it's a real bug: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_mpc.c:475:6: warning: variable 'val' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] and it sure is true: the code literally does uint32_t val; if (opp_id < MAX_OPP && REG(MUX[opp_id])) REG_GET(MUX[opp_id], MPC_OUT_MUX, &val); return val; so clearly 'val' isn't initialized if that if-statement isn't true. I assume 'opp_id' is always presumed to be valid, but that code really is disgusting. Just make it return 0 (or whatever) for invalid, possibly together with a WARN_ON_ONCE(). Ok? Linus
Re: [GIT PULL] ext4 updates for v5.11-rc1
The pull request you sent on Tue, 22 Dec 2020 17:49:10 -0500: > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git > tags/ext4_for_linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/555a6e8c11e6282bb2704ef1cee64ceaeb41773e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] A few documentation fixes
The pull request you sent on Wed, 23 Dec 2020 13:03:39 -0700: > git://git.lwn.net/linux.git tags/docs-5.11-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/71c5f03154ac1cb27423b984743ccc2f5d11d14d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] RISC-V Fixes for 5.11-rc1 (or rc2, if it's too late)
The pull request you sent on Wed, 23 Dec 2020 20:24:05 -0800 (PST): > git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git > tags/riscv-for-linus-5.11-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7a2fde8def1fffceda728d2441d7e69230478285 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.11-2 tag
The pull request you sent on Thu, 24 Dec 2020 12:53:10 +1100: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.11-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9b3f7f1b841e91f0f0414525fa6edaaa2df33ccb Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Smack additional patch for v5.11
The pull request you sent on Tue, 22 Dec 2020 16:43:25 -0800: > https://github.com/cschaufler/smack-next smack-for-5.11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2f2fce3d535779cb1b0d77ce839029d5d875d4f4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH] nfp: remove h from printk format specifier
On 12/24/20 12:21 PM, Simon Horman wrote:
> On Wed, Dec 23, 2020 at 12:20:53PM -0800, t...@redhat.com wrote:
>> From: Tom Rix
>>
>> This change fixes the checkpatch warning described in this commit
>> commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of
>> unnecessary %h[xudi] and %hh[xudi]")
>>
>> Standard integer promotion is already done and %hx and %hhx is useless
>> so do not encourage the use of %hh[xudi] or %h[xudi].
>>
>> Signed-off-by: Tom Rix
> Hi Tom,
>
> This patch looks appropriate for net-next, which is currently closed.
>
> The changes look fine, but I'm curious to know if its intentionally that
> the following was left alone in
> ethernet/netronome/nfp/nfp_net_ethtool.c:nfp_net_get_nspinfo()
>
> snprintf(version, ETHTOOL_FWVERS_LEN, "%hu.%hu"
I am limiting changes to logging functions, what is roughly in checkpatch.
I can add this snprintf in if you want.
Tom
>
> If the above was not intentional then perhaps you could respin with that
> updated and resubmit when net-next re-opens. Feel free to add:
>
> Reviewed-by: Simon Horman
>
Re: [GIT PULL] Smack additional patch for v5.11
On Tue, Dec 22, 2020 at 4:43 PM Casey Schaufler wrote: > > https://github.com/cschaufler/smack-next smack-for-5.11 That is not a tag. And I really want signed tags for non-kernel.org pull requests. Digging at that repo, I do find the tag, it's 'tags/Smack-for-5.11-io_uring-fix' and it has a proper pgp signature from you. So I pulled that one. But please don't make me search for these things. Linus
Spende
850.000,00 Euro wurden Ihnen gespendet
Re: [GIT pull] irq/core for v5.11-rc1
The pull request you sent on Tue, 22 Dec 2020 23:52:47 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-2020-12-23 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3913d00ac51a9d93225eeea776026326ff8f717d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [git pull] drm fixes for 5.11-rc1
The pull request you sent on Thu, 24 Dec 2020 12:29:16 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-12-24 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ef2c8b81b88868f042579b9dd021cc9edbc2d0c6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT pull] efi/core for v5.11-rc1
The pull request you sent on Mon, 14 Dec 2020 20:22:11 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-core-2020-12-14 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e0a6aa30504cb8179d07609fb6386705e8f00663 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] libnvdimm for v5.11
The pull request you sent on Thu, 24 Dec 2020 11:01:53 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm > tags/libnvdimm-for-5.11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1f13d2f7d8a407be09e841f17805b2451271d493 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] efi/core for v5.11
The pull request you sent on Thu, 24 Dec 2020 10:04:06 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > tags/efi_updates_for_v5.11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4a1106afeed26012de69f4837b8d7a8b83f28489 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] virtio,vdpa: features, cleanups, fixes
The pull request you sent on Wed, 23 Dec 2020 07:24:48 -0500: > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/64145482d3339d71f58857591d021588040543f4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Devicetree fixes for 5.11, take 1
The pull request you sent on Wed, 23 Dec 2020 11:11:20 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git > tags/devicetree-fixes-for-5.11-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/14571d5f22d3f7f6ecb97e037a2e346b3fb488bd Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT pull] irq/core for v5.11-rc1
On Tue, Dec 22, 2020 at 3:58 PM Thomas Gleixner wrote:
>
> A treewide cleanup of interrupt descriptor (ab)use with all sorts of racy
> accesses, inefficient and disfunctional code. The goal is to remove the
> export of irq_to_desc() to prevent these things from creeping up again.
This exposed that the mellanox mlx5 driver had grown another use of
'irq_desc' in commit 145e5637d941 ("net/mlx5e: Add TX PTP port object
support").
Except that use was write-only, with the only acces being this assignment:
c->irq_desc = irq_to_desc(irq);
so I removed the 'irq_desc' field and that assignment in my merge.
I didn't even replace it with an affinity mask thing like commit
6e745db4ddd0 ("net/mlx5: Replace irq_to_desc() abuse") did for the
previous case, because the irq_desc thing was literally pointless and
unused. I suspect it was some cut-and-paste programming.
Just writing this note so that everybody knows what's going on.
Linus
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.c:122:6: warning: stack frame size of 4240 bytes in function 'dml_log_pipe_params'
Hi Alex,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 58cf05f597b03a8212d9ecf2c79ee046d3ee8ad9
commit: 20f2ffe504728612d7b0c34e4f8280e34251e704 drm/amdgpu: fold
CONFIG_DRM_AMD_DC_DCN3* into CONFIG_DRM_AMD_DC_DCN (v3)
date: 7 weeks ago
config: powerpc-randconfig-r016-20201223 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
cee1e7d14f4628d6174b33640d502bff3b54ae45)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=20f2ffe504728612d7b0c34e4f8280e34251e704
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 20f2ffe504728612d7b0c34e4f8280e34251e704
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.c:122:6:
>> warning: stack frame size of 4240 bytes in function 'dml_log_pipe_params'
>> [-Wframe-larger-than=]
void dml_log_pipe_params(
^
1 warning generated.
vim +/dml_log_pipe_params +122
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.c
20f2ffe50472861 Alex Deucher 2020-11-02 121
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 @122 void dml_log_pipe_params(
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 123 struct
display_mode_lib *mode_lib,
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 124
display_e2e_pipe_params_st *pipes,
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 125 int pipe_cnt)
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 126 {
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 127
display_pipe_source_params_st *pipe_src;
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 128
display_pipe_dest_params_st *pipe_dest;
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 129 scaler_ratio_depth_st
*scale_ratio_depth;
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 130 scaler_taps_st
*scale_taps;
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 131
display_output_params_st *dout;
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 132
display_clocks_and_cfg_st *clks_cfg;
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 133 int i;
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 134
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 135 for (i = 0; i <
pipe_cnt; i++) {
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 136 pipe_src =
&(pipes[i].pipe.src);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 137 pipe_dest =
&(pipes[i].pipe.dest);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 138
scale_ratio_depth = &(pipes[i].pipe.scale_ratio_depth);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 139 scale_taps =
&(pipes[i].pipe.scale_taps);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 140 dout =
&(pipes[i].dout);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 141 clks_cfg =
&(pipes[i].clks_cfg);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 142
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 143 dml_print("DML
PARAMS: =\n");
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 144 dml_print("DML
PARAMS: PIPE [%d] SOURCE PARAMS:\n", i);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 145 dml_print("DML
PARAMS: source_format = %d\n", pipe_src->source_format);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 146 dml_print("DML
PARAMS: dcc= %d\n", pipe_src->dcc);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 147 dml_print("DML
PARAMS: dcc_rate = %d\n", pipe_src->dcc_rate);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 148 dml_print("DML
PARAMS: dcc_use_global = %d\n", pipe_src->dcc_use_global);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 149 dml_print("DML
PARAMS: vm = %d\n", pipe_src->vm);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 150 dml_print("DML
PARAMS: gpuvm = %d\n", pipe_src->gpuvm);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 151 dml_print("DML
PARAMS: hostvm = %d\n", pipe_src->hostvm);
6725a88f88a7e92 Bhawanpreet Lakha 2020-05-21 1
Re: [PATCH] net: ethernet: Fix memleak in ethoc_probe
On 12/24/2020 10:06 AM, Konstantin Ryabitsev wrote: > On Wed, Dec 23, 2020 at 05:41:46PM -0800, Jakub Kicinski wrote: > Does patchwork not automagically add Fixes: lines from full up emails? > That seems like a reasonable automation. Looks like it's been a TODO for 3 years now: https://github.com/getpatchwork/patchwork/issues/151 >>> >>> It was proposed before, but rejected. You can have your local patchwork >>> admin take care of that for you though and add custom tags: >>> >>> https://lists.ozlabs.org/pipermail/patchwork/2017-January/003910.html >> >> Konstantin, would you be willing to mod the kernel.org instance of >> patchwork to populate Fixes tags in the generated mboxes? > > I'd really rather not -- we try not to diverge from project upstream if at all > possible, as this dramatically complicates upgrades. Well that is really unfortunate then because the Linux developer community settled on using the Fixes: tag for years now and having patchwork automatically append those tags would greatly help maintainers. -- Florian
Re: [PATCH net] net: ethernet: ti: cpts: fix ethtool output when no ptp_clock registered
On Thu, Dec 24, 2020 at 06:24:05PM +0200, Grygorii Strashko wrote:
> The CPTS driver registers PTP PHC clock when first netif is going up and
> unregister it when all netif are down. Now ethtool will show:
> - PTP PHC clock index 0 after boot until first netif is up;
> - the last assigned PTP PHC clock index even if PTP PHC clock is not
> registered any more after all netifs are down.
>
> This patch ensures that -1 is returned by ethtool when PTP PHC clock is not
> registered any more.
>
> Fixes: 8a2c9a5ab4b9 ("net: ethernet: ti: cpts: rework
> initialization/deinitialization")
> Signed-off-by: Grygorii Strashko
Acked-by: Richard Cochran
Re: [RFC PATCH v2] pinctrl: add helper to expose pinctrl state in debugfs
On Fri, Dec 18, 2020 at 06:01:25PM +0200, Andy Shevchenko wrote:
> On Fri, Dec 18, 2020 at 6:52 AM Drew Fustini wrote:
> >
> > BeagleBoard.org [0] currently uses an out-of-tree driver called
> > bone-pinmux-helper [1] developed by Pantelis Antoniou [2] back in 2013.
> > The driver assists users of our BeagleBone and PocketBeagle boards in
> > rapid prototyping by allowing them to change at run-time between defined
> > set of pinctrl states [3] for each pin on the expansion connectors [4].
> > This is achieved by exposing a 'state' file in sysfs for each pin which
> > is used by our 'config-pin' utility [5].
> >
> > Our goal is to eliminate all out-of-tree drivers for BeagleBoard.org
> > boards and thus I have been working to replace bone-pinmux-helper with a
> > new driver that could be acceptable upstream. My understanding is that
> > debugfs, unlike sysfs, could be the appropriate mechanism to expose such
> > functionality.
>
> No objections here.
>
> > I used the compatible string "pinctrl,state-helper" but would appreciate
> > advice on how to best name this. Should I create a new vendor prefix?
>
> Here is the first concern. Why does this require to be a driver with a
> compatible string?
I have not been able to figure out how to have different active pinctrl
states for each header pins (for example P2 header pin 3) unless they
are represented as DT nodes with their own compatible for this helper
driver such as:
&ocp {
P2_03_pinmux {
compatible = "pinctrl,state-helper";
pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd",
"gpio_input", "pwm";
pinctrl-0 = <&P2_03_default_pin>;
pinctrl-1 = <&P2_03_gpio_pin>;
pinctrl-2 = <&P2_03_gpio_pu_pin>;
pinctrl-3 = <&P2_03_gpio_pd_pin>;
pinctrl-4 = <&P2_03_gpio_input_pin>;
pinctrl-5 = <&P2_03_pwm_pin>;
};
}
I can assign pinctrl states in the pin controller DT node which has
compatible pinctrl-single (line 301 arch/arm/boot/dts/am33xx-l4.dtsi):
&am33xx_pinmux {
pinctrl-names = "default", "gpio", "pwm";
pinctrl-0 = < &P2_03_default_pin &P1_34_default_pin
&P2_19_default_pin &P2_24_default_pin
&P2_33_default_pin &P2_22_default_pin
&P2_18_default_pin &P2_10_default_pin
&P2_06_default_pin &P2_04_default_pin
&P2_02_default_pin &P2_08_default_pin
&P2_17_default_pin >;
pinctrl-1 = < &P2_03_gpio_pin &P1_34_gpio_pin &P2_19_gpio_pin
&P2_24_gpio_pin
&P2_33_gpio_pin &P2_22_gpio_pin &P2_18_gpio_pin
&P2_10_gpio_pin
&P2_06_gpio_pin &P2_04_gpio_pin &P2_02_gpio_pin
&P2_08_gpio_pin
&P2_17_gpio_pin >;
pinctrl-2 = < &P2_03_pwm &P1_34_pwm &P2_19_pwm &P2_24_pwm
&P2_33_pwm &P2_22_pwm &P2_18_pwm &P2_10_pwm
&P2_06_pwm &P2_04_pwm &P2_02_pwm &P2_08_pwm
&P2_17_pwm >;
}
However, there is no way to later select "gpio" for P2.03 and select
"pwm" for P1.34 at the same time. Thus, I can not figure out a way to
select independent states per pin unless I make a node for each pin that
binds to a helper driver.
It feels like there may be a simpler soluation but I can't see to figure
it out. Suggestions welcome!
>
> > The P9_14_pinmux entry would cause pinctrl-state-helper to be probed.
> > The driver would create the corresponding pinctrl state file in debugfs
> > for the pin. Here is an example of how the state can be read and
> > written from userspace:
> >
> > root@beaglebone:~# cat
> > /sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
> > default
> > root@beaglebone:~# echo pwm >
> > /sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
> > root@beaglebone:~# cat
> > /sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
> > pwm
> >
> > I would very much appreciate feedback on both this general concept, and
> > also specific areas in which the code should be changed to be acceptable
> > upstream.
>
> Two more concerns:
> - why is it OF only?
I am open to figuring out a more general solution but I am really only
familiar with Device Tree. Is there a way to represent the possible
pinctrl states in ACPI?
> - why has it been separated from pin control per device debug folder?
>From the v1 thread, I see what you mean that there could be a combined
state file for each pinctrl device where one would echo '
' such as 'P2_03 pwm'. I will attempt to implement that.
>
>
> > [0] http://beagleboard.org/latest-images
> > [1]
> > https://github.com/beagleboard/linux/blob/5.4/drivers/misc/cape/beaglebone/bone-pinmux-helper.c
> > [2]
> > https://github.com/RobertCNelson/linux-dev/blob/master/patches/drivers/ti/gpio/0001-BeagleBone-pinmux-helper.patch
> > [3]
> > https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v5.4.x-ti-overlays/src/arm/am33
Re: [PATCH] nfp: remove h from printk format specifier
On Wed, Dec 23, 2020 at 12:20:53PM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> This change fixes the checkpatch warning described in this commit
> commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of
> unnecessary %h[xudi] and %hh[xudi]")
>
> Standard integer promotion is already done and %hx and %hhx is useless
> so do not encourage the use of %hh[xudi] or %h[xudi].
>
> Signed-off-by: Tom Rix
Hi Tom,
This patch looks appropriate for net-next, which is currently closed.
The changes look fine, but I'm curious to know if its intentionally that
the following was left alone in
ethernet/netronome/nfp/nfp_net_ethtool.c:nfp_net_get_nspinfo()
snprintf(version, ETHTOOL_FWVERS_LEN, "%hu.%hu"
If the above was not intentional then perhaps you could respin with that
updated and resubmit when net-next re-opens. Feel free to add:
Reviewed-by: Simon Horman
[RFC][PATCH] NT_FILE/NT_SIGINFO breakage on mips compat coredumps
On Wed, Dec 23, 2020 at 07:12:13AM +, Al Viro wrote:
> On Wed, Dec 23, 2020 at 07:03:20AM +, Al Viro wrote:
>
> Argh Wrong commit blamed - the parent of the correct one.
> It's actually 2aa362c49c31 ("coredump: extend core dump note section to
> contain file names of mapped files"). My apologies - fat-fingered
> cut'n'paste...
>
> siginfo commit does suffer the same problem, but it becomes an issue
> only for 32bit processes under mips64 big-endian kernel (there it yields
> e.g. zero .__sigfault.si_addr in $_siginfo when using gdb with a coredump
> of 32bit process, whatever the actual faulting address had been). And
> b-e mips64 is rather uncommon, so that's less of an issue.
FWIW, here's debian/mips image (stretch) booted with
qemu-system-mips64 -M malta -cpu 5KEc:
root@mips:~# uname -a
Linux mips 4.9.0-13-5kc-malta #1 Debian 4.9.228-1 (2020-07-05) mips64 GNU/Linux
root@mips:~# cat a.c
main()
{
*(char *)0x0123 = 0;
}
root@mips:~# gcc a.c
a.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
main()
^~~~
root@mips:~# ulimit -c unlimited
root@mips:~# ./a.out
[ 519.744983] do_page_fault(): sending SIGSEGV to a.out for invalid write
access to 0123
[ 519.746735] epc = 558477c0 in a.out[55847000+1000]
[ 519.747758] ra = 7792f4a8 in libc-2.24.so[77916000+16a000]
Segmentation fault (core dumped)
root@mips:~# gdb a.out core
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mips-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mips-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Re: [PATCH] xfs: fix system crash caused by null bp->b_pages
On 12/24/20 3:51 AM, Fengfei Xi wrote:
> We have encountered the following problems several times:
> 1、A raid slot or hardware problem causes block device loss.
> 2、Continue to issue IO requests to the problematic block device.
> 3、The system possibly crash after a few hours.
What kernel is this on?
> dmesg log as below:
> [15205901.268313] blk_partition_remap: fail for partition 1
I think this message has been gone since kernel v4.16...
If you're testing this on an old kernel, can you reproduce it on a
current kernel?
> [15205901.319309] blk_partition_remap: fail for partition 1
> [15205901.319341] blk_partition_remap: fail for partition 1
> [15205901.319873] sysctl (3998546): drop_caches: 3
What performed the drop_caches immediately before the BUG? Does
the BUG happen without drop_caches?
> [15205901.371379] BUG: unable to handle kernel NULL pointer dereference at
was something lost here? "dereference at" ... what?
> [15205901.372602] IP: xfs_buf_offset+0x32/0x60 [xfs]
> [15205901.373605] PGD 0 P4D 0
> [15205901.374690] Oops: [#1] SMP
> [15205901.375629] Modules linked in:
> [15205901.382445] CPU: 6 PID: 18545 Comm: xfsaild/sdh1 Kdump: loaded Tainted:
> G
> [15205901.384728] Hardware name:
> [15205901.385830] task: 885216939e80 task.stack: b28ba9b38000
> [15205901.386974] RIP: 0010:xfs_buf_offset+0x32/0x60 [xfs]
> [15205901.388044] RSP: 0018:b28ba9b3bc68 EFLAGS: 00010246
> [15205901.389021] RAX: RBX: RCX:
> 000b
> [15205901.390016] RDX: RSI: RDI:
> 88627bebf000
> [15205901.391075] RBP: b28ba9b3bc98 R08: 88627bebf000 R09:
> 0001802a000d
> [15205901.392031] R10: 88521f3a0240 R11: 88627bebf000 R12:
> 88521041e000
> [15205901.392950] R13: 0020 R14: 88627bebf000 R15:
>
> [15205901.393858] FS: () GS:88521f38()
> knlGS:
> [15205901.394774] CS: 0010 DS: ES: CR0: 80050033
> [15205901.395756] CR2: CR3: 00099bc09001 CR4:
> 007606e0
> [15205901.396904] DR0: DR1: DR2:
>
> [15205901.397869] DR3: DR6: fffe0ff0 DR7:
> 0400
> [15205901.398836] PKRU: 5554
> [15205901.400111] Call Trace:
> [15205901.401058] ? xfs_inode_buf_verify+0x8e/0xf0 [xfs]
> [15205901.402069] ? xfs_buf_delwri_submit_buffers+0x16d/0x2b0 [xfs]
> [15205901.403060] xfs_inode_buf_write_verify+0x10/0x20 [xfs]
> [15205901.404017] _xfs_buf_ioapply+0x88/0x410 [xfs]
> [15205901.404990] ? xfs_buf_delwri_submit_buffers+0x16d/0x2b0 [xfs]
> [15205901.405929] xfs_buf_submit+0x63/0x200 [xfs]
> [15205901.406801] xfs_buf_delwri_submit_buffers+0x16d/0x2b0 [xfs]
> [15205901.407675] ? xfs_buf_delwri_submit_nowait+0x10/0x20 [xfs]
> [15205901.408540] ? xfs_inode_item_push+0xb7/0x190 [xfs]
> [15205901.409395] xfs_buf_delwri_submit_nowait+0x10/0x20 [xfs]
> [15205901.410249] xfsaild+0x29a/0x780 [xfs]
> [15205901.411121] kthread+0x109/0x140
> [15205901.411981] ? xfs_trans_ail_cursor_first+0x90/0x90 [xfs]
> [15205901.412785] ? kthread_park+0x60/0x60
> [15205901.413578] ret_from_fork+0x2a/0x40
>
> The "obvious" cause is that the bp->b_pages was NULL in function
> xfs_buf_offset. Analyzing vmcore, we found that b_pages=NULL but
> b_page_count=16, so b_pages is set to NULL for some reason.
this can happen, for example _xfs_buf_get_pages sets the count, but may
fail the allocation, and leave the count set while the pointer is NULL.
>
> crash> struct xfs_buf 88627bebf000 | less
> ...
> b_pages = 0x0,
> b_page_array = {0x0, 0x0},
> b_maps = 0x88627bebf118,
> __b_map = {
> bm_bn = 512,
> bm_len = 128
> },
> b_map_count = 1,
> b_io_length = 128,
> b_pin_count = {
> counter = 0
> },
> b_io_remaining = {
> counter = 1
> },
> b_page_count = 16,
> b_offset = 0,
> b_error = 0,
> ...
>
> To avoid system crash, we can add the check of 'bp->b_pages' to
> xfs_inode_buf_verify(). If b_pages == NULL, we mark the buffer
> as -EFSCORRUPTED and the IO will not dispatched.
>
> Signed-off-by: Fengfei Xi
> Reviewed-by: Xianting Tian
> ---
> fs/xfs/libxfs/xfs_inode_buf.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/fs/xfs/libxfs/xfs_inode_buf.c b/fs/xfs/libxfs/xfs_inode_buf.c
> index c667c63f2..5a485c51f 100644
> --- a/fs/xfs/libxfs/xfs_inode_buf.c
> +++ b/fs/xfs/libxfs/xfs_inode_buf.c
> @@ -45,6 +45,17 @@ xfs_inode_buf_verify(
> int i;
> int ni;
>
> + /*
> + * Don't crash and mark buffer EFSCORRUPTED when b_pages is NULL
> + */
> + if (!bp->b_pages) {
> + xfs_buf_ioerror(bp, -EFSCORRUPTED);
> + xfs_alert(mp,
> + "xfs_buf(%p) b_pages corruption detected at %pS\n",
> + bp, __return_address);
> +
Re: drivers/char/random.c needs a (new) maintainer
Hi! > > On Wed, Dec 23, 2020 at 3:17 PM Petr Tesarik wrote: > > > Upfront, let me admit that SUSE has a vested interest in a > > > FIPS-certifiable Linux kernel. > > > > Sorry, but just because you have a "vested interest", or a financial > > interest, or because you want it does not suddenly make it a good > > idea. The idea is to have good crypto, not to merely check some boxes > > I never suggested that this should serve as a supportive argument. I was just > trying to be honest about our motivations. > > I'm a bit sad that this discussion has quickly gone back to the choice of > algorithms and how they can be implemented. The real issue is that the RNG > subsystem has not developed as fast as it could. This had not been much of an > issue as long as nobody was really interested in making any substantial > changes to that code, but it is more apparent now. Torsten believes it can be > partly because of a maintainer who is too busy with other tasks, and he > suggested we try to improve the situation by giving the RNG-related tasks to > someone else. > (Please wrap at 80 columns). To play devil's advocate, does RNG subsystem need to evolve? Its task is to get random numbers. Does it fail at the task? Problem is, random subsystem is hard to verify, and big rewrite is likely to cause security problems... Best regards, Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Thu, Dec 24, 2020 at 01:49:45PM -0500, Andrea Arcangeli wrote: > Without the above, can't the CPU decrement the tlb_flush_pending while > the IPI to ack didn't arrive yet in csd_lock_wait? Ehm: csd_lock_wait has smp_acquire__after_ctrl_dep() so the write side looks ok after all sorry.
Re: drivers/char/random.c needs a (new) maintainer
Hi! > > Any updates on that? > > > > I don't believe Torsten's concerns are simply about *applying* patches > > but more about these long periods of radio silence. That kills > > Exactly. I could live with replies in the style of "old" Linus like: > "Your code is crap, because it does X and Y". Then I knew how to > proceed. But this extended silence slows things down a lot. Well... you know. We now have code of conflict, so maintainers are not supposed to tell submitters that their code is . So... you get silence. Pavel -- p http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature
Re: [PATCH] HID: Add Wireless Radio Control feature for Chicony devices
On Tue 2020-12-22 15:38:56, Jian-Hong Pan wrote: > Some Chicony's keyboards support airplane mode hotkey (Fn+F2) with > "Wireless Radio Control" feature. For example, the wireless keyboard > [04f2:1236] shipped with ASUS all-in-one desktop. > > After consulting Chicony for this hotkey, learned the device will send > with 0x11 as the report ID and 0x1 as the value when the key is pressed > down. Fun, how can airplane mode work on _wireless_ keyboard? :-). Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature
[GIT PULL] libnvdimm for v5.11
Hi Linus, Twas the day before Christmas and the only thing stirring in libnvdimm / device-dax land is a pile of miscellaneous fixups and cleanups. If this is too late for -rc1 I'll pull out the fixes and resubmit after the holidays. The bulk of it has appeared in -next save the last two patches to device-dax that are passed my build and unit tests. Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-for-5.11 --- The following changes since commit 09162bc32c880a791c6c0668ce0745cf7958f576: Linux 5.10-rc4 (2020-11-15 16:44:31 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-for-5.11 for you to fetch changes up to 127c3d2e7e8a79628160e56e54d2be099bdd47c6: Merge branch 'for-5.11/dax' into for-5.11/libnvdimm (2020-12-24 10:14:04 -0800) libnvdimm for 5.11 - Fix a long standing block-window-namespace issue surfaced by the ndctl change to attempt to preserve the kernel device name over a 'reconfigure' - Fix a few error path memory leaks in nfit and device-dax - Silence a smatch warning in the ioctl path - Miscellaneous cleanups Dan Williams (4): libnvdimm/namespace: Fix reaping of invalidated block-window-namespace labels ACPI: NFIT: Fix input validation of bus-family device-dax: Fix range release Merge branch 'for-5.11/dax' into for-5.11/libnvdimm Enrico Weigelt (1): libnvdimm: Cleanup include of badblocks.h Wang Hai (1): device-dax/core: Fix memory leak when rmmod dax.ko Zhang Qilong (1): libnvdimm/label: Return -ENXIO for no slot in __blk_label_update Zhen Lei (3): ACPI/nfit: avoid accessing uninitialized memory in acpi_nfit_ctl() device-dax: delete a redundancy check in dev_dax_validate_align() device-dax: Avoid an unnecessary check in alloc_dev_dax_range() Zheng Yongjun (1): device-dax/pmem: Convert comma to semicolon drivers/acpi/nfit/core.c | 15 ++ drivers/dax/bus.c| 71 ++-- drivers/dax/pmem/core.c | 2 +- drivers/dax/super.c | 1 + drivers/nvdimm/btt.h | 3 +- drivers/nvdimm/claim.c | 1 + drivers/nvdimm/core.c| 1 - drivers/nvdimm/label.c | 13 - 8 files changed, 54 insertions(+), 53 deletions(-)
[GIT PULL] perf tools changes for v5.11, 2nd batch
Hi Linus, Please consider pulling, Best regards, - Arnaldo The following changes since commit 58cf05f597b03a8212d9ecf2c79ee046d3ee8ad9: Merge tag 'sound-fix-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound (2020-12-23 15:11:08 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-tools-2020-12-24 for you to fetch changes up to 5149303fdfe5c67ddb51c911e23262f781cd75eb: perf probe: Fix memory leak when synthesizing SDT probes (2020-12-24 10:52:10 -0300) perf tools changes for v5.11, 2nd batch: - Refactor 'perf stat' per CPU/socket/die/thread aggregation fixing use cases in ARM machines. - Fix memory leak when synthesizing SDT probes in 'perf probe'. - Update kernel header copies related to KVM, epol_pwait, msr-index and powerpc and s390 syscall tables. Signed-off-by: Arnaldo Carvalho de Melo Test results in the signed tag at: https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tag/?h=perf-tools-2020-12-24 Arnaldo Carvalho de Melo (8): tools headers UAPI: Update epoll_pwait2 affected files tools headers cpufeatures: Sync with the kernel sources tools arch x86: Sync the msr-index.h copy with the kernel sources tools headers UAPI: Sync kvm.h headers with the kernel sources tools headers UAPI: Sync KVM's vmx.h header with the kernel sources tools kvm headers: Update KVM headers from the kernel sources tools headers UAPI: Synch KVM's svm.h header with the kernel perf probe: Fix memory leak when synthesizing SDT probes James Clark (12): perf tests: Improve topology test to check all aggregation types perf cpumap: Use existing allocator to avoid using malloc perf cpumap: Add new struct for cpu aggregation perf stat: Replace aggregation ID with a struct perf cpumap: Add new map type for aggregation perf cpumap: Drop in cpu_aggr_map struct perf stat aggregation: Start using cpu_aggr_id in map perf stat aggregation: Add separate node member perf stat aggregation: Add separate socket member perf stat aggregation: Add separate die member perf stat aggregation: Add separate core member perf stat aggregation: Add separate thread member Tiezhu Yang (4): perf powerpc: Move syscall.tbl check to check-headers.sh perf s390: Move syscall.tbl check into check-headers.sh perf tools: Update powerpc's syscall.tbl copy from the kernel sources perf tools: Update s390's syscall.tbl copy from the kernel sources tools/arch/arm64/include/uapi/asm/kvm.h| 3 - tools/arch/x86/include/asm/cpufeatures.h | 2 + tools/arch/x86/include/asm/msr-index.h | 1 + tools/arch/x86/include/uapi/asm/kvm.h | 1 + tools/arch/x86/include/uapi/asm/svm.h | 28 ++ tools/arch/x86/include/uapi/asm/vmx.h | 2 + tools/include/uapi/asm-generic/unistd.h| 4 +- tools/include/uapi/linux/kvm.h | 56 ++- tools/perf/arch/powerpc/Makefile | 7 - tools/perf/arch/powerpc/entry/syscalls/syscall.tbl | 26 +- tools/perf/arch/s390/Makefile | 4 - tools/perf/arch/s390/entry/syscalls/syscall.tbl| 396 - tools/perf/arch/x86/entry/syscalls/syscall_64.tbl | 1 + tools/perf/builtin-stat.c | 128 +++ tools/perf/check-headers.sh| 2 + tools/perf/tests/topology.c| 64 +++- tools/perf/trace/beauty/tracepoints/x86_msr.sh | 2 +- tools/perf/util/cpumap.c | 171 ++--- tools/perf/util/cpumap.h | 55 +-- tools/perf/util/probe-file.c | 13 +- tools/perf/util/stat-display.c | 102 +++--- tools/perf/util/stat.c | 2 +- tools/perf/util/stat.h | 9 +- 23 files changed, 688 insertions(+), 391 deletions(-)
Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG()
On 24.12.2020 19:46, Ignat Korchagin wrote: On Wed, Dec 23, 2020 at 8:57 PM Herbert Xu wrote: On Wed, Dec 23, 2020 at 04:37:34PM +0100, Maciej S. Szmigiero wrote: It looks like to me that the skcipher API might not be safe to call from a softirq context, after all. skcipher is safe to use in a softirq. The problem is only in dm-crypt where it tries to allocate memory with GFP_NOIO. Hm.. After eliminating the GFP_NOIO (as well as some other sleeping paths) from dm-crypt softirq code I still hit an occasional crash in my extreme setup (QEMU with 1 CPU and cryptd_max_cpu_qlen set to 1) (decoded with stacktrace_decode.sh): (..) This happens when running dm-crypt with no_read_workqueues on top of an emulated NVME in QEMU (NVME driver "completes" IO in IRQ context). Somehow sending decryption requests to cryptd in some fashion in softirq context corrupts the crypto queue it seems. You can try compiling your test kernel with KASAN, as it often immediately points out where the memory starts to get corrupted (if that's the bug). Enabling other "checking" kernel debug options might help debugging the root case of this, too. Regards, Ignat Thanks, Maciej
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Wed, Dec 23, 2020 at 09:18:09PM -0800, Nadav Amit wrote: > I am not trying to be argumentative, and I did not think through about an > alternative solution. It sounds to me that your proposed solution is correct > and would probably be eventually (slightly) more efficient than anything > that I can propose. On a side note, on the last proposed solution, I've been wondering about the memory ordering mm_tlb_flush_pending. There's plenty of locking before the point where the actual data is read, but it's not a release/acquire full barrier (or more accurately it is only on x86), so smp_rmb() seems needed before cow_user_page to be sure no data can be read before we read the value of mm_tlb_flush_pending. To avoid an explicit smp_rmb() and to inherit the implicit smp_mb() from the release/acquire of PT unlock/PT lock, we'd need to put the flush before the previous PT unlock. (note, not after the next PT lock or it'd be even worse). So this made me look also the inc/dec: + smp_mb__before_atomic(); atomic_dec(&mm->tlb_flush_pending); Without the above, can't the CPU decrement the tlb_flush_pending while the IPI to ack didn't arrive yet in csd_lock_wait? The smp_rmb() is still needed in the page fault (implicit or explicit doesn't matter), but we also need a smp_mb__before_atomic() above to really make this work. > Yet, I do want to explain my position. Reasoning on TLB flushes is hard, as > this long thread shows. The question is whether it has to be so hard. In > theory, we can only think about architectural considerations - whether a PTE > permissions are promoted/demoted and whether the PTE was changed/cleared. > > Obviously, it is more complex than that. Yet, once you add into the equation > various parameters such as the VMA flags or whether a page is locked (which > Mel told me was once a consideration), things become much more complicated. > If all the logic of TLB flushes had been concentrated in a single point and > maintenance of this code did not require thought about users and use-cases, > I think things would have been much simpler, at least for me. In your previous email you also suggested to add range invalidates and bloom filter to index them by the address in the page fault since it'd help MADV_PAGEOUT. That would increase complexity and it won't go exactly in the above direction. I assume that here nobody wants to add gratuitous complexity, and I never suggested the code shouldn't become simpler and easier to understand and maintain. But we can't solve everything in a single thread in terms of cleaning up and auditing the entirety of the TLB code. To refocus: the only short term objective in this thread, is to fix the data corruption in uffd-wp and clear_refs_write without introducing new performance regressions compared to the previous clear_refs_write runtime. Once that is fixed and we didn't introduce a performance regression while fixing an userland memory corruption regression (i.e. not really a regression in theory, but in practice it is because it worked by luck), then we can look at all the rest without hurry. So if already want to start the cleanups like I mentioned in a previous email, and I'll say it more explicitly, the tlb gather is for freeing memory, it's just pure overhead and gives a false sense of security, like it can make any difference, when just changing protection with mmap_read_lock. It wouldn't be needed with the write lock and it can't help solve the races that trigger with mmap_read_lock either. It is needed when you have to store the page pointer outside the pte, clear a pte, flush the tlb and only then put_page. So it is needed to keep tracks of which pages got cleared in the ptes so you don't have to issue a tlb flush for each single pte that gets cleared. So the only case when to use the tlb_gather is when you must make the pte stop pointing to the page and you need an external storage that will keep track of those pages that we cannot yet lose track of since we didn't do put_page yet. That kind of external storage to keep track of the pages that have pending tlb flushes, is never needed in change_protection and clear_refs_write. change_protection is already correct in that respect, it doesn't use the tlb_gather. clear_refs_write is not ok and it need to stop using tlb_gather_mmu/tlb_finish_mmu. * tlb_gather_mmu - initialize an mmu_gather structure for page-table tear-down See also the tear-down mention which doesn't apply to clear_refs_write. clear_refs_write needs to become identical to change_protection_range. Just increasing inc_tlb_flush_pending and then doing a flush of the range right before the dec_tlb_flush_pending. That change is actually orthogonal to the regression fix to teach the COW to deal with stale TLB entries and it will clean up the code. So to pursue your simplification objective you could already go ahead doing this improvement since it's very confusing to see the clear_refs_write use something that it sh
Re: dm-crypt with no_read_workqueue and no_write_workqueue + btrfs scrub = BUG()
On Wed, Dec 23, 2020 at 8:57 PM Herbert Xu wrote: > > On Wed, Dec 23, 2020 at 04:37:34PM +0100, Maciej S. Szmigiero wrote: > > > > It looks like to me that the skcipher API might not be safe to > > call from a softirq context, after all. > > skcipher is safe to use in a softirq. The problem is only in > dm-crypt where it tries to allocate memory with GFP_NOIO. Hm.. After eliminating the GFP_NOIO (as well as some other sleeping paths) from dm-crypt softirq code I still hit an occasional crash in my extreme setup (QEMU with 1 CPU and cryptd_max_cpu_qlen set to 1) (decoded with stacktrace_decode.sh): [ 89.324723] BUG: kernel NULL pointer dereference, address: 0008 [ 89.325713] #PF: supervisor write access in kernel mode [ 89.326460] #PF: error_code(0x0002) - not-present page [ 89.327211] PGD 0 P4D 0 [ 89.327589] Oops: 0002 [#1] PREEMPT SMP PTI [ 89.328200] CPU: 0 PID: 21 Comm: kworker/0:1 Not tainted 5.10.0+ #79 [ 89.329109] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 [ 89.330284] Workqueue: cryptd cryptd_queue_worker [ 89.330999] RIP: 0010:crypto_dequeue_request (/cfsetup_build/./include/linux/list.h:112 /cfsetup_build/./include/linux/list.h:135 /cfsetup_build/./include/linux/list.h:146 /cfsetup_build/crypto/algapi.c:957) [ 89.331757] Code: e9 c9 d0 a8 48 c7 c7 f9 c9 d0 a8 e8 c2 88 fe ff 4c 8b 23 48 c7 c6 e9 c9 d0 a8 48 c7 c7 f9 c9 d0 a8 49 8b 14 24 49 8b 44 24 08 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 49 89 04 24 48 All code 0: e9 c9 d0 a8 48jmpq 0x48a8d0ce 5: c7 c7 f9 c9 d0 a8mov$0xa8d0c9f9,%edi b: e8 c2 88 fe ffcallq 0xfffe88d2 10: 4c 8b 23 mov(%rbx),%r12 13: 48 c7 c6 e9 c9 d0 a8 mov$0xa8d0c9e9,%rsi 1a: 48 c7 c7 f9 c9 d0 a8 mov$0xa8d0c9f9,%rdi 21: 49 8b 14 24 mov(%r12),%rdx 25: 49 8b 44 24 08mov0x8(%r12),%rax 2a:* 48 89 42 08 mov%rax,0x8(%rdx) <-- trapping instruction 2e: 48 89 10 mov%rdx,(%rax) 31: 48 b8 00 01 00 00 00 movabs $0xdead0100,%rax 38: 00 ad de 3b: 49 89 04 24 mov%rax,(%r12) 3f: 48rex.W Code starting with the faulting instruction === 0: 48 89 42 08 mov%rax,0x8(%rdx) 4: 48 89 10 mov%rdx,(%rax) 7: 48 b8 00 01 00 00 00 movabs $0xdead0100,%rax e: 00 ad de 11: 49 89 04 24 mov%rax,(%r12) 15: 48rex.W [ 89.334414] RSP: 0018:ba64c00bbe68 EFLAGS: 00010246 [ 89.335165] RAX: RBX: 9b9d6fc28d88 RCX: [ 89.336182] RDX: RSI: a8d0c9e9 RDI: a8d0c9f9 [ 89.337204] RBP: R08: a906e708 R09: 0058 [ 89.338208] R10: a9068720 R11: fc00 R12: 9b9a43797478 [ 89.339216] R13: 0020 R14: 9b9d6fc28e00 R15: [ 89.340231] FS: () GS:9b9d6fc0() knlGS: [ 89.341376] CS: 0010 DS: ES: CR0: 80050033 [ 89.342207] CR2: 0008 CR3: 00014cd76002 CR4: 00170ef0 [ 89.343238] Call Trace: [ 89.343609] cryptd_queue_worker (/cfsetup_build/crypto/cryptd.c:172) [ 89.344218] process_one_work (/cfsetup_build/./arch/x86/include/asm/preempt.h:26 /cfsetup_build/kernel/workqueue.c:2284) [ 89.344821] ? rescuer_thread (/cfsetup_build/kernel/workqueue.c:2364) [ 89.345399] worker_thread (/cfsetup_build/./include/linux/list.h:282 /cfsetup_build/kernel/workqueue.c:2422) [ 89.345923] ? rescuer_thread (/cfsetup_build/kernel/workqueue.c:2364) [ 89.346504] kthread (/cfsetup_build/kernel/kthread.c:292) [ 89.346986] ? kthread_create_worker_on_cpu (/cfsetup_build/kernel/kthread.c:245) [ 89.347713] ret_from_fork (/cfsetup_build/arch/x86/entry/entry_64.S:302) [ 89.348255] Modules linked in: [ 89.348708] CR2: 0008 [ 89.349197] ---[ end trace b7e9618b4122ed3b ]--- [ 89.349863] RIP: 0010:crypto_dequeue_request (/cfsetup_build/./include/linux/list.h:112 /cfsetup_build/./include/linux/list.h:135 /cfsetup_build/./include/linux/list.h:146 /cfsetup_build/crypto/algapi.c:957) [ 89.350606] Code: e9 c9 d0 a8 48 c7 c7 f9 c9 d0 a8 e8 c2 88 fe ff 4c 8b 23 48 c7 c6 e9 c9 d0 a8 48 c7 c7 f9 c9 d0 a8 49 8b 14 24 49 8b 44 24 08 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 49 89 04 24 48 All code 0: e9 c9 d0 a8 48jmpq 0x48a8d0ce 5: c7 c7 f9 c9 d0 a8mov$0xa8d0c9f9,%edi b: e8 c2 88 fe ffcallq 0xfffe88d2 10: 4c 8b 23 mov(%rbx),%r12 13: 48 c7 c6 e9 c9 d0 a8 mov$0xa8d0c9e9,%rsi 1a: 48 c7 c7 f9 c9 d0 a8 mov$0xa8d0c9f9,%rdi 21: 49 8b 14 24 mov(%r12),%rdx 25: 49 8b 44 24 08mov0x8(%r12),%rax 2a:* 48 89 42 08 mov%rax,0x8(%rdx) <--
Re: [PATCH v5 0/4] powercap/dtpm: Add the DTPM framework
Hi! > The density of components greatly increased the last decade bringing a > numerous number of heating sources which are monitored by more than 20 > sensors on recent SoC. The skin temperature, which is the case > temperature of the device, must stay below approximately 45°C in order > to comply with the legal requirements. What kind of device is that? Does that mean that running fsck is now "illegal" because temperature will not be managed during that time? Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature
RE: [PATCH v3 05/14] software_node: unregister software_nodes in reverse order
From: Daniel Scally > Sent: 24 December 2020 14:14 ... > >> The array will be unwound in reverse order (i.e. last entry first). If > >> any member of the array is a child of another member then the child must > > children ? > > Yes, you are right of course. The second 'child' is a back-reference to 'any member' so is singular so 'child' is correct. 'the child' could be replaced by 'it' You could have: If any members of the array are children of another member then the children must appear later in the list. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH] fs: delete repeated words in comments
On Wed, Dec 23, 2020 at 09:28:10PM -0800, Randy Dunlap wrote: > Delete duplicate words in fs/*.c. > The doubled words that are being dropped are: > that, be, the, in, and, for > > Signed-off-by: Randy Dunlap > Cc: Andrew Morton > Cc: Alexander Viro > Cc: linux-fsde...@vger.kernel.org Reviewed-by: Matthew Wilcox (Oracle)
Re: [RFC V2 37/37] Add documentation for dmemfs
Hi, On 12/7/20 3:31 AM, yulei.ker...@gmail.com wrote: > From: Yulei Zhang > > Introduce dmemfs.rst to document the basic usage of dmemfs. > > Signed-off-by: Yulei Zhang > --- > Documentation/filesystems/dmemfs.rst | 58 > > Documentation/filesystems/index.rst | 1 + > 2 files changed, 59 insertions(+) > create mode 100644 Documentation/filesystems/dmemfs.rst > > diff --git a/Documentation/filesystems/dmemfs.rst > b/Documentation/filesystems/dmemfs.rst > new file mode 100644 > index ..f13ed0c > --- /dev/null > +++ b/Documentation/filesystems/dmemfs.rst > @@ -0,0 +1,58 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > += > +The Direct Memory Filesystem - DMEMFS > += > + > + > +.. Table of contents > + > + - Overview > + - Compilation > + - Usage > + > +Overview > + > + > +Dmemfs (Direct Memory filesystem) is device memory or reserved > +memory based filesystem. This kind of memory is special as it > +is not managed by kernel and it is without 'struct page'. Therefore > +it can save extra memory from the host system for various usage, usages, or uses, > +especially for guest virtual machines. > + > +It uses a kernel boot parameter ``dmem=`` to reserve the system > +memory when the host system boots up, the details can be checked boots up. The detail > +in /Documentation/admin-guide/kernel-parameters.txt. > + > +Compilation > +=== > + > +The filesystem should be enabled by turning on the kernel configuration > +options:: > + > +CONFIG_DMEM_FS - Direct Memory filesystem support > +CONFIG_DMEM - Allow reservation of memory for dmem Would anyone want DMEM_FS without DMEM? > + > + > +Additionally, the following can be turned on to aid debugging:: > + > +CONFIG_DMEM_DEBUG_FS- Enable debug information for dmem > + > +Usage > + > + > +Dmemfs supports mapping ``4K``, ``2M`` and ``1G`` size of pages to sizes > +the userspace, for example :: userspace. For example:: > + > +# mount -t dmemfs none -o pagesize=4K /mnt/ > + > +The it can create the backing storage with 4G size :: Then > + > +# truncate /mnt/dmemfs-uuid --size 4G > + > +To use as backing storage for virtual machine starts with qemu, just need started with qemu, just specify the memory-backed-file > +to specify the memory-backed-file in the qemu command line like this :: > + > +# -object memory-backend-file,id=ram-node0,mem-path=/mnt/dmemfs-uuid \ backed > +share=yes,size=4G,host-nodes=0,policy=preferred -numa > node,nodeid=0,memdev=ram-node0 > + -- ~Randy
Re: [PATCH] ACPI: NFIT: fix flexible_array.cocci warnings
On Tue, Dec 22, 2020 at 1:10 PM Julia Lawall wrote:
>
> From: kernel test robot
>
> Zero-length and one-element arrays are deprecated, see
> Documentation/process/deprecated.rst
> Flexible-array members should be used instead.
>
> Generated by: scripts/coccinelle/misc/flexible_array.cocci
>
> Fixes: 7b36c1398fb6 ("coccinelle: misc: add flexible_array.cocci script")
> CC: Denis Efremov
> Reported-by: kernel test robot
> Signed-off-by: kernel test robot
> Signed-off-by: Julia Lawall
Hmm, this triggers:
drivers/acpi/nfit/core.c:2276:4: error: flexible array member in a
struct with no named members
drivers/acpi/nfit/core.c:2287:4: error: flexible array member in a
struct with no named members
$ gcc --version
gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6)
I'll need to circle back to this later.
Re: [PATCH] net: ethernet: Fix memleak in ethoc_probe
On Wed, Dec 23, 2020 at 05:41:46PM -0800, Jakub Kicinski wrote: > > >> Does patchwork not automagically add Fixes: lines from full up emails? > > >> That seems like a reasonable automation. > > > > > > Looks like it's been a TODO for 3 years now: > > > > > > https://github.com/getpatchwork/patchwork/issues/151 > > > > It was proposed before, but rejected. You can have your local patchwork > > admin take care of that for you though and add custom tags: > > > > https://lists.ozlabs.org/pipermail/patchwork/2017-January/003910.html > > Konstantin, would you be willing to mod the kernel.org instance of > patchwork to populate Fixes tags in the generated mboxes? I'd really rather not -- we try not to diverge from project upstream if at all possible, as this dramatically complicates upgrades. -K
Re: [PATCH v1 0/6] no-copy bvec
On Wed, 2020-12-23 at 15:23 -0500, Douglas Gilbert wrote: > On 2020-12-23 11:04 a.m., James Bottomley wrote: > > On Wed, 2020-12-23 at 15:51 +, Christoph Hellwig wrote: > > > On Wed, Dec 23, 2020 at 12:52:59PM +, Pavel Begunkov wrote: > > > > Can scatterlist have 0-len entries? Those are directly > > > > translated into bvecs, e.g. in nvme/target/io-cmd-file.c and > > > > target/target_core_file.c. I've audited most of others by this > > > > moment, they're fine. > > > > > > For block layer SGLs we should never see them, and for nvme > > > neither. I think the same is true for the SCSI target code, but > > > please double check. > > > > Right, no-one ever wants to see a 0-len scatter list entry. The > > reason is that every driver uses the sgl to program the device DMA > > engine in the way NVME does. a 0 length sgl would be a dangerous > > corner case: some DMA engines would ignore it and others would go > > haywire, so if we ever let a 0 length list down into the driver, > > they'd have to understand the corner case behaviour of their DMA > > engine and filter it accordingly, which is why we disallow them in > > the upper levels, since they're effective nops anyway. > > When using scatter gather lists at the far end (i.e. on the storage > device) the T10 examples (WRITE SCATTERED and POPULATE TOKEN in SBC- > 4) explicitly allow the "number of logical blocks" in their sgl_s to > be zero and state that it is _not_ to be considered an error. But that's pretty irrelevant. The scatterlists that block has been constructing to drive DMA engines pre-date SCSI's addition of SGLs by decades (all SCSI commands before the object commands use a linear buffer which is implemented in the HBA engine as a scatterlist but not described by the SCSI standard as one). So the answer to the question should the block layer emit zero length sgl elements is "no" because they can confuse some DMA engines. If there's a more theoretical question of whether the target driver in adding commands it doesn't yet support should inject zero length SGL elements into block because SCSI allows it, the answer is still "no" because we don't want block to have SGLs that may confuse other DMA engines. There's lots of daft corner cases in the SCSI standard we don't implement and a nop for SGL elements seems to be one of the more hare brained because it adds no useful feature and merely causes compatibility issues. James
Re: [PATCH] staging: ralink-gdma: Fixed blank line coding style issue
On Wed, 2020-12-23 at 21:22 +0100, Ayoub Soussi wrote:
> Fixed coding style issue.
[]
> diff --git a/drivers/staging/ralink-gdma/ralink-gdma.c
> b/drivers/staging/ralink-gdma/ralink-gdma.c
[]
> @@ -122,6 +122,7 @@ struct gdma_dma_dev {
> struct gdma_data *data;
> void __iomem *base;
> struct tasklet_struct task;
> +
> volatile unsigned long chan_issued;
> atomic_t cnt;
This is presumably a checkpatch false positive.
checkpatch is not now nor never will be a perfect tool.
Please consider what you are doing and what the desired coding style is
before submitting patches.
[PATCH v2 1/3] scsi: ufs: Replace sprintf and snprintf with sysfs_emit
From: Bean Huo
sprintf and snprintf may cause output defect in sysfs content, it is
better to use new added sysfs_emit function which knows the size of the
temporary buffer.
Reviewed-by: Avri Altman
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Bean Huo
---
drivers/scsi/ufs/ufs-sysfs.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c
index 08e72b7eef6a..0e1438485133 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -67,7 +67,7 @@ static ssize_t rpm_lvl_show(struct device *dev,
{
struct ufs_hba *hba = dev_get_drvdata(dev);
- return sprintf(buf, "%d\n", hba->rpm_lvl);
+ return sysfs_emit(buf, "%d\n", hba->rpm_lvl);
}
static ssize_t rpm_lvl_store(struct device *dev,
@@ -81,7 +81,7 @@ static ssize_t rpm_target_dev_state_show(struct device *dev,
{
struct ufs_hba *hba = dev_get_drvdata(dev);
- return sprintf(buf, "%s\n", ufschd_ufs_dev_pwr_mode_to_string(
+ return sysfs_emit(buf, "%s\n", ufschd_ufs_dev_pwr_mode_to_string(
ufs_pm_lvl_states[hba->rpm_lvl].dev_state));
}
@@ -90,7 +90,7 @@ static ssize_t rpm_target_link_state_show(struct device *dev,
{
struct ufs_hba *hba = dev_get_drvdata(dev);
- return sprintf(buf, "%s\n", ufschd_uic_link_state_to_string(
+ return sysfs_emit(buf, "%s\n", ufschd_uic_link_state_to_string(
ufs_pm_lvl_states[hba->rpm_lvl].link_state));
}
@@ -99,7 +99,7 @@ static ssize_t spm_lvl_show(struct device *dev,
{
struct ufs_hba *hba = dev_get_drvdata(dev);
- return sprintf(buf, "%d\n", hba->spm_lvl);
+ return sysfs_emit(buf, "%d\n", hba->spm_lvl);
}
static ssize_t spm_lvl_store(struct device *dev,
@@ -113,7 +113,7 @@ static ssize_t spm_target_dev_state_show(struct device *dev,
{
struct ufs_hba *hba = dev_get_drvdata(dev);
- return sprintf(buf, "%s\n", ufschd_ufs_dev_pwr_mode_to_string(
+ return sysfs_emit(buf, "%s\n", ufschd_ufs_dev_pwr_mode_to_string(
ufs_pm_lvl_states[hba->spm_lvl].dev_state));
}
@@ -122,7 +122,7 @@ static ssize_t spm_target_link_state_show(struct device
*dev,
{
struct ufs_hba *hba = dev_get_drvdata(dev);
- return sprintf(buf, "%s\n", ufschd_uic_link_state_to_string(
+ return sysfs_emit(buf, "%s\n", ufschd_uic_link_state_to_string(
ufs_pm_lvl_states[hba->spm_lvl].link_state));
}
@@ -165,7 +165,7 @@ static ssize_t auto_hibern8_show(struct device *dev,
ufshcd_release(hba);
pm_runtime_put_sync(hba->dev);
- return scnprintf(buf, PAGE_SIZE, "%d\n", ufshcd_ahit_to_us(ahit));
+ return sysfs_emit(buf, "%d\n", ufshcd_ahit_to_us(ahit));
}
static ssize_t auto_hibern8_store(struct device *dev,
@@ -233,18 +233,18 @@ static ssize_t ufs_sysfs_read_desc_param(struct ufs_hba
*hba,
return -EINVAL;
switch (param_size) {
case 1:
- ret = sprintf(sysfs_buf, "0x%02X\n", *desc_buf);
+ ret = sysfs_emit(sysfs_buf, "0x%02X\n", *desc_buf);
break;
case 2:
- ret = sprintf(sysfs_buf, "0x%04X\n",
+ ret = sysfs_emit(sysfs_buf, "0x%04X\n",
get_unaligned_be16(desc_buf));
break;
case 4:
- ret = sprintf(sysfs_buf, "0x%08X\n",
+ ret = sysfs_emit(sysfs_buf, "0x%08X\n",
get_unaligned_be32(desc_buf));
break;
case 8:
- ret = sprintf(sysfs_buf, "0x%016llX\n",
+ ret = sysfs_emit(sysfs_buf, "0x%016llX\n",
get_unaligned_be64(desc_buf));
break;
}
@@ -609,7 +609,7 @@ static ssize_t _name##_show(struct device *dev,
\
SD_ASCII_STD);\
if (ret < 0)\
goto out; \
- ret = snprintf(buf, PAGE_SIZE, "%s\n", desc_buf); \
+ ret = sysfs_emit(buf, "%s\n", desc_buf);\
out: \
pm_runtime_put_sync(hba->dev); \
kfree(desc_buf);\
@@ -659,7 +659,7 @@ static ssize_t _name##_show(struct device *dev,
\
pm_runtime_put_sync(hba->dev); \
if (ret)\
return -EINVAL; \
- return sprintf(buf, "%s\n", flag ? "true" : "false"); \
+ return sysfs_emit(buf, "%s\n", flag ? "true" : "false");\
[PATCH v2 3/3] scsi: ufs: Let resume callback return -EBUSY after ufshcd_shutdown
From: Bean Huo
After ufshcd_shutdown(), both UFS device and UFS LINk are powered off,
return '0' will mislead the upper PM layer since the device has not been
successfully resumed yet. This will let pm_runtime_get_sync() caller
mistakenly believe the device/LINK has been resumed, which leads to
request processing timeout that was en-queued later.
To fix this, let ufshcd_system/runtimie_resume() return -EBUSY in case of
hba->is_powered == false.
Signed-off-by: Bean Huo
---
drivers/scsi/ufs/ufshcd.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e221add25a7e..e1bcac51c01f 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8950,14 +8950,16 @@ int ufshcd_system_resume(struct ufs_hba *hba)
return -EINVAL;
}
- if (!hba->is_powered || pm_runtime_suspended(hba->dev))
+ if (!hba->is_powered || pm_runtime_suspended(hba->dev)) {
/*
* Let the runtime resume take care of resuming
* if runtime suspended.
*/
+ ret = -EBUSY;
goto out;
- else
+ } else {
ret = ufshcd_resume(hba, UFS_SYSTEM_PM);
+ }
out:
trace_ufshcd_system_resume(dev_name(hba->dev), ret,
ktime_to_us(ktime_sub(ktime_get(), start)),
@@ -9026,10 +9028,12 @@ int ufshcd_runtime_resume(struct ufs_hba *hba)
if (!hba)
return -EINVAL;
- if (!hba->is_powered)
+ if (!hba->is_powered) {
+ ret = -EBUSY;
goto out;
- else
+ } else {
ret = ufshcd_resume(hba, UFS_RUNTIME_PM);
+ }
out:
trace_ufshcd_runtime_resume(dev_name(hba->dev), ret,
ktime_to_us(ktime_sub(ktime_get(), start)),
--
2.17.1
[PATCH v2 2/3] scsi: ufs: Add handling of the return value of pm_runtime_get_sync()
From: Bean Huo
The race issue may exist between UFS access in UFS sysfs context and UFS
shutdown, thus will cause pm_runtime_get_sync() resume failure.
Add handling of the return value of pm_runtime_get_sync(). Let it return
in case pm_runtime_get_sync() resume failed.
Signed-off-by: Bean Huo
---
drivers/scsi/ufs/ufs-sysfs.c | 38 ++--
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c
index 0e1438485133..8e5e36e01bee 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -154,12 +154,17 @@ static ssize_t auto_hibern8_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
u32 ahit;
+ int ret;
struct ufs_hba *hba = dev_get_drvdata(dev);
if (!ufshcd_is_auto_hibern8_supported(hba))
return -EOPNOTSUPP;
- pm_runtime_get_sync(hba->dev);
+ ret = pm_runtime_get_sync(hba->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(hba->dev);
+ return ret;
+ }
ufshcd_hold(hba, false);
ahit = ufshcd_readl(hba, REG_AUTO_HIBERNATE_IDLE_TIMER);
ufshcd_release(hba);
@@ -225,7 +230,12 @@ static ssize_t ufs_sysfs_read_desc_param(struct ufs_hba
*hba,
if (param_size > 8)
return -EINVAL;
- pm_runtime_get_sync(hba->dev);
+ ret = pm_runtime_get_sync(hba->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(hba->dev);
+ return ret;
+ }
+
ret = ufshcd_read_desc_param(hba, desc_id, desc_index,
param_offset, desc_buf, param_size);
pm_runtime_put_sync(hba->dev);
@@ -594,7 +604,11 @@ static ssize_t _name##_show(struct device *dev,
\
desc_buf = kzalloc(QUERY_DESC_MAX_SIZE, GFP_ATOMIC);\
if (!desc_buf) \
return -ENOMEM; \
- pm_runtime_get_sync(hba->dev); \
+ ret = pm_runtime_get_sync(hba->dev);\
+ if (ret < 0) { \
+ pm_runtime_put_noidle(hba->dev);\
+ return ret; \
+ } \
ret = ufshcd_query_descriptor_retry(hba,\
UPIU_QUERY_OPCODE_READ_DESC, QUERY_DESC_IDN_DEVICE, \
0, 0, desc_buf, &desc_len); \
@@ -653,7 +667,11 @@ static ssize_t _name##_show(struct device *dev,
\
struct ufs_hba *hba = dev_get_drvdata(dev); \
if (ufshcd_is_wb_flags(QUERY_FLAG_IDN##_uname)) \
index = ufshcd_wb_get_query_index(hba); \
- pm_runtime_get_sync(hba->dev); \
+ ret = pm_runtime_get_sync(hba->dev);\
+ if (ret < 0) { \
+ pm_runtime_put_noidle(hba->dev);\
+ return ret; \
+ } \
ret = ufshcd_query_flag(hba, UPIU_QUERY_OPCODE_READ_FLAG, \
QUERY_FLAG_IDN##_uname, index, &flag); \
pm_runtime_put_sync(hba->dev); \
@@ -711,7 +729,11 @@ static ssize_t _name##_show(struct device *dev,
\
u8 index = 0; \
if (ufshcd_is_wb_attrs(QUERY_ATTR_IDN##_uname)) \
index = ufshcd_wb_get_query_index(hba); \
- pm_runtime_get_sync(hba->dev); \
+ ret = pm_runtime_get_sync(hba->dev);\
+ if (ret < 0) { \
+ pm_runtime_put_noidle(hba->dev);\
+ return ret; \
+ } \
ret = ufshcd_query_attr(hba, UPIU_QUERY_OPCODE_READ_ATTR, \
QUERY_ATTR_IDN##_uname, index, 0, &value); \
pm_runtime_put_sync(hba->dev); \
@@ -850,7 +872,11 @@ static ssize_t dyn_cap_needed_attribute_show(struct device
*dev,
u8 lun = ufshcd_scsi_to_upiu_lun(sdev->lun);
int ret;
- pm_runtime_get_sync(hba->dev);
+ ret = pm_runtime_get_sync(hba->dev);
+ if (ret < 0)
[PATCH v2 0/3] Two changes of UFS sysfs
From: Bean Huo Changelog: V1---v2: 1. Add new patch "Let resume callback return -EBUSY after ufshcd_shutdown", Because the ufshcd_*_resume still returns successful result 0 after ufshcd_shutdown(). Even add handling of the return value of pm_runtime_get_sync(), but still there is timeout. Bean Huo (3): scsi: ufs: Replace sprintf and snprintf with sysfs_emit scsi: ufs: Add handling of the return value of pm_runtime_get_sync() scsi: ufs: Let resume callback return -EBUSY after ufshcd_shutdown drivers/scsi/ufs/ufs-sysfs.c | 68 +--- drivers/scsi/ufs/ufshcd.c| 12 --- 2 files changed, 55 insertions(+), 25 deletions(-) -- 2.17.1
Re: [PATCH] staging: rtl8723bs: clean up brace coding style issues
On Tue, 2020-12-22 at 15:17 +0100, Michael Straube wrote:
> Add missing braces around else arm of if else statement to clear
> style issues reported by checkpatch.
>
> CHECK: braces {} should be used on all arms of this statement
> CHECK: Unbalanced braces around else statement
[]
> diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c
> b/drivers/staging/rtl8723bs/core/rtw_efuse.c
[]
> @@ -245,8 +245,9 @@ u16 Address)
> break;
> }
> return rtw_read8(Adapter, EFUSE_CTRL);
> - } else
> + } else {
> return 0xFF;
> + }
Instead, when you see a pattern like this it's generally
better to reverse whatever test is above this, return early
and unindent the block above the else.
Here that would be:
---
diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c
b/drivers/staging/rtl8723bs/core/rtw_efuse.c
index 32ca10f01413..e5c3dba5c8ae 100644
--- a/drivers/staging/rtl8723bs/core/rtw_efuse.c
+++ b/drivers/staging/rtl8723bs/core/rtw_efuse.c
@@ -222,31 +222,31 @@ u16 Address)
EFUSE_GetEfuseDefinition(Adapter, EFUSE_WIFI,
TYPE_EFUSE_REAL_CONTENT_LEN, (void *)&contentLen, false);
- if (Address < contentLen) {/* E-fuse 512Byte */
- /* Write E-fuse Register address bit0~7 */
- temp = Address & 0xFF;
- rtw_write8(Adapter, EFUSE_CTRL+1, temp);
- Bytetemp = rtw_read8(Adapter, EFUSE_CTRL+2);
- /* Write E-fuse Register address bit8~9 */
- temp = ((Address >> 8) & 0x03) | (Bytetemp & 0xFC);
- rtw_write8(Adapter, EFUSE_CTRL+2, temp);
-
- /* Write 0x30[31]= 0 */
- Bytetemp = rtw_read8(Adapter, EFUSE_CTRL+3);
- temp = Bytetemp & 0x7F;
- rtw_write8(Adapter, EFUSE_CTRL+3, temp);
+ if (Address >= contentLen) /* E-fuse 512Byte */
+ return 0xFF;
- /* Wait Write-ready (0x30[31]= 1) */
+ /* Write E-fuse Register address bit0~7 */
+ temp = Address & 0xFF;
+ rtw_write8(Adapter, EFUSE_CTRL+1, temp);
+ Bytetemp = rtw_read8(Adapter, EFUSE_CTRL+2);
+ /* Write E-fuse Register address bit8~9 */
+ temp = ((Address >> 8) & 0x03) | (Bytetemp & 0xFC);
+ rtw_write8(Adapter, EFUSE_CTRL+2, temp);
+
+ /* Write 0x30[31]= 0 */
+ Bytetemp = rtw_read8(Adapter, EFUSE_CTRL+3);
+ temp = Bytetemp & 0x7F;
+ rtw_write8(Adapter, EFUSE_CTRL+3, temp);
+
+ /* Wait Write-ready (0x30[31]= 1) */
+ Bytetemp = rtw_read8(Adapter, EFUSE_CTRL+3);
+ while (!(Bytetemp & 0x80)) {
Bytetemp = rtw_read8(Adapter, EFUSE_CTRL+3);
- while (!(Bytetemp & 0x80)) {
- Bytetemp = rtw_read8(Adapter, EFUSE_CTRL+3);
- k++;
- if (k == 1000)
- break;
- }
- return rtw_read8(Adapter, EFUSE_CTRL);
- } else
- return 0xFF;
+ k++;
+ if (k == 1000)
+ break;
+ }
+ return rtw_read8(Adapter, EFUSE_CTRL);
} /* EFUSE_Read1Byte */
drivers/scsi/fnic/vnic_dev.c:332:32: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 58cf05f597b03a8212d9ecf2c79ee046d3ee8ad9
commit: 8f28ca6bd8211214faf717677bbffe375c2a6072 iomap: constify ioreadX()
iomem argument (as in generic implementation)
date: 4 months ago
config: i386-randconfig-s001-20201220 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-184-g1b896707-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8f28ca6bd8211214faf717677bbffe375c2a6072
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 8f28ca6bd8211214faf717677bbffe375c2a6072
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> drivers/scsi/fnic/vnic_dev.c:332:32: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@ expected void const [noderef]
>> __iomem * @@ got unsigned int * @@
drivers/scsi/fnic/vnic_dev.c:332:32: sparse: expected void const
[noderef] __iomem *
drivers/scsi/fnic/vnic_dev.c:332:32: sparse: got unsigned int *
drivers/scsi/fnic/vnic_dev.c:333:37: sparse: sparse: incorrect type in
argument 1 (different address spaces) @@ expected void const [noderef]
__iomem * @@ got unsigned int * @@
drivers/scsi/fnic/vnic_dev.c:333:37: sparse: expected void const
[noderef] __iomem *
drivers/scsi/fnic/vnic_dev.c:333:37: sparse: got unsigned int *
drivers/scsi/fnic/vnic_dev.c:373:36: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void [noderef] __iomem *
@@ got unsigned int * @@
drivers/scsi/fnic/vnic_dev.c:373:36: sparse: expected void [noderef]
__iomem *
drivers/scsi/fnic/vnic_dev.c:373:36: sparse: got unsigned int *
drivers/scsi/fnic/vnic_dev.c:469:32: sparse: sparse: incorrect type in
assignment (different address spaces) @@ expected struct vnic_wq_ctrl
*wq_ctrl @@ got struct vnic_wq_ctrl [noderef] __iomem *ctrl @@
drivers/scsi/fnic/vnic_dev.c:469:32: sparse: expected struct
vnic_wq_ctrl *wq_ctrl
drivers/scsi/fnic/vnic_dev.c:469:32: sparse: got struct vnic_wq_ctrl
[noderef] __iomem *ctrl
drivers/scsi/fnic/vnic_dev.c:943:11: sparse: sparse: incorrect type in
assignment (different address spaces) @@ expected void *p @@ got void
[noderef] __iomem * @@
drivers/scsi/fnic/vnic_dev.c:943:11: sparse: expected void *p
drivers/scsi/fnic/vnic_dev.c:943:11: sparse: got void [noderef] __iomem *
vim +332 drivers/scsi/fnic/vnic_dev.c
5df6d737dd4b0fe Abhijeet Joglekar 2009-04-17 318
363f4d937501ba4 Jason Yan 2020-04-15 319 static int
vnic_dev_cmd2(struct vnic_dev *vdev, enum vnic_devcmd_cmd cmd,
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 320 int wait)
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 321 {
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 322 struct
devcmd2_controller *dc2c = vdev->devcmd2;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 323 struct devcmd2_result
*result;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 324 u8 color;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 325 unsigned int i;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 326 int delay;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 327 int err;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 328 u32 fetch_index;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 329 u32 posted;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 330 u32 new_posted;
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 331
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 @332 posted =
ioread32(&dc2c->wq_ctrl->posted_index);
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 333 fetch_index =
ioread32(&dc2c->wq_ctrl->fetch_index);
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 334
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 335 if (posted ==
0x || fetch_index == 0x) {
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 336 /* Hardware
surprise removal: return error */
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 337 pr_err("%s:
devcmd2 invalid posted or fetch index on cmd %d\n",
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 338
pci_name(vdev->pdev), _CMD_N(cmd));
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 339 pr_err("%s:
fetch index: %u, posted index: %u\n",
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 340
pci_name(vdev->pdev), fetch_index, posted);
0a2fdd2215e1fa3 Satish Kharat 2019-01-18 341
0a2fdd2215e1fa3 Satish Kha
[PATCH V2 9/9] arm64: dts: renesas: beacon: Increase sdhi speeds
The eMMC can run at hs400 and the WiFi chip can run at sdr104.
Set the respective flags to push the sdhi faster.
Signed-off-by: Adam Ford
---
V2: New to series
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
index b34ffa1e77fa..56bdd80e36d0 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
@@ -271,8 +271,9 @@ &scif2 {
};
&sdhi2 {
- pinctrl-names = "default";
pinctrl-0 = <&sdhi2_pins>;
+ pinctrl-1 = <&sdhi2_pins>;
+ pinctrl-names = "default", "state_uhs";
bus-width = <4>;
vmmc-supply = <®_3p3v>;
vqmmc-supply = <®_1p8v>;
@@ -281,6 +282,8 @@ &sdhi2 {
pm-ignore-notify;
keep-power-in-suspend;
mmc-pwrseq = <&wlan_pwrseq>;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
--
2.25.1
[PATCH V2 6/9] arm64: dts: renesas: beacon-rzg2m-kit: Rearange SoC unique functions
In preparation for adding new dev kits, move anything specific to the
RZ/G2M from the SOM-level and baseboard-levels and move them to the
kit-level. This allows the SOM and baseboard to be reused with
other SoC's.
Signed-off-by: Adam Ford
---
V2: Fix missing entries in dts file.
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index 3b3efaf749bb..a6aa0b815c46 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -241,21 +241,6 @@ &can1 {
status = "okay";
};
-&du {
- pinctrl-0 = <&du_pins>;
- pinctrl-names = "default";
- status = "okay";
-
- clocks = <&cpg CPG_MOD 724>,
- <&cpg CPG_MOD 723>,
- <&cpg CPG_MOD 722>,
- <&versaclock5 1>,
- <&x302_clk>,
- <&versaclock5 2>;
- clock-names = "du.0", "du.1", "du.2",
- "dclkin.0", "dclkin.1", "dclkin.2";
-};
-
&du_out_rgb {
remote-endpoint = <&rgb_panel>;
};
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
index a6f7193e4d97..b34ffa1e77fa 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
@@ -13,11 +13,6 @@ memory@4800 {
reg = <0x0 0x4800 0x0 0x7800>;
};
- memory@6 {
- device_type = "memory";
- reg = <0x6 0x 0x0 0x8000>;
- };
-
osc_32k: osc_32k {
compatible = "fixed-clock";
#clock-cells = <0>;
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
b/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
index 25eeac411f12..501cb05da228 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
@@ -26,6 +26,26 @@ aliases {
chosen {
stdout-path = "serial0:115200n8";
};
+
+ memory@6 {
+ device_type = "memory";
+ reg = <0x6 0x 0x0 0x8000>;
+ };
+};
+
+&du {
+ pinctrl-0 = <&du_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ clocks = <&cpg CPG_MOD 724>,
+<&cpg CPG_MOD 723>,
+<&cpg CPG_MOD 722>,
+<&versaclock5 1>,
+<&x302_clk>,
+<&versaclock5 2>;
+ clock-names = "du.0", "du.1", "du.2",
+ "dclkin.0", "dclkin.1", "dclkin.2";
};
/* Reference versaclock instead of audio_clk_a */
--
2.25.1
[PATCH V2 8/9] arm64: dts: renesas: Introduce r8a774e1-beacon-rzg2h-kit
eacon EmebeddedWorks is introducing a new kit based on the
RZ/G2H SoC from Renesas.
The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1
cellular radio.
The Baseboard has Ethernet, USB, HDMI, stereo audio in and out,
along with a variety of push buttons and LED's, and support for
a parallel RGB and an LVDS display. It uses the same baseboard
and SOM files as the RZ/G2M and RZ/G2N kits.
Signed-off-by: Adam Ford
---
V2: Add missing du node entries
diff --git a/arch/arm64/boot/dts/renesas/Makefile
b/arch/arm64/boot/dts/renesas/Makefile
index cf7e2f77e4ea..5c68de184501 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-ek874.dtb
dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-ek874-idk-2121wr.dtb
dtb-$(CONFIG_ARCH_R8A774C0) += r8a774c0-ek874-mipi-2.1.dtb
+dtb-$(CONFIG_ARCH_R8A774E1) += r8a774e1-beacon-rzg2h-kit.dtb
dtb-$(CONFIG_ARCH_R8A774E1) += r8a774e1-hihope-rzg2h.dtb
dtb-$(CONFIG_ARCH_R8A774E1) += r8a774e1-hihope-rzg2h-ex.dtb
dtb-$(CONFIG_ARCH_R8A774E1) += r8a774e1-hihope-rzg2h-ex-idk-1110wr.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts
b/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts
new file mode 100644
index ..273f062f2909
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020, Compass Electronics Group, LLC
+ */
+
+/dts-v1/;
+
+#include "r8a774e1.dtsi"
+#include "beacon-renesom-som.dtsi"
+#include "beacon-renesom-baseboard.dtsi"
+
+/ {
+ model = "Beacon Embedded Works RZ/G2H Development Kit";
+ compatible ="beacon,beacon-rzg2h", "renesas,r8a774e1";
+
+ aliases {
+ serial0 = &scif2;
+ serial1 = &hscif0;
+ serial2 = &hscif1;
+ serial3 = &scif0;
+ serial4 = &hscif2;
+ serial5 = &scif5;
+ serial6 = &scif4;
+ ethernet0 = &avb;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@5 {
+ device_type = "memory";
+ reg = <0x5 0x 0x0 0x8000>;
+ };
+};
+
+&du {
+ pinctrl-0 = <&du_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ clocks = <&cpg CPG_MOD 724>,
+ <&cpg CPG_MOD 723>,
+ <&cpg CPG_MOD 721>,
+ <&versaclock5 1>,
+ <&x302_clk>,
+ <&versaclock5 2>;
+ clock-names = "du.0", "du.1", "du.3",
+ "dclkin.0", "dclkin.1", "dclkin.3";
+};
+
+/* Reference versaclock instead of audio_clk_a */
+&rcar_sound {
+ clocks = <&cpg CPG_MOD 1005>,
+<&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
+<&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
+<&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
+<&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
+<&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
+<&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
+<&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
+<&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
+<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
+<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
+<&versaclock6_bb 4>, <&audio_clk_b>,
+<&audio_clk_c>,
+<&cpg CPG_CORE R8A774E1_CLK_S0D4>;
+};
--
2.25.1
[PATCH V2 4/9] arm64: dts: renesas: beacon: Better describe keys
The keys on the baseboard are laid out in an diamond pattern, up, down,
left, right and center. Update the descriptions to make it easier to
read.
Signed-off-by: Adam Ford
---
V2: Make keycode match the key name.
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index dc5e05d7a792..a54ec36c69e4 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -40,38 +40,38 @@ hdmi0_con: endpoint {
keys {
compatible = "gpio-keys";
- key-1 {
+ key-1 { /* S19 */
gpios = <&gpio4 6 GPIO_ACTIVE_LOW>;
- linux,code = ;
- label = "Switch-1";
+ linux,code = ;
+ label = "Up";
wakeup-source;
debounce-interval = <20>;
};
- key-2 {
+ key-2 { /*S20 */
gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
- linux,code = ;
- label = "Switch-2";
+ linux,code = ;
+ label = "Left";
wakeup-source;
debounce-interval = <20>;
};
- key-3 {
+ key-3 { /* S21 */
gpios = <&gpio5 17 GPIO_ACTIVE_LOW>;
- linux,code = ;
- label = "Switch-3";
+ linux,code = ;
+ label = "Down";
wakeup-source;
debounce-interval = <20>;
};
- key-4 {
+ key-4 { /* S22 */
gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
- linux,code = ;
- label = "Switch-4";
+ linux,code = ;
+ label = "Right";
wakeup-source;
debounce-interval = <20>;
};
- key-5 {
+ key-5 { /* S23 */
gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
- linux,code = ;
- label = "Switch-4";
+ linux,code = ;
+ label = "Center";
wakeup-source;
debounce-interval = <20>;
};
--
2.25.1
[PATCH V2 7/9] arm64: dts: renesas: Introduce r8a774b1-beacon-rzg2n-kit
Beacon EmebeddedWorks is introducing a new kit based on the
RZ/G2N SoC from Renesas.
The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1
cellular radio.
The Baseboard has Ethernet, USB, HDMI, stereo audio in and out,
along with a variety of push buttons and LED's, and support for
a parallel RGB and an LVDS display. It uses the same baseboard
and SOM as the RZ/G2M.
This SOM has only 2GB of DDR, and beacon-renesom-som.dtsi contains
the base memory node, so an additional memory node isn't necessary.
Signed-off-by: Adam Ford
---
V2: Add missing du node entries.
diff --git a/arch/arm64/boot/dts/renesas/Makefile
b/arch/arm64/boot/dts/renesas/Makefile
index dffefe030a76..cf7e2f77e4ea 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -7,6 +7,7 @@ dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-rev2.dtb
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-rev2-ex.dtb
dtb-$(CONFIG_ARCH_R8A774A1) += r8a774a1-hihope-rzg2m-rev2-ex-idk-1110wr.dtb
+dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-beacon-rzg2n-kit.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n-ex.dtb
dtb-$(CONFIG_ARCH_R8A774B1) += r8a774b1-hihope-rzg2n-ex-idk-1110wr.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts
b/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts
new file mode 100644
index ..71763f4402a7
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020, Compass Electronics Group, LLC
+ */
+
+/dts-v1/;
+
+#include "r8a774b1.dtsi"
+#include "beacon-renesom-som.dtsi"
+#include "beacon-renesom-baseboard.dtsi"
+
+/ {
+ model = "Beacon Embedded Works RZ/G2N Development Kit";
+ compatible ="beacon,beacon-rzg2n", "renesas,r8a774b1";
+
+ aliases {
+ serial0 = &scif2;
+ serial1 = &hscif0;
+ serial2 = &hscif1;
+ serial3 = &scif0;
+ serial4 = &hscif2;
+ serial5 = &scif5;
+ serial6 = &scif4;
+ ethernet0 = &avb;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&du {
+ pinctrl-0 = <&du_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ clocks = <&cpg CPG_MOD 724>,
+ <&cpg CPG_MOD 723>,
+ <&cpg CPG_MOD 721>,
+ <&versaclock5 1>,
+ <&x302_clk>,
+ <&versaclock5 2>;
+ clock-names = "du.0", "du.1", "du.3",
+ "dclkin.0", "dclkin.1", "dclkin.3";
+};
+
+/* Reference versaclock instead of audio_clk_a */
+&rcar_sound {
+ clocks = <&cpg CPG_MOD 1005>,
+<&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
+<&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
+<&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
+<&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
+<&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
+<&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
+<&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
+<&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
+<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
+<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
+<&versaclock6_bb 4>, <&audio_clk_b>,
+<&audio_clk_c>,
+<&cpg CPG_CORE R8A774B1_CLK_S0D4>;
+};
--
2.25.1
[PATCH V2 5/9] arm64: dts: renesas: beacon: Cleanup USB References
The programmable versaclock is used for the usb_extal reference clock for
the EHCI driver instead of a fixed-clock. Because the versaclock needs to
be enabled, the clock reference needs to be added to the clocks list.
For the USB3 Phy, the perferred clock reference is usb3s_clk, so
remove the usb_extal reference.
Signed-off-by: Adam Ford
---
V2: Split this off into its own patch.
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index a54ec36c69e4..3b3efaf749bb 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -263,12 +263,22 @@ &du_out_rgb {
&ehci0 {
dr_mode = "otg";
status = "okay";
- clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+ clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>, <&versaclock5 3>;
};
&ehci1 {
status = "okay";
- clocks = <&cpg CPG_MOD 703>, <&cpg CPG_MOD 704>;
+ clocks = <&cpg CPG_MOD 702>, <&versaclock5 3>;
+};
+
+&gpio6 {
+
+ usb_hub_reset {
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "usb-hub-reset";
+ };
};
&hdmi0 {
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
index ade2f58ad99b..a6f7193e4d97 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi
@@ -75,15 +75,6 @@ &extalr_clk {
clock-frequency = <32768>;
};
-&gpio6 {
- usb_hub_reset {
- gpio-hog;
- gpios = <10 GPIO_ACTIVE_HIGH>;
- output-high;
- line-name = "usb-hub-reset";
- };
-};
-
&hscif0 {
pinctrl-0 = <&hscif0_pins>;
pinctrl-names = "default";
@@ -315,16 +306,12 @@ &sdhi3 {
vmmc-supply = <®_3p3v>;
vqmmc-supply = <®_1p8v>;
bus-width = <8>;
- mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
non-removable;
fixed-emmc-driver-type = <1>;
status = "okay";
};
-&usb_extal_clk {
- clock-frequency = <5000>;
-};
-
&usb3s0_clk {
clock-frequency = <1>;
};
--
2.25.1
[PATCH V2 3/9] arm64: dts: renesas: beacon: Configure Audio CODEC clocks
With the newly added configurable clock options, the audio CODEC can
configure the mclk automatically. Add the reference to the versaclock.
Since the devices on I2C5 can communicate at 400KHz, let's also increase
that too
Signed-off-by: Adam Ford
---
V2: Remove the un-used clock-names reference.
Base on:
https://patchwork.kernel.org/project/alsa-devel/patch/20201217162740.1452000-1-aford...@gmail.com/
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index 4e86d308d07e..dc5e05d7a792 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -385,13 +385,14 @@ &i2c0 {
&i2c5 {
status = "okay";
- clock-frequency = <10>;
+ clock-frequency = <40>;
pinctrl-0 = <&i2c5_pins>;
pinctrl-names = "default";
codec: wm8962@1a {
compatible = "wlf,wm8962";
reg = <0x1a>;
+ clocks = <&versaclock6_bb 3>;
DCVDD-supply = <®_audio>;
DBVDD-supply = <®_audio>;
AVDD-supply = <®_audio>;
--
2.25.1
[PATCH V2 2/9] arm64: dts: renesas: beacon kit: Fix Audio Clock sources
The SoC was expecting two clock sources with different frequencies.
One to support 44.1KHz and one to support 48KHz. With the newly added
ability to configure the programmably clock, configure both clocks.
Assign the rcar-sound clocks to reference the versaclock instead of
the fixed clock.
Signed-off-by: Adam Ford
---
V2: Go from fixed-factor-clock to just redefining the rcar-sound node
to reference the versaclock instead of the audio_clk_a.
diff --git a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
index 46a3ba895330..4e86d308d07e 100644
--- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
+++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
@@ -223,12 +223,6 @@ x304_clk: x304-clock {
};
};
-&audio_clk_a {
- clock-frequency = <24576000>;
- assigned-clocks = <&versaclock6_bb 4>;
- assigned-clock-rates = <24576000>;
-};
-
&audio_clk_b {
clock-frequency = <22579200>;
};
@@ -574,7 +568,7 @@ sound_pins: sound {
};
sound_clk_pins: sound_clk {
- groups = "audio_clk_a_a";
+ groups = "audio_clk_a_a", "audio_clk_b_a";
function = "audio_clk";
};
@@ -625,23 +619,6 @@ &rcar_sound {
status = "okay";
- clocks = <&cpg CPG_MOD 1005>,
-<&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
-<&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
-<&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
-<&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
-<&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
-<&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
-<&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
-<&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
-<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
-<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
-<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
-<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
-<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
-<&audio_clk_a>, <&audio_clk_b>, <&audio_clk_c>,
-<&cpg CPG_CORE R8A774A1_CLK_S0D4>;
-
ports {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
b/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
index 2c5b057c30c6..25eeac411f12 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
+++ b/arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts
@@ -27,3 +27,24 @@ chosen {
stdout-path = "serial0:115200n8";
};
};
+
+/* Reference versaclock instead of audio_clk_a */
+&rcar_sound {
+ clocks = <&cpg CPG_MOD 1005>,
+<&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
+<&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
+<&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
+<&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
+<&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
+<&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
+<&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
+<&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
+<&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
+<&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+<&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+<&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
+<&versaclock6_bb 4>, <&audio_clk_b>,
+<&audio_clk_c>,
+<&cpg CPG_CORE R8A774A1_CLK_S0D4>;
+};
--
2.25.1
