[PATCH v3 3/4] staging: mt7621-dts: add pci-phy related bindings to board's device tree
New driver for pci phy has been added, as well as. pci driver has been
changed to use kernel's generic PHY API. Add related PCI PHY bindings
accordly.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-dts/mt7621.dtsi | 31 ++
1 file changed, 31 insertions(+)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 71f069d59ad8..0cbc298ed457 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -424,6 +424,8 @@
reset-names = "pcie0", "pcie1", "pcie2";
clocks = < 24 25 26>;
clock-names = "pcie0", "pcie1", "pcie2";
+ phys = <_port>, <_port>, <_port>;
+ phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
pcie@0,0 {
reg = <0x 0 0 0 0>;
@@ -449,4 +451,33 @@
bus-range = <0x00 0xff>;
};
};
+
+ pcie0_phy: pcie-phy@1a149000 {
+ compatible = "mediatek,mt7621-pci-phy";
+ reg = <0x1a149000 0x0700>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcie0_port: pcie-phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ pcie1_port: pcie-phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
+
+ pcie1_phy: pcie-phy@1a14a000 {
+ compatible = "mediatek,mt7621-pci-phy";
+ reg = <0x1a14a000 0x0700>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcie2_port: pcie-phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+ };
};
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 4/4] staging: mt7621-pci-phy: dt-bindings: add bindings for Mediatek MT7621 Pcie PHY
Add bindings documentation for PCie PHY of Mediatek MT7621.
This file will be moved into its appropiate documentation bindings'place
when this driver is mainlined.
CC: Device Tree mailing list
Signed-off-by: Sergio Paracuellos
---
.../mediatek,mt7621-pci-phy.txt | 54 +++
1 file changed, 54 insertions(+)
create mode 100644 drivers/staging/mt7621-pci-phy/mediatek,mt7621-pci-phy.txt
diff --git a/drivers/staging/mt7621-pci-phy/mediatek,mt7621-pci-phy.txt
b/drivers/staging/mt7621-pci-phy/mediatek,mt7621-pci-phy.txt
new file mode 100644
index ..33a8a698bdd0
--- /dev/null
+++ b/drivers/staging/mt7621-pci-phy/mediatek,mt7621-pci-phy.txt
@@ -0,0 +1,54 @@
+Mediatek Mt7621 PCIe PHY
+
+Required properties:
+- compatible: must be "mediatek,mt7621-pci-phy"
+- reg: base address and length of the PCIe PHY block
+- #address-cells: must be 1
+- #size-cells: must be 0
+
+Each PCIe PHY should be represented by a child node
+
+Required properties For the child node:
+- reg: the PHY ID
+0 - PCIe RC 0
+1 - PCIe RC 1
+- #phy-cells: must be 0
+
+Example:
+ pcie0_phy: pcie-phy@1a149000 {
+ compatible = "mediatek,mt7621-pci-phy";
+ reg = <0x1a149000 0x0700>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcie0_port: pcie-phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ pcie1_port: pcie-phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
+
+ pcie1_phy: pcie-phy@1a14a000 {
+ compatible = "mediatek,mt7621-pci-phy";
+ reg = <0x1a14a000 0x0700>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pcie2_port: pcie-phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+ };
+
+ /* users of the PCIe phy */
+
+ pcie: pcie@1e14 {
+ ...
+ ...
+ phys = <_port>, <_port>, <_port>;
+ phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
+ };
\ No newline at end of file
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 2/4] staging: mt7621-pci: handle phy using new generic phy 'pci-mt7621-phy' driver
Phy part of this driver has been moved to a new 'pci-mt7621-phy' driver.
Change code to use kernel's generic phy API removing also no more need
moved code.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-pci/pci-mt7621.c | 250 +++-
1 file changed, 32 insertions(+), 218 deletions(-)
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c
b/drivers/staging/mt7621-pci/pci-mt7621.c
index e720524ba5a3..507b8c68d20b 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -95,76 +96,12 @@
#define RALINK_PCI_IO_MAP_BASE 0x1e16
#define MEMORY_BASE0x0
-/* pcie phy related macros */
-#define RALINK_PCIEPHY_P0P1_CTL_OFFSET 0x9000
-#define RALINK_PCIEPHY_P2_CTL_OFFSET 0xA000
-
-#define RG_P0_TO_P1_WIDTH 0x100
-
-#define RG_PE1_PIPE_REG0x02c
-#define RG_PE1_PIPE_RSTBIT(12)
-#define RG_PE1_PIPE_CMD_FRCBIT(4)
-
-#define RG_PE1_H_LCDDS_REG 0x49c
-#define RG_PE1_H_LCDDS_PCW GENMASK(30, 0)
-#define RG_PE1_H_LCDDS_PCW_VAL(x) ((0x7fff & (x)) << 0)
-
-#define RG_PE1_FRC_H_XTAL_REG 0x400
-#define RG_PE1_FRC_H_XTAL_TYPE BIT(8)
-#define RG_PE1_H_XTAL_TYPE GENMASK(10, 9)
-#define RG_PE1_H_XTAL_TYPE_VAL(x) ((0x3 & (x)) << 9)
-
-#define RG_PE1_FRC_PHY_REG 0x000
-#define RG_PE1_FRC_PHY_EN BIT(4)
-#define RG_PE1_PHY_EN BIT(5)
-
-#define RG_PE1_H_PLL_REG 0x490
-#define RG_PE1_H_PLL_BCGENMASK(23, 22)
-#define RG_PE1_H_PLL_BC_VAL(x) ((0x3 & (x)) << 22)
-#define RG_PE1_H_PLL_BPGENMASK(21, 18)
-#define RG_PE1_H_PLL_BP_VAL(x) ((0xf & (x)) << 18)
-#define RG_PE1_H_PLL_IRGENMASK(15, 12)
-#define RG_PE1_H_PLL_IR_VAL(x) ((0xf & (x)) << 12)
-#define RG_PE1_H_PLL_ICGENMASK(11, 8)
-#define RG_PE1_H_PLL_IC_VAL(x) ((0xf & (x)) << 8)
-#define RG_PE1_H_PLL_PREDIV GENMASK(7, 6)
-#define RG_PE1_H_PLL_PREDIV_VAL(x) ((0x3 & (x)) << 6)
-#define RG_PE1_PLL_DIVEN GENMASK(3, 1)
-#define RG_PE1_PLL_DIVEN_VAL(x)((0x7 & (x)) << 1)
-
-#define RG_PE1_H_PLL_FBKSEL_REG0x4bc
-#define RG_PE1_H_PLL_FBKSEL GENMASK(5, 4)
-#define RG_PE1_H_PLL_FBKSEL_VAL(x) ((0x3 & (x)) << 4)
-
-#defineRG_PE1_H_LCDDS_SSC_PRD_REG 0x4a4
-#define RG_PE1_H_LCDDS_SSC_PRD GENMASK(15, 0)
-#define RG_PE1_H_LCDDS_SSC_PRD_VAL(x) ((0x & (x)) << 0)
-
-#define RG_PE1_H_LCDDS_SSC_DELTA_REG 0x4a8
-#define RG_PE1_H_LCDDS_SSC_DELTAGENMASK(11, 0)
-#define RG_PE1_H_LCDDS_SSC_DELTA_VAL(x) ((0xfff & (x)) << 0)
-#define RG_PE1_H_LCDDS_SSC_DELTA1 GENMASK(27, 16)
-#define RG_PE1_H_LCDDS_SSC_DELTA1_VAL(x) ((0xff & (x)) << 16)
-
-#define RG_PE1_LCDDS_CLK_PH_INV_REG0x4a0
-#define RG_PE1_LCDDS_CLK_PH_INVBIT(5)
-
-#define RG_PE1_H_PLL_BR_REG0x4ac
-#define RG_PE1_H_PLL_BRGENMASK(18, 16)
-#define RG_PE1_H_PLL_BR_VAL(x) ((0x7 & (x)) << 16)
-
-#defineRG_PE1_MSTCKDIV_REG 0x414
-#define RG_PE1_MSTCKDIVGENMASK(7, 6)
-#define RG_PE1_MSTCKDIV_VAL(x) ((0x3 & (x)) << 6)
-
-#define RG_PE1_FRC_MSTCKDIVBIT(5)
-
/**
* struct mt7621_pcie_port - PCIe port information
* @base: I/O mapped register base
* @list: port list
* @pcie: pointer to PCIe host info
- * @phy_reg_offset: offset to related phy registers
+ * @phy: pointer to PHY control block
* @pcie_rst: pointer to port reset control
* @slot: port slot
* @enabled: indicates if port is enabled
@@ -173,7 +110,7 @@ struct mt7621_pcie_port {
void __iomem *base;
struct list_head list;
struct mt7621_pcie *pcie;
- u32 phy_reg_offset;
+ struct phy *phy;
struct reset_control *pcie_rst;
u32 slot;
bool enabled;
@@ -265,150 +202,6 @@ static void write_config(struct mt7621_pcie *pcie,
unsigned int dev,
pcie_write(pcie, val, RALINK_PCI_CONFIG_DATA);
}
-static void bypass_pipe_rst(struct mt7621_pcie_port *port)
-{
- struct mt7621_pcie *pcie = port->pcie;
- u32 phy_offset = port->phy_reg_offset;
- u32 offset = (port->slot != 1) ?
- phy_offset + RG_PE1_PIPE_REG :
- phy_offset + RG_PE1_PIPE_REG + RG_P0_TO_P1_WIDTH;
- u32 reg = pcie_read(pcie, offset);
-
- reg &= ~(RG_PE1_PIPE_RST | RG_PE1_PIPE_CMD_FRC);
- reg |= (RG_PE1_PIPE_RST | RG_PE1_PIPE_CMD_FRC);
- pcie_write(pcie, reg, offset);
-}
-
-static void set_phy_for_ssc(struct mt7621_pcie_port *port)
-{
- struct mt7621_pcie *pcie = port->pcie;
- struct device *dev = pcie->dev;
- u32 phy_offset =
[PATCH v3 0/4] staging: mt7621-pci: extract PCI PHY part into a new 'pci-mt7621-phy' driver
There is a lot of code related with PHY part of the mt7621 PCI driver that can be extracted to a new PHY generic driver to do the same function. This patch series add a new 'mt7621-pci-phy' driver to handle those and updates the mt7621-pci driver code to use generic kernel's PHY API. This makes the code much better and readable. Device tree has been also updated with new related bindinds for the PCI PHY part. This changes are only compile-tested. Changes in v3: - Change '#phy-cells' to be zero instead of one avoiding to implement custom 'xlate' function in phy's driver. All of phy types for the phy driver are 'PHY_TYPE_PCIE' which is for that the '#phy-cells' was using for. There is no sense to check the type in a custom 'xlate' function. Phy's driver 'mt7621_pci_phy_xlate' has been deleted and now the generic 'of_phy_simple_xlate' is being used. - Update MODULE_LICENSE to use 'GPL v2' instead of 'GPL'. - Add kernel doc for phy's driver data structures. - Add a PATCH with DT bindings documentation. Changes in v2: - PATCH 1: remap registers first and assign virtual address after for each port because they share the same address space. Hope this helps. Thanks in advance. Best regards, Sergio Paracuellos Sergio Paracuellos (4): staging: mt7621-pci-phy: add new driver for phy part of mt7621-pci staging: mt7621-pci: handle phy using new generic phy 'pci-mt7621-phy' driver staging: mt7621-dts: add pci-phy related bindings to board's device tree staging: mt7621-pci-phy: dt-bindings: add bindings for Mediatek MT7621 Pcie PHY drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + drivers/staging/mt7621-dts/mt7621.dtsi| 31 ++ drivers/staging/mt7621-pci-phy/Kconfig| 7 + drivers/staging/mt7621-pci-phy/Makefile | 1 + drivers/staging/mt7621-pci-phy/TODO | 4 + .../mediatek,mt7621-pci-phy.txt | 54 +++ .../staging/mt7621-pci-phy/pci-mt7621-phy.c | 387 ++ drivers/staging/mt7621-pci/pci-mt7621.c | 250 ++- 9 files changed, 519 insertions(+), 218 deletions(-) create mode 100644 drivers/staging/mt7621-pci-phy/Kconfig create mode 100644 drivers/staging/mt7621-pci-phy/Makefile create mode 100644 drivers/staging/mt7621-pci-phy/TODO create mode 100644 drivers/staging/mt7621-pci-phy/mediatek,mt7621-pci-phy.txt create mode 100644 drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c -- 2.19.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/4] staging: mt7621-pci-phy: add new driver for phy part of mt7621-pci
Phy part of the pci for this SoC can be handled using a generic phy driver. This commit extracts phy part of the mt7621-pci into a new 'mt7621-pci-phy' driver. Signed-off-by: Sergio Paracuellos --- drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + drivers/staging/mt7621-pci-phy/Kconfig| 7 + drivers/staging/mt7621-pci-phy/Makefile | 1 + drivers/staging/mt7621-pci-phy/TODO | 4 + .../staging/mt7621-pci-phy/pci-mt7621-phy.c | 387 ++ 6 files changed, 402 insertions(+) create mode 100644 drivers/staging/mt7621-pci-phy/Kconfig create mode 100644 drivers/staging/mt7621-pci-phy/Makefile create mode 100644 drivers/staging/mt7621-pci-phy/TODO create mode 100644 drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index e4f608815c05..4a3d6e00f7cb 100644 --- a/drivers/staging/Kconfig +++ b/drivers/staging/Kconfig @@ -104,6 +104,8 @@ source "drivers/staging/pi433/Kconfig" source "drivers/staging/mt7621-pci/Kconfig" +source "drivers/staging/mt7621-pci-phy/Kconfig" + source "drivers/staging/mt7621-pinctrl/Kconfig" source "drivers/staging/mt7621-spi/Kconfig" diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 5868631e8f1b..413890dd5a14 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -42,6 +42,7 @@ obj-$(CONFIG_BCM2835_VCHIQ) += vc04_services/ obj-$(CONFIG_DRM_VBOXVIDEO)+= vboxvideo/ obj-$(CONFIG_PI433)+= pi433/ obj-$(CONFIG_SOC_MT7621) += mt7621-pci/ +obj-$(CONFIG_SOC_MT7621) += mt7621-pci-phy/ obj-$(CONFIG_SOC_MT7621) += mt7621-pinctrl/ obj-$(CONFIG_SOC_MT7621) += mt7621-spi/ obj-$(CONFIG_SOC_MT7621) += mt7621-dma/ diff --git a/drivers/staging/mt7621-pci-phy/Kconfig b/drivers/staging/mt7621-pci-phy/Kconfig new file mode 100644 index ..b9f6ab784ee8 --- /dev/null +++ b/drivers/staging/mt7621-pci-phy/Kconfig @@ -0,0 +1,7 @@ +config PCI_MT7621_PHY + tristate "MediaTek MT7621 PCI PHY Driver" + depends on RALINK && OF + select GENERIC_PHY + help + Say 'Y' here to add support for MediaTek MT7621 PCI PHY driver, + diff --git a/drivers/staging/mt7621-pci-phy/Makefile b/drivers/staging/mt7621-pci-phy/Makefile new file mode 100644 index ..2b82ccfc28c6 --- /dev/null +++ b/drivers/staging/mt7621-pci-phy/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_SOC_MT7621) += pci-mt7621-phy.o diff --git a/drivers/staging/mt7621-pci-phy/TODO b/drivers/staging/mt7621-pci-phy/TODO new file mode 100644 index ..a255e8f753eb --- /dev/null +++ b/drivers/staging/mt7621-pci-phy/TODO @@ -0,0 +1,4 @@ + +- general code review and cleanup + +Cc: NeilBrown and Sergio Paracuellos diff --git a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c new file mode 100644 index ..3d16716cfebc --- /dev/null +++ b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c @@ -0,0 +1,387 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Mediatek MT7621 PCI PHY Driver + * Author: Sergio Paracuellos + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define RALINK_CLKCFG1 0x30 +#define CHIP_REV_MT7621_E2 0x0101 + +#define PCIE_PORT_CLK_EN(x)BIT(24 + (x)) + +#define RG_PE1_PIPE_REG0x02c +#define RG_PE1_PIPE_RSTBIT(12) +#define RG_PE1_PIPE_CMD_FRCBIT(4) + +#define RG_P0_TO_P1_WIDTH 0x100 +#define RG_PE1_H_LCDDS_REG 0x49c +#define RG_PE1_H_LCDDS_PCW GENMASK(30, 0) +#define RG_PE1_H_LCDDS_PCW_VAL(x) ((0x7fff & (x)) << 0) + +#define RG_PE1_FRC_H_XTAL_REG 0x400 +#define RG_PE1_FRC_H_XTAL_TYPE BIT(8) +#define RG_PE1_H_XTAL_TYPE GENMASK(10, 9) +#define RG_PE1_H_XTAL_TYPE_VAL(x) ((0x3 & (x)) << 9) + +#define RG_PE1_FRC_PHY_REG 0x000 +#define RG_PE1_FRC_PHY_EN BIT(4) +#define RG_PE1_PHY_EN BIT(5) + +#define RG_PE1_H_PLL_REG 0x490 +#define RG_PE1_H_PLL_BCGENMASK(23, 22) +#define RG_PE1_H_PLL_BC_VAL(x) ((0x3 & (x)) << 22) +#define RG_PE1_H_PLL_BPGENMASK(21, 18) +#define RG_PE1_H_PLL_BP_VAL(x) ((0xf & (x)) << 18) +#define RG_PE1_H_PLL_IRGENMASK(15, 12) +#define RG_PE1_H_PLL_IR_VAL(x) ((0xf & (x)) << 12) +#define RG_PE1_H_PLL_ICGENMASK(11, 8) +#define RG_PE1_H_PLL_IC_VAL(x) ((0xf & (x)) << 8) +#define RG_PE1_H_PLL_PREDIV GENMASK(7, 6) +#define RG_PE1_H_PLL_PREDIV_VAL(x) ((0x3 & (x)) << 6) +#define RG_PE1_PLL_DIVEN GENMASK(3, 1) +#define RG_PE1_PLL_DIVEN_VAL(x)((0x7 & (x)) << 1) + +#define RG_PE1_H_PLL_FBKSEL_REG
Re: [PATCH] staging: android: ion: Add chunk heaps instantiation
On 1/2/19 10:28 PM, Alexey Skidanov wrote: On 1/3/19 12:37 AM, Laura Abbott wrote: On 12/20/18 1:29 PM, Alexey Skidanov wrote: On 12/20/18 10:36 PM, Laura Abbott wrote: On 12/16/18 2:46 AM, Alexey Skidanov wrote: Chunk heap instantiation should be supported for device tree platforms and non device tree platforms. For device tree platforms, it's a platform specific code responsibility to retrieve the heap configuration data and to call the appropriate API for heap creation. For non device tree platforms, there is no defined way to create the heaps. This patch provides the way of chunk heaps creation using "ion_chunk_heap=name:size@start" kernel boot parameter. I've been thinking about this and I think it works but I'm still kind of torn about not having devicetree bindings. It doesn't _preclude_ devicetree bindings but I'd hate to merge this and then end up with something incompatible. I do want to support non-Android use cases too. Sorry, what do you mean by non-Android cases? Any user of Ion that isn't tied to Android. This includes other userspace frameworks as well as non-devicetree targets. Sorry, don't follow you ... I tested the patch on Ubuntu machine - so the non-Android and non-devicetree case is obviously supported :) This patch _doesn't_ provide the required support for devicetree bindings and Android use case. I'm trying to balance wanting to support this use case with knowing that the Android use case is still unsolved. Laura ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: android: ion: add buffer flag update ioctl
On 1/3/19 5:42 PM, Zengtao (B) wrote: -Original Message- From: Laura Abbott [mailto:labb...@redhat.com] Sent: Thursday, January 03, 2019 6:31 AM To: Zengtao (B) ; sumit.sem...@linaro.org Cc: Greg Kroah-Hartman ; Arve Hjønnevåg ; Todd Kjos ; Martijn Coenen ; Joel Fernandes ; de...@driverdev.osuosl.org; dri-de...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH] staging: android: ion: add buffer flag update ioctl On 12/23/18 6:47 PM, Zengtao (B) wrote: Hi laura: -Original Message- From: Laura Abbott [mailto:labb...@redhat.com] Sent: Friday, December 21, 2018 4:50 AM To: Zengtao (B) ; sumit.sem...@linaro.org Cc: Greg Kroah-Hartman ; Arve Hjønnevåg ; Todd Kjos ; Martijn Coenen ; Joel Fernandes ; de...@driverdev.osuosl.org; dri-de...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH] staging: android: ion: add buffer flag update ioctl On 12/19/18 5:39 PM, Zengtao (B) wrote: Hi laura: -Original Message- From: Laura Abbott [mailto:labb...@redhat.com] Sent: Thursday, December 20, 2018 2:10 AM To: Zengtao (B) ; sumit.sem...@linaro.org Cc: Greg Kroah-Hartman ; Arve Hjønnevåg ; Todd Kjos ; Martijn Coenen ; Joel Fernandes ; de...@driverdev.osuosl.org; dri-de...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH] staging: android: ion: add buffer flag update ioctl On 12/19/18 9:19 AM, Zeng Tao wrote: In some usecases, the buffer cached attribute is not determined at allocation time, it's determined just before the real cpu mapping. And from the memory view of point, a buffer should not have the cached attribute util is really mapped by the cpu. So in this patch, we introduced the new ioctl command to target the requirement. This is racy and error prone. Can you explain more what problem you are trying to solve? My use case is like this: 1. There are two process A and B, A takes case of ion buffer allocation, and pass the buffer fd to B, then B maps and uses it. 2. Process B need to map the buffer with different cached attribute for different use case, for example, if the buffer is used for pure software algorithm, then we need to map it as cached, otherwise non-cached, and B needs to deal with both cases. And unfortunately the mmap syscall takes no cached flags and we can't decide the cache attribute when we are doing the mmap, so I introduce new the ioctl even though I think the solution is not as good. Thanks for the explanation, this was about the use case I expected. I'm pretty sure I had this exact problem once upon a time and we didn't come up with a solution. I'd still like to get rid of uncached buffers in general and just use cached buffers (see http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/201 8-N ovember/128842.html) What's your usecase for uncached buffers? Some buffers are only used by HW, in this case, we tend to use uncached buffers. But sometimes the SW need to read few buffer contents for debug purpose and no synchronization is needed. If this is primarily for debug, that's not really a compelling reason to support uncached buffers. It's incredibly difficult to do uncached buffers correctly I'd rather spend effort on making the cached use cases work better. No, not only for debug, I meant if the buffers are uncached, the SW will only mmap them for debug or even don't need to mmap them. So for the two kinds of buffers: 1. uncached: only the HW need to access it, the SW don't need to mmap it or just for debug. 2. cached: both the HW and the SW need to access it. The ION is designed as a generalized memory manager, I think we should cover as many requirements as we can in the ION design, so I 'd rather that we keep the uncached support. And I don’t quite understand the difficulty you mentioned to support the uncached buffers, would you explain a little more about it. We end up with aliasing problems. Each kernel page still has a cached mapping so it's very difficult to keep the two mappings in sync. https://lore.kernel.org/lkml/20181120164636.jcw7li2uaa3cmwc3@DESKTOP-E1NTVVP.localdomain/ This thread does a better job of explaining the problem and the objections to uncached buffers. And if the software never touches the buffer, why does it matter if the buffer is uncached? Laura Thanks Zengtao Signed-off-by: Zeng Tao --- drivers/staging/android/ion/ion-ioctl.c | 4 drivers/staging/android/ion/ion.c | 17 + drivers/staging/android/ion/ion.h | 1 + drivers/staging/android/uapi/ion.h | 22 ++ 4 files changed, 44 insertions(+) diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c index a8d3cc4..60bb702 100644 --- a/drivers/staging/android/ion/ion-ioctl.c +++ b/drivers/staging/android/ion/ion-ioctl.c @@
RE: [PATCH] staging: android: ion: add buffer flag update ioctl
>-Original Message- >From: Laura Abbott [mailto:labb...@redhat.com] >Sent: Thursday, January 03, 2019 6:31 AM >To: Zengtao (B) ; sumit.sem...@linaro.org >Cc: Greg Kroah-Hartman ; Arve Hjønnevåg >; Todd Kjos ; Martijn Coenen >; Joel Fernandes ; >de...@driverdev.osuosl.org; dri-de...@lists.freedesktop.org; >linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org >Subject: Re: [PATCH] staging: android: ion: add buffer flag update ioctl > >On 12/23/18 6:47 PM, Zengtao (B) wrote: >> Hi laura: >> >>> -Original Message- >>> From: Laura Abbott [mailto:labb...@redhat.com] >>> Sent: Friday, December 21, 2018 4:50 AM >>> To: Zengtao (B) ; >sumit.sem...@linaro.org >>> Cc: Greg Kroah-Hartman ; Arve >Hjønnevåg >>> ; Todd Kjos ; Martijn >Coenen >>> ; Joel Fernandes ; >>> de...@driverdev.osuosl.org; dri-de...@lists.freedesktop.org; >>> linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org >>> Subject: Re: [PATCH] staging: android: ion: add buffer flag update >>> ioctl >>> >>> On 12/19/18 5:39 PM, Zengtao (B) wrote: Hi laura: > -Original Message- > From: Laura Abbott [mailto:labb...@redhat.com] > Sent: Thursday, December 20, 2018 2:10 AM > To: Zengtao (B) ; >>> sumit.sem...@linaro.org > Cc: Greg Kroah-Hartman ; Arve >>> Hjønnevåg > ; Todd Kjos ; Martijn >>> Coenen > ; Joel Fernandes ; > de...@driverdev.osuosl.org; dri-de...@lists.freedesktop.org; > linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH] staging: android: ion: add buffer flag update > ioctl > > On 12/19/18 9:19 AM, Zeng Tao wrote: >> In some usecases, the buffer cached attribute is not determined at >> allocation time, it's determined just before the real cpu mapping. >> And from the memory view of point, a buffer should not have the > cached >> attribute util is really mapped by the cpu. So in this patch, we >> introduced the new ioctl command to target the requirement. >> > > This is racy and error prone. Can you explain more what problem >you > are trying to solve? My use case is like this: 1. There are two process A and B, A takes case of ion buffer allocation, >>> and pass the buffer fd to B, then B maps and uses it. 2. Process B need to map the buffer with different cached attribute for different use case, for example, if the buffer is used for pure software algorithm, then we need to map it as cached, otherwise non-cached, and B needs to deal with both cases. And unfortunately the mmap syscall takes no cached flags and we can't decide the cache attribute when we are doing the mmap, so I introduce new the ioctl even though I think the solution is not as >good. >>> >>> Thanks for the explanation, this was about the use case I expected. >>> I'm pretty sure I had this exact problem once upon a time and we >>> didn't come up with a solution. I'd still like to get rid of uncached >>> buffers in general and just use cached buffers (see >>> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/201 >>> 8-N >>> ovember/128842.html) >>> What's your usecase for uncached buffers? >> >> Some buffers are only used by HW, in this case, we tend to use >uncached buffers. >> But sometimes the SW need to read few buffer contents for debug >> purpose and no synchronization is needed. >> > >If this is primarily for debug, that's not really a compelling reason to >support uncached buffers. It's incredibly difficult to do uncached buffers >correctly I'd rather spend effort on making the cached use cases work >better. > No, not only for debug, I meant if the buffers are uncached, the SW will only mmap them for debug or even don't need to mmap them. So for the two kinds of buffers: 1. uncached: only the HW need to access it, the SW don't need to mmap it or just for debug. 2. cached: both the HW and the SW need to access it. The ION is designed as a generalized memory manager, I think we should cover as many requirements as we can in the ION design, so I 'd rather that we keep the uncached support. And I don’t quite understand the difficulty you mentioned to support the uncached buffers, would you explain a little more about it. Thanks Zengtao > >>> > >> Signed-off-by: Zeng Tao >> --- >> drivers/staging/android/ion/ion-ioctl.c | 4 >> drivers/staging/android/ion/ion.c | 17 >>> + >> drivers/staging/android/ion/ion.h | 1 + >> drivers/staging/android/uapi/ion.h | 22 > ++ >> 4 files changed, 44 insertions(+) >> >> diff --git a/drivers/staging/android/ion/ion-ioctl.c >> b/drivers/staging/android/ion/ion-ioctl.c >> index a8d3cc4..60bb702 100644 >> --- a/drivers/staging/android/ion/ion-ioctl.c >> +++ b/drivers/staging/android/ion/ion-ioctl.c >> @@ -12,6 +12,7 @@ >> >>
[driver-core:debugfs_cleanup 77/93] drivers/scsi/qla2xxx/qla_dfs.c:442:3: error: label 'out' used but not defined
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
debugfs_cleanup
head: b035e887993ae9ea01a16d9bad49c887557334f9
commit: c15a0efedf7dfa6eb6dd9e42244943d6bc4ab4e1 [77/93] scsi: qla2xxx: no need
to check return value of debugfs_create functions
config: x86_64-kexec (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout c15a0efedf7dfa6eb6dd9e42244943d6bc4ab4e1
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/scsi/qla2xxx/qla_dfs.c: In function 'qla2x00_dfs_setup':
>> drivers/scsi/qla2xxx/qla_dfs.c:442:3: error: label 'out' used but not defined
goto out;
^~~~
vim +/out +442 drivers/scsi/qla2xxx/qla_dfs.c
09620eeb6 Quinn Tran 2017-06-13 431
09620eeb6 Quinn Tran 2017-06-13 432
df613b960 Andrew Vasquez 2008-01-17 433 int
7b867cf76 Anirban Chakraborty 2008-11-06 434
qla2x00_dfs_setup(scsi_qla_host_t *vha)
df613b960 Andrew Vasquez 2008-01-17 435 {
7b867cf76 Anirban Chakraborty 2008-11-06 436 struct qla_hw_data *ha =
vha->hw;
3a03eb797 Andrew Vasquez 2009-01-05 437
f73cb695d Chad Dupuis 2014-02-26 438 if (!IS_QLA25XX(ha) &&
!IS_QLA81XX(ha) && !IS_QLA83XX(ha) &&
f73cb695d Chad Dupuis 2014-02-26 439 !IS_QLA27XX(ha))
df613b960 Andrew Vasquez 2008-01-17 440 goto out;
df613b960 Andrew Vasquez 2008-01-17 441 if (!ha->fce)
df613b960 Andrew Vasquez 2008-01-17 @442 goto out;
df613b960 Andrew Vasquez 2008-01-17 443
df613b960 Andrew Vasquez 2008-01-17 444 if (qla2x00_dfs_root)
df613b960 Andrew Vasquez 2008-01-17 445 goto create_dir;
df613b960 Andrew Vasquez 2008-01-17 446
df613b960 Andrew Vasquez 2008-01-17 447
atomic_set(_dfs_root_count, 0);
df613b960 Andrew Vasquez 2008-01-17 448 qla2x00_dfs_root =
debugfs_create_dir(QLA2XXX_DRIVER_NAME, NULL);
df613b960 Andrew Vasquez 2008-01-17 449
df613b960 Andrew Vasquez 2008-01-17 450 create_dir:
df613b960 Andrew Vasquez 2008-01-17 451 if (ha->dfs_dir)
df613b960 Andrew Vasquez 2008-01-17 452 goto create_nodes;
df613b960 Andrew Vasquez 2008-01-17 453
df613b960 Andrew Vasquez 2008-01-17 454 mutex_init(>fce_mutex);
7b867cf76 Anirban Chakraborty 2008-11-06 455 ha->dfs_dir =
debugfs_create_dir(vha->host_str, qla2x00_dfs_root);
df613b960 Andrew Vasquez 2008-01-17 456
df613b960 Andrew Vasquez 2008-01-17 457
atomic_inc(_dfs_root_count);
df613b960 Andrew Vasquez 2008-01-17 458
df613b960 Andrew Vasquez 2008-01-17 459 create_nodes:
03e8c680d Quinn Tran 2015-12-17 460 ha->dfs_fw_resource_cnt =
debugfs_create_file("fw_resource_count",
03e8c680d Quinn Tran 2015-12-17 461 S_IRUSR, ha->dfs_dir, vha,
_fw_resource_cnt_ops);
03e8c680d Quinn Tran 2015-12-17 462
ce1025cd4 Himanshu Madhani2015-12-17 463 ha->dfs_tgt_counters =
debugfs_create_file("tgt_counters", S_IRUSR,
ce1025cd4 Himanshu Madhani2015-12-17 464 ha->dfs_dir, vha,
_tgt_counters_ops);
ce1025cd4 Himanshu Madhani2015-12-17 465
c423437e3 Himanshu Madhani2017-03-15 466 ha->tgt.dfs_tgt_port_database =
debugfs_create_file("tgt_port_database",
c423437e3 Himanshu Madhani2017-03-15 467 S_IRUSR, ha->dfs_dir, vha,
_tgt_port_database_ops);
c423437e3 Himanshu Madhani2017-03-15 468
94279edec Giridhar Malavali 2009-03-24 469 ha->dfs_fce =
debugfs_create_file("fce", S_IRUSR, ha->dfs_dir, vha,
df613b960 Andrew Vasquez 2008-01-17 470 _fce_ops);
36c784528 Quinn Tran 2016-02-04 471
36c784528 Quinn Tran 2016-02-04 472 ha->tgt.dfs_tgt_sess =
debugfs_create_file("tgt_sess",
36c784528 Quinn Tran 2016-02-04 473 S_IRUSR, ha->dfs_dir,
vha, _tgt_sess_ops);
36c784528 Quinn Tran 2016-02-04 474
c15a0efed Greg Kroah-Hartman 2019-01-03 475 if (IS_QLA27XX(ha) ||
IS_QLA83XX(ha))
09620eeb6 Quinn Tran 2017-06-13 476 ha->tgt.dfs_naqp =
debugfs_create_file("naqp",
09620eeb6 Quinn Tran 2017-06-13 477 0400, ha->dfs_dir,
vha, _naqp_ops);
df613b960 Andrew Vasquez 2008-01-17 478 return 0;
df613b960 Andrew Vasquez 2008-01-17 479 }
df613b960 Andrew Vasquez 2008-01-17 480
:: The code at line 442 was first introduced by commit
:: df613b96077cee826b14089ae6e75eeabf71faa3 [SCSI] qla2xxx: Add Fibre
Channel Event (FCE) tracing support.
:: TO: Andrew Vasquez
:: CC: James Bottomley
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
[driver-core:debugfs_cleanup 70/70] sound/soc//codecs/wm_adsp.c:616:3: error: label 'err' used but not defined
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
debugfs_cleanup
head: ab2bf016efcd6603fab18068c1f3dd76f1389f7f
commit: ab2bf016efcd6603fab18068c1f3dd76f1389f7f [70/70] WIP: split up the
pieces...
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ab2bf016efcd6603fab18068c1f3dd76f1389f7f
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sh
All errors (new ones prefixed by >>):
sound/soc//codecs/wm_adsp.c: In function 'wm_adsp2_init_debugfs':
>> sound/soc//codecs/wm_adsp.c:616:3: error: label 'err' used but not defined
goto err;
^~~~
vim +/err +616 sound/soc//codecs/wm_adsp.c
f9f55e31f Richard Fitzgerald 2015-06-11 607
f9f55e31f Richard Fitzgerald 2015-06-11 608 static void
wm_adsp2_init_debugfs(struct wm_adsp *dsp,
0fe1daa66 Kuninori Morimoto 2018-02-13 609
struct snd_soc_component *component)
f9f55e31f Richard Fitzgerald 2015-06-11 610 {
f9f55e31f Richard Fitzgerald 2015-06-11 611struct dentry *root = NULL;
f9f55e31f Richard Fitzgerald 2015-06-11 612int i;
f9f55e31f Richard Fitzgerald 2015-06-11 613
0fe1daa66 Kuninori Morimoto 2018-02-13 614if (!component->debugfs_root) {
f9f55e31f Richard Fitzgerald 2015-06-11 615adsp_err(dsp, "No codec
debugfs root\n");
f9f55e31f Richard Fitzgerald 2015-06-11 @616goto err;
f9f55e31f Richard Fitzgerald 2015-06-11 617}
f9f55e31f Richard Fitzgerald 2015-06-11 618
605391d0f Richard Fitzgerald 2018-08-08 619root =
debugfs_create_dir(dsp->name, component->debugfs_root);
f9f55e31f Richard Fitzgerald 2015-06-11 620
ab2bf016e Greg Kroah-Hartman 2019-01-03 621debugfs_create_bool("booted",
0444, root, >booted);
ab2bf016e Greg Kroah-Hartman 2019-01-03 622debugfs_create_bool("running",
0444, root, >running);
ab2bf016e Greg Kroah-Hartman 2019-01-03 623debugfs_create_x32("fw_id",
0444, root, >fw_id);
ab2bf016e Greg Kroah-Hartman 2019-01-03 624
debugfs_create_x32("fw_version", 0444, root, >fw_id_version);
f9f55e31f Richard Fitzgerald 2015-06-11 625
ab2bf016e Greg Kroah-Hartman 2019-01-03 626for (i = 0; i <
ARRAY_SIZE(wm_adsp_debugfs_fops); ++i)
ab2bf016e Greg Kroah-Hartman 2019-01-03 627
debugfs_create_file(wm_adsp_debugfs_fops[i].name, 0444, root,
ab2bf016e Greg Kroah-Hartman 2019-01-03 628
dsp, _adsp_debugfs_fops[i].fops);
f9f55e31f Richard Fitzgerald 2015-06-11 629
f9f55e31f Richard Fitzgerald 2015-06-11 630dsp->debugfs_root = root;
f9f55e31f Richard Fitzgerald 2015-06-11 631 }
f9f55e31f Richard Fitzgerald 2015-06-11 632
:: The code at line 616 was first introduced by commit
:: f9f55e31f8a537b7eaccc4fdb243cff938fa428c ASoC: wm_adsp: Add basic
debugfs entries
:: TO: Richard Fitzgerald
:: CC: Mark Brown
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:debugfs_cleanup 67/70] drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected ';' before ')' token
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git debugfs_cleanup head: ab2bf016efcd6603fab18068c1f3dd76f1389f7f commit: 8cc1d21c4abb620671c8011ba78a17ad2430b93a [67/70] realtek: no need to check return value of debugfs_create functions config: sh-allmodconfig (attached as .config) compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 8cc1d21c4abb620671c8011ba78a17ad2430b93a # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=sh All errors (new ones prefixed by >>): drivers/net/wireless/realtek/rtlwifi/debug.c: In function 'rtl_debug_add_one': >> drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected ';' >> before ')' token _ops_ ##fopname)) \ ^ drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:489:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_0); ^~~ >> drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected >> statement before ')' token _ops_ ##fopname)) \ ^ drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:489:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_0); ^~~ >> drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected ';' >> before ')' token _ops_ ##fopname)) \ ^ drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:490:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_1); ^~~ >> drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected >> statement before ')' token _ops_ ##fopname)) \ ^ drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:490:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_1); ^~~ >> drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected ';' >> before ')' token _ops_ ##fopname)) \ ^ drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:491:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_2); ^~~ >> drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected >> statement before ')' token _ops_ ##fopname)) \ ^ drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:491:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_2); ^~~ >> drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected ';' >> before ')' token _ops_ ##fopname)) \ ^ drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:492:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_3); ^~~ >> drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected >> statement before ')' token _ops_ ##fopname)) \ ^ drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:492:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_3); ^~~ >> drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected ';'
Re: [PATCH v1 2/2] binderfs: reserve devices for initial mount
On Thu, Jan 03, 2019 at 01:47:13PM -0800, Todd Kjos wrote: > On Thu, Jan 3, 2019 at 12:34 PM Christian Brauner > wrote: > > > > On Thu, Jan 03, 2019 at 12:25:24PM -0800, Todd Kjos wrote: > > > On Sun, Dec 23, 2018 at 6:36 AM Christian Brauner > > > wrote: > > > > > > > > The binderfs instance in the initial ipc namespace will always have a > > > > reserve of 4 binder devices unless explicitly capped by specifying a > > > > lower > > > > value via the "max" mount option. > > > > This ensures when binder devices are removed (on accident or on purpose) > > > > they can always be recreated without risking that all minor numbers have > > > > already been used up. > > > > > > > > Cc: Todd Kjos > > > > Cc: Greg Kroah-Hartman > > > > Signed-off-by: Christian Brauner > > > > --- > > > > v1: > > > > - patch introduced > > > > v0: > > > > - patch not present > > > > --- > > > > drivers/android/binderfs.c | 7 ++- > > > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c > > > > index 873adda064ac..aa635c7ea727 100644 > > > > --- a/drivers/android/binderfs.c > > > > +++ b/drivers/android/binderfs.c > > > > @@ -40,6 +40,8 @@ > > > > #define INODE_OFFSET 3 > > > > #define INTSTRLEN 21 > > > > #define BINDERFS_MAX_MINOR (1U << MINORBITS) > > > > +/* Ensure that the initial ipc namespace always has a devices > > > > available. */ > > > > +#define BINDERFS_MAX_MINOR_CAPPED (BINDERFS_MAX_MINOR - 4) > > > > > > Why do you ever need more minors per instance than the number of > > > devices listed in CONFIG_ANDROID_BINDER_DEVICES? > > > > Are you asking asking why this is 4 and not 3? In that case we should > > probably parse CONFIG_ANDROID_BINDER_DEVICES once at init time and then > > reserve that many binder devices. Thoughts? > > I'm asking why CONFIG_ANDROID_BINDER_DEVICES isn't the source of truth > for the number of devices (it normally specifies 3 devices, but could > be different). I can't think of a reason why you'd want > CONFIG_MAX_MINOR_CAPPED to be different than the number of devices > indicated by CONFIG_ANDROID_BINDER_DEVICES and having it specified in > two places seems error prone. I'm not following. The CONFIG_MAX_MINOR_CAPPED and CONFIG_ANDROID_BINDER_DEVICES do not have a relation to each other just like binder devices requested in CONFIG_ANDROID_BINDER_DEVICES do not have a relation to binderfs binder devices as was requested for this patchset. I also don't know what you mean "appear in two places". The fact is, binderfs binder devices are independent of binderfs binder devices. So it is perfectly reasonable for someone to say CONFIG_ANDROID_BINDER_DEVICES="" and *only* rely on binderfs itself. Which absolutely need to be possible. What I want in such scenarios is that people always have a number of binderfs binder devices guaranteed to be available in the binderfs mount in the initial ipc namespace no matter how many devices are allocated in non-initial ipc namespace binderfs mounts. That's why allo non-initial ipc namespace binderfs mounts will use the CONFIG_MAX_MINOR_CAPPED macro which guarantees that there's number of devices reserved for the binderfs instance in the initial ipc namespace. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:debugfs_cleanup 67/70] drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of macro 'RTL_DEBUGFS_ADD_CORE'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git debugfs_cleanup head: ab2bf016efcd6603fab18068c1f3dd76f1389f7f commit: 8cc1d21c4abb620671c8011ba78a17ad2430b93a [67/70] realtek: no need to check return value of debugfs_create functions config: sh-allmodconfig (attached as .config) compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 8cc1d21c4abb620671c8011ba78a17ad2430b93a # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=sh All warnings (new ones prefixed by >>): drivers/net/wireless/realtek/rtlwifi/debug.c: In function 'rtl_debug_add_one': drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected ';' before ')' token _ops_ ##fopname)) \ ^ >> drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of >> macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ >> drivers/net/wireless/realtek/rtlwifi/debug.c:489:2: note: in expansion of >> macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_0); ^~~ drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected statement before ')' token _ops_ ##fopname)) \ ^ >> drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of >> macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ >> drivers/net/wireless/realtek/rtlwifi/debug.c:489:2: note: in expansion of >> macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_0); ^~~ drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected ';' before ')' token _ops_ ##fopname)) \ ^ >> drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of >> macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:490:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_1); ^~~ drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected statement before ')' token _ops_ ##fopname)) \ ^ >> drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of >> macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:490:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_1); ^~~ drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected ';' before ')' token _ops_ ##fopname)) \ ^ >> drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of >> macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:491:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_2); ^~~ drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected statement before ')' token _ops_ ##fopname)) \ ^ >> drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of >> macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:491:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_2); ^~~ drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected ';' before ')' token _ops_ ##fopname)) \ ^ >> drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of >> macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:492:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_3); ^~~ drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error: expected statement before ')' token _ops_ ##fopname)) \ ^ >> drivers/net/wireless/realtek/rtlwifi/debug.c:472:3: note: in expansion of >> macro 'RTL_DEBUGFS_ADD_CORE' RTL_DEBUGFS_ADD_CORE(name, S_IFREG | 0444, common) ^~~~ drivers/net/wireless/realtek/rtlwifi/debug.c:492:2: note: in expansion of macro 'RTL_DEBUGFS_ADD' RTL_DEBUGFS_ADD(mac_3); ^~~ drivers/net/wireless/realtek/rtlwifi/debug.c:468:30: error:
Re: [PATCH v1 2/2] binderfs: reserve devices for initial mount
On Thu, Jan 03, 2019 at 12:25:24PM -0800, Todd Kjos wrote: > On Sun, Dec 23, 2018 at 6:36 AM Christian Brauner > wrote: > > > > The binderfs instance in the initial ipc namespace will always have a > > reserve of 4 binder devices unless explicitly capped by specifying a lower > > value via the "max" mount option. > > This ensures when binder devices are removed (on accident or on purpose) > > they can always be recreated without risking that all minor numbers have > > already been used up. > > > > Cc: Todd Kjos > > Cc: Greg Kroah-Hartman > > Signed-off-by: Christian Brauner > > --- > > v1: > > - patch introduced > > v0: > > - patch not present > > --- > > drivers/android/binderfs.c | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c > > index 873adda064ac..aa635c7ea727 100644 > > --- a/drivers/android/binderfs.c > > +++ b/drivers/android/binderfs.c > > @@ -40,6 +40,8 @@ > > #define INODE_OFFSET 3 > > #define INTSTRLEN 21 > > #define BINDERFS_MAX_MINOR (1U << MINORBITS) > > +/* Ensure that the initial ipc namespace always has a devices available. */ > > +#define BINDERFS_MAX_MINOR_CAPPED (BINDERFS_MAX_MINOR - 4) > > Why do you ever need more minors per instance than the number of > devices listed in CONFIG_ANDROID_BINDER_DEVICES? Are you asking asking why this is 4 and not 3? In that case we should probably parse CONFIG_ANDROID_BINDER_DEVICES once at init time and then reserve that many binder devices. Thoughts? Christian ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 2/2] binderfs: reserve devices for initial mount
On Sun, Dec 23, 2018 at 6:36 AM Christian Brauner wrote: > > The binderfs instance in the initial ipc namespace will always have a > reserve of 4 binder devices unless explicitly capped by specifying a lower > value via the "max" mount option. > This ensures when binder devices are removed (on accident or on purpose) > they can always be recreated without risking that all minor numbers have > already been used up. > > Cc: Todd Kjos > Cc: Greg Kroah-Hartman > Signed-off-by: Christian Brauner > --- > v1: > - patch introduced > v0: > - patch not present > --- > drivers/android/binderfs.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c > index 873adda064ac..aa635c7ea727 100644 > --- a/drivers/android/binderfs.c > +++ b/drivers/android/binderfs.c > @@ -40,6 +40,8 @@ > #define INODE_OFFSET 3 > #define INTSTRLEN 21 > #define BINDERFS_MAX_MINOR (1U << MINORBITS) > +/* Ensure that the initial ipc namespace always has a devices available. */ > +#define BINDERFS_MAX_MINOR_CAPPED (BINDERFS_MAX_MINOR - 4) Why do you ever need more minors per instance than the number of devices listed in CONFIG_ANDROID_BINDER_DEVICES? > > static struct vfsmount *binderfs_mnt; > > @@ -129,11 +131,14 @@ static int binderfs_binder_device_create(struct inode > *ref_inode, > struct inode *inode = NULL; > struct super_block *sb = ref_inode->i_sb; > struct binderfs_info *info = sb->s_fs_info; > + bool use_reserve = (info->ipc_ns == _ipc_ns); > > /* Reserve new minor number for the new device. */ > mutex_lock(_minors_mutex); > if (++info->device_count <= info->mount_opts.max) > - minor = ida_alloc_max(_minors, BINDERFS_MAX_MINOR, > + minor = ida_alloc_max(_minors, > + use_reserve ? BINDERFS_MAX_MINOR : > + BINDERFS_MAX_MINOR_CAPPED, > GFP_KERNEL); > else > minor = -ENOSPC; > -- > 2.19.1 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[driver-core:debugfs_cleanup 51/61] drivers/opp/debugfs.c:66:9: warning: 'return' with a value, in function returning void
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
debugfs_cleanup
head: d8de692bccca02a757f4d4c2de9805b561497014
commit: 19410727eb72c71fd3c6c0398e3e8e8ac236f696 [51/61] opp: no need to check
return value of debugfs_create functions
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 19410727eb72c71fd3c6c0398e3e8e8ac236f696
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sh
All warnings (new ones prefixed by >>):
drivers/opp/debugfs.c: In function 'opp_debug_create_supplies':
>> drivers/opp/debugfs.c:66:9: warning: 'return' with a value, in function
>> returning void
return true;
^~~~
drivers/opp/debugfs.c:38:13: note: declared here
static void opp_debug_create_supplies(struct dev_pm_opp *opp,
^
drivers/opp/debugfs.c: In function 'opp_list_debug_create_link':
drivers/opp/debugfs.c:123:23: warning: unused variable 'dev'
[-Wunused-variable]
const struct device *dev = opp_dev->dev;
^~~
vim +/return +66 drivers/opp/debugfs.c
deaa5146 drivers/base/power/opp/debugfs.c Viresh Kumar 2015-11-11 37
19410727 drivers/opp/debugfs.cGreg Kroah-Hartman 2019-01-03 38
static void opp_debug_create_supplies(struct dev_pm_opp *opp,
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 39
struct opp_table *opp_table,
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 40
struct dentry *pdentry)
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 41 {
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 42
struct dentry *d;
1fae788e drivers/base/power/opp/debugfs.c Viresh Kumar 2017-05-23 43
int i;
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 44
1fae788e drivers/base/power/opp/debugfs.c Viresh Kumar 2017-05-23 45
for (i = 0; i < opp_table->regulator_count; i++) {
d741029a drivers/opp/debugfs.cArvind Yadav 2017-09-21 46
char name[15];
d741029a drivers/opp/debugfs.cArvind Yadav 2017-09-21 47
d741029a drivers/opp/debugfs.cArvind Yadav 2017-09-21 48
snprintf(name, sizeof(name), "supply-%d", i);
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 49
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 50
/* Create per-opp directory */
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 51
d = debugfs_create_dir(name, pdentry);
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 52
19410727 drivers/opp/debugfs.cGreg Kroah-Hartman 2019-01-03 53
debugfs_create_ulong("u_volt_target", S_IRUGO, d,
19410727 drivers/opp/debugfs.cGreg Kroah-Hartman 2019-01-03 54
>supplies[i].u_volt);
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 55
19410727 drivers/opp/debugfs.cGreg Kroah-Hartman 2019-01-03 56
debugfs_create_ulong("u_volt_min", S_IRUGO, d,
19410727 drivers/opp/debugfs.cGreg Kroah-Hartman 2019-01-03 57
>supplies[i].u_volt_min);
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 58
19410727 drivers/opp/debugfs.cGreg Kroah-Hartman 2019-01-03 59
debugfs_create_ulong("u_volt_max", S_IRUGO, d,
19410727 drivers/opp/debugfs.cGreg Kroah-Hartman 2019-01-03 60
>supplies[i].u_volt_max);
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 61
19410727 drivers/opp/debugfs.cGreg Kroah-Hartman 2019-01-03 62
debugfs_create_ulong("u_amp", S_IRUGO, d,
19410727 drivers/opp/debugfs.cGreg Kroah-Hartman 2019-01-03 63
>supplies[i].u_amp);
1fae788e drivers/base/power/opp/debugfs.c Viresh Kumar 2017-05-23 64
}
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 65
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 @66
return true;
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 67 }
dfbe4678 drivers/base/power/opp/debugfs.c Viresh Kumar 2016-12-01 68
:: The code at line 66 was first introduced by commit
:: dfbe4678d709e25e0f36e6b6333e2a7a67aefb7e PM / OPP: Add infrastructure to
manage multiple regulators
:: TO: Viresh Kumar
:: CC: Rafael J. Wysocki
---
0-DAY
[PATCH] staging: wilc1000: define wilc_get_stats_async as static
Declare wilc_get_stats_async as static since it's only
used within the definition file scope.
Signed-off-by: Juan Manuel Torres Palma
---
drivers/staging/wilc1000/host_interface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index 70c854d939ce..5dae6e7155d3 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1992,7 +1992,7 @@ int wilc_get_rssi(struct wilc_vif *vif, s8 *rssi_level)
return result;
}
-int wilc_get_stats_async(struct wilc_vif *vif, struct rf_info *stats)
+static int wilc_get_stats_async(struct wilc_vif *vif, struct rf_info *stats)
{
int result;
struct host_if_msg *msg;
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] binderfs: implement "max" mount option
On Wed, Jan 2, 2019 at 12:32 PM Christian Brauner wrote: > > Since binderfs can be mounted by userns root in non-initial user namespaces > some precautions are in order. First, a way to set a maximum on the number > of binder devices that can be allocated per binderfs instance and second, a > way to reserve a reasonable chunk of binderfs devices for the initial ipc > namespace. > A first approach as seen in [1] used sysctls similiar to devpts but was > shown to be flawed (cf. [2] and [3]) since some aspects were unneeded. This > is an alternative approach which avoids sysctls completely and instead > switches to a single mount option. > > Starting with this commit binderfs instances can be mounted with a limit on > the number of binder devices that can be allocated. The max= mount > option serves as a per-instance limit. If max= is set then only > number of binder devices can be allocated in this binderfs > instance. > > This allows to safely bind-mount binderfs instances into unprivileged user > namespaces since userns root in a non-initial user namespace cannot change > the mount option as long as it does not own the mount namespace the > binderfs mount was created in and hence cannot drain the host of minor > device numbers > > [1]: https://lore.kernel.org/lkml/20181221133909.18794-1-christ...@brauner.io/ > [2]; https://lore.kernel.org/lkml/20181221163316.ga8...@kroah.com/ > [3]: > https://lore.kernel.org/lkml/cahrssex+gdvw4fkkk8oznair9g5icjlyodo8hykv3o0o1jt...@mail.gmail.com/ > [4]: https://lore.kernel.org/lkml/20181221192044.5yvfnuri7gdop...@brauner.io/ > > Cc: Todd Kjos > Cc: Greg Kroah-Hartman > Signed-off-by: Christian Brauner Fwiw, once this lands I intend to add a binderfs.txt file to Documentation/filesystems so that we have proper documentation too. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Editing photos 112
Do you have photos for editing? We have 20 image editors and we can edit your photos. Please send us a photo with instruction and we will work on it. Services like: Photos cut out Image retouching Color correction. Beauty retouching, skin retouching. We do unlimited revisions until you are satisfied with the work. Thanks, Jenny Young ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 3/3] staging: mt7621-dts: add pci-phy related bindings to board's device tree
Hi Neil,
On Thu, Jan 3, 2019 at 7:40 AM Sergio Paracuellos
wrote:
>
> On Thu, Jan 3, 2019 at 6:15 AM NeilBrown wrote:
> >
> > On Mon, Dec 24 2018, Sergio Paracuellos wrote:
> >
> > > New driver for pci phy has been added, as well as. pci driver has been
> > > changed to use kernel's generic PHY API. Add related PCI PHY bindings
> > > accordly.
> > >
> > > Signed-off-by: Sergio Paracuellos
> > > ---
> > > drivers/staging/mt7621-dts/mt7621.dtsi | 40 ++
> > > 1 file changed, 40 insertions(+)
> > >
> > > diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
> > > b/drivers/staging/mt7621-dts/mt7621.dtsi
> > > index 71f069d59ad8..60ddfb7699b0 100644
> > > --- a/drivers/staging/mt7621-dts/mt7621.dtsi
> > > +++ b/drivers/staging/mt7621-dts/mt7621.dtsi
> > > @@ -424,6 +424,10 @@
> > > reset-names = "pcie0", "pcie1", "pcie2";
> > > clocks = < 24 25 26>;
> > > clock-names = "pcie0", "pcie1", "pcie2";
> > > + phys = <_port PHY_TYPE_PCIE>,
> > > +<_port PHY_TYPE_PCIE>,
> > > +<_port PHY_TYPE_PCIE>;
> >
> > This doesn't compile - PHY_TYPE_PCIE is unknown.
> > If I add
> > #include
>
> It seems that my device tree is not being compiled with the rest of
> the kernel tree which is weird, so sorry
> for this. I though it was being compiling correctly.
So I fixed this. I don't know why but in some moment
'CONFIG_DTB_GNUBEE1' disappeared from my config. Now it is ok again.
Thanks and sorry for inconvenience.
>
> >
> > it gets further.
> >
> >
> > > + phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
> > >
> > > pcie@0,0 {
> > > reg = <0x 0 0 0 0>;
> > > @@ -449,4 +453,40 @@
> > > bus-range = <0x00 0xff>;
> > > };
> > > };
> > > +
> > > + pcie0_phy: pcie-phy@1a149000 {
> > > + compatible = "mediatek,mt7621-pci-phy";
> > > + reg = <0x1a149000 0x0700>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> >
> > This causes warning
> > drivers/staging/mt7621-dts/gbpc1.dtb: Warning (ranges_format):
> > /pcie-phy@1a149000:ranges: empty "ranges" property but its #size-cells (0)
> > differs from / (1)
> > drivers/staging/mt7621-dts/gbpc1.dtb: Warning (ranges_format):
> > /pcie-phy@1a14a000:ranges: empty "ranges" property but its #size-cells (0)
> > differs from / (1)
Actually I think there is no real need for 'ranges' property here. So
the following patch should cleanly compile and gets the DT for the pci
phy to a very minimum one:
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index a63b84015814..a2754f016b4d 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -1,4 +1,5 @@
#include
+#include
/ {
#address-cells = <1>;
@@ -459,19 +460,15 @@
reg = <0x1a149000 0x0700>;
#address-cells = <1>;
#size-cells = <0>;
- ranges;
- status = "disabled";
pcie0_port: pcie-phy@0 {
reg = <0>;
#phy-cells = <1>;
- status = "okay";
};
pcie1_port: pcie-phy@1 {
reg = <1>;
#phy-cells = <1>;
- status = "okay";
};
};
@@ -480,13 +477,10 @@
reg = <0x1a14a000 0x0700>;
#address-cells = <1>;
#size-cells = <0>;
- ranges;
- status = "disabled";
pcie2_port: pcie-phy@0 {
reg = <0>;
#phy-cells = <1>;
- status = "okay";
};
};
> >
> > Whether I leave it as <0>, or change it to <1>, booting results in
> >
> > [0.600602] mt7621-pci 1e14.pcie: Parsing DT failed
>
> Uhmmm... The only place this can fail is getting the phy here (from
> PATCH 2) but the code seems to be correct:
>
> + snprintf(name, sizeof(name), "pcie-phy%d", slot);
> + port->phy = devm_phy_get(dev, name);
> + if (IS_ERR(port->phy))
> + return PTR_ERR(port->phy);
> +
>
> So it seems this is getting wrong stuff from DT... I'll check the DT
> warnings to check if could or not be related.
I reviewed the code and I think it should work.
Is the phy driver being loaded properly? Is any trace for the pci-phy
part in the log that put me in the way of what to check for
correctness?
Thanks in advance.
Best regards,
Sergio Paracuellos
>
> >
> > I haven't tried to dig into why it fails.
> >
> > Thanks,
> > NeilBrown
>
> Thanks for testing this.
>
> Best regards,
> Sergio Paracuellos
> >
> >
> > > + ranges;
> > > + status = "disabled";
> > > +
> > > + pcie0_port: pcie-phy@0 {
> > > +
Re: [PATCH 0/2] staging: mt7621-pinctrl: use pinconf-generic in some driver ops
On Thu, Jan 3, 2019 at 3:02 AM NeilBrown wrote: > > On Mon, Dec 31 2018, Sergio Paracuellos wrote: > > > dt_node_to_map and dt_free_map operations can use pinconf-generic API's > > instead of redefine operations in the driver. Make use of them cleaning > > a bit driver's code. > > > > Update DT accordly to make sure used bindings property in code match > > with the board's DT bindings. > > > > Changes are only compile-tested. > > Thanks. This appears to work for me. > It is awkward to test pinctrl changes because the firmware preconfigures > all the pins, so the hardware will work correctly if pinctrl does > nothing. > So I change the dts file to mis-configure some pins for driving LEDs, > and checked that the LEDs broken. The fixed the dts, and the LEDs > started working again. > I think that will have to do. > > Tested-by: NeilBrown > > Thanks, > NeilBrown Cool! Thanks for testing and let me know. So, I sent this patch which solves a problem: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-December/130260.html And this new patch is generated with that applied. Also this patch solves the original problem also and seems the way to go... Should be better to re-do this one with all the fixed and reported by tags added as a solution? What do you prefer, Greg? Thanks in advance. Best regards, Sergio Paracuellos > > > > > > Hope this helps. > > > > Best regards, > > Sergio Paracuellos > > > > Sergio Paracuellos (2): > > staging: mt7621-pinctrl: use pinconf-generic for 'dt_node_to_map' and > > 'dt_free_map' > > staging: mt7621-dts: use standard 'groups' instead of 'group' for > > pinctrl bindings > > > > drivers/staging/mt7621-dts/gbpc1.dts | 4 +- > > drivers/staging/mt7621-dts/mt7621.dtsi| 24 +-- > > drivers/staging/mt7621-pinctrl/Kconfig| 1 + > > .../staging/mt7621-pinctrl/pinctrl-rt2880.c | 42 ++- > > 4 files changed, 18 insertions(+), 53 deletions(-) > > > > -- > > 2.19.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
