Re: [PATCH -next] drm/virtio: Make virtgpu_dmabuf_ops with static keyword
On Sat, Nov 14, 2020 at 03:16:13PM +0800, Zou Wei wrote: > Fix the following sparse warning: > > ./virtgpu_prime.c:46:33: warning: symbol 'virtgpu_dmabuf_ops' was not > declared. Should it be static? Pushed to drm-misc-next. thanks, Gerd
[PATCH 2/4] dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B
From: Chen-Yu Tsai The NanoPi M4B is a minor revision of the original M4. The differences against the original Nanopi M4 that are common with the other M4V2 revision include: - microphone header removed - power button added - recovery button added Additional changes specific to the M4B: - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x USB 2.0 ports - ADB toggle switch added; this changes the top USB 3.0 host port to a peripheral port - Type-C port no longer supports data or PD - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 but only 1T1R (down from 2T2R) for WiFi Add a compatible string for the new board revision. Signed-off-by: Chen-Yu Tsai --- Documentation/devicetree/bindings/arm/rockchip.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 37fd456170d2..1c0ec57ba860 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -126,6 +126,7 @@ properties: - enum: - friendlyarm,nanopc-t4 - friendlyarm,nanopi-m4 + - friendlyarm,nanopi-m4b - friendlyarm,nanopi-neo4 - const: rockchip,rk3399 -- 2.29.1
[PATCH 1/4] PCI: rockchip: make ep_gpio optional
From: Chen-Yu Tsai
The Rockchip PCIe controller DT binding clearly states that ep-gpios is
an optional property. And indeed there are boards that don't require it.
Make the driver follow the binding by using devm_gpiod_get_optional()
instead of devm_gpiod_get().
Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
Fixes: 956cd99b35a8 ("PCI: rockchip: Separate common code from RC driver")
Fixes: 964bac9455be ("PCI: rockchip: Split out rockchip_pcie_parse_dt() to
parse DT")
Signed-off-by: Chen-Yu Tsai
---
drivers/pci/controller/pcie-rockchip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pcie-rockchip.c
b/drivers/pci/controller/pcie-rockchip.c
index 904dec0d3a88..c95950e9004f 100644
--- a/drivers/pci/controller/pcie-rockchip.c
+++ b/drivers/pci/controller/pcie-rockchip.c
@@ -118,7 +118,7 @@ int rockchip_pcie_parse_dt(struct rockchip_pcie *rockchip)
}
if (rockchip->is_rc) {
- rockchip->ep_gpio = devm_gpiod_get(dev, "ep", GPIOD_OUT_HIGH);
+ rockchip->ep_gpio = devm_gpiod_get_optional(dev, "ep",
GPIOD_OUT_HIGH);
if (IS_ERR(rockchip->ep_gpio)) {
dev_err(dev, "missing ep-gpios property in node\n");
return PTR_ERR(rockchip->ep_gpio);
--
2.29.1
[PATCH 0/4] arm64: rockchip: Fix PCIe ep-gpios requirement and Add Nanopi M4B
From: Chen-Yu Tsai Hi everyone, This series mainly adds support for the new Nanopi M4B, which is a newer variant of the Nanopi M4. The differences against the original Nanopi M4 that are common with the other M4V2 revision include: - microphone header removed - power button added - recovery button added Additional changes specific to the M4B: - USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x USB 2.0 ports - ADB toggle switch added; this changes the top USB 3.0 host port to a peripheral port - Type-C port no longer supports data or PD - WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0 but only 1T1R (down from 2T2R) for WiFi While working on this, I found that for the M4 family, the PCIe reset pin (from the M.2 expansion board) was not wired to the SoC. Only the NanoPC T4 has this wired. This ended up in patches 1 and 3. Patch 1 makes ep_gpio in the Rockchip PCIe driver optional. This property is optional in the DT binding, so this just makes the driver adhere to the binding. Patch 2 adds a new compatible string for the new board. Patch 3 moves the ep-gpios property of the pcie controller from the common nanopi4.dtsi file to the nanopc-t4.dts file. Patch 4 adds a new device tree file for the new board. It includes the original device tree for the M4, and then lists the differences. Given that patch 3 would make PCIe unusable without patch 1, I suggest merging patch 1 through the PCI tree as a fix for 5.10, and the rest for 5.11 through the Rockchip tree. Please have a look. The changes are mostly trivial. Regards ChenYu Chen-Yu Tsai (4): PCI: rockchip: make ep_gpio optional dt-bindings: arm: rockchip: Add FriendlyARM NanoPi M4B arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4 arm64: dts: rockchip: rk3399: Add NanoPi M4B .../devicetree/bindings/arm/rockchip.yaml | 1 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3399-nanopc-t4.dts| 1 + .../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++ .../boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 - drivers/pci/controller/pcie-rockchip.c| 2 +- 6 files changed, 56 insertions(+), 2 deletions(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts -- 2.29.1
[PATCH 4/4] arm64: dts: rockchip: rk3399: Add NanoPi M4B
From: Chen-Yu Tsai
The NanoPi M4B is a minor revision of the original M4.
The differences against the original Nanopi M4 that are common with the
other M4V2 revision include:
- microphone header removed
- power button added
- recovery button added
Additional changes specific to the M4B:
- USB 3.0 hub removed; board now has 2x USB 3.0 type-A ports and 2x
USB 2.0 ports
- ADB toggle switch added; this changes the top USB 3.0 host port to
a peripheral port
- Type-C port no longer supports data or PD
- WiFi/Bluetooth combo chip switched to AP6256, which supports BT 5.0
but only 1T1R (down from 2T2R) for WiFi
Add a new dts file for the new board revision that shows the difference
against the original.
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3399-nanopi-m4b.dts | 52 +++
2 files changed, 53 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 5a53979b7057..fd47414e40eb 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-kobol-helios64.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-pinebook-pro.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
new file mode 100644
index ..72182c58cc46
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-m4b.dts
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec NanoPi M4B board device tree source
+ *
+ * Copyright (c) 2020 Chen-Yu Tsai
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi-m4.dts"
+
+/ {
+ model = "FriendlyElec NanoPi M4B";
+ compatible = "friendlyarm,nanopi-m4b", "rockchip,rk3399";
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <150>;
+ poll-interval = <100>;
+
+ recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <18000>;
+ };
+ };
+};
+
+/* No USB type-C PD power manager */
+/delete-node/ &fusb0;
+
+&i2c4 {
+ status = "disabled";
+};
+
+&u2phy0_host {
+ phy-supply = <&vcc5v0_usb2>;
+};
+
+&u2phy0_otg {
+ phy-supply = <&vbus_typec>;
+};
+
+&u2phy1_otg {
+ phy-supply = <&vcc5v0_usb1>;
+};
+
+&vbus_typec {
+ enable-active-high;
+ gpios = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
+};
--
2.29.1
Re: drivers/net/wireless/ath/ath10k/sdio.c:2234:2: warning: Non-boolean value returned from function returning bool
+ ath10k list kernel test robot writes: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: f01c30de86f1047e9bae1b1b1417b0ce8dcd15b1 > commit: 3c45f21af84eb05a355919abc80cf70a3a681cee ath10k: sdio: add > firmware coredump support > compiler: nios2-linux-gcc (GCC) 9.3.0 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > > cppcheck possible warnings: (new ones prefixed by >>, may not real problems) > >>> drivers/net/wireless/ath/ath10k/sdio.c:2234:2: warning: Non-boolean > value returned from function returning bool > [returnNonBoolInBooleanFunction] > return param & HI_OPTION_SDIO_CRASH_DUMP_ENHANCEMENT_FW; > ^ Is this really a problem? I guess we could change that to "!!(param & HI_OPTION_SDIO_CRASH_DUMP_ENHANCEMENT_FW)" but how is that better and does it make any practical difference when ath10k_sdio_is_fast_dump_supported() returns a boolean anyway? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH 3/4] arm64: dts: rockchip: nanopi4: Move ep-gpios property to nanopc-t4
From: Chen-Yu Tsai
Only the NanoPC T4 hs the PCIe reset pin routed to the SoC. For the
NanoPi M4 family, no such signal is routed to the expansion header on
the base board.
As the schematics for the expansion board were not released, it is
unclear how this is handled, but the likely answer is that the signal
is always pulled high.
Move the ep-gpios property from the common nanopi4.dtsi file to the
board level nanopc-t4.dts file. This makes the nanopi-m4 lack ep-gpios,
matching the board design.
A companion patch "PCI: rockchip: make ep_gpio optional" for the Linux
driver is required, as the driver currently requires the property to be
present.
Fixes: e7a095908227 ("arm64: dts: rockchip: Add devicetree for NanoPC-T4")
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts | 1 +
arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
index e0d75617bb7e..452728b82e42 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopc-t4.dts
@@ -95,6 +95,7 @@ map3 {
};
&pcie0 {
+ ep-gpios = <&gpio2 RK_PA4 GPIO_ACTIVE_HIGH>;
num-lanes = <4>;
vpcie3v3-supply = <&vcc3v3_sys>;
};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
index 76a8b40a93c6..48ed4aaa37f3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
@@ -504,7 +504,6 @@ &pcie_phy {
};
&pcie0 {
- ep-gpios = <&gpio2 RK_PA4 GPIO_ACTIVE_HIGH>;
max-link-speed = <2>;
num-lanes = <2>;
vpcie0v9-supply = <&vcca0v9_s3>;
--
2.29.1
Re: [PATCH 0/2] phy: qualcomm: usb: Fix two COMPILE_TEST errors
On 13-11-20, 15:12, Bryan O'Donoghue wrote: > kernel build robot fired this email at me about an hour ago > https://lkml.org/lkml/2020/11/13/414 > > The build robot has flagged the super-speed PHY driver but both Kconfig > entries have the same error. Fix those now. > > verified with "make menuconfig ARCH=s390" Applied, thanks -- ~Vinod
RE: [PATCH] mmc: sdhci-of-arasan: Allow configuring zero tap values
Hi,
> -Original Message-
> From: Manish Narani
> Sent: Tuesday, November 10, 2020 11:12 PM
> To: Michal Simek ; adrian.hun...@intel.com;
> ulf.hans...@linaro.org
> Cc: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; git ; Manish Narani
> ; Sai Krishna Potthuri
> Subject: [PATCH] mmc: sdhci-of-arasan: Allow configuring zero tap values
>
> Allow configuring the Output and Input tap values with zero to avoid
> failures in some cases (one of them is SD boot mode) where the output
> and input tap values may be already set to non-zero.
>
Fixes: a5c8b2ae2e51 ("mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap
Delays Setup")
> Signed-off-by: Sai Krishna Potthuri
> Signed-off-by: Manish Narani
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 40 ++
> 1 file changed, 8 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-
> of-arasan.c
> index 829ccef87426..100621e55427 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -600,14 +600,8 @@ static int sdhci_zynqmp_sdcardclk_set_phase(struct
> clk_hw *hw, int degrees)
> u8 tap_delay, tap_max = 0;
> int ret;
>
> - /*
> - * This is applicable for SDHCI_SPEC_300 and above
> - * ZynqMP does not set phase for <=25MHz clock.
> - * If degrees is zero, no need to do anything.
> - */
> - if (host->version < SDHCI_SPEC_300 ||
> - host->timing == MMC_TIMING_LEGACY ||
> - host->timing == MMC_TIMING_UHS_SDR12 || !degrees)
> + /* This is applicable for SDHCI_SPEC_300 and above */
> + if (host->version < SDHCI_SPEC_300)
> return 0;
>
> switch (host->timing) {
> @@ -668,14 +662,8 @@ static int
> sdhci_zynqmp_sampleclk_set_phase(struct clk_hw *hw, int degrees)
> u8 tap_delay, tap_max = 0;
> int ret;
>
> - /*
> - * This is applicable for SDHCI_SPEC_300 and above
> - * ZynqMP does not set phase for <=25MHz clock.
> - * If degrees is zero, no need to do anything.
> - */
> - if (host->version < SDHCI_SPEC_300 ||
> - host->timing == MMC_TIMING_LEGACY ||
> - host->timing == MMC_TIMING_UHS_SDR12 || !degrees)
> + /* This is applicable for SDHCI_SPEC_300 and above */
> + if (host->version < SDHCI_SPEC_300)
> return 0;
>
> switch (host->timing) {
> @@ -733,14 +721,8 @@ static int sdhci_versal_sdcardclk_set_phase(struct
> clk_hw *hw, int degrees)
> struct sdhci_host *host = sdhci_arasan->host;
> u8 tap_delay, tap_max = 0;
>
> - /*
> - * This is applicable for SDHCI_SPEC_300 and above
> - * Versal does not set phase for <=25MHz clock.
> - * If degrees is zero, no need to do anything.
> - */
> - if (host->version < SDHCI_SPEC_300 ||
> - host->timing == MMC_TIMING_LEGACY ||
> - host->timing == MMC_TIMING_UHS_SDR12 || !degrees)
> + /* This is applicable for SDHCI_SPEC_300 and above */
> + if (host->version < SDHCI_SPEC_300)
> return 0;
>
> switch (host->timing) {
> @@ -804,14 +786,8 @@ static int sdhci_versal_sampleclk_set_phase(struct
> clk_hw *hw, int degrees)
> struct sdhci_host *host = sdhci_arasan->host;
> u8 tap_delay, tap_max = 0;
>
> - /*
> - * This is applicable for SDHCI_SPEC_300 and above
> - * Versal does not set phase for <=25MHz clock.
> - * If degrees is zero, no need to do anything.
> - */
> - if (host->version < SDHCI_SPEC_300 ||
> - host->timing == MMC_TIMING_LEGACY ||
> - host->timing == MMC_TIMING_UHS_SDR12 || !degrees)
> + /* This is applicable for SDHCI_SPEC_300 and above */
> + if (host->version < SDHCI_SPEC_300)
> return 0;
>
> switch (host->timing) {
> --
> 2.17.1
Thanks,
Manish
[PATCH] scsi: pmcraid: replace atomic_add_return()
atomic_inc_return() looks better
Signed-off-by: Yejune Deng
---
drivers/scsi/pmcraid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index cbe5fab..3e5b70c 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -3381,7 +3381,7 @@ static int pmcraid_queuecommand_lck(
* block of scsi_cmd which is re-used (e.g. cancel/abort), which uses
* hrrq_id assigned here in queuecommand
*/
- ioarcb->hrrq_id = atomic_add_return(1, &(pinstance->last_message_id)) %
+ ioarcb->hrrq_id = atomic_inc_return(&pinstance->last_message_id) %
pinstance->num_hrrq;
cmd->cmd_done = pmcraid_io_done;
@@ -3684,7 +3684,7 @@ static long pmcraid_ioctl_passthrough(
* block of scsi_cmd which is re-used (e.g. cancel/abort), which uses
* hrrq_id assigned here in queuecommand
*/
- ioarcb->hrrq_id = atomic_add_return(1, &(pinstance->last_message_id)) %
+ ioarcb->hrrq_id = atomic_inc_return(&pinstance->last_message_id) %
pinstance->num_hrrq;
if (request_size) {
--
1.9.1
Re: [PATCH] phy: mediatek: fix spelling mistake in Kconfig "veriosn" -> "version"
On 14-11-20, 12:05, Colin King wrote: > From: Colin Ian King > > There is a spelling mistake in the Kconfig. Fix it. Applied, thanks -- ~Vinod
[PATCH] Asoc: qcom: lpass-sc7180: Add 32 bit format support for capture
From: V Sujith Kumar Reddy
Add 32 bit format support for capture in lpass-sc7180
snd_soc_dai_driver capabilities. Need to add contstraints
in machine driver so that only specific format allowed.
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao Manidadapu
---
sound/soc/qcom/lpass-sc7180.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/qcom/lpass-sc7180.c b/sound/soc/qcom/lpass-sc7180.c
index 61b51b5..3dc80fc 100644
--- a/sound/soc/qcom/lpass-sc7180.c
+++ b/sound/soc/qcom/lpass-sc7180.c
@@ -34,7 +34,8 @@ static struct snd_soc_dai_driver
sc7180_lpass_cpu_dai_driver[] = {
},
.capture = {
.stream_name = "Primary Capture",
- .formats = SNDRV_PCM_FMTBIT_S16,
+ .formats = SNDRV_PCM_FMTBIT_S16 |
+ SNDRV_PCM_FMTBIT_S32,
.rates = SNDRV_PCM_RATE_48000,
.rate_min = 48000,
.rate_max = 48000,
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH] phy: mapphone-mdm6600: remove the unused variable error value assignment
On 13-11-20, 16:34, xiakaixu1...@gmail.com wrote:
> From: Kaixu Xia
>
> The value of variable error is overwritten by the following call
> devm_request_threaded_irq() in phy_mdm6600_device_power_on(), so here the
> value assignment is useless. Remove it.
>
> Reported-by: Tosk Robot
> Signed-off-by: Kaixu Xia
> ---
> drivers/phy/motorola/phy-mapphone-mdm6600.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/phy/motorola/phy-mapphone-mdm6600.c
> b/drivers/phy/motorola/phy-mapphone-mdm6600.c
> index 5172971..24ab848 100644
> --- a/drivers/phy/motorola/phy-mapphone-mdm6600.c
> +++ b/drivers/phy/motorola/phy-mapphone-mdm6600.c
> @@ -421,7 +421,6 @@ static int phy_mdm6600_device_power_on(struct phy_mdm6600
> *ddata)
> dev_info(ddata->dev, "Powered up OK\n");
> } else {
> ddata->enabled = false;
> - error = -ETIMEDOUT;
> dev_err(ddata->dev, "Timed out powering up\n");
Maybe the right fix is adding return error here..?
--
~Vinod
Re: [PATCH] phy: tegra: Don't warn on probe deferral
On 11-11-20, 10:37, Jon Hunter wrote: > Deferred probe is an expected return value for devm_regulator_bulk_get(). > Given that the driver deals with it properly, there's no need to output a > warning that may potentially confuse users. Applied, thanks -- ~Vinod
[PATCH] dt-bindings: phy: bcm-ns-usb2-phy: convert to yaml
From: Rafał Miłecki
1. Convert from txt to yaml
2. Drop "Driver for" from the title
3. Document "#phy-cells"
4. Fix example node name (noticed by dt_binding_check)
5. Add #include to example (noticed by dt_binding_check)
6. Specify license
Signed-off-by: Rafał Miłecki
---
I think this should go through linux-phy tree. Kishon, Vinod, can you
take this patch?
This patch generates a false positive checkpatch.pl warning [0].
Please ignore:
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
[0] https://lkml.org/lkml/2020/2/18/1084
---
.../bindings/phy/bcm-ns-usb2-phy.txt | 21 ---
.../bindings/phy/bcm-ns-usb2-phy.yaml | 59 +++
2 files changed, 59 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
create mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
deleted file mode 100644
index a7aee9ea8926..
--- a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Driver for Broadcom Northstar USB 2.0 PHY
-
-Required properties:
-- compatible: brcm,ns-usb2-phy
-- reg: iomem address range of DMU (Device Management Unit)
-- reg-names: "dmu", the only needed & supported reg right now
-- clocks: USB PHY reference clock
-- clock-names: "phy-ref-clk", the only needed & supported clock right now
-
-To initialize USB 2.0 PHY driver needs to setup PLL correctly. To do this it
-requires passing phandle to the USB PHY reference clock.
-
-Example:
- usb2-phy {
- compatible = "brcm,ns-usb2-phy";
- reg = <0x1800c000 0x1000>;
- reg-names = "dmu";
- #phy-cells = <0>;
- clocks = <&genpll BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
- clock-names = "phy-ref-clk";
- };
diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml
b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml
new file mode 100644
index ..05b4dcd80019
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb2-phy.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/bcm-ns-usb2-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Northstar USB 2.0 PHY
+
+description: >
+ To initialize USB 2.0 PHY driver needs to setup PLL correctly.
+ To do this it requires passing phandle to the USB PHY reference clock.
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+const: brcm,ns-usb2-phy
+
+ reg:
+items:
+ - description: iomem address range of DMU (Device Management Unit)
+
+ reg-names:
+items:
+ - const: dmu
+
+ clocks:
+items:
+ - description: USB PHY reference clock
+
+ clock-names:
+items:
+ - const: phy-ref-clk
+
+ "#phy-cells":
+const: 0
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+phy@1800c000 {
+compatible = "brcm,ns-usb2-phy";
+reg = <0x1800c000 0x1000>;
+reg-names = "dmu";
+clocks = <&genpll BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
+clock-names = "phy-ref-clk";
+#phy-cells = <0>;
+};
--
2.27.0
[PATCH] dt-bindings: phy: bcm-ns-usb3-phy: convert to yaml
From: Rafał Miłecki
1. Change syntax from txt to yaml
2. Drop "Driver for" from the title
3. Drop "reg = <0x0>;" from example (noticed by dt_binding_check)
4. Specify license
Signed-off-by: Rafał Miłecki
---
I think this should go through linux-phy tree. Kishon, Vinod, can you
take this patch?
This patch generates a false positive checkpatch.pl warning [0].
Please ignore:
WARNING: DT binding docs and includes should be a separate patch. See:
Documentation/devicetree/bindings/submitting-patches.rst
[0] https://lkml.org/lkml/2020/2/18/1084
---
.../bindings/phy/bcm-ns-usb3-phy.txt | 34 --
.../bindings/phy/bcm-ns-usb3-phy.yaml | 62 +++
2 files changed, 62 insertions(+), 34 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
create mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
deleted file mode 100644
index 32f057260351..
--- a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Driver for Broadcom Northstar USB 3.0 PHY
-
-Required properties:
-
-- compatible: one of: "brcm,ns-ax-usb3-phy", "brcm,ns-bx-usb3-phy".
-- reg: address of MDIO bus device
-- usb3-dmp-syscon: phandle to syscon with DMP (Device Management Plugin)
- registers
-- #phy-cells: must be 0
-
-Initialization of USB 3.0 PHY depends on Northstar version. There are currently
-three known series: Ax, Bx and Cx.
-Known A0: BCM4707 rev 0
-Known B0: BCM4707 rev 4, BCM53573 rev 2
-Known B1: BCM4707 rev 6
-Known C0: BCM47094 rev 0
-
-Example:
- mdio: mdio@0 {
- reg = <0x0>;
- #size-cells = <1>;
- #address-cells = <0>;
-
- usb3-phy@10 {
- compatible = "brcm,ns-ax-usb3-phy";
- reg = <0x10>;
- usb3-dmp-syscon = <&usb3_dmp>;
- #phy-cells = <0>;
- };
- };
-
- usb3_dmp: syscon@18105000 {
- reg = <0x18105000 0x1000>;
- };
diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.yaml
b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.yaml
new file mode 100644
index ..7fd419db45d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/bcm-ns-usb3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom Northstar USB 3.0 PHY
+
+description: |
+ Initialization of USB 3.0 PHY depends on Northstar version. There are
currently
+ three known series: Ax, Bx and Cx.
+ Known A0: BCM4707 rev 0
+ Known B0: BCM4707 rev 4, BCM53573 rev 2
+ Known B1: BCM4707 rev 6
+ Known C0: BCM47094 rev 0
+
+maintainers:
+ - Rafał Miłecki
+
+properties:
+ compatible:
+enum:
+ - brcm,ns-ax-usb3-phy
+ - brcm,ns-bx-usb3-phy
+
+ reg:
+description: address of MDIO bus device
+maxItems: 1
+
+ usb3-dmp-syscon:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ Phandle to the DMP (Device Management Plugin) syscon
+
+ "#phy-cells":
+const: 0
+
+required:
+ - compatible
+ - reg
+ - usb3-dmp-syscon
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+mdio {
+#address-cells = <1>;
+#size-cells = <0>;
+
+usb3-phy@10 {
+compatible = "brcm,ns-ax-usb3-phy";
+reg = <0x10>;
+usb3-dmp-syscon = <&usb3_dmp>;
+#phy-cells = <0>;
+};
+};
+
+usb3_dmp: syscon@18105000 {
+reg = <0x18105000 0x1000>;
+};
--
2.27.0
Re: [PATCH v2] mm: memblock: add more debug logs
On Mon, Nov 16, 2020 at 10:14:04AM +0530, Faiyaz Mohammed wrote: > It is useful to know the exact caller of memblock_phys_alloc_range() to > track early memory reservations during development. > > Currently, when memblock debugging is enabled, the allocations done with > memblock_phys_alloc_range() are only reported at memblock_reserve(): > > [0.00] memblock_reserve: [0x00023fc6b000-0x00023fc6bfff] > memblock_alloc_range_nid+0xc0/0x188 > > Add memblock_dbg() to memblock_phys_alloc_range() to get details about > its usage. > > For example: > > [0.00] memblock_phys_alloc_range: 4096 bytes align=0x1000 > from=0x max_addr=0x > early_pgtable_alloc+0x24/0x178 > [0.00] memblock_reserve: [0x00023fc6b000-0x00023fc6bfff] > memblock_alloc_range_nid+0xc0/0x188 > > Signed-off-by: Faiyaz Mohammed Applied, thanks!
[PATCH] net/tun: Call notifiers before and after changing device type
Signed-off-by: Martin Schiller
---
drivers/net/tun.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index be69d272052f..8253c5b03105 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -3124,9 +3124,11 @@ static long __tun_chr_ioctl(struct file *file, unsigned
int cmd,
"Linktype set failed because interface is
up\n");
ret = -EBUSY;
} else {
+ call_netdevice_notifiers(NETDEV_PRE_TYPE_CHANGE,
tun->dev);
tun->dev->type = (int) arg;
netif_info(tun, drv, tun->dev, "linktype set to %d\n",
tun->dev->type);
+ call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE,
tun->dev);
ret = 0;
}
break;
--
2.20.1
Re: [PATCH v2 0/2] phy: phy-brcm-sata: Allow configuration SATA AFE TX amplitude
On 22-10-20, 13:50, Florian Fainelli wrote: > Hi Vinod, Kishon, > > This patch series allows the configuration of the Broadcom SATA PHY TX > amplitude which may be required in order to meet specific tests. Applied, thanks Btw please do convert the binding doc to yaml Thanks -- ~Vinod
Re: [PATCH] phy: intel: PHY_INTEL_KEEMBAY_EMMC should depend on ARCH_KEEMBAY
On 10-11-20, 15:46, Geert Uytterhoeven wrote: > The Intel Keem Bay eMMC PHY is only present on Intel Keem Bay SoCs. > Hence add a dependency on ARCH_KEEMBAY, to prevent asking the user about > this driver when configuring a kernel without Intel Keem Bay platform > support. Applied, thanks -- ~Vinod
Re: [PATCH 1/2] phy: stm32: don't print an error on probe deferral
On 10-11-20, 11:23, Amelie Delaunay wrote: > Change stm32-usbphyc driver to not print an error message when the device > probe operation is deferred. Applied all, thanks -- ~Vinod
[PATCH 6/6] net/lapb: fix t1 timer handling
fix t1 timer handling in LAPB_STATE_0:
o DTE interface changes immediately to LAPB_STATE_1 and start sending
SABM(E).
o DCE interface sends N2-times DM and changes to LAPB_STATE_1
afterwards if there is no response in the meantime.
Signed-off-by: Martin Schiller
---
net/lapb/lapb_timer.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/lapb/lapb_timer.c b/net/lapb/lapb_timer.c
index 8f5b17001a07..d1f80d67892f 100644
--- a/net/lapb/lapb_timer.c
+++ b/net/lapb/lapb_timer.c
@@ -85,11 +85,16 @@ static void lapb_t1timer_expiry(struct timer_list *t)
switch (lapb->state) {
/*
-* If we are a DCE, keep going DM .. DM .. DM
+* If we are a DCE, send DM up to N2 times, then switch to
STATE_1 and send SABM(E)
*/
case LAPB_STATE_0:
- if (lapb->mode & LAPB_DCE)
+ if (lapb->mode & LAPB_DCE && lapb->n2count != lapb->n2)
{
+ lapb->n2count++;
lapb_send_control(lapb, LAPB_DM, LAPB_POLLOFF,
LAPB_RESPONSE);
+ } else {
+ lapb->state = LAPB_STATE_1;
+ lapb_establish_data_link(lapb);
+ }
break;
/*
--
2.20.1
Re: [PATCH] phy: tegra: Constify static device_type structs
On 09-11-20, 22:58, Rikard Falkeborn wrote: > The only usage of tegra_xusb_pad_type and tegra_xusb_port_type is to > assign their address to the type field in the device struct, which is a > const pointer. Make them const to allow the compiler to put them in > read-only memory. Applied, thanks -- ~Vinod
[PATCH 1/6] net/x25: add/remove x25_link_device by NETDEV_REGISTER/UNREGISTER
and also by NETDEV_POST_TYPE_CHANGE/NETDEV_PRE_TYPE_CHANGE.
This change is needed so that the x25_neigh struct for an interface is
already created when it shows up and is kept independantly if the
interface goes UP or DOWN.
This is used in the next commit, where x25 params of an neighbour will
get configurable through ioctls.
Signed-off-by: Martin Schiller
---
include/net/x25.h | 2 ++
net/x25/af_x25.c | 19 +
net/x25/x25_link.c | 51 --
3 files changed, 66 insertions(+), 6 deletions(-)
diff --git a/include/net/x25.h b/include/net/x25.h
index d7d6c2b4ffa7..af841c5ede28 100644
--- a/include/net/x25.h
+++ b/include/net/x25.h
@@ -231,6 +231,8 @@ int x25_backlog_rcv(struct sock *, struct sk_buff *);
/* x25_link.c */
void x25_link_control(struct sk_buff *, struct x25_neigh *, unsigned short);
+void x25_link_device_add(struct net_device *);
+void x25_link_device_remove(struct net_device *);
void x25_link_device_up(struct net_device *);
void x25_link_device_down(struct net_device *);
void x25_link_established(struct x25_neigh *);
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index a10487e7574c..d8e5ca251801 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -233,10 +233,20 @@ static int x25_device_event(struct notifier_block *this,
unsigned long event,
#endif
) {
switch (event) {
+ case NETDEV_REGISTER:
+ pr_debug("X.25: got event NETDEV_REGISTER for device:
%s\n", dev->name);
+ x25_link_device_add(dev);
+ break;
+ case NETDEV_POST_TYPE_CHANGE:
+ pr_debug("X.25: got event NETDEV_POST_TYPE_CHANGE for
device: %s\n", dev->name);
+ x25_link_device_add(dev);
+ break;
case NETDEV_UP:
+ pr_debug("X.25: got event NETDEV_UP for device: %s\n",
dev->name);
x25_link_device_up(dev);
break;
case NETDEV_GOING_DOWN:
+ pr_debug("X.25: got event NETDEV_GOING_DOWN for device:
%s\n", dev->name);
nb = x25_get_neigh(dev);
if (nb) {
x25_terminate_link(nb);
@@ -244,10 +254,19 @@ static int x25_device_event(struct notifier_block *this,
unsigned long event,
}
break;
case NETDEV_DOWN:
+ pr_debug("X.25: got event NETDEV_DOWN for device:
%s\n", dev->name);
x25_kill_by_device(dev);
x25_route_device_down(dev);
x25_link_device_down(dev);
break;
+ case NETDEV_PRE_TYPE_CHANGE:
+ pr_debug("X.25: got event NETDEV_PRE_TYPE_CHANGE for
device: %s\n", dev->name);
+ x25_link_device_remove(dev);
+ break;
+ case NETDEV_UNREGISTER:
+ pr_debug("X.25: got event NETDEV_UNREGISTER for device:
%s\n", dev->name);
+ x25_link_device_remove(dev);
+ break;
}
}
diff --git a/net/x25/x25_link.c b/net/x25/x25_link.c
index fdae054b7dc1..22055ee40056 100644
--- a/net/x25/x25_link.c
+++ b/net/x25/x25_link.c
@@ -239,9 +239,19 @@ void x25_link_terminated(struct x25_neigh *nb)
/*
* Add a new device.
*/
-void x25_link_device_up(struct net_device *dev)
+void x25_link_device_add(struct net_device *dev)
{
- struct x25_neigh *nb = kmalloc(sizeof(*nb), GFP_ATOMIC);
+ struct x25_neigh *nb = x25_get_neigh(dev);
+
+ /*
+* Check, if we already have a neighbour for this device
+*/
+ if (nb) {
+ x25_neigh_put(nb);
+ return;
+ }
+
+ nb = kmalloc(sizeof(*nb), GFP_ATOMIC);
if (!nb)
return;
@@ -268,6 +278,22 @@ void x25_link_device_up(struct net_device *dev)
write_unlock_bh(&x25_neigh_list_lock);
}
+/*
+ * A device is coming up
+ */
+void x25_link_device_up(struct net_device *dev)
+{
+ struct x25_neigh *nb = x25_get_neigh(dev);
+
+ if (!nb)
+ return;
+
+ nb->state = X25_LINK_STATE_1;
+ x25_establish_link(nb);
+
+ x25_neigh_put(nb);
+}
+
/**
* __x25_remove_neigh - remove neighbour from x25_neigh_list
* @nb: - neigh to remove
@@ -277,9 +303,6 @@ void x25_link_device_up(struct net_device *dev)
*/
static void __x25_remove_neigh(struct x25_neigh *nb)
{
- skb_queue_purge(&nb->queue);
- x25_stop_t20timer(nb);
-
if (nb->node.next) {
list_del(&nb->node);
x25_neigh_put(nb);
@@ -289,7 +312,7 @@ static void __x25_remove_neigh(struct x25_neigh *nb)
/*
* A device has been removed, remove its links.
*/
-void x25_link_devic
Re: [PATCH 5/9] phy: cadence: Sierra: Fix PHY power_on sequence
On 03-11-20, 09:25, Kishon Vijay Abraham I wrote:
> Commit 44d30d622821d ("phy: cadence: Add driver for Sierra PHY")
> de-asserts PHY_RESET even before the configurations are loaded in
> phy_init(). However PHY_RESET should be de-asserted only after
> all the configurations has been initialized, instead of de-asserting
> in probe. Fix it here.
Move this up in series..? Also I think we should apply this to fixes and
perhaps cc stable..?
>
> Fixes: 44d30d622821d ("phy: cadence: Add driver for Sierra PHY")
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/phy/cadence/phy-cadence-sierra.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/cadence/phy-cadence-sierra.c
> b/drivers/phy/cadence/phy-cadence-sierra.c
> index 4429f41a8f58..e08548417bce 100644
> --- a/drivers/phy/cadence/phy-cadence-sierra.c
> +++ b/drivers/phy/cadence/phy-cadence-sierra.c
> @@ -319,6 +319,12 @@ static int cdns_sierra_phy_on(struct phy *gphy)
> u32 val;
> int ret;
>
> + ret = reset_control_deassert(sp->phy_rst);
> + if (ret) {
> + dev_err(dev, "Failed to take the PHY out of reset\n");
> + return ret;
> + }
> +
> /* Take the PHY lane group out of reset */
> ret = reset_control_deassert(ins->lnk_rst);
> if (ret) {
> @@ -621,7 +627,6 @@ static int cdns_sierra_phy_probe(struct platform_device
> *pdev)
>
> pm_runtime_enable(dev);
> phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> - reset_control_deassert(sp->phy_rst);
> return PTR_ERR_OR_ZERO(phy_provider);
>
> put_child:
> --
> 2.17.1
--
~Vinod
[PATCH] ipmi/watchdog: replace atomic_add() and atomic_sub()
atomic_inc() and atomic_dec() looks better
Signed-off-by: Yejune Deng
---
drivers/char/ipmi/ipmi_watchdog.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_watchdog.c
b/drivers/char/ipmi/ipmi_watchdog.c
index f78156d..32c334e 100644
--- a/drivers/char/ipmi/ipmi_watchdog.c
+++ b/drivers/char/ipmi/ipmi_watchdog.c
@@ -495,7 +495,7 @@ static void panic_halt_ipmi_heartbeat(void)
msg.cmd = IPMI_WDOG_RESET_TIMER;
msg.data = NULL;
msg.data_len = 0;
- atomic_add(1, &panic_done_count);
+ atomic_inc(&panic_done_count);
rv = ipmi_request_supply_msgs(watchdog_user,
(struct ipmi_addr *) &addr,
0,
@@ -505,7 +505,7 @@ static void panic_halt_ipmi_heartbeat(void)
&panic_halt_heartbeat_recv_msg,
1);
if (rv)
- atomic_sub(1, &panic_done_count);
+ atomic_dec(&panic_done_count);
}
static struct ipmi_smi_msg panic_halt_smi_msg = {
@@ -529,12 +529,12 @@ static void panic_halt_ipmi_set_timeout(void)
/* Wait for the messages to be free. */
while (atomic_read(&panic_done_count) != 0)
ipmi_poll_interface(watchdog_user);
- atomic_add(1, &panic_done_count);
+ atomic_inc(&panic_done_count);
rv = __ipmi_set_timeout(&panic_halt_smi_msg,
&panic_halt_recv_msg,
&send_heartbeat_now);
if (rv) {
- atomic_sub(1, &panic_done_count);
+ atomic_dec(&panic_done_count);
pr_warn("Unable to extend the watchdog timeout\n");
} else {
if (send_heartbeat_now)
--
1.9.1
RE: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection
> From: Raj, Ashok > Sent: Monday, November 16, 2020 8:23 AM > > On Sun, Nov 15, 2020 at 11:11:27PM +0100, Thomas Gleixner wrote: > > On Sun, Nov 15 2020 at 11:31, Ashok Raj wrote: > > > On Sun, Nov 15, 2020 at 12:26:22PM +0100, Thomas Gleixner wrote: > > >> > opt-in by device or kernel? The way we are planning to support this is: > > >> > > > >> > Device support for IMS - Can discover in device specific means > > >> > Kernel support for IMS. - Supported by IOMMU driver. > > >> > > >> And why exactly do we have to enforce IOMMU support? Please stop > looking > > >> at IMS purely from the IDXD perspective. We are talking about the > > >> general concept here and not about the restricted Intel universe. > > > > > > I think you have mentioned it almost every reply :-)..Got that! Point > > > taken > > > several emails ago!! :-) > > > > You sure? I _try_ to not mention it again then. No promise though. :) > > Hey.. anything that's entertaining go for it :-) > > > > > > I didn't mean just for idxd, I said for *ANY* device driver that wants to > > > use IMS. > > > > Which is wrong. Again: > > > > A) For PF/VF on bare metal there is absolutely no IOMMU dependency > >because it does not have a PASID requirement. It's just an > >alternative solution to MSI[X], which allows optimizations like > >storing the message in driver manages queue memory or lifting the > >restriction of 2048 interrupts per device. Nothing else. > > You are right.. my eyes were clouded by virtualization.. no dependency for > native absolutely. > > > > > B) For PF/VF in a guest the IOMMU dependency of IMS is a red herring. > >There is no direct dependency on the IOMMU. > > > >The problem is the inability of the VMM to trap the message write to > >the IMS storage if the storage is in guest driver managed memory. > >This can be solved with either > > > >- a hypercall which translates the guest MSI message > >or > >- a vIOMMU which uses a hypercall or whatever to translate the guest > > MSI message > > > > C) Subdevices ala mdev are a different story. They require PASID which > >enforces IOMMU and the IMS part is not managed by the users anyway. > > You are right again :) > > The subdevices require PASID & IOMMU in native, but inside the guest there > is no > need for IOMMU unless you want to build SVM on top. subdevices work > without > any vIOMMU or hypercall in the guest. Only because they look like normal > PCI devices we could map interrupts to legacy MSIx. Guest managed subdevices on PF/VF requires vIOMMU. Anyway I think Thomas was just pointing out that subdevices are the only category out of above three which may have business tied to IOMMU. 😊 > > > > > So we have a couple of problems to solve: > > > > 1) Figure out whether the OS runs on bare metal > > > > There is no reliable answer to that, so we either: > > > > - Use heuristics and assume that failure is unlikely and in case > > of failure blame the incompetence of VMM authors and/or > > sysadmins > > > > or > > > > - Default to IMS disabled and let the sysadmin enable it via > > command line option. > > > > If the kernel detects to run in a VM it yells and disables it > > unless the OS and the hypervisor agree to provide support for > > that scenario (see #2). > > > > That's fails as well if the sysadmin does so when the OS runs on > > a VMM which is not identifiable, but at least we can rightfully > > blame the sysadmin in that case. > > cmdline isn't nice, best to have this functional out of box. > > > > > or > > > > - Declare that IMS always depends on IOMMU > > As you had mentioned IMS has no real dependency on IOMMU in native. > > we just need to make sure if running in guest we have support for it > plumbed. > > > > > I personaly don't care, but people working on these kind of > > device already said, that they want to avoid it when possible. > > > > If you want to go that route, then please talk to those folks > > and ask them to agree in public. > > > > You also need to take into account that this must work on all > > architectures which support virtualization because IMS is > > architecture independent. > > What you suggest makes perfect sense. We can certainly get buy in from > iommu list and have this co-ordinated between all existing iommu varients. Does a hybrid scheme sound good here? - Say a cmdline parameter: ims=[auto|on|off], with 'auto' as default; - if ims=auto: * If arch doesn't implement probably_on_bare_metal, disallow ims; * If probably_on_bare_metal returns false, disallow ims; # (future) if hypercall is supported, allow ims; * If probably_on_bare_metal returns true, allow ims with caveat on possible mis-interception of running on an old hypervisor. Sysadmin may need to double-confirm in other means # (fu
Re: [PATCH] md: dm-writeback: add __noreturn to BUG-ging function
On 13.11.20 23:52, Randy Dunlap wrote:
> Building on arch/s390/ flags this as an error, so add the
> __noreturn attribute modifier to prevent the build error.
>
> cc1: some warnings being treated as errors
> ../drivers/md/dm-writecache.c: In function 'persistent_memory_claim':
> ../drivers/md/dm-writecache.c:323:1: error: no return statement in function
> returning non-void [-Werror=return-type]
ok with me, but I am asking why
the unreachable macro is not good enough. For x86 it obviously is.
form arch/s390/include/asm/bug.h
#define BUG() do { \
__EMIT_BUG(0); \
unreachable(); \
} while (0)
>
> Fixes: 48debafe4f2f ("dm: add writecache target")
> Signed-off-by: Randy Dunlap
> Cc: Mikulas Patocka
> Cc: Alasdair Kergon
> Cc: Mike Snitzer
> Cc: dm-de...@redhat.com
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Christian Borntraeger
> Cc: linux-s...@vger.kernel.org
> ---
> drivers/md/dm-writecache.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-next-20201113.orig/drivers/md/dm-writecache.c
> +++ linux-next-20201113/drivers/md/dm-writecache.c
> @@ -317,7 +317,7 @@ err1:
> return r;
> }
> #else
> -static int persistent_memory_claim(struct dm_writecache *wc)
> +static int __noreturn persistent_memory_claim(struct dm_writecache *wc)
> {
> BUG();
> }
>
Re: [PATCH 3/9] phy: ti: j721e-wiz: Don't configure wiz if its already configured
On 03-11-20, 09:25, Kishon Vijay Abraham I wrote:
> From: Faiz Abbas
>
> Serdes lanes might be shared between multiple cores in some usecases
> and its not possible to lock PLLs for both the lanes independently
> by the two cores. This requires a bootloader to configure both the
> lanes at early boot time.
>
> To handle this case, skip all configuration if any of the lanes has
> already been enabled.
>
> While we are here, also fix the wiz_init() to be called before the
> of_platform_device_create() call.
Let's do two patches for these two issues :-)
Other than that, change lgtm, with exception of minor nit
> Signed-off-by: Faiz Abbas
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/phy/ti/phy-j721e-wiz.c | 36 +-
> 1 file changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
> index d57d29382ce4..9786e8aec252 100644
> --- a/drivers/phy/ti/phy-j721e-wiz.c
> +++ b/drivers/phy/ti/phy-j721e-wiz.c
> @@ -816,13 +816,14 @@ static int wiz_probe(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct device_node *node = dev->of_node;
> struct platform_device *serdes_pdev;
> + bool already_configured = false;
> struct device_node *child_node;
> struct regmap *regmap;
> struct resource res;
> void __iomem *base;
> struct wiz *wiz;
> u32 num_lanes;
> - int ret;
> + int ret, val, i;
>
> wiz = devm_kzalloc(dev, sizeof(*wiz), GFP_KERNEL);
> if (!wiz)
> @@ -944,10 +945,26 @@ static int wiz_probe(struct platform_device *pdev)
> goto err_get_sync;
> }
>
> - ret = wiz_clock_init(wiz, node);
> - if (ret < 0) {
> - dev_warn(dev, "Failed to initialize clocks\n");
> - goto err_get_sync;
> + for (i = 0; i < wiz->num_lanes; i++) {
> + regmap_field_read(wiz->p_enable[i], &val);
> + if (val & (P_ENABLE | P_ENABLE_FORCE)) {
> + already_configured = true;
> + break;
> + }
> + }
> +
> + if (!already_configured) {
do you really need this variable and check, why not move the below into
precceding block and do wiz_clock_init() and wiz_init() inside the
if condition and drop the variable
> + ret = wiz_clock_init(wiz, node);
> + if (ret < 0) {
> + dev_warn(dev, "Failed to initialize clocks\n");
> + goto err_get_sync;
> + }
> +
> + ret = wiz_init(wiz);
> + if (ret) {
> + dev_err(dev, "WIZ initialization failed\n");
> + goto err_pdev_create;
> + }
> }
>
> serdes_pdev = of_platform_device_create(child_node, NULL, dev);
> @@ -958,18 +975,9 @@ static int wiz_probe(struct platform_device *pdev)
> }
> wiz->serdes_pdev = serdes_pdev;
>
> - ret = wiz_init(wiz);
> - if (ret) {
> - dev_err(dev, "WIZ initialization failed\n");
> - goto err_wiz_init;
> - }
> -
> of_node_put(child_node);
> return 0;
>
> -err_wiz_init:
> - of_platform_device_destroy(&serdes_pdev->dev, NULL);
> -
> err_pdev_create:
> wiz_clock_cleanup(wiz, node);
>
> --
> 2.17.1
--
~Vinod
[PATCH 5/6] net/lapb: support netdev events
This makes it possible to handle carrier loss and detection.
In case of Carrier Loss, layer 2 is terminated
In case of Carrier Detection, we start timer t1 on a DCE interface,
and on a DTE interface we change to state LAPB_STATE_1 and start
sending SABM(E).
Signed-off-by: Martin Schiller
---
net/lapb/lapb_iface.c | 74 +++
1 file changed, 74 insertions(+)
diff --git a/net/lapb/lapb_iface.c b/net/lapb/lapb_iface.c
index 3c03f6512c5f..6a109c8c286f 100644
--- a/net/lapb/lapb_iface.c
+++ b/net/lapb/lapb_iface.c
@@ -418,14 +418,88 @@ int lapb_data_transmit(struct lapb_cb *lapb, struct
sk_buff *skb)
return used;
}
+/*
+ * Handle device status changes.
+ */
+static int lapb_device_event(struct notifier_block *this, unsigned long event,
+ void *ptr)
+{
+ struct net_device *dev = ptr;
+ struct lapb_cb *lapb;
+
+ if (!net_eq(dev_net(dev), &init_net))
+ return NOTIFY_DONE;
+
+ if (dev->type == ARPHRD_X25) {
+ switch (event) {
+ case NETDEV_REGISTER:
+ lapb_dbg(0, "(%p): got event NETDEV_REGISTER for
device: %s\n", dev, dev->name);
+ break;
+ case NETDEV_POST_TYPE_CHANGE:
+ lapb_dbg(0, "(%p): got event NETDEV_POST_TYPE_CHANGE
for device: %s\n", dev, dev->name);
+ break;
+ case NETDEV_UP:
+ lapb_dbg(0, "(%p): got event NETDEV_UP for device:
%s\n", dev, dev->name);
+ break;
+ case NETDEV_GOING_DOWN:
+ lapb_dbg(0, "(%p): got event NETDEV_GOING_DOWN for
device: %s\n", dev, dev->name);
+ break;
+ case NETDEV_DOWN:
+ lapb_dbg(0, "(%p): got event NETDEV_DOWN for device:
%s\n", dev, dev->name);
+ break;
+ case NETDEV_PRE_TYPE_CHANGE:
+ lapb_dbg(0, "(%p): got event NETDEV_PRE_TYPE_CHANGE for
device: %s\n", dev, dev->name);
+ break;
+ case NETDEV_UNREGISTER:
+ lapb_dbg(0, "(%p): got event NETDEV_UNREGISTER for
device: %s\n", dev, dev->name);
+ break;
+ case NETDEV_CHANGE:
+ lapb_dbg(0, "(%p): got event NETDEV_CHANGE for device:
%s\n", dev, dev->name);
+ lapb = lapb_devtostruct(dev);
+ if (lapb) {
+ if (!netif_carrier_ok(dev)) {
+ lapb_dbg(0, "(%p): Carrier lost ->
Entering LAPB_STATE_0: %s\n", dev, dev->name);
+ lapb_disconnect_indication(lapb,
LAPB_OK);
+ lapb_clear_queues(lapb);
+ lapb->state = LAPB_STATE_0;
+ lapb->n2count = 0;
+ lapb_stop_t1timer(lapb);
+ lapb_stop_t2timer(lapb);
+ } else {
+ lapb_dbg(0, "(%p): Carrier detected:
%s\n", dev, dev->name);
+ if (lapb->mode & LAPB_DCE) {
+ lapb_start_t1timer(lapb);
+ } else {
+ if (lapb->state ==
LAPB_STATE_0) {
+ lapb->state =
LAPB_STATE_1;
+
lapb_establish_data_link(lapb);
+ }
+ }
+ }
+ }
+ break;
+ }
+ }
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block lapb_dev_notifier = {
+ .notifier_call = lapb_device_event,
+};
+
static int __init lapb_init(void)
{
+ register_netdevice_notifier(&lapb_dev_notifier);
+
return 0;
}
static void __exit lapb_exit(void)
{
WARN_ON(!list_empty(&lapb_list));
+
+ unregister_netdevice_notifier(&lapb_dev_notifier);
}
MODULE_AUTHOR("Jonathan Naylor ");
--
2.20.1
[PATCH 3/6] net/x25: replace x25_kill_by_device with x25_kill_by_neigh
Remove unnecessary function x25_kill_by_device.
Signed-off-by: Martin Schiller
---
net/x25/af_x25.c | 22 +-
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 439ae65ab7a8..d98d1145500e 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -210,22 +210,6 @@ static void x25_remove_socket(struct sock *sk)
write_unlock_bh(&x25_list_lock);
}
-/*
- * Kill all bound sockets on a dropped device.
- */
-static void x25_kill_by_device(struct net_device *dev)
-{
- struct sock *s;
-
- write_lock_bh(&x25_list_lock);
-
- sk_for_each(s, &x25_list)
- if (x25_sk(s)->neighbour && x25_sk(s)->neighbour->dev == dev)
- x25_disconnect(s, ENETUNREACH, 0, 0);
-
- write_unlock_bh(&x25_list_lock);
-}
-
/*
* Handle device status changes.
*/
@@ -266,7 +250,11 @@ static int x25_device_event(struct notifier_block *this,
unsigned long event,
break;
case NETDEV_DOWN:
pr_debug("X.25: got event NETDEV_DOWN for device:
%s\n", dev->name);
- x25_kill_by_device(dev);
+ nb = x25_get_neigh(dev);
+ if (nb) {
+ x25_kill_by_neigh(nb);
+ x25_neigh_put(nb);
+ }
x25_route_device_down(dev);
x25_link_device_down(dev);
break;
--
2.20.1
[PATCH 4/6] net/x25: support NETDEV_CHANGE notifier
This makes it possible to handle carrier lost and detection.
In case of carrier lost, we shutdown layer 3 and flush all sessions.
Signed-off-by: Martin Schiller
---
net/x25/af_x25.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index d98d1145500e..d61a154b94e4 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -266,6 +266,17 @@ static int x25_device_event(struct notifier_block *this,
unsigned long event,
pr_debug("X.25: got event NETDEV_UNREGISTER for device:
%s\n", dev->name);
x25_link_device_remove(dev);
break;
+ case NETDEV_CHANGE:
+ pr_debug("X.25: got event NETDEV_CHANGE for device:
%s\n", dev->name);
+ if (!netif_carrier_ok(dev)) {
+ pr_debug("X.25: Carrier lost -> set link state
down: %s\n", dev->name);
+ nb = x25_get_neigh(dev);
+ if (nb) {
+ x25_link_terminated(nb);
+ x25_neigh_put(nb);
+ }
+ }
+ break;
}
}
--
2.20.1
[PATCH 2/6] net/x25: make neighbour params configurable
Extended struct x25_neigh and x25_subscrip_struct to configure following
params through SIOCX25SSUBSCRIP:
o mode (DTE/DCE)
o number of channels
o facilities (packet size, window size)
o timer T20
Based on this configuration options the follwing changes/extensions
where made:
o DTE/DCE handling to select the next lc (DCE=from bottom / DTE=from
top)
o DTE/DCE handling to set correct clear/reset/restart cause
o take default facilities from neighbour settings
Signed-off-by: Martin Schiller
---
include/net/x25.h| 7 ++-
include/uapi/linux/x25.h | 54
net/x25/af_x25.c | 132 ---
net/x25/x25_facilities.c | 6 +-
net/x25/x25_link.c | 104 +-
net/x25/x25_subr.c | 22 ++-
6 files changed, 255 insertions(+), 70 deletions(-)
diff --git a/include/net/x25.h b/include/net/x25.h
index af841c5ede28..6e8600456d39 100644
--- a/include/net/x25.h
+++ b/include/net/x25.h
@@ -140,6 +140,9 @@ struct x25_neigh {
struct net_device *dev;
unsigned intstate;
unsigned intextended;
+ unsigned intdce;
+ unsigned intlc;
+ struct x25_facilities facilities;
struct sk_buff_head queue;
unsigned long t20;
struct timer_list t20timer;
@@ -164,6 +167,7 @@ struct x25_sock {
struct timer_list timer;
struct x25_causediagcausediag;
struct x25_facilities facilities;
+ unsigned intsocket_defined_facilities; /* set, if
facilities changed by SIOCX25SFACILITIES */
struct x25_dte_facilities dte_facilities;
struct x25_calluserdata calluserdata;
unsigned long vc_facil_mask; /* inc_call facilities mask */
@@ -215,7 +219,8 @@ int x25_create_facilities(unsigned char *, struct
x25_facilities *,
struct x25_dte_facilities *, unsigned long);
int x25_negotiate_facilities(struct sk_buff *, struct sock *,
struct x25_facilities *,
-struct x25_dte_facilities *);
+ struct x25_dte_facilities *,
+ struct x25_neigh *);
void x25_limit_facilities(struct x25_facilities *, struct x25_neigh *);
/* x25_forward.c */
diff --git a/include/uapi/linux/x25.h b/include/uapi/linux/x25.h
index 034b7dc5593a..963848e94880 100644
--- a/include/uapi/linux/x25.h
+++ b/include/uapi/linux/x25.h
@@ -63,31 +63,6 @@ struct sockaddr_x25 {
struct x25_address sx25_addr; /* X.121 Address */
};
-/*
- * DTE/DCE subscription options.
- *
- * As this is missing lots of options, user should expect major
- * changes of this structure in 2.5.x which might break compatibilty.
- * The somewhat ugly dimension 200-sizeof() is needed to maintain
- * backward compatibility.
- */
-struct x25_subscrip_struct {
- char device[200-sizeof(unsigned long)];
- unsigned long global_facil_mask; /* 0 to disable negotiation */
- unsigned intextended;
-};
-
-/* values for above global_facil_mask */
-
-#defineX25_MASK_REVERSE0x01
-#defineX25_MASK_THROUGHPUT 0x02
-#defineX25_MASK_PACKET_SIZE0x04
-#defineX25_MASK_WINDOW_SIZE0x08
-
-#define X25_MASK_CALLING_AE 0x10
-#define X25_MASK_CALLED_AE 0x20
-
-
/*
* Routing table control structure.
*/
@@ -127,6 +102,35 @@ struct x25_dte_facilities {
__u8 called_ae[20];
};
+/*
+ * DTE/DCE subscription options.
+ *
+ * As this is missing lots of options, user should expect major
+ * changes of this structure in 2.5.x which might break compatibilty.
+ * The somewhat ugly dimension 200-sizeof() is needed to maintain
+ * backward compatibility.
+ */
+struct x25_subscrip_struct {
+ char device[200-((2 * sizeof(unsigned long)) + sizeof(struct
x25_facilities) + (2 * sizeof(unsigned int)))];
+ unsigned intdce;
+ unsigned intlc;
+ struct x25_facilities facilities;
+ unsigned long t20;
+ unsigned long global_facil_mask; /* 0 to disable
negotiation */
+ unsigned intextended;
+};
+
+/* values for above global_facil_mask */
+
+#defineX25_MASK_REVERSE0x01
+#defineX25_MASK_THROUGHPUT 0x02
+#defineX25_MASK_PACKET_SIZE0x04
+#defineX25_MASK_WINDOW_SIZE0x08
+
+#define X25_MASK_CALLING_AE 0x10
+#define X25_MASK_CALLED_AE 0x20
+
+
/*
* Call User Data structure.
*/
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index d8e5ca251801..439ae65ab7a8 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -72,8 +72,19 @@ static const struct proto_ops x25_proto_ops;
static const struct x25_address null_x25_address = {" "};
#ifdef CONFIG_COMPAT
+struct co
Re: [PATCH 2/3] phy: mediatek: Move mtk_mipi_dsi_phy driver into drivers/phy/mediatek folder
On 02-11-20, 07:08, Chun-Kuang Hu wrote:
> + Vinod:
>
> Hi, Chunfeng:
>
> Chunfeng Yun 於 2020年10月30日 週五 下午2:24寫道：
> >
> > On Thu, 2020-10-29 at 23:27 +0800, Chun-Kuang Hu wrote:
> > > mtk_mipi_dsi_phy is currently placed inside mediatek drm driver, but it's
> > > more suitable to place a phy driver into phy driver folder, so move
> > > mtk_mipi_dsi_phy driver into phy driver folder.
> > >
> > > Signed-off-by: Chun-Kuang Hu
> > > ---
> > > drivers/gpu/drm/mediatek/Kconfig | 7 ---
> > > drivers/gpu/drm/mediatek/Makefile | 6 --
> > > drivers/phy/mediatek/Kconfig | 7 +++
> > > drivers/phy/mediatek/Makefile | 5 +
> > > .../mediatek/phy-mtk-mipi-dsi-mt8173.c}| 2 +-
> > > .../mediatek/phy-mtk-mipi-dsi-mt8183.c}| 2 +-
> > > .../mtk_mipi_tx.c => phy/mediatek/phy-mtk-mipi-dsi.c} | 2 +-
> > > .../mtk_mipi_tx.h => phy/mediatek/phy-mtk-mipi-dsi.h} | 0
> > > 8 files changed, 15 insertions(+), 16 deletions(-)
> > > rename drivers/{gpu/drm/mediatek/mtk_mt8173_mipi_tx.c =>
> > > phy/mediatek/phy-mtk-mipi-dsi-mt8173.c} (99%)
> > > rename drivers/{gpu/drm/mediatek/mtk_mt8183_mipi_tx.c =>
> > > phy/mediatek/phy-mtk-mipi-dsi-mt8183.c} (99%)
> > > rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.c =>
> > > phy/mediatek/phy-mtk-mipi-dsi.c} (99%)
> > > rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.h =>
> > > phy/mediatek/phy-mtk-mipi-dsi.h} (100%)
> >
> > Reviewed-by: Chunfeng Yun
>
> I would like to apply the whole series into my tree, would you please
> give an acked-by tag on this patch, so I could apply this patch into
> my tree.
I would prefer this to go thru phy tree, unless there are dependencies,
which I am not clear looking at above
--
~Vinod
Re: [PATCH] phy: amlogic: Replace devm_reset_control_array_get()
On 03-11-20, 12:37, Yejune Deng wrote: > devm_reset_control_array_get_exclusive() looks more readable Applied, thanks -- ~Vinod
Re: [PATCH] irqchip/gic-v4.1: Optimize the wait for the completion of the analysis of the VPT
Hi Marc,
Friendly ping, it is some time since I sent this patch according to your last
advice...
Besides, recently we found that the mmio delay on GICv4.1 system is about 10
times higher
than that on GICv4.0 system in kvm-unit-tests (the specific data is as
follows). By the
way, HiSilicon GICv4.1 has already been implemented and will be released with
our
next-generation server, which is almost the only implementation of GICv4.1 at
present.
| GICv4.1 emulator | GICv4.0 emulator
mmio_read_user (ns) |12811 |1598
After analysis, this is mainly caused by the 10 us delay in
its_wait_vpt_parse_complete()
(the above difference is just about 10 us)...
What's your opinion about this?
Thanks,
Shenming
On 2020/9/23 14:35, Shenming Lu wrote:
> Right after a vPE is made resident, the code starts polling the
> GICR_VPENDBASER.Dirty bit until it becomes 0, where the delay_us
> is set to 10. But in our measurement, it takes only hundreds of
> nanoseconds, or 1~2 microseconds, to finish parsing the VPT in most
> cases. And we also measured the time from vcpu_load() (include it)
> to __guest_enter() on Kunpeng 920. On average, it takes 2.55 microseconds
> (not first run && the VPT is empty). So 10 microseconds delay might
> really hurt performance.
>
> To avoid this, we can set the delay_us to 1, which is more appropriate
> in this situation and universal. Besides, we can delay the execution
> of its_wait_vpt_parse_complete() (call it from kvm_vgic_flush_hwstate()
> corresponding to vPE resident), giving the GIC a chance to work in
> parallel with the CPU on the entry path.
>
> Signed-off-by: Shenming Lu
> ---
> arch/arm64/kvm/vgic/vgic-v4.c | 18 ++
> arch/arm64/kvm/vgic/vgic.c | 2 ++
> drivers/irqchip/irq-gic-v3-its.c | 14 +++---
> drivers/irqchip/irq-gic-v4.c | 11 +++
> include/kvm/arm_vgic.h | 3 +++
> include/linux/irqchip/arm-gic-v4.h | 4
> 6 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
> index b5fa73c9fd35..1d5d2d6894d3 100644
> --- a/arch/arm64/kvm/vgic/vgic-v4.c
> +++ b/arch/arm64/kvm/vgic/vgic-v4.c
> @@ -353,6 +353,24 @@ int vgic_v4_load(struct kvm_vcpu *vcpu)
> return err;
> }
>
> +void vgic_v4_wait_vpt(struct kvm_vcpu *vcpu)
> +{
> + struct its_vpe *vpe;
> +
> + if (kvm_vgic_global_state.type == VGIC_V2 ||
> !vgic_supports_direct_msis(vcpu->kvm))
> + return;
> +
> + vpe = &vcpu->arch.vgic_cpu.vgic_v3.its_vpe;
> +
> + if (vpe->vpt_ready)
> + return;
> +
> + if (its_wait_vpt(vpe))
> + return;
> +
> + vpe->vpt_ready = true;
> +}
> +
> static struct vgic_its *vgic_get_its(struct kvm *kvm,
>struct kvm_kernel_irq_routing_entry
> *irq_entry)
> {
> diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
> index c3643b7f101b..ed810a80cda2 100644
> --- a/arch/arm64/kvm/vgic/vgic.c
> +++ b/arch/arm64/kvm/vgic/vgic.c
> @@ -915,6 +915,8 @@ void kvm_vgic_flush_hwstate(struct kvm_vcpu *vcpu)
>
> if (can_access_vgic_from_kernel())
> vgic_restore_state(vcpu);
> +
> + vgic_v4_wait_vpt(vcpu);
> }
>
> void kvm_vgic_load(struct kvm_vcpu *vcpu)
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index 548de7538632..b7cbc9bcab9d 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -3803,7 +3803,7 @@ static void its_wait_vpt_parse_complete(void)
> WARN_ON_ONCE(readq_relaxed_poll_timeout_atomic(vlpi_base +
> GICR_VPENDBASER,
> val,
> !(val &
> GICR_VPENDBASER_Dirty),
> -10, 500));
> +1, 500));
> }
>
> static void its_vpe_schedule(struct its_vpe *vpe)
> @@ -3837,7 +3837,7 @@ static void its_vpe_schedule(struct its_vpe *vpe)
> val |= GICR_VPENDBASER_Valid;
> gicr_write_vpendbaser(val, vlpi_base + GICR_VPENDBASER);
>
> - its_wait_vpt_parse_complete();
> + vpe->vpt_ready = false;
> }
>
> static void its_vpe_deschedule(struct its_vpe *vpe)
> @@ -3881,6 +3881,10 @@ static int its_vpe_set_vcpu_affinity(struct irq_data
> *d, void *vcpu_info)
> its_vpe_schedule(vpe);
> return 0;
>
> + case WAIT_VPT:
> + its_wait_vpt_parse_complete();
> + return 0;
> +
> case DESCHEDULE_VPE:
> its_vpe_deschedule(vpe);
> return 0;
> @@ -4047,7 +4051,7 @@ static void its_vpe_4_1_schedule(struct its_vpe *vpe,
>
> gicr_write_vpendbaser(val, vlpi_base + GICR_VPENDBASER);
>
> - its_wait_vpt_parse_complete();
> + vpe->vpt_ready = false;
> }
>
> static void its_
Re: [PATCH v2 01/17] phy: allwinner: convert to devm_platform_ioremap_resource(_byname)
On 06-11-20, 14:08, Chunfeng Yun wrote: > Use devm_platform_ioremap_resource(_byname) to simplify code Applied all, thanks -- ~Vinod
Re: [PATCH] dt-bindings: phy: Add Cadence Sierra PHY bindings in YAML format
On 28-10-20, 16:22, Swapnil Jakhade wrote: > Add Cadence Sierra PHY bindings in YAML format. Applied, thanks -- ~Vinod
[PATCH v2] checkpatch: add fix option for MAINTAINERS_STYLE
Checkpatch expects entries in MAINTAINERS file in a specific order and
warns if the changes made do not follow the specified order.
E.g., running checkpatch on commit 6f736909f0a4 ("MAINTAINERS: Add
patchwork link for PWM entry") reports this warning:
WARNING: Misordered MAINTAINERS entry - list 'Q:' before 'T:'
T: git
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git
+Q: https://patchwork.ozlabs.org/project/linux-pwm/list/
Provide a simple fix by swapping the unordered lines
Signed-off-by: Aditya Srivastava
---
Changes in v2:
modified commit message
scripts/checkpatch.pl | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 2749f32dffe9..c9443265 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3299,13 +3299,22 @@ sub process {
"Unknown MAINTAINERS entry type:
'$cur'\n" . $herecurr);
} else {
if ($previndex >= 0 && $curindex <
$previndex) {
- WARN("MAINTAINERS_STYLE",
-"Misordered MAINTAINERS
entry - list '$cur:' before '$prev:'\n" . $hereprev);
+ if (WARN("MAINTAINERS_STYLE",
+"Misordered
MAINTAINERS entry - list '$cur:' before '$prev:'\n" . $hereprev) &&
+ $fix) {
+ # swap these lines
+ $fixed[$fixlinenr - 1]
= $rawline;
+ $fixed[$fixlinenr] =
$prevrawline;
+ }
} elsif ((($prev eq 'F' && $cur eq 'F')
||
($prev eq 'X' && $cur eq
'X')) &&
($prevval cmp $curval) > 0) {
- WARN("MAINTAINERS_STYLE",
-"Misordered MAINTAINERS
entry - list file patterns in alphabetic order\n" . $hereprev);
+ if (WARN("MAINTAINERS_STYLE",
+"Misordered
MAINTAINERS entry - list file patterns in alphabetic order\n" . $hereprev) &&
+ $fix) {
+ $fixed[$fixlinenr - 1]
= $rawline;
+ $fixed[$fixlinenr] =
$prevrawline;
+ }
}
}
}
--
2.17.1
RE: [EXT] Re: [PATCH v3 3/4] arm64: dts: imx8m: add nvmem-cell related stuff
> -Original Message- > From: Krzysztof Kozlowski > Sent: 2020年11月15日 0:01 > To: Alice Guo > Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de; > dl-linux-imx ; Peng Fan ; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org > Subject: [EXT] Re: [PATCH v3 3/4] arm64: dts: imx8m: add nvmem-cell related > stuff > > Caution: EXT Email > > On Fri, Nov 13, 2020 at 07:04:08PM +0800, Alice Guo wrote: > > Add nvmem-cell related stuff for the soc unique ID. > > Do not silently ignore comments during review. Let me repeat my comment > from v1: > > Subject and commit msg: please do not add "stuff" but describe what are you > adding and why (what is the purpose, feature, benefit). > "Stuff" is too generic. > > I can rephrase it, since maybe I was not understood. Do not use words like > "stuff" or "thing". Instead describe exactly what you are adding and answer to > the most important question: why are you adding it. > > Best regards, > Krzysztof > [Alice Guo] Hi, I will modify according to your comment. Best Regards, Alice > > > > Signed-off-by: Alice Guo > > --- > > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 6 ++ > > arch/arm64/boot/dts/freescale/imx8mn.dtsi | 6 ++ > > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 6 ++ > > arch/arm64/boot/dts/freescale/imx8mq.dtsi | 6 ++ > > 4 files changed, 24 insertions(+)
Re: [RESEND PATCH 03/10] fpga: fpga-mgr: dfl-fme-mgr: Simplify registration
Tested on DFL FPGA platform, it is OK.
Thanks,
Yilun
On Sun, Nov 15, 2020 at 11:51:20AM -0800, Moritz Fischer wrote:
> Simplify registration using new devm_fpga_mgr_register() API.
>
> Reviewed-by: Tom Rix
> Signed-off-by: Moritz Fischer
> ---
> drivers/fpga/dfl-fme-mgr.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c
> index b3f7eee3c93f..d5861d13b306 100644
> --- a/drivers/fpga/dfl-fme-mgr.c
> +++ b/drivers/fpga/dfl-fme-mgr.c
> @@ -314,18 +314,8 @@ static int fme_mgr_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> mgr->compat_id = compat_id;
> - platform_set_drvdata(pdev, mgr);
>
> - return fpga_mgr_register(mgr);
> -}
> -
> -static int fme_mgr_remove(struct platform_device *pdev)
> -{
> - struct fpga_manager *mgr = platform_get_drvdata(pdev);
> -
> - fpga_mgr_unregister(mgr);
> -
> - return 0;
> + return devm_fpga_mgr_register(dev, mgr);
> }
>
> static struct platform_driver fme_mgr_driver = {
> @@ -333,7 +323,6 @@ static struct platform_driver fme_mgr_driver = {
> .name= DFL_FPGA_FME_MGR,
> },
> .probe = fme_mgr_probe,
> - .remove = fme_mgr_remove,
> };
>
> module_platform_driver(fme_mgr_driver);
> --
> 2.29.2
Re: [PATCH v2 1/6] bus: mhi: core: Allow receiving a STOP channel command response
On Wed, Nov 11, 2020 at 11:21:08AM -0800, Bhaumik Bhatt wrote: > Add support to receive the response to a STOP channel command to the > MHI bus. If a client would like to STOP a channel instead of issuing > a RESET to it, this would provide support for it. > > Signed-off-by: Bhaumik Bhatt > --- > drivers/bus/mhi/core/init.c | 5 +++-- > drivers/bus/mhi/core/main.c | 5 + > 2 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c > index 8cefa35..4d34d62 100644 > --- a/drivers/bus/mhi/core/init.c > +++ b/drivers/bus/mhi/core/init.c > @@ -1267,8 +1267,9 @@ static int mhi_driver_remove(struct device *dev) > > mutex_lock(&mhi_chan->mutex); > > - if (ch_state[dir] == MHI_CH_STATE_ENABLED && > - !mhi_chan->offload_ch) > + if ((ch_state[dir] == MHI_CH_STATE_ENABLED || > + ch_state[dir] == MHI_CH_STATE_STOP) && This enum is not defined in this patch so it'll break. Please add a separate patch which introduces the new state enums alone and then have patches 1/2 as a followup. Also this change is not belonging to this commit I believe. Thanks, Mani > + !mhi_chan->offload_ch) > mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan); > > mhi_chan->ch_state = MHI_CH_STATE_DISABLED; > diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c > index f953e2a..ad881a1 100644 > --- a/drivers/bus/mhi/core/main.c > +++ b/drivers/bus/mhi/core/main.c > @@ -1194,6 +1194,11 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl, > cmd_tre->dword[0] = MHI_TRE_CMD_RESET_DWORD0; > cmd_tre->dword[1] = MHI_TRE_CMD_RESET_DWORD1(chan); > break; > + case MHI_CMD_STOP_CHAN: > + cmd_tre->ptr = MHI_TRE_CMD_STOP_PTR; > + cmd_tre->dword[0] = MHI_TRE_CMD_STOP_DWORD0; > + cmd_tre->dword[1] = MHI_TRE_CMD_STOP_DWORD1(chan); > + break; > case MHI_CMD_START_CHAN: > cmd_tre->ptr = MHI_TRE_CMD_START_PTR; > cmd_tre->dword[0] = MHI_TRE_CMD_START_DWORD0; > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
RE: [EXT] Re: [PATCH v3 2/4] arm64: dts: imx8m: add compatible string to .dtsi file
> -Original Message- > From: Krzysztof Kozlowski > Sent: 2020年11月14日 23:57 > To: Alice Guo > Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de; > dl-linux-imx ; Peng Fan ; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org > Subject: [EXT] Re: [PATCH v3 2/4] arm64: dts: imx8m: add compatible string > to .dtsi file > > Caution: EXT Email > > On Fri, Nov 13, 2020 at 07:04:07PM +0800, Alice Guo wrote: > > Where is the changelog against v2? > > Change the subject to: "arm64: dts: imx8m: add SoC ID compatible". It is kind > of obvious that you add it to DTSI files, so no need to put it into the > subject. > > > Add compatible string to .dtsi file for binding of > > imx8_soc_init_driver and device. > > s/file/files/ > > With above changes: > Reviewed-by: Krzysztof Kozlowski [Alice Guo] Hi, I will modify according to your comment. Best regards, Alice > Best regards, > Krzysztof
Re: [PATCH 1/2] mmc: sdhci-of-arasan: Use Mask writes for Tap delays
On 16. 11. 20 7:15, Manish Narani wrote:
> Mask the ITAP and OTAP delay bits before updating with the new
> tap value for Versal platform.
>
> Fixes: 1a470721c8f5 ("sdhci: arasan: Add support for Versal Tap Delays")
> Signed-off-by: Sai Krishna Potthuri
> Signed-off-by: Manish Narani
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c
> b/drivers/mmc/host/sdhci-of-arasan.c
> index 100621e55427..3ec5ecad637c 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -30,7 +30,10 @@
> #define SDHCI_ARASAN_VENDOR_REGISTER 0x78
>
> #define SDHCI_ARASAN_ITAPDLY_REGISTER0xF0F8
> +#define SDHCI_ARASAN_ITAPDLY_SEL_MASK0xFF
> +
> #define SDHCI_ARASAN_OTAPDLY_REGISTER0xF0FC
> +#define SDHCI_ARASAN_OTAPDLY_SEL_MASK0x3F
>
> #define SDHCI_ARASAN_CQE_BASE_ADDR 0x200
> #define VENDOR_ENHANCED_STROBE BIT(0)
> @@ -755,6 +758,7 @@ static int sdhci_versal_sdcardclk_set_phase(struct clk_hw
> *hw, int degrees)
> regval = sdhci_readl(host, SDHCI_ARASAN_OTAPDLY_REGISTER);
> regval |= SDHCI_OTAPDLY_ENABLE;
> sdhci_writel(host, regval, SDHCI_ARASAN_OTAPDLY_REGISTER);
> + regval &= ~SDHCI_ARASAN_OTAPDLY_SEL_MASK;
> regval |= tap_delay;
> sdhci_writel(host, regval, SDHCI_ARASAN_OTAPDLY_REGISTER);
> }
> @@ -822,6 +826,7 @@ static int sdhci_versal_sampleclk_set_phase(struct clk_hw
> *hw, int degrees)
> sdhci_writel(host, regval, SDHCI_ARASAN_ITAPDLY_REGISTER);
> regval |= SDHCI_ITAPDLY_ENABLE;
> sdhci_writel(host, regval, SDHCI_ARASAN_ITAPDLY_REGISTER);
> + regval &= ~SDHCI_ARASAN_ITAPDLY_SEL_MASK;
> regval |= tap_delay;
> sdhci_writel(host, regval, SDHCI_ARASAN_ITAPDLY_REGISTER);
> regval &= ~SDHCI_ITAPDLY_CHGWIN;
>
Acked-by: Michal Simek
Thanks,
Michal
Re: [PATCH v2] PCI: check also dynamic IDs for duplicate in new_id_store()
Hi Bjorn, On Sat, Nov 14, 2020 at 6:47 AM Bjorn Helgaas wrote: > > [+cc Alex, Cornelia in case VFIO cares about new_id/remove_id > semantics] > > On Mon, Oct 26, 2020 at 11:57:10AM +0800, Zhenzhong Duan wrote: > > When a device ID data is writen to /sys/bus/pci/drivers/.../new_id, > > only static ID table is checked for duplicate and multiple dynamic ID > > entries of same kind are allowed to exist in a dynamic linked list. > > This doesn't quite say what the problem is. > > I see that currently new_id_store() uses pci_match_id() to see if the > new device ID is in the static id_table, so adding the same ID twice > adds multiple entries to the dynids list. That does seem wrong, and I > think we should fix it. > > But I would like to clarify this commit log so we know whether the > current behavior causes user-visible broken behavior. The dynids list > is mostly used by pci_match_device(), and it looks like duplicate > entries shouldn't cause it a problem. > > I guess remove_id_store() will only remove one of the duplicate > entries, so if we add an ID several times, we would have to remove it > the same number of times before it's completely gone. Current behavior doesn't cause user-visible broken behavior, only not user friendly. One has to remove an ID at least twice to ensure it's really removed if he doesn't know how many times it has been added before. > > > Fix it by calling pci_match_device() which checks both dynamic and static > > IDs. > > > > After fix, it shows below result which is expected. > > > > echo "1af4:1000" > /sys/bus/pci/drivers/vfio-pci/new_id > > echo "1af4:1000" > /sys/bus/pci/drivers/vfio-pci/new_id > > -bash: echo: write error: File exists > > > > Drop the static specifier and add a prototype to avoid build error. > > I don't get this part. You added a prototype in include/linux/pci.h, > which means you expect callers outside drivers/pci. But there aren't > any. > > In fact, you're only adding a call in the same file where > pci_match_device() is defined. The usual way to resolve that is to > move the pci_match_device() definition before the call, so no forward > declaration is needed and the function can remain static. > > I think pci_match_id() and pci_match_device() should both be moved so > they remain together. It would be nice if the move itself were a > no-op patch separate from the one that changes new_id_store(). Yes, that's better, will do, thanks for your suggestions. Zhenzhong
Antw: [EXT] [systemd-devel] [SPECIFICATION RFC] The firmware and bootloader log specification
>>> Daniel Kiper schrieb am 14.11.2020 um 00:52 in Nachricht <20201113235242.k6fzlwmwm2xqh...@tomti.i.net-space.pl>: ... > The members of struct bf_log_msg: > ‑ size: total size of bf_log_msg struct, > ‑ ts_nsec: timestamp expressed in nanoseconds starting from 0, Who or what defines t == 0? ... Regards, Ulrich Windl
Re: [PATCH 2/2] mmc: sdhci-of-arasan: Issue DLL reset explicitly
On 16. 11. 20 7:15, Manish Narani wrote:
> In the current implementation DLL reset will be issued for
> each ITAP and OTAP setting inside ATF, this is creating issues
> in some scenarios and this sequence is not inline with the TRM.
> To fix the issue, DLL reset should be removed from the ATF and
> host driver will request it explicitly.
> This patch update host driver to explicitly request for DLL reset
> before ITAP (assert DLL) and after OTAP (release DLL) settings.
>
> Fixes: a5c8b2ae2e51 ("mmc: sdhci-of-arasan: Add support for ZynqMP Platform
> Tap Delays Setup")
> Signed-off-by: Sai Krishna Potthuri
> Signed-off-by: Manish Narani
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c
> b/drivers/mmc/host/sdhci-of-arasan.c
> index 3ec5ecad637c..e066d8f51954 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -635,6 +635,9 @@ static int sdhci_zynqmp_sdcardclk_set_phase(struct clk_hw
> *hw, int degrees)
> if (ret)
> pr_err("Error setting Output Tap Delay\n");
>
> + eemi_ops->ioctl(node_id, IOCTL_SD_DLL_RESET,
> + PM_DLL_RESET_RELEASE, 0, NULL);
> +
> return ret;
> }
>
> @@ -794,6 +797,9 @@ static int sdhci_versal_sampleclk_set_phase(struct clk_hw
> *hw, int degrees)
> if (host->version < SDHCI_SPEC_300)
> return 0;
>
> + eemi_ops->ioctl(node_id, IOCTL_SD_DLL_RESET,
> + PM_DLL_RESET_ASSERT, 0, NULL);
> +
> switch (host->timing) {
> case MMC_TIMING_MMC_HS:
> case MMC_TIMING_SD_HS:
>
this won't apply. It needs to be fixed.
Thanks,
Michal
Re: [GIT PULL] bootconfig: Extend the magic check range to the preceding 3 bytes
On Fri, 13 Nov 2020 13:03:05 -0500 Steven Rostedt wrote: > On Fri, 13 Nov 2020 09:57:54 -0800 > Linus Torvalds wrote: > > > On Fri, Nov 13, 2020 at 9:54 AM Steven Rostedt wrote: > > > > > > The issue is that grub padded the end of the ramdisk after loading it > > > into memory. I'm not sure how the bootconfig tool can fix this. Perhaps > > > make sure the ram disk size is 4 bytes aligned? > > > > Exactly. Since - as far as I can tell - the _only_ thing that actually > > generates that BOOTCONFIG_MAGIC marker is the bootconfig tool, you > > control the vertical and the horizontal. No need for some "heuristic" > > and searching for things. > > > > And then that thing needs to be documented, so that if somebody else > > starts generating BOOTCONFIG_MAGIC markers, we have a hard rule in > > place that "look, the bootconfig is always aligned". > > > > Might as well align it more than 4 bytes while at it and make it even > > stricter. > > > > OK, yes I agree with this. OK, but note that the initrd_end can be modified by the bootloader anyway. The bootloader can pass any "size" bigger than actual initramfs size because initramfs is a cpio file which has a "TRAILER!!!" magic as the end of file. This means kernel can ignore or use (as the bootconfig does) for a tailing data storage. But I agree that we need to document it, so that anyone can refer the data format. > Masami, can you send a patch to fix the bootconfig tool to make sure > that when it appends to the initrd that it makes sure the file size is > aligned. Would 32 bytes be big enough for an alignment? OK, it is easy to me to update bootconfig tool to align up the total size to 32bytes, but I think 4 bytes align is OK if we document it. Without documentation, no one in the bootloader decides what is the correct format. Thank you, -- Masami Hiramatsu
[PATCH V3] clocksource/drivers/cadence_ttc: fix memory leak in ttc_setup_clockevent()
If clk_notifier_register() failed, ttc_setup_clockevent() will return
without freeing 'ttcce', which will leak memory.
Fixes: 70504f311d4b ("clocksource/drivers/cadence_ttc: Convert init function to
return error")
Reported-by: Hulk Robot
Signed-off-by: Yu Kuai
---
drivers/clocksource/timer-cadence-ttc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/clocksource/timer-cadence-ttc.c
b/drivers/clocksource/timer-cadence-ttc.c
index 80e960602030..c410d1620e24 100644
--- a/drivers/clocksource/timer-cadence-ttc.c
+++ b/drivers/clocksource/timer-cadence-ttc.c
@@ -413,10 +413,8 @@ static int __init ttc_setup_clockevent(struct clk *clk,
ttcce->ttc.clk = clk;
err = clk_prepare_enable(ttcce->ttc.clk);
- if (err) {
- kfree(ttcce);
- return err;
- }
+ if (err)
+ go out_kfree;
ttcce->ttc.clk_rate_change_nb.notifier_call =
ttc_rate_change_clockevent_cb;
@@ -426,7 +424,7 @@ static int __init ttc_setup_clockevent(struct clk *clk,
&ttcce->ttc.clk_rate_change_nb);
if (err) {
pr_warn("Unable to register clock notifier.\n");
- return err;
+ goto out_kfree;
}
ttcce->ttc.freq = clk_get_rate(ttcce->ttc.clk);
@@ -455,15 +453,17 @@ static int __init ttc_setup_clockevent(struct clk *clk,
err = request_irq(irq, ttc_clock_event_interrupt,
IRQF_TIMER, ttcce->ce.name, ttcce);
- if (err) {
- kfree(ttcce);
- return err;
- }
+ if (err)
+ goto out_kfree;
clockevents_config_and_register(&ttcce->ce,
ttcce->ttc.freq / PRESCALE, 1, 0xfffe);
return 0;
+
+out_kfree:
+ kfree(ttcce);
+ return err;
}
static int __init ttc_timer_probe(struct platform_device *pdev)
--
2.25.4
RE: [EXT] Re: [PATCH v3 1/4] dt-bindings: soc: imx8m: add DT Binding doc for soc unique ID
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: 2020年11月15日 0:50
> To: Alice Guo
> Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de;
> dl-linux-imx ; Peng Fan ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org
> Subject: [EXT] Re: [PATCH v3 1/4] dt-bindings: soc: imx8m: add DT Binding doc
> for soc unique ID
>
> Caution: EXT Email
>
> On Fri, Nov 13, 2020 at 07:04:06PM +0800, Alice Guo wrote:
> > Add DT Binding doc for the Unique ID of i.MX 8M series.
> >
> > Signed-off-by: Alice Guo
> > ---
> > .../devicetree/bindings/arm/fsl.yaml | 25
> +++
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
> > b/Documentation/devicetree/bindings/arm/fsl.yaml
> > index e4db0f9ed664..f4faebbb57da 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > @@ -901,6 +901,31 @@ properties:
> >- fsl,s32v234-evb # S32V234-EVB2 Customer
> Evaluation Board
> >- const: fsl,s32v234
> >
> > + soc:
> > +type: object
> > +properties:
> > + compatible:
> > +oneOf:
> > + - description: i.MX8M SoCs
> > +items:
> > + - enum:
> > + - fsl,imx8mm-soc
> > + - fsl,imx8mn-soc
> > + - fsl,imx8mp-soc
> > + - fsl,imx8mq-soc
> > + - const: simple-bus
> > +
> > + - description: Other SoCs
> > +items:
> > + - const: simple-bus
> > +
> > + nvmem-cells:
> > +maxItems: 1
> > +description: Phandle to the SOC Unique ID provided by a nvmem
> > + node
> > +
> > + nvmem-cells-names:
> > +const: soc_unique_id
> > +
> > additionalProperties: true
>
> The "soc" node should be required for these compatibles. Otherwise you will
> have to stay with this backwards-compatible-DTB-device-initcall-glue for many
> years... I think you can achieve it with allOf.
>
[Alice Guo]Hi,
I find that my description for compatible is ambiguous. There are two kinds of
compatible of the "soc" node:
1. For dtsi files used for SoCs other than imx8m series SoCs and old version
dtsi files used for imx8m series SoCs,
compatible of the "soc" node is "simple-bus".
2. For new version dtsi files used for imx8m series SoCs, compatible of the
"soc" node is {"fsl,imx8mX-soc","simple-bus"}.
"nvmem-cell" is an optional property.
I do not understand what you mean. You mean that limit the compatible of "soc"
node must include " fsl,imx8mX-soc" in new version dts files. Is my
understanding correct?
Best regards,
Alice
> Best regards,
> Krzysztof
[rcu:dev.2020.11.10a] BUILD REGRESSION 1bc2f285f9c940176cc2c231db1372d5b2f0c635
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2020.11.10a branch HEAD: 1bc2f285f9c940176cc2c231db1372d5b2f0c635 EXP refscale: Allow summarization of verbose output Error/Warning reports: https://lore.kernel.org/lkml/202011160746.rmedmjqm-...@intel.com Error/Warning in current branch: ERROR: modpost: "get_state_synchronize_srcu" [kernel/rcu/rcutorture.ko] undefined! ERROR: modpost: "poll_state_synchronize_srcu" [kernel/rcu/rcutorture.ko] undefined! ERROR: modpost: "start_poll_synchronize_srcu" [kernel/rcu/rcutorture.ko] undefined! Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- i386-randconfig-m021-20201115 | |-- ERROR:get_state_synchronize_srcu-kernel-rcu-rcutorture.ko-undefined | |-- ERROR:poll_state_synchronize_srcu-kernel-rcu-rcutorture.ko-undefined | `-- ERROR:start_poll_synchronize_srcu-kernel-rcu-rcutorture.ko-undefined `-- x86_64-randconfig-s022-20201115 |-- ERROR:get_state_synchronize_srcu-kernel-rcu-rcutorture.ko-undefined |-- ERROR:poll_state_synchronize_srcu-kernel-rcu-rcutorture.ko-undefined `-- ERROR:start_poll_synchronize_srcu-kernel-rcu-rcutorture.ko-undefined elapsed time: 721m configs tested: 110 configs skipped: 2 gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm lpc32xx_defconfig mipse55_defconfig openrisc simple_smp_defconfig powerpc allnoconfig sh rts7751r2d1_defconfig riscvnommu_k210_defconfig arm eseries_pxa_defconfig mips malta_kvm_defconfig m68k amcore_defconfig arm viper_defconfig ia64 tiger_defconfig mips capcella_defconfig mipsnlm_xlr_defconfig shdreamcast_defconfig h8300 h8s-sim_defconfig powerpc64 defconfig xtensa alldefconfig powerpc pmac32_defconfig nios2 defconfig nds32alldefconfig powerpc ppc40x_defconfig arm badge4_defconfig umkunit_defconfig sh rsk7203_defconfig powerpc mpc834x_itxgp_defconfig mips xway_defconfig alpha defconfig riscv allnoconfig powerpc mpc512x_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig i386 randconfig-a006-20201116 i386 randconfig-a005-20201116 i386 randconfig-a001-20201116 i386 randconfig-a002-20201116 i386 randconfig-a004-20201116 i386 randconfig-a003-20201116 i386 randconfig-a006-20201115 i386 randconfig-a005-20201115 i386 randconfig-a001-20201115 i386 randconfig-a002-20201115 i386 randconfig-a004-20201115 i386 randconfig-a003-20201115 x86_64 randconfig-a015-20201115 x86_64 randconfig-a011-20201115 x86_64 randconfig-a014-20201115 x86_64 randconfig-a013-20201115 x86_64 randconfig-a016-20201115 x86_64
linux-next: Tree for Nov 16
Hi all, Changes since 20201113: The drivers-memory tree lost its build failure. The ext3 tree lost its build failure. The amdgpu tree gained a conflict against the drm tree. The usb-chipidea-next tree lost its build failure. Non-merge commits (relative to Linus' tree): 5389 5443 files changed, 532938 insertions(+), 90825 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 327 trees (counting Linus' and 85 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (a6af8718b98e Merge tag 'drm-fixes-2020-11-16' of git://anongit.freedesktop.org/drm/drm) Merging fixes/fixes (9123e3a74ec7 Linux 5.9-rc1) Merging kbuild-current/fixes (d1889589a4f5 builddeb: Fix rootless build in setuid/setgid directory) Merging arc-current/for-curr (3b57533b460c ARC: [plat-hsdk] Remap CCMs super early in asm boot trampoline) Merging arm-current/fixes (9fa2e7af3d53 ARM: 9019/1: kprobes: Avoid fortify_panic() when copying optprobe template) Merging arm64-fixes/for-next/fixes (23c216416056 arm64: cpu_errata: Apply Erratum 845719 to KRYO2XX Silver) Merging arm-soc-fixes/arm/fixes (b57d5437e374 Merge tag 'sunxi-fixes-for-5.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/fixes) Merging drivers-memory-fixes/fixes (275374b46da2 memory: pl353-smc: fix compile test on !ARM_AMBA) Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver to platform driver) Merging powerpc-fixes/fixes (01776f070ffc powerpc/32s: Use relocation offset when setting early hash table) Merging s390-fixes/fixes (78d732e1f326 s390/cpum_sf.c: fix file permission for cpum_sfb_size) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (849920c70339 devlink: Add missing genlmsg_cancel() in devlink_nl_sb_port_pool_fill()) Merging bpf/master (f782e2c300a7 bpf: Relax return code check for subprograms) Merging ipsec/master (48f486e13ffd net: xfrm: fix memory leak in xfrm_user_policy()) Merging netfilter/master (fea07a487c6d net: openvswitch: silence suspicious RCU usage warning) Merging ipvs/master (fea07a487c6d net: openvswitch: silence suspicious RCU usage warning) Merging wireless-drivers/master (fe56d05ee6c8 iwlwifi: mvm: fix kernel panic in case of assert during CSA) Merging mac80211/master (1395f8df87b0 Merge tag 'mac80211-for-net-2020-11-13' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging rdma-fixes/for-rc (f8394f232b1e Linux 5.10-rc3) Merging sound-current/for-linus (02a9c6ee4183 ALSA: firewire: Clean up a locking issue in copy_resp_to_buf()) Merging sound-asoc-fixes/for-linus (ee57a9cf5438 Merge remote-tracking branch 'asoc/for-5.10' into asoc-linus) Merging regmap-fixes/for-linus (3650b228f83a Linux 5.10-rc1) Merging regulator-fixes/for-linus (f5c042b23f74 regulator: workaround self-referent regulators) Merging spi-fixes/for-linus (386eaa2deaba Merge remote-tracking branch 'spi/for-5.10' into spi-linus) Merging pci-current/for-linus (51e2e24504ad PCI: Add function 1 DMA alias quirk for Marvell 9215 SATA controller) Merging driver-core.current/driver-core-linus (f8394f232b1e Linux 5.10-rc3) Merging tty.current/tty-linus (4
[PATCH] scsi: sd: remove obsolete variable in sd_remove()
Commit 140ea3bbf39a ("sd: use __register_blkdev to avoid a modprobe for an
unregistered dev_t") removed blk_register_region(devt, ...) in sd_remove()
and since then, devt is unused in sd_remove().
Hence, make W=1 warns:
drivers/scsi/sd.c:3516:8:
warning: variable 'devt' set but not used [-Wunused-but-set-variable]
Simply remove this obsolete variable.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on current master and next-20201113
Christoph, Hannes, please ack.
Martin, James, please pick this minor non-urgent clean-up patch.
drivers/scsi/sd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 106a9cda0eb7..82d0cb97b758 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -3513,10 +3513,8 @@ static int sd_probe(struct device *dev)
static int sd_remove(struct device *dev)
{
struct scsi_disk *sdkp;
- dev_t devt;
sdkp = dev_get_drvdata(dev);
- devt = disk_devt(sdkp->disk);
scsi_autopm_get_device(sdkp->device);
async_synchronize_full_domain(&scsi_sd_pm_domain);
--
2.17.1
[PATCH] lockdep: fix the typo
Fix the 'signle' to 'single".
Signed-off-by: Huang Shijie
---
include/linux/lockdep_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/lockdep_types.h b/include/linux/lockdep_types.h
index 9a1fd49df17f..1989017d663f 100644
--- a/include/linux/lockdep_types.h
+++ b/include/linux/lockdep_types.h
@@ -46,7 +46,7 @@ enum lockdep_wait_type {
* NR_LOCKDEP_CACHING_CLASSES ... Number of classes
* cached in the instance of lockdep_map
*
- * Currently main class (subclass == 0) and signle depth subclass
+ * Currently main class (subclass == 0) and single depth subclass
* are cached in lockdep_map. This optimization is mainly targeting
* on rq->lock. double_rq_lock() acquires this highly competitive with
* single depth.
--
2.17.1
[PATCH v1 0/9] scsi: ufs: Refactoring and cleanups
Hi, This series simply do some refactoring and cleanups in UFS drivers. Stanley Chu (9): scsi: ufs-mediatek: Refactor performance scaling functions scsi: ufs: Introduce device parameter initialization function scsi: ufs-mediatek: Use device parameter initialization function scsi: ufs-qcom: Use device parameter initialization function scsi: ufs-exynos: Use device parameter initialization function scsi: ufs-hisi: Use device parameter initialization function scsi: ufs: Refactor ADAPT configuration function scsi: ufs-mediatek: Use common ADAPT configuration function scsi: ufs-qcom: Use common ADAPT configuration function drivers/scsi/ufs/ufs-exynos.c| 15 +- drivers/scsi/ufs/ufs-exynos.h| 13 drivers/scsi/ufs/ufs-hisi.c | 13 +--- drivers/scsi/ufs/ufs-hisi.h | 13 drivers/scsi/ufs/ufs-mediatek.c | 51 ++-- drivers/scsi/ufs/ufs-mediatek.h | 16 -- drivers/scsi/ufs/ufs-qcom.c | 27 +++-- drivers/scsi/ufs/ufs-qcom.h | 11 --- drivers/scsi/ufs/ufshcd-pltfrm.c | 17 +++ drivers/scsi/ufs/ufshcd-pltfrm.h | 1 + drivers/scsi/ufs/ufshcd.c| 16 ++ drivers/scsi/ufs/ufshcd.h| 3 ++ 12 files changed, 65 insertions(+), 131 deletions(-) -- 2.18.0
[PATCH net-next] r8153_ecm: avoid to be prior to r8152 driver
Avoid r8153_ecm is compiled as built-in, if r8152 driver is compiled
as modules. Otherwise, the r8153_ecm would be used, even though the
device is supported by r8152 driver.
Fixes: c1aedf015ebd ("net/usb/r8153_ecm: support ECM mode for RTL8153")
Reported-by: Marek Szyprowski
Signed-off-by: Hayes Wang
---
drivers/net/usb/Makefile | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 99381e6bea78..98f4c100955e 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_USB_LAN78XX) += lan78xx.o
obj-$(CONFIG_USB_NET_AX8817X) += asix.o
asix-y := asix_devices.o asix_common.o ax88172a.o
obj-$(CONFIG_USB_NET_AX88179_178A) += ax88179_178a.o
-obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o r8153_ecm.o
+obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o
obj-$(CONFIG_USB_NET_CDC_EEM) += cdc_eem.o
obj-$(CONFIG_USB_NET_DM9601) += dm9601.o
obj-$(CONFIG_USB_NET_SR9700) += sr9700.o
@@ -41,3 +41,11 @@ obj-$(CONFIG_USB_NET_QMI_WWAN) += qmi_wwan.o
obj-$(CONFIG_USB_NET_CDC_MBIM) += cdc_mbim.o
obj-$(CONFIG_USB_NET_CH9200) += ch9200.o
obj-$(CONFIG_USB_NET_AQC111) += aqc111.o
+
+ifdef CONFIG_USB_NET_CDCETHER
+ifeq ($(CONFIG_USB_RTL8152), m)
+obj-$(CONFIG_USB_RTL8152) += r8153_ecm.o
+else
+obj-$(CONFIG_USB_NET_CDCETHER) += r8153_ecm.o
+endif
+endif
--
2.26.2
[PATCH v1 8/9] scsi: ufs-mediatek: Use common ADAPT configuration function
Use common ADAPT configuration function to reduce duplicated
code in UFS drivers.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-mediatek.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 87b4bf125e23..1d3c5cd4592e 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -677,7 +677,6 @@ static int ufs_mtk_pre_pwr_change(struct ufs_hba *hba,
{
struct ufs_mtk_host *host = ufshcd_get_variant(hba);
struct ufs_dev_params host_cap;
- u32 adapt_val;
int ret;
ufshcd_init_pwr_dev_param(&host_cap);
@@ -693,13 +692,9 @@ static int ufs_mtk_pre_pwr_change(struct ufs_hba *hba,
}
if (host->hw_ver.major >= 3) {
- if (dev_req_params->gear_tx == UFS_HS_G4)
- adapt_val = PA_INITIAL_ADAPT;
- else
- adapt_val = PA_NO_ADAPT;
- ufshcd_dme_set(hba,
- UIC_ARG_MIB(PA_TXHSADAPTTYPE),
- adapt_val);
+ ret = ufshcd_dme_configure_adapt(hba,
+ dev_req_params->gear_tx,
+ PA_INITIAL_ADAPT);
}
return ret;
--
2.18.0
[PATCH v1 9/9] scsi: ufs-qcom: Use common ADAPT configuration function
Use common ADAPT configuration function to reduce duplicated
code in UFS drivers.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-qcom.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 04adfbd10753..1e434cce0f79 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -723,17 +723,9 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
ufs_qcom_dev_ref_clk_ctrl(host, true);
if (host->hw_ver.major >= 0x4) {
- if (dev_req_params->gear_tx == UFS_HS_G4) {
- /* INITIAL ADAPT */
- ufshcd_dme_set(hba,
- UIC_ARG_MIB(PA_TXHSADAPTTYPE),
- PA_INITIAL_ADAPT);
- } else {
- /* NO ADAPT */
- ufshcd_dme_set(hba,
- UIC_ARG_MIB(PA_TXHSADAPTTYPE),
- PA_NO_ADAPT);
- }
+ ufshcd_dme_configure_adapt(hba,
+ dev_req_params->gear_tx,
+ PA_INITIAL_ADAPT);
}
break;
case POST_CHANGE:
--
2.18.0
[PATCH v1 5/9] scsi: ufs-exynos: Use device parameter initialization function
Use common device parameter initialization function instead of initialziing those parameters by vendor driver itself. Signed-off-by: Stanley Chu --- drivers/scsi/ufs/ufs-exynos.c | 15 +-- drivers/scsi/ufs/ufs-exynos.h | 13 - 2 files changed, 1 insertion(+), 27 deletions(-) diff --git a/drivers/scsi/ufs/ufs-exynos.c b/drivers/scsi/ufs/ufs-exynos.c index 5e6b95dbb578..a8770ff14588 100644 --- a/drivers/scsi/ufs/ufs-exynos.c +++ b/drivers/scsi/ufs/ufs-exynos.c @@ -617,20 +617,7 @@ static int exynos_ufs_pre_pwr_mode(struct ufs_hba *hba, goto out; } - - ufs_exynos_cap.tx_lanes = UFS_EXYNOS_LIMIT_NUM_LANES_TX; - ufs_exynos_cap.rx_lanes = UFS_EXYNOS_LIMIT_NUM_LANES_RX; - ufs_exynos_cap.hs_rx_gear = UFS_EXYNOS_LIMIT_HSGEAR_RX; - ufs_exynos_cap.hs_tx_gear = UFS_EXYNOS_LIMIT_HSGEAR_TX; - ufs_exynos_cap.pwm_rx_gear = UFS_EXYNOS_LIMIT_PWMGEAR_RX; - ufs_exynos_cap.pwm_tx_gear = UFS_EXYNOS_LIMIT_PWMGEAR_TX; - ufs_exynos_cap.rx_pwr_pwm = UFS_EXYNOS_LIMIT_RX_PWR_PWM; - ufs_exynos_cap.tx_pwr_pwm = UFS_EXYNOS_LIMIT_TX_PWR_PWM; - ufs_exynos_cap.rx_pwr_hs = UFS_EXYNOS_LIMIT_RX_PWR_HS; - ufs_exynos_cap.tx_pwr_hs = UFS_EXYNOS_LIMIT_TX_PWR_HS; - ufs_exynos_cap.hs_rate = UFS_EXYNOS_LIMIT_HS_RATE; - ufs_exynos_cap.desired_working_mode = - UFS_EXYNOS_LIMIT_DESIRED_MODE; + ufshcd_init_pwr_dev_param(&ufs_exynos_cap); ret = ufshcd_get_pwr_dev_param(&ufs_exynos_cap, dev_max_params, dev_req_params); diff --git a/drivers/scsi/ufs/ufs-exynos.h b/drivers/scsi/ufs/ufs-exynos.h index 76d6e39efb2f..06ee565f7eb0 100644 --- a/drivers/scsi/ufs/ufs-exynos.h +++ b/drivers/scsi/ufs/ufs-exynos.h @@ -90,19 +90,6 @@ struct exynos_ufs; #define SLOW 1 #define FAST 2 -#define UFS_EXYNOS_LIMIT_NUM_LANES_RX 2 -#define UFS_EXYNOS_LIMIT_NUM_LANES_TX 2 -#define UFS_EXYNOS_LIMIT_HSGEAR_RX UFS_HS_G3 -#define UFS_EXYNOS_LIMIT_HSGEAR_TX UFS_HS_G3 -#define UFS_EXYNOS_LIMIT_PWMGEAR_RXUFS_PWM_G4 -#define UFS_EXYNOS_LIMIT_PWMGEAR_TXUFS_PWM_G4 -#define UFS_EXYNOS_LIMIT_RX_PWR_PWMSLOW_MODE -#define UFS_EXYNOS_LIMIT_TX_PWR_PWMSLOW_MODE -#define UFS_EXYNOS_LIMIT_RX_PWR_HS FAST_MODE -#define UFS_EXYNOS_LIMIT_TX_PWR_HS FAST_MODE -#define UFS_EXYNOS_LIMIT_HS_RATE PA_HS_MODE_B -#define UFS_EXYNOS_LIMIT_DESIRED_MODE FAST - #define RX_ADV_FINE_GRAN_SUP_EN0x1 #define RX_ADV_FINE_GRAN_STEP_VAL 0x3 #define RX_ADV_MIN_ACTV_TIME_CAP 0x9 -- 2.18.0
[PATCH v1 7/9] scsi: ufs: Refactor ADAPT configuration function
Several vendors are using same code to configure ADAPT
settings for HS-G4. Simply refactor it as common function.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd.c | 16
drivers/scsi/ufs/ufshcd.h | 3 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 9186ee01379a..80cbce414678 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3587,6 +3587,22 @@ static int ufshcd_dme_reset(struct ufs_hba *hba)
return ret;
}
+int ufshcd_dme_configure_adapt(struct ufs_hba *hba,
+ int agreed_gear,
+ int adapt_val)
+{
+ int ret;
+
+ if (agreed_gear != UFS_HS_G4)
+ adapt_val = PA_INITIAL_ADAPT;
+
+ ret = ufshcd_dme_set(hba,
+UIC_ARG_MIB(PA_TXHSADAPTTYPE),
+adapt_val);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(ufshcd_dme_configure_adapt);
+
/**
* ufshcd_dme_enable - UIC command for DME_ENABLE
* @hba: per adapter instance
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 5191d87f6263..d0b68df07eef 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -956,6 +956,9 @@ extern int ufshcd_runtime_idle(struct ufs_hba *hba);
extern int ufshcd_system_suspend(struct ufs_hba *hba);
extern int ufshcd_system_resume(struct ufs_hba *hba);
extern int ufshcd_shutdown(struct ufs_hba *hba);
+extern int ufshcd_dme_configure_adapt(struct ufs_hba *hba,
+ int agreed_gear,
+ int adapt_val);
extern int ufshcd_dme_set_attr(struct ufs_hba *hba, u32 attr_sel,
u8 attr_set, u32 mib_val, u8 peer);
extern int ufshcd_dme_get_attr(struct ufs_hba *hba, u32 attr_sel,
--
2.18.0
[PATCH v1 4/9] scsi: ufs-qcom: Use device parameter initialization function
Use common device parameter initialization function instead of
initialziing those parameters by vendor driver itself.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-qcom.c | 13 +
drivers/scsi/ufs/ufs-qcom.h | 11 ---
2 files changed, 1 insertion(+), 23 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 357c3b49321d..04adfbd10753 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -691,19 +691,8 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
switch (status) {
case PRE_CHANGE:
- ufs_qcom_cap.tx_lanes = UFS_QCOM_LIMIT_NUM_LANES_TX;
- ufs_qcom_cap.rx_lanes = UFS_QCOM_LIMIT_NUM_LANES_RX;
- ufs_qcom_cap.hs_rx_gear = UFS_QCOM_LIMIT_HSGEAR_RX;
- ufs_qcom_cap.hs_tx_gear = UFS_QCOM_LIMIT_HSGEAR_TX;
- ufs_qcom_cap.pwm_rx_gear = UFS_QCOM_LIMIT_PWMGEAR_RX;
- ufs_qcom_cap.pwm_tx_gear = UFS_QCOM_LIMIT_PWMGEAR_TX;
- ufs_qcom_cap.rx_pwr_pwm = UFS_QCOM_LIMIT_RX_PWR_PWM;
- ufs_qcom_cap.tx_pwr_pwm = UFS_QCOM_LIMIT_TX_PWR_PWM;
- ufs_qcom_cap.rx_pwr_hs = UFS_QCOM_LIMIT_RX_PWR_HS;
- ufs_qcom_cap.tx_pwr_hs = UFS_QCOM_LIMIT_TX_PWR_HS;
+ ufshcd_init_pwr_dev_param(&ufs_qcom_cap);
ufs_qcom_cap.hs_rate = UFS_QCOM_LIMIT_HS_RATE;
- ufs_qcom_cap.desired_working_mode =
- UFS_QCOM_LIMIT_DESIRED_MODE;
if (host->hw_ver.major == 0x1) {
/*
diff --git a/drivers/scsi/ufs/ufs-qcom.h b/drivers/scsi/ufs/ufs-qcom.h
index 3f4922743b3e..8208e3a3ef59 100644
--- a/drivers/scsi/ufs/ufs-qcom.h
+++ b/drivers/scsi/ufs/ufs-qcom.h
@@ -27,18 +27,7 @@
#define SLOW 1
#define FAST 2
-#define UFS_QCOM_LIMIT_NUM_LANES_RX2
-#define UFS_QCOM_LIMIT_NUM_LANES_TX2
-#define UFS_QCOM_LIMIT_HSGEAR_RX UFS_HS_G3
-#define UFS_QCOM_LIMIT_HSGEAR_TX UFS_HS_G3
-#define UFS_QCOM_LIMIT_PWMGEAR_RX UFS_PWM_G4
-#define UFS_QCOM_LIMIT_PWMGEAR_TX UFS_PWM_G4
-#define UFS_QCOM_LIMIT_RX_PWR_PWM SLOW_MODE
-#define UFS_QCOM_LIMIT_TX_PWR_PWM SLOW_MODE
-#define UFS_QCOM_LIMIT_RX_PWR_HS FAST_MODE
-#define UFS_QCOM_LIMIT_TX_PWR_HS FAST_MODE
#define UFS_QCOM_LIMIT_HS_RATE PA_HS_MODE_B
-#define UFS_QCOM_LIMIT_DESIRED_MODEFAST
/* QCOM UFS host controller vendor specific registers */
enum {
--
2.18.0
[PATCH v1 2/9] scsi: ufs: Introduce device parameter initialization function
Nowadays many vendors initialize their device parameters in
their own vendor drivers. The initialization code is almost
the same as well as the pre-defined definitions. Introduce
a common device parameter initialization function which assign
the most common initial values. With this function, we
could remove those duplicated codes in vendor drivers.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd-pltfrm.c | 17 +
drivers/scsi/ufs/ufshcd-pltfrm.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index 3db0af66c71c..a6f76399b3ae 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -354,6 +354,23 @@ int ufshcd_get_pwr_dev_param(struct ufs_dev_params
*pltfrm_param,
}
EXPORT_SYMBOL_GPL(ufshcd_get_pwr_dev_param);
+void ufshcd_init_pwr_dev_param(struct ufs_dev_params *dev_param)
+{
+ dev_param->tx_lanes = 2;
+ dev_param->rx_lanes = 2;
+ dev_param->hs_rx_gear = UFS_HS_G3;
+ dev_param->hs_tx_gear = UFS_HS_G3;
+ dev_param->pwm_rx_gear = UFS_PWM_G4;
+ dev_param->pwm_tx_gear = UFS_PWM_G4;
+ dev_param->rx_pwr_pwm = SLOW_MODE;
+ dev_param->tx_pwr_pwm = SLOW_MODE;
+ dev_param->rx_pwr_hs = FAST_MODE;
+ dev_param->tx_pwr_hs = FAST_MODE;
+ dev_param->hs_rate = PA_HS_MODE_B;
+ dev_param->desired_working_mode = UFS_HS_MODE;
+}
+EXPORT_SYMBOL_GPL(ufshcd_init_pwr_dev_param);
+
/**
* ufshcd_pltfrm_init - probe routine of the driver
* @pdev: pointer to Platform device handle
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.h b/drivers/scsi/ufs/ufshcd-pltfrm.h
index b79cdf9129a0..772a8e848098 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.h
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.h
@@ -28,6 +28,7 @@ struct ufs_dev_params {
int ufshcd_get_pwr_dev_param(struct ufs_dev_params *dev_param,
struct ufs_pa_layer_attr *dev_max,
struct ufs_pa_layer_attr *agreed_pwr);
+void ufshcd_init_pwr_dev_param(struct ufs_dev_params *dev_param);
int ufshcd_pltfrm_init(struct platform_device *pdev,
const struct ufs_hba_variant_ops *vops);
void ufshcd_pltfrm_shutdown(struct platform_device *pdev);
--
2.18.0
[PATCH v1 6/9] scsi: ufs-hisi: Use device parameter initialization function
Use common device parameter initialization function instead of
initialziing those parameters by vendor driver itself.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-hisi.c | 13 +
drivers/scsi/ufs/ufs-hisi.h | 13 -
2 files changed, 1 insertion(+), 25 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
index 074a6a055a4c..0aa58131e791 100644
--- a/drivers/scsi/ufs/ufs-hisi.c
+++ b/drivers/scsi/ufs/ufs-hisi.c
@@ -293,18 +293,7 @@ static int ufs_hisi_link_startup_notify(struct ufs_hba
*hba,
static void ufs_hisi_set_dev_cap(struct ufs_dev_params *hisi_param)
{
- hisi_param->rx_lanes = UFS_HISI_LIMIT_NUM_LANES_RX;
- hisi_param->tx_lanes = UFS_HISI_LIMIT_NUM_LANES_TX;
- hisi_param->hs_rx_gear = UFS_HISI_LIMIT_HSGEAR_RX;
- hisi_param->hs_tx_gear = UFS_HISI_LIMIT_HSGEAR_TX;
- hisi_param->pwm_rx_gear = UFS_HISI_LIMIT_PWMGEAR_RX;
- hisi_param->pwm_tx_gear = UFS_HISI_LIMIT_PWMGEAR_TX;
- hisi_param->rx_pwr_pwm = UFS_HISI_LIMIT_RX_PWR_PWM;
- hisi_param->tx_pwr_pwm = UFS_HISI_LIMIT_TX_PWR_PWM;
- hisi_param->rx_pwr_hs = UFS_HISI_LIMIT_RX_PWR_HS;
- hisi_param->tx_pwr_hs = UFS_HISI_LIMIT_TX_PWR_HS;
- hisi_param->hs_rate = UFS_HISI_LIMIT_HS_RATE;
- hisi_param->desired_working_mode = UFS_HISI_LIMIT_DESIRED_MODE;
+ ufshcd_init_pwr_dev_param(hisi_param);
}
static void ufs_hisi_pwr_change_pre_change(struct ufs_hba *hba)
diff --git a/drivers/scsi/ufs/ufs-hisi.h b/drivers/scsi/ufs/ufs-hisi.h
index 3231d3d81c98..5a90c0f4e90c 100644
--- a/drivers/scsi/ufs/ufs-hisi.h
+++ b/drivers/scsi/ufs/ufs-hisi.h
@@ -76,19 +76,6 @@ enum {
#define SLOW 1
#define FAST 2
-#define UFS_HISI_LIMIT_NUM_LANES_RX2
-#define UFS_HISI_LIMIT_NUM_LANES_TX2
-#define UFS_HISI_LIMIT_HSGEAR_RX UFS_HS_G3
-#define UFS_HISI_LIMIT_HSGEAR_TX UFS_HS_G3
-#define UFS_HISI_LIMIT_PWMGEAR_RX UFS_PWM_G4
-#define UFS_HISI_LIMIT_PWMGEAR_TX UFS_PWM_G4
-#define UFS_HISI_LIMIT_RX_PWR_PWM SLOW_MODE
-#define UFS_HISI_LIMIT_TX_PWR_PWM SLOW_MODE
-#define UFS_HISI_LIMIT_RX_PWR_HS FAST_MODE
-#define UFS_HISI_LIMIT_TX_PWR_HS FAST_MODE
-#define UFS_HISI_LIMIT_HS_RATE PA_HS_MODE_B
-#define UFS_HISI_LIMIT_DESIRED_MODEFAST
-
#define UFS_HISI_CAP_RESERVED BIT(0)
#define UFS_HISI_CAP_PHY10nm BIT(1)
--
2.18.0
[PATCH v1 1/9] scsi: ufs-mediatek: Refactor performance scaling functions
Refactor preformance scaling related functions in MediaTek
UFS driver.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-mediatek.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 7fed7630d36c..b9b423752ee1 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -514,6 +514,19 @@ static void ufs_mtk_init_host_caps(struct ufs_hba *hba)
dev_info(hba->dev, "caps: 0x%x", host->caps);
}
+static void ufs_mtk_scale_perf(struct ufs_hba *hba, bool up)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+
+ ufs_mtk_boost_crypt(hba, up);
+ ufs_mtk_setup_ref_clk(hba, up);
+
+ if (up)
+ phy_power_on(host->mphy);
+ else
+ phy_power_off(host->mphy);
+}
+
/**
* ufs_mtk_setup_clocks - enables/disable clocks
* @hba: host controller instance
@@ -555,15 +568,10 @@ static int ufs_mtk_setup_clocks(struct ufs_hba *hba, bool
on,
clk_pwr_off = true;
}
- if (clk_pwr_off) {
- ufs_mtk_boost_crypt(hba, on);
- ufs_mtk_setup_ref_clk(hba, on);
- phy_power_off(host->mphy);
- }
+ if (clk_pwr_off)
+ ufs_mtk_scale_perf(hba, false);
} else if (on && status == POST_CHANGE) {
- phy_power_on(host->mphy);
- ufs_mtk_setup_ref_clk(hba, on);
- ufs_mtk_boost_crypt(hba, on);
+ ufs_mtk_scale_perf(hba, true);
}
return ret;
--
2.18.0
[PATCH v1 3/9] scsi: ufs-mediatek: Use device parameter initialization function
Use common device parameter initialization function instead of initialziing those parameters by vendor driver itself. Signed-off-by: Stanley Chu --- drivers/scsi/ufs/ufs-mediatek.c | 16 +++- drivers/scsi/ufs/ufs-mediatek.h | 16 2 files changed, 3 insertions(+), 29 deletions(-) diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c index b9b423752ee1..87b4bf125e23 100644 --- a/drivers/scsi/ufs/ufs-mediatek.c +++ b/drivers/scsi/ufs/ufs-mediatek.c @@ -680,19 +680,9 @@ static int ufs_mtk_pre_pwr_change(struct ufs_hba *hba, u32 adapt_val; int ret; - host_cap.tx_lanes = UFS_MTK_LIMIT_NUM_LANES_TX; - host_cap.rx_lanes = UFS_MTK_LIMIT_NUM_LANES_RX; - host_cap.hs_rx_gear = UFS_MTK_LIMIT_HSGEAR_RX; - host_cap.hs_tx_gear = UFS_MTK_LIMIT_HSGEAR_TX; - host_cap.pwm_rx_gear = UFS_MTK_LIMIT_PWMGEAR_RX; - host_cap.pwm_tx_gear = UFS_MTK_LIMIT_PWMGEAR_TX; - host_cap.rx_pwr_pwm = UFS_MTK_LIMIT_RX_PWR_PWM; - host_cap.tx_pwr_pwm = UFS_MTK_LIMIT_TX_PWR_PWM; - host_cap.rx_pwr_hs = UFS_MTK_LIMIT_RX_PWR_HS; - host_cap.tx_pwr_hs = UFS_MTK_LIMIT_TX_PWR_HS; - host_cap.hs_rate = UFS_MTK_LIMIT_HS_RATE; - host_cap.desired_working_mode = - UFS_MTK_LIMIT_DESIRED_MODE; + ufshcd_init_pwr_dev_param(&host_cap); + host_cap.hs_rx_gear = UFS_HS_G4; + host_cap.hs_tx_gear = UFS_HS_G4; ret = ufshcd_get_pwr_dev_param(&host_cap, dev_max_params, diff --git a/drivers/scsi/ufs/ufs-mediatek.h b/drivers/scsi/ufs/ufs-mediatek.h index ac37b11803fb..93d35097dfb0 100644 --- a/drivers/scsi/ufs/ufs-mediatek.h +++ b/drivers/scsi/ufs/ufs-mediatek.h @@ -30,22 +30,6 @@ #define REFCLK_REQ_TIMEOUT_US 3000 -/* - * Vendor specific pre-defined parameters - */ -#define UFS_MTK_LIMIT_NUM_LANES_RX 2 -#define UFS_MTK_LIMIT_NUM_LANES_TX 2 -#define UFS_MTK_LIMIT_HSGEAR_RX UFS_HS_G4 -#define UFS_MTK_LIMIT_HSGEAR_TX UFS_HS_G4 -#define UFS_MTK_LIMIT_PWMGEAR_RXUFS_PWM_G4 -#define UFS_MTK_LIMIT_PWMGEAR_TXUFS_PWM_G4 -#define UFS_MTK_LIMIT_RX_PWR_PWMSLOW_MODE -#define UFS_MTK_LIMIT_TX_PWR_PWMSLOW_MODE -#define UFS_MTK_LIMIT_RX_PWR_HS FAST_MODE -#define UFS_MTK_LIMIT_TX_PWR_HS FAST_MODE -#define UFS_MTK_LIMIT_HS_RATE PA_HS_MODE_B -#define UFS_MTK_LIMIT_DESIRED_MODE UFS_HS_MODE - /* * Other attributes */ -- 2.18.0
[PATCH doc] doc: zh_CN: add tmpfs to index tree
Add temfs to the index tree while adding tempfs translation. Signed-off-by: Wang Qing --- Documentation/translations/zh_CN/filesystems/index.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/translations/zh_CN/filesystems/index.rst b/Documentation/translations/zh_CN/filesystems/index.rst index 186501d..9f2a8b0 --- a/Documentation/translations/zh_CN/filesystems/index.rst +++ b/Documentation/translations/zh_CN/filesystems/index.rst @@ -25,4 +25,5 @@ Linux Kernel中的文件系统 virtiofs debugfs + tmpfs -- 2.7.4
Re: [PATCH v2] mfd: kempld-core: Check for DMI definition before ACPI
On Fri, 2020-11-13 at 10:16 +, Lee Jones wrote:
> On Tue, 10 Nov 2020, Michael Brunner wrote:
>
> > Change the detection order to priorize DMI table entries over
> > available
> > ACPI entries.
> >
> > This makes it more easy for product developers to patch product
> > specific
> > handling into the driver.
> > Furthermore it allows to simplify the implementation a bit and
> > especially to remove the need to force synchronous probing.
> > Based on the following commit introduced with v5.10-rc1:
> > commit e8299c7313af ("mfd: Add ACPI support to Kontron PLD driver")
>
> This section should also be removed from the change log.
No problem, just sent v3.
Thanks,
Michael
[PATCH v3] mfd: kempld-core: Check for DMI definition before ACPI
Change the detection order to priorize DMI table entries over available
ACPI entries.
This makes it more easy for product developers to patch product specific
handling into the driver.
Furthermore it allows to simplify the implementation a bit and
especially to remove the need to force synchronous probing.
Signed-off-by: Michael Brunner
Reviewed-by: Guenter Roeck
---
v3: Cleaned up comment, added Reviewed-by
drivers/mfd/kempld-core.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/mfd/kempld-core.c b/drivers/mfd/kempld-core.c
index 2c9295953c11..ecd26271b9a4 100644
--- a/drivers/mfd/kempld-core.c
+++ b/drivers/mfd/kempld-core.c
@@ -125,7 +125,6 @@ static const struct kempld_platform_data
kempld_platform_data_generic = {
};
static struct platform_device *kempld_pdev;
-static bool kempld_acpi_mode;
static int kempld_create_platform_device(const struct dmi_system_id *id)
{
@@ -501,8 +500,6 @@ static int kempld_probe(struct platform_device *pdev)
ret = kempld_get_acpi_data(pdev);
if (ret)
return ret;
-
- kempld_acpi_mode = true;
} else if (kempld_pdev != pdev) {
/*
* The platform device we are probing is not the one we
@@ -565,7 +562,6 @@ static struct platform_driver kempld_driver = {
.driver = {
.name = "kempld",
.acpi_match_table = ACPI_PTR(kempld_acpi_table),
- .probe_type = PROBE_FORCE_SYNCHRONOUS,
},
.probe = kempld_probe,
.remove = kempld_remove,
@@ -884,7 +880,6 @@ MODULE_DEVICE_TABLE(dmi, kempld_dmi_table);
static int __init kempld_init(void)
{
const struct dmi_system_id *id;
- int ret;
if (force_device_id[0]) {
for (id = kempld_dmi_table;
@@ -894,24 +889,11 @@ static int __init kempld_init(void)
break;
if (id->matches[0].slot == DMI_NONE)
return -ENODEV;
- }
-
- ret = platform_driver_register(&kempld_driver);
- if (ret)
- return ret;
-
- /*
-* With synchronous probing the device should already be probed now.
-* If no device id is forced and also no ACPI definition for the
-* device was found, scan DMI table as fallback.
-*
-* If drivers_autoprobing is disabled and the device is found here,
-* only that device can be bound manually later.
-*/
- if (!kempld_pdev && !kempld_acpi_mode)
+ } else {
dmi_check_system(kempld_dmi_table);
+ }
- return 0;
+ return platform_driver_register(&kempld_driver);
}
static void __exit kempld_exit(void)
--
2.25.1
[PATCH] arm64: dts: meson: enable rtc node on Khadas VIM1/VIM2 boards
Enable the rtc node on VIM1/VIM2 boards so users can simply attach a power
cell and use the on-board RTC without modifying the device-tree.
Cold boot with no cell attached is gracefully handled:
VIM2:~ # dmesg | grep rtc
[7.716150] rtc-hym8563 1-0051: no valid clock/calendar values available
[7.716957] rtc-hym8563 1-0051: registered as rtc0
[7.729850] rtc-hym8563 1-0051: no valid clock/calendar values available
[7.729877] rtc-hym8563 1-0051: hctosys: unable to read the hardware clock
[8.126768] rtc-hym8563 1-0051: no valid clock/calendar values available
Warm boot (and any boot with cell attached) recalls stored values resulting
in consistently faster (re)boot times:
VIM2:~ # dmesg | grep rtc
[7.441671] rtc-hym8563 1-0051: registered as rtc0
[7.442663] rtc-hym8563 1-0051: setting system clock to 2020-11-16T05:49:59
UTC (1605505799)
Suggested-by: Artem Lapkin
Signed-off-by: Christian Hewitt
---
This supersedes other recent attempts by Art to make the same change [0]
and [1] which were rejected for lack of justification for the change and
leaving comments behind. I have been using the same changes in my own
tree for a while.
Christian
[0]
https://patchwork.kernel.org/project/linux-amlogic/patch/20200925033017.1790973-8-...@khadas.com/
[1]
https://patchwork.kernel.org/project/linux-amlogic/patch/20200925033017.1790973-9-...@khadas.com/
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts | 3 +--
arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
index 8bcdffdf55d0..638a5992d760 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
@@ -97,8 +97,7 @@
pinctrl-names = "default";
rtc: rtc@51 {
- /* has to be enabled manually when a battery is connected: */
- status = "disabled";
+ status = "okay";
compatible = "haoyu,hym8563";
reg = <0x51>;
#clock-cells = <0>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
index bff8ec2c1c70..da000c10b945 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
@@ -228,8 +228,7 @@
pinctrl-names = "default";
rtc: rtc@51 {
- /* has to be enabled manually when a battery is connected: */
- status = "disabled";
+ status = "okay";
compatible = "haoyu,hym8563";
reg = <0x51>;
#clock-cells = <0>;
--
2.17.1
Re: [PATCH v4 00/12] Bug fixes and improvements for MHI power operations
On Mon, Nov 09, 2020 at 12:47:19PM -0800, Bhaumik Bhatt wrote: > Bug fixes and improvements for MHI powerup and shutdown handling. > Firmware load function names are updated to accurately reflect their purpose. > Closed certain design gaps where the host (MHI bus) would allow clients to > operate after a power down or error detection. > Move to an error state sooner based on different scenarios. > > These patches were tested on arm64 and X86_64 architectures. > > v4: > -Fixed up bus: mhi: core: Move to SYS_ERROR regardless of RDDM capability > patch > by removing check for EE as well since a previous guard to check if MHI > pm_state > allows event ring access is already present. Event ring access should not be > allowed at the time and hence the check is safe to remove. > > v3: > -Fixed bus: mhi: core: Remove MHI event ring IRQ handlers when powering down > -Mistakenly placed the free_irq() calls in mhi_pm_sys_error_transition() > -Moved it to mhi_pm_disable_transition() > > v2: > -Addressed patches based on review comments and made improvements > -Added bus: mhi: core: Check for IRQ availability during registration > -Dropped bus: mhi: core: Use the IRQF_ONESHOT flag for the BHI interrupt line > -Split bus: mhi: core: Move to an error state on any firmware load failure > -Modified the following patches: > -bus: mhi: core: Disable IRQs when powering down > -bus: mhi: core: Improve shutdown handling after link down detection > -bus: mhi: core: Mark device inactive soon after host issues a shutdown > -bus: mhi: core: Move to SYS_ERROR regardless of RDDM capability > -Addressed the above as follow-up patches with improvements: > -bus: mhi: core: Prevent sending multiple RDDM entry callbacks > -bus: mhi: core: Separate system error and power down handling > -bus: mhi: core: Remove MHI event ring IRQ handlers when powering down > > Bhaumik Bhatt (12): > bus: mhi: core: Use appropriate names for firmware load functions > bus: mhi: core: Move to using high priority workqueue > bus: mhi: core: Skip device wake in error or shutdown states > bus: mhi: core: Move to SYS_ERROR regardless of RDDM capability > bus: mhi: core: Prevent sending multiple RDDM entry callbacks > bus: mhi: core: Move to an error state on any firmware load failure > bus: mhi: core: Use appropriate label in firmware load handler API > bus: mhi: core: Move to an error state on mission mode failure > bus: mhi: core: Check for IRQ availability during registration > bus: mhi: core: Separate system error and power down handling > bus: mhi: core: Mark and maintain device states early on after power > down > bus: mhi: core: Remove MHI event ring IRQ handlers when powering down Series applied to mhi-next! Thanks, Mani > > drivers/bus/mhi/core/boot.c | 60 ++- > drivers/bus/mhi/core/init.c | 11 ++- > drivers/bus/mhi/core/main.c | 9 +- > drivers/bus/mhi/core/pm.c | 236 > > include/linux/mhi.h | 2 + > 5 files changed, 222 insertions(+), 96 deletions(-) > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
linux-next: build warning after merge of the ftrace tree
Hi all,
After merging the ftrace tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/trace/ftrace-uses.rst:123: WARNING: Unexpected indentation.
Introduced by commit
a25d036d939a ("ftrace: Reverse what the RECURSION flag means in the
ftrace_ops")
--
Cheers,
Stephen Rothwell
pgpLwhAXd6kuP.pgp
Description: OpenPGP digital signature
[PATCH v2 0/1] Fix object remain in offline per-cpu quarantine
This patch fixes object remain in the offline per-cpu quarantine as describe below. Free objects will get into per-cpu quarantine if enable generic KASAN. If a cpu is offline and users use kmem_cache_destroy, kernel will detect objects still remain in the offline per-cpu quarantine and report error. Register a cpu hotplug function to remove all objects in the offline per-cpu quarantine when cpu is going offline. Set a per-cpu variable to indicate this cpu is offline. Changes since v2: - Thanks for Dmitry suggestion - Remove unnecessary code - Put offline variable into cpu_quarantine - Use single qlist_free_all call instead of iteration over all slabs - Add bug reporter in commit message Kuan-Ying Lee (1): kasan: fix object remain in offline per-cpu quarantine mm/kasan/quarantine.c | 35 +++ 1 file changed, 35 insertions(+) -- 2.18.0
[PATCH v2 1/1] kasan: fix object remain in offline per-cpu quarantine
We hit this issue in our internal test.
When enabling generic kasan, a kfree()'d object is put into per-cpu
quarantine first. If the cpu goes offline, object still remains in
the per-cpu quarantine. If we call kmem_cache_destroy() now, slub
will report "Objects remaining" error.
[ 74.982625]
=
[ 74.983380] BUG test_module_slab (Not tainted): Objects remaining in
test_module_slab on __kmem_cache_shutdown()
[ 74.984145]
-
[ 74.984145]
[ 74.984883] Disabling lock debugging due to kernel taint
[ 74.985561] INFO: Slab 0x(ptrval) objects=34 used=1
fp=0x(ptrval) flags=0x20010200
[ 74.986638] CPU: 3 PID: 176 Comm: cat Tainted: GB
5.10.0-rc1-7-g4525c8781ec0-dirty #10
[ 74.987262] Hardware name: linux,dummy-virt (DT)
[ 74.987606] Call trace:
[ 74.987924] dump_backtrace+0x0/0x2b0
[ 74.988296] show_stack+0x18/0x68
[ 74.988698] dump_stack+0xfc/0x168
[ 74.989030] slab_err+0xac/0xd4
[ 74.989346] __kmem_cache_shutdown+0x1e4/0x3c8
[ 74.989779] kmem_cache_destroy+0x68/0x130
[ 74.990176] test_version_show+0x84/0xf0
[ 74.990679] module_attr_show+0x40/0x60
[ 74.991218] sysfs_kf_seq_show+0x128/0x1c0
[ 74.991656] kernfs_seq_show+0xa0/0xb8
[ 74.992059] seq_read+0x1f0/0x7e8
[ 74.992415] kernfs_fop_read+0x70/0x338
[ 74.993051] vfs_read+0xe4/0x250
[ 74.993498] ksys_read+0xc8/0x180
[ 74.993825] __arm64_sys_read+0x44/0x58
[ 74.994203] el0_svc_common.constprop.0+0xac/0x228
[ 74.994708] do_el0_svc+0x38/0xa0
[ 74.995088] el0_sync_handler+0x170/0x178
[ 74.995497] el0_sync+0x174/0x180
[ 74.996050] INFO: Object 0x(ptrval) @offset=15848
[ 74.996752] INFO: Allocated in test_version_show+0x98/0xf0 age=8188 cpu=6
pid=172
[ 75.000802] stack_trace_save+0x9c/0xd0
[ 75.002420] set_track+0x64/0xf0
[ 75.002770] alloc_debug_processing+0x104/0x1a0
[ 75.003171] ___slab_alloc+0x628/0x648
[ 75.004213] __slab_alloc.isra.0+0x2c/0x58
[ 75.004757] kmem_cache_alloc+0x560/0x588
[ 75.005376] test_version_show+0x98/0xf0
[ 75.005756] module_attr_show+0x40/0x60
[ 75.007035] sysfs_kf_seq_show+0x128/0x1c0
[ 75.007433] kernfs_seq_show+0xa0/0xb8
[ 75.007800] seq_read+0x1f0/0x7e8
[ 75.008128] kernfs_fop_read+0x70/0x338
[ 75.008507] vfs_read+0xe4/0x250
[ 75.008990] ksys_read+0xc8/0x180
[ 75.009462] __arm64_sys_read+0x44/0x58
[ 75.010085] el0_svc_common.constprop.0+0xac/0x228
[ 75.011006] kmem_cache_destroy test_module_slab: Slab cache still has objects
Register a cpu hotplug function to remove all objects in the offline
per-cpu quarantine when cpu is going offline. Set a per-cpu variable
to indicate this cpu is offline.
Signed-off-by: Kuan-Ying Lee
Suggested-by: Dmitry Vyukov
Reported-by: Guangye Yang
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: Andrew Morton
Cc: Matthias Brugger
---
mm/kasan/quarantine.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
index 4c5375810449..16e618ea805e 100644
--- a/mm/kasan/quarantine.c
+++ b/mm/kasan/quarantine.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "../slab.h"
#include "kasan.h"
@@ -43,6 +44,7 @@ struct qlist_head {
struct qlist_node *head;
struct qlist_node *tail;
size_t bytes;
+ bool offline;
};
#define QLIST_INIT { NULL, NULL, 0 }
@@ -188,6 +190,11 @@ void quarantine_put(struct kasan_free_meta *info, struct
kmem_cache *cache)
local_irq_save(flags);
q = this_cpu_ptr(&cpu_quarantine);
+ if (q->offline) {
+ qlink_free(&info->quarantine_link, cache);
+ local_irq_restore(flags);
+ return;
+ }
qlist_put(q, &info->quarantine_link, cache->size);
if (unlikely(q->bytes > QUARANTINE_PERCPU_SIZE)) {
qlist_move_all(q, &temp);
@@ -328,3 +335,31 @@ void quarantine_remove_cache(struct kmem_cache *cache)
synchronize_srcu(&remove_cache_srcu);
}
+
+static int kasan_cpu_online(unsigned int cpu)
+{
+ this_cpu_ptr(&cpu_quarantine)->offline = false;
+ return 0;
+}
+
+static int kasan_cpu_offline(unsigned int cpu)
+{
+ struct qlist_head *q;
+
+ q = this_cpu_ptr(&cpu_quarantine);
+ q->offline = true;
+ qlist_free_all(q, NULL);
+ return 0;
+}
+
+static int __init kasan_cpu_offline_quarantine_init(void)
+{
+ int ret = 0;
+
+ ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "mm/kasan:online",
+ kasan_cpu_online, kasan_cpu_offline);
+ if (ret < 0)
+ pr_err("kasan offline cpu quarantine register failed [%d]\n",
ret);
+ return ret;
+}
+late_initcall(kasan_cpu_offline_quarantine_init);
--
2.18.0
Re: [PATCH 0/9] iio: adc: at91_adc: cleanup DT bindings
On Fri, Nov 13, 2020 at 10:26:41PM +0100, Alexandre Belloni wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Hello, > > This series cleans up the at91_adc devicetree bindings. This mainly > moves back the resolution options and names and the triggers description > back in the driver. > > There are also other cleanups, like removing platform data support, this > was pending for a while. > Nice cleanup of this old and obscur binding. Reviewed-by: Ludovic Desroches Thanks. > Alexandre Belloni (8): > iio: adc: at91_adc: remove platform data > iio: adc: at91_adc: rework resolution selection > iio: adc: at91_adc: rework trigger definition > iio: adc: at91_adc: merge at91_adc_probe_dt back in at91_adc_probe > iio: adc: at91_adc: remove forward declaration > iio: adc: at91_adc: use devm_input_allocate_device > ARM: dts: at91: sama5d3: use proper ADC compatible > ARM: dts: at91: remove deprecated ADC properties > > Jonathan Cameron (1): > dt-bindings:iio:adc:atmel,sama9260-adc: conversion to yaml from > at91_adc.txt > > .../devicetree/bindings/iio/adc/at91_adc.txt | 83 > .../bindings/iio/adc/atmel,sama9260-adc.yaml | 121 ++ > arch/arm/boot/dts/at91sam9260.dtsi| 25 -- > arch/arm/boot/dts/at91sam9g45.dtsi| 27 -- > arch/arm/boot/dts/at91sam9rl.dtsi | 25 -- > arch/arm/boot/dts/at91sam9x5.dtsi | 28 -- > arch/arm/boot/dts/sama5d3.dtsi| 26 +- > arch/arm/boot/dts/sama5d4.dtsi| 22 - > drivers/iio/adc/at91_adc.c| 377 +++--- > include/linux/platform_data/at91_adc.h| 49 --- > 10 files changed, 259 insertions(+), 524 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/iio/adc/at91_adc.txt > create mode 100644 > Documentation/devicetree/bindings/iio/adc/atmel,sama9260-adc.yaml > delete mode 100644 include/linux/platform_data/at91_adc.h > > -- > 2.28.0
Re: [PATCH 3/3] powerpc: fix -Wimplicit-fallthrough
On Sun, Nov 15, 2020 at 08:35:32PM -0800, Nick Desaulniers wrote: > The "fallthrough" pseudo-keyword was added as a portable way to denote > intentional fallthrough. Clang will still warn on cases where there is a > fallthrough to an immediate break. Add explicit breaks for those cases. > > Link: https://github.com/ClangBuiltLinux/linux/issues/236 > Signed-off-by: Nick Desaulniers Reviewed-by: Gustavo A. R. Silva Thanks -- Gustavo > --- > arch/powerpc/kernel/prom_init.c | 1 + > arch/powerpc/kernel/uprobes.c | 1 + > arch/powerpc/perf/imc-pmu.c | 1 + > 3 files changed, 3 insertions(+) > > diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c > index 38ae5933d917..e9d4eb6144e1 100644 > --- a/arch/powerpc/kernel/prom_init.c > +++ b/arch/powerpc/kernel/prom_init.c > @@ -355,6 +355,7 @@ static int __init prom_strtobool(const char *s, bool *res) > default: > break; > } > + break; > default: > break; > } > diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c > index d200e7df7167..e8a63713e655 100644 > --- a/arch/powerpc/kernel/uprobes.c > +++ b/arch/powerpc/kernel/uprobes.c > @@ -141,6 +141,7 @@ int arch_uprobe_exception_notify(struct notifier_block > *self, > case DIE_SSTEP: > if (uprobe_post_sstep_notifier(regs)) > return NOTIFY_STOP; > + break; > default: > break; > } > diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c > index 7b25548ec42b..e106909ff9c3 100644 > --- a/arch/powerpc/perf/imc-pmu.c > +++ b/arch/powerpc/perf/imc-pmu.c > @@ -1500,6 +1500,7 @@ static int update_pmu_ops(struct imc_pmu *pmu) > pmu->pmu.stop = trace_imc_event_stop; > pmu->pmu.read = trace_imc_event_read; > pmu->attr_groups[IMC_FORMAT_ATTR] = &trace_imc_format_group; > + break; > default: > break; > } > -- > 2.29.2.299.gdc1121823c-goog >
Re: [PATCH 1/3] powerpc: boot: include compiler_attributes.h
On Sun, Nov 15, 2020 at 08:35:30PM -0800, Nick Desaulniers wrote: > The kernel uses `-include` to include include/linux/compiler_types.h > into all translation units (see scripts/Makefile.lib), which #includes > compiler_attributes.h. > > arch/powerpc/boot/ uses different compiler flags from the rest of the > kernel. As such, it doesn't contain the definitions from these headers, > and redefines a few that it needs. > > For the purpose of enabling -Wimplicit-fallthrough for ppc, include > compiler_types.h via `-include`. > > Link: https://github.com/ClangBuiltLinux/linux/issues/236 > Signed-off-by: Nick Desaulniers Acked-by: Gustavo A. R. Silva Thanks, Nick. -- Gustavo > --- > We could just `#include "include/linux/compiler_types.h"` in the few .c > sources used from lib/ (there are proper header guards in > compiler_types.h). > > It was also noted in 6a9dc5fd6170 that we could -D__KERNEL__ and > -include compiler_types.h like the main kernel does, though testing that > produces a whole sea of warnings to cleanup. This approach is minimally > invasive. > > arch/powerpc/boot/Makefile | 1 + > arch/powerpc/boot/decompress.c | 1 - > 2 files changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile > index f8ce6d2dde7b..1659963a8f1d 100644 > --- a/arch/powerpc/boot/Makefile > +++ b/arch/powerpc/boot/Makefile > @@ -31,6 +31,7 @@ endif > BOOTCFLAGS:= -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ >-fno-strict-aliasing -O2 -msoft-float -mno-altivec -mno-vsx \ >-pipe -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \ > + -include $(srctree)/include/linux/compiler_attributes.h \ >$(LINUXINCLUDE) > > ifdef CONFIG_PPC64_BOOT_WRAPPER > diff --git a/arch/powerpc/boot/decompress.c b/arch/powerpc/boot/decompress.c > index 8bf39ef7d2df..6098b879ac97 100644 > --- a/arch/powerpc/boot/decompress.c > +++ b/arch/powerpc/boot/decompress.c > @@ -21,7 +21,6 @@ > > #define STATIC static > #define INIT > -#define __always_inline inline > > /* > * The build process will copy the required zlib source files and headers > -- > 2.29.2.299.gdc1121823c-goog >
Re: [PATCH 2/3] Revert "lib: Revert use of fallthrough pseudo-keyword in lib/"
On Sun, Nov 15, 2020 at 08:35:31PM -0800, Nick Desaulniers wrote:
> This reverts commit 6a9dc5fd6170 ("lib: Revert use of fallthrough
> pseudo-keyword in lib/")
>
> Now that we can build arch/powerpc/boot/ free of -Wimplicit-fallthrough,
> re-enable these fixes for lib/.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/236
> Signed-off-by: Nick Desaulniers
Reviewed-by: Gustavo A. R. Silva
Thanks
--
Gustavo
> ---
> lib/asn1_decoder.c | 4 ++--
> lib/assoc_array.c | 2 +-
> lib/bootconfig.c| 4 ++--
> lib/cmdline.c | 10 +-
> lib/dim/net_dim.c | 2 +-
> lib/dim/rdma_dim.c | 4 ++--
> lib/glob.c | 2 +-
> lib/siphash.c | 36 ++--
> lib/ts_fsm.c| 2 +-
> lib/vsprintf.c | 14 +++---
> lib/xz/xz_dec_lzma2.c | 4 ++--
> lib/xz/xz_dec_stream.c | 16
> lib/zstd/bitstream.h| 10 +-
> lib/zstd/compress.c | 2 +-
> lib/zstd/decompress.c | 12 ++--
> lib/zstd/huf_compress.c | 4 ++--
> 16 files changed, 64 insertions(+), 64 deletions(-)
>
> diff --git a/lib/asn1_decoder.c b/lib/asn1_decoder.c
> index 58f72b25f8e9..13da529e2e72 100644
> --- a/lib/asn1_decoder.c
> +++ b/lib/asn1_decoder.c
> @@ -381,7 +381,7 @@ int asn1_ber_decoder(const struct asn1_decoder *decoder,
> case ASN1_OP_END_SET_ACT:
> if (unlikely(!(flags & FLAG_MATCHED)))
> goto tag_mismatch;
> - /* fall through */
> + fallthrough;
>
> case ASN1_OP_END_SEQ:
> case ASN1_OP_END_SET_OF:
> @@ -448,7 +448,7 @@ int asn1_ber_decoder(const struct asn1_decoder *decoder,
> pc += asn1_op_lengths[op];
> goto next_op;
> }
> - /* fall through */
> + fallthrough;
>
> case ASN1_OP_ACT:
> ret = actions[machine[pc + 1]](context, hdr, tag, data + tdp,
> len);
> diff --git a/lib/assoc_array.c b/lib/assoc_array.c
> index 6f4bcf524554..04c98799c3ba 100644
> --- a/lib/assoc_array.c
> +++ b/lib/assoc_array.c
> @@ -1113,7 +1113,7 @@ struct assoc_array_edit *assoc_array_delete(struct
> assoc_array *array,
> index_key))
> goto found_leaf;
> }
> - /* fall through */
> + fallthrough;
> case assoc_array_walk_tree_empty:
> case assoc_array_walk_found_wrong_shortcut:
> default:
> diff --git a/lib/bootconfig.c b/lib/bootconfig.c
> index 649ed44f199c..9f8c70a98fcf 100644
> --- a/lib/bootconfig.c
> +++ b/lib/bootconfig.c
> @@ -827,7 +827,7 @@ int __init xbc_init(char *buf, const char **emsg, int
> *epos)
> q - 2);
> break;
> }
> - /* fall through */
> + fallthrough;
> case '=':
> ret = xbc_parse_kv(&p, q, c);
> break;
> @@ -836,7 +836,7 @@ int __init xbc_init(char *buf, const char **emsg, int
> *epos)
> break;
> case '#':
> q = skip_comment(q);
> - /* fall through */
> + fallthrough;
> case ';':
> case '\n':
> ret = xbc_parse_key(&p, q);
> diff --git a/lib/cmdline.c b/lib/cmdline.c
> index 9e186234edc0..46f2cb4ce6d1 100644
> --- a/lib/cmdline.c
> +++ b/lib/cmdline.c
> @@ -144,23 +144,23 @@ unsigned long long memparse(const char *ptr, char
> **retptr)
> case 'E':
> case 'e':
> ret <<= 10;
> - /* fall through */
> + fallthrough;
> case 'P':
> case 'p':
> ret <<= 10;
> - /* fall through */
> + fallthrough;
> case 'T':
> case 't':
> ret <<= 10;
> - /* fall through */
> + fallthrough;
> case 'G':
> case 'g':
> ret <<= 10;
> - /* fall through */
> + fallthrough;
> case 'M':
> case 'm':
> ret <<= 10;
> - /* fall through */
> + fallthrough;
> case 'K':
> case 'k':
> ret <<= 10;
> diff --git a/lib/dim/net_dim.c b/lib/dim/net_dim.c
> index a4db51c21266..06811d866775 100644
> --- a/lib/dim/net_dim.c
> +++ b/lib/dim/net_dim.c
> @@ -233,7 +233,7 @@ void net_dim(struct dim *dim, struct dim_sample
> end_sample)
> schedule_work(&dim->work);
> break;
> }
> - /* fall through */
> + fallthrough;
> case DIM_START_MEASURE:
> dim_update_sample(end_sample.event_ctr, end_sample.pkt_ctr,
> end_sample.byte_ctr, &dim->start_sample);
> diff --git a/lib/dim
[PATCH v3 1/7] arm64: dts: meson: add audio playback to a95x
Add initial audio support limited to HDMI i2s.
Signed-off-by: Christian Hewitt
---
.../dts/amlogic/meson-gxbb-nexbox-a95x.dts| 40 +++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 67d901ed2fa3..b5b11cb9f393 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -10,6 +10,7 @@
#include "meson-gxbb.dtsi"
#include
#include
+#include
/ {
compatible = "nexbox,a95x", "amlogic,meson-gxbb";
@@ -139,6 +140,45 @@
};
};
};
+
+ sound {
+ compatible = "amlogic,gx-sound-card";
+ model = "GXBB-NEXBOX-A95X";
+ assigned-clocks = <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>,
+ <&clkc CLKID_MPLL2>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+ status = "okay";
+
+ dai-link-0 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
+ dai-format = "i2s";
+ mclk-fs = <256>;
+
+ codec-0 {
+ sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
+ };
+ };
+
+ dai-link-2 {
+ sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
+
+ codec-0 {
+ sound-dai = <&hdmi_tx>;
+ };
+ };
+ };
+};
+
+&aiu {
+ status = "okay";
};
&cvbs_vdac_port {
--
2.17.1
[PATCH v3 4/7] arm64: dts: meson: add audio playback to nanopi-k2
Add initial audio support limited to HDMI i2s.
Signed-off-by: Christian Hewitt
---
.../boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 40 +++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
index 7be3e354093b..8e5df00b06a2 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts
@@ -7,6 +7,7 @@
#include "meson-gxbb.dtsi"
#include
+#include
/ {
compatible = "friendlyarm,nanopi-k2", "amlogic,meson-gxbb";
@@ -130,6 +131,45 @@
};
};
};
+
+ sound {
+ compatible = "amlogic,gx-sound-card";
+ model = "GXBB-NANOPI-K2";
+ assigned-clocks = <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>,
+ <&clkc CLKID_MPLL2>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+ status = "okay";
+
+ dai-link-0 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
+ dai-format = "i2s";
+ mclk-fs = <256>;
+
+ codec-0 {
+ sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
+ };
+ };
+
+ dai-link-2 {
+ sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
+
+ codec-0 {
+ sound-dai = <&hdmi_tx>;
+ };
+ };
+ };
+};
+
+&aiu {
+ status = "okay";
};
&cec_AO {
--
2.17.1
[PATCH v3 6/7] arm64: dts: meson: add audio playback to wetek-hub
Add initial audio support limited to HDMI i2s.
Signed-off-by: Christian Hewitt
---
.../boot/dts/amlogic/meson-gxbb-wetek-hub.dts | 40 +++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
index 83b985bb015e..0c1570153842 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
@@ -7,10 +7,50 @@
/dts-v1/;
#include "meson-gxbb-wetek.dtsi"
+#include
/ {
compatible = "wetek,hub", "amlogic,meson-gxbb";
model = "WeTek Hub";
+
+ sound {
+ compatible = "amlogic,gx-sound-card";
+ model = "GXBB-WETEK-HUB";
+ assigned-clocks = <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>,
+ <&clkc CLKID_MPLL2>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+ status = "okay";
+
+ dai-link-0 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
+ dai-format = "i2s";
+ mclk-fs = <256>;
+
+ codec-0 {
+ sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
+ };
+ };
+
+ dai-link-2 {
+ sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
+
+ codec-0 {
+ sound-dai = <&hdmi_tx>;
+ };
+ };
+ };
+};
+
+&aiu {
+ status = "okay";
};
&ir {
--
2.17.1
[PATCH v3 2/7] arm64: dts: meson: add audio playback to khadas-vim
Add initial audio support limited to HDMI i2s.
Signed-off-by: Christian Hewitt
---
.../amlogic/meson-gxl-s905x-khadas-vim.dts| 43 ++-
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
index 8bcdffdf55d0..de5361f20cd6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
@@ -5,9 +5,9 @@
/dts-v1/;
-#include
-
#include "meson-gxl-s905x-p212.dtsi"
+#include
+#include
/ {
compatible = "khadas,vim", "amlogic,s905x", "amlogic,meson-gxl";
@@ -63,6 +63,45 @@
};
};
};
+
+ sound {
+ compatible = "amlogic,gx-sound-card";
+ model = "GXL-KHADAS-VIM1";
+ assigned-clocks = <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>,
+ <&clkc CLKID_MPLL2>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+ status = "okay";
+
+ dai-link-0 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
+ dai-format = "i2s";
+ mclk-fs = <256>;
+
+ codec-0 {
+ sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
+ };
+ };
+
+ dai-link-2 {
+ sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
+
+ codec-0 {
+ sound-dai = <&hdmi_tx>;
+ };
+ };
+ };
+};
+
+&aiu {
+ status = "okay";
};
&cec_AO {
--
2.17.1
[PATCH v3 7/7] arm64: dts: meson: add audio playback to wetek-play2
Add initial support limited to HDMI i2s and SPDIF (LPCM).
Signed-off-by: Christian Hewitt
---
.../dts/amlogic/meson-gxbb-wetek-play2.dts| 61 +++
1 file changed, 61 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
index 2ab8a3d10079..f2562c7de67c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-play2.dts
@@ -8,11 +8,19 @@
#include "meson-gxbb-wetek.dtsi"
#include
+#include
/ {
compatible = "wetek,play2", "amlogic,meson-gxbb";
model = "WeTek Play 2";
+ spdif_dit: audio-codec-0 {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ status = "okay";
+ sound-name-prefix = "DIT";
+ };
+
leds {
led-wifi {
label = "wetek-play:wifi-status";
@@ -39,6 +47,59 @@
gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_LOW>;
};
};
+
+ sound {
+ compatible = "amlogic,gx-sound-card";
+ model = "GXBB-WETEK-PLAY2";
+ assigned-clocks = <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>,
+ <&clkc CLKID_MPLL2>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+ status = "okay";
+
+ dai-link-0 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&aiu AIU_CPU CPU_SPDIF_FIFO>;
+ };
+
+ dai-link-2 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
+ dai-format = "i2s";
+ mclk-fs = <256>;
+
+ codec-0 {
+ sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
+ };
+ };
+
+ dai-link-3 {
+ sound-dai = <&aiu AIU_CPU CPU_SPDIF_ENCODER>;
+
+ codec-0 {
+ sound-dai = <&spdif_dit>;
+ };
+ };
+
+ dai-link-4 {
+ sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
+
+ codec-0 {
+ sound-dai = <&hdmi_tx>;
+ };
+ };
+ };
+};
+
+&aiu {
+ status = "okay";
+ pinctrl-0 = <&spdif_out_y_pins>;
+ pinctrl-names = "default";
};
&i2c_A {
--
2.17.1
[PATCH v3 0/7] arm64: dts: meson: add more GX soundcards
This series adds basic support for LPCM audio over HDMI and S/PDIF to GXBB/GXL/GXM devices that I own and have tested with. Audio can be extended in the future (some devices have DACs and headphone hardware to connect) but this gets the basics working. Changes from v2 - Drop p200/p201/p212-s905x/vega-s95 changes - Add khadas-vim(1) Changes from v1 - Drop nexbox-a1 and rbox-pro Christian Hewitt (7): arm64: dts: meson: add audio playback to a95x arm64: dts: meson: add audio playback to khadas-vim arm64: dts: meson: add audio playback to khadas-vim2 arm64: dts: meson: add audio playback to nanopi-k2 arm64: dts: meson: add audio playback to odroid-c2 arm64: dts: meson: add audio playback to wetek-hub arm64: dts: meson: add audio playback to wetek-play2 .../boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 40 .../dts/amlogic/meson-gxbb-nexbox-a95x.dts| 40 .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 40 .../boot/dts/amlogic/meson-gxbb-wetek-hub.dts | 40 .../dts/amlogic/meson-gxbb-wetek-play2.dts| 61 +++ .../amlogic/meson-gxl-s905x-khadas-vim.dts| 43 - .../dts/amlogic/meson-gxm-khadas-vim2.dts | 44 - 7 files changed, 303 insertions(+), 5 deletions(-) -- 2.17.1
[PATCH v3 3/7] arm64: dts: meson: add audio playback to khadas-vim2
Add initial audio support limited to HDMI i2s.
Signed-off-by: Christian Hewitt
---
.../dts/amlogic/meson-gxm-khadas-vim2.dts | 44 +--
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
index bff8ec2c1c70..d4734220443c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
@@ -7,9 +7,9 @@
/dts-v1/;
-#include
-
#include "meson-gxm.dtsi"
+#include
+#include
/ {
compatible = "khadas,vim2", "amlogic,s912", "amlogic,meson-gxm";
@@ -145,6 +145,45 @@
clock-frequency = <32768>;
pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
};
+
+ sound {
+ compatible = "amlogic,gx-sound-card";
+ model = "GXM-KHADAS-VIM2";
+ assigned-clocks = <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>,
+ <&clkc CLKID_MPLL2>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+ status = "okay";
+
+ dai-link-0 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
+ dai-format = "i2s";
+ mclk-fs = <256>;
+
+ codec-0 {
+ sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
+ };
+ };
+
+ dai-link-2 {
+ sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
+
+ codec-0 {
+ sound-dai = <&hdmi_tx>;
+ };
+ };
+ };
+};
+
+&aiu {
+ status = "okay";
};
&cec_AO {
@@ -154,7 +193,6 @@
hdmi-phandle = <&hdmi_tx>;
};
-
&cpu_cooling_maps {
map0 {
cooling-device = <&gpio_fan THERMAL_NO_LIMIT 1>;
--
2.17.1
[PATCH v3 5/7] arm64: dts: meson: add audio playback to odroid-c2
Add initial audio support limited to HDMI i2s.
Signed-off-by: Christian Hewitt
---
.../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 40 +++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 70fcfb7b0683..9d8c919c6e19 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -9,6 +9,7 @@
#include "meson-gxbb.dtsi"
#include
+#include
/ {
compatible = "hardkernel,odroid-c2", "amlogic,meson-gxbb";
@@ -172,6 +173,45 @@
};
};
};
+
+ sound {
+ compatible = "amlogic,gx-sound-card";
+ model = "GXBB-ODROID-C2";
+ assigned-clocks = <&clkc CLKID_MPLL0>,
+ <&clkc CLKID_MPLL1>,
+ <&clkc CLKID_MPLL2>;
+ assigned-clock-parents = <0>, <0>, <0>;
+ assigned-clock-rates = <294912000>,
+ <270950400>,
+ <393216000>;
+ status = "okay";
+
+ dai-link-0 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
+ };
+
+ dai-link-1 {
+ sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
+ dai-format = "i2s";
+ mclk-fs = <256>;
+
+ codec-0 {
+ sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
+ };
+ };
+
+ dai-link-2 {
+ sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
+
+ codec-0 {
+ sound-dai = <&hdmi_tx>;
+ };
+ };
+ };
+};
+
+&aiu {
+ status = "okay";
};
&cec_AO {
--
2.17.1
[PATCH 0/2] Bug Fixes to Tap Delay code in SDHCI Arasan driver
This patch set consists a couple of minor bug fixes for SDHCI Arasan driver. The fixes are for tap delay programming where in some cases tuning is failing for some of the SD cards. Manish Narani (2): mmc: sdhci-of-arasan: Use Mask writes for Tap delays mmc: sdhci-of-arasan: Issue DLL reset explicitly drivers/mmc/host/sdhci-of-arasan.c | 11 +++ 1 file changed, 11 insertions(+) -- 2.17.1
[PATCH 2/2] mmc: sdhci-of-arasan: Issue DLL reset explicitly
In the current implementation DLL reset will be issued for
each ITAP and OTAP setting inside ATF, this is creating issues
in some scenarios and this sequence is not inline with the TRM.
To fix the issue, DLL reset should be removed from the ATF and
host driver will request it explicitly.
This patch update host driver to explicitly request for DLL reset
before ITAP (assert DLL) and after OTAP (release DLL) settings.
Fixes: a5c8b2ae2e51 ("mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap
Delays Setup")
Signed-off-by: Sai Krishna Potthuri
Signed-off-by: Manish Narani
---
drivers/mmc/host/sdhci-of-arasan.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 3ec5ecad637c..e066d8f51954 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -635,6 +635,9 @@ static int sdhci_zynqmp_sdcardclk_set_phase(struct clk_hw
*hw, int degrees)
if (ret)
pr_err("Error setting Output Tap Delay\n");
+ eemi_ops->ioctl(node_id, IOCTL_SD_DLL_RESET,
+ PM_DLL_RESET_RELEASE, 0, NULL);
+
return ret;
}
@@ -794,6 +797,9 @@ static int sdhci_versal_sampleclk_set_phase(struct clk_hw
*hw, int degrees)
if (host->version < SDHCI_SPEC_300)
return 0;
+ eemi_ops->ioctl(node_id, IOCTL_SD_DLL_RESET,
+ PM_DLL_RESET_ASSERT, 0, NULL);
+
switch (host->timing) {
case MMC_TIMING_MMC_HS:
case MMC_TIMING_SD_HS:
--
2.17.1
Re: [PATCH v4 10/12] bus: mhi: core: Separate system error and power down handling
On Mon, Nov 09, 2020 at 12:47:29PM -0800, Bhaumik Bhatt wrote:
> Currently, there exist a set of if...else statements in the
> mhi_pm_disable_transition() function which make handling system
> error and disable transitions differently complex. To make that
> cleaner and facilitate differences in behavior, separate these
> two transitions for MHI host.
>
> Signed-off-by: Bhaumik Bhatt
Reviewed-by: Manivannan Sadhasivam
Thanks,
Mani
> ---
> drivers/bus/mhi/core/pm.c | 159
> +++---
> 1 file changed, 137 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> index 1d04e401..347ae7d 100644
> --- a/drivers/bus/mhi/core/pm.c
> +++ b/drivers/bus/mhi/core/pm.c
> @@ -444,7 +444,7 @@ static int mhi_pm_mission_mode_transition(struct
> mhi_controller *mhi_cntrl)
> return ret;
> }
>
> -/* Handle SYS_ERR and Shutdown transitions */
> +/* Handle shutdown transitions */
> static void mhi_pm_disable_transition(struct mhi_controller *mhi_cntrl,
> enum mhi_pm_state transition_state)
> {
> @@ -460,10 +460,6 @@ static void mhi_pm_disable_transition(struct
> mhi_controller *mhi_cntrl,
> to_mhi_pm_state_str(mhi_cntrl->pm_state),
> to_mhi_pm_state_str(transition_state));
>
> - /* We must notify MHI control driver so it can clean up first */
> - if (transition_state == MHI_PM_SYS_ERR_PROCESS)
> - mhi_cntrl->status_cb(mhi_cntrl, MHI_CB_SYS_ERROR);
> -
> mutex_lock(&mhi_cntrl->pm_mutex);
> write_lock_irq(&mhi_cntrl->pm_lock);
> prev_state = mhi_cntrl->pm_state;
> @@ -502,11 +498,8 @@ static void mhi_pm_disable_transition(struct
> mhi_controller *mhi_cntrl,
> MHICTRL_RESET_SHIFT,
> &in_reset) ||
> !in_reset, timeout);
> - if ((!ret || in_reset) && cur_state == MHI_PM_SYS_ERR_PROCESS) {
> + if (!ret || in_reset)
> dev_err(dev, "Device failed to exit MHI Reset state\n");
> - mutex_unlock(&mhi_cntrl->pm_mutex);
> - return;
> - }
>
> /*
>* Device will clear BHI_INTVEC as a part of RESET processing,
> @@ -566,19 +559,142 @@ static void mhi_pm_disable_transition(struct
> mhi_controller *mhi_cntrl,
> er_ctxt->wp = er_ctxt->rbase;
> }
>
> - if (cur_state == MHI_PM_SYS_ERR_PROCESS) {
> - mhi_ready_state_transition(mhi_cntrl);
> - } else {
> - /* Move to disable state */
> - write_lock_irq(&mhi_cntrl->pm_lock);
> - cur_state = mhi_tryset_pm_state(mhi_cntrl, MHI_PM_DISABLE);
> - write_unlock_irq(&mhi_cntrl->pm_lock);
> - if (unlikely(cur_state != MHI_PM_DISABLE))
> - dev_err(dev, "Error moving from PM state: %s to: %s\n",
> - to_mhi_pm_state_str(cur_state),
> - to_mhi_pm_state_str(MHI_PM_DISABLE));
> + /* Move to disable state */
> + write_lock_irq(&mhi_cntrl->pm_lock);
> + cur_state = mhi_tryset_pm_state(mhi_cntrl, MHI_PM_DISABLE);
> + write_unlock_irq(&mhi_cntrl->pm_lock);
> + if (unlikely(cur_state != MHI_PM_DISABLE))
> + dev_err(dev, "Error moving from PM state: %s to: %s\n",
> + to_mhi_pm_state_str(cur_state),
> + to_mhi_pm_state_str(MHI_PM_DISABLE));
> +
> + dev_dbg(dev, "Exiting with PM state: %s, MHI state: %s\n",
> + to_mhi_pm_state_str(mhi_cntrl->pm_state),
> + TO_MHI_STATE_STR(mhi_cntrl->dev_state));
> +
> + mutex_unlock(&mhi_cntrl->pm_mutex);
> +}
> +
> +/* Handle system error transitions */
> +static void mhi_pm_sys_error_transition(struct mhi_controller *mhi_cntrl)
> +{
> + enum mhi_pm_state cur_state, prev_state;
> + struct mhi_event *mhi_event;
> + struct mhi_cmd_ctxt *cmd_ctxt;
> + struct mhi_cmd *mhi_cmd;
> + struct mhi_event_ctxt *er_ctxt;
> + struct device *dev = &mhi_cntrl->mhi_dev->dev;
> + int ret, i;
> +
> + dev_dbg(dev, "Transitioning from PM state: %s to: %s\n",
> + to_mhi_pm_state_str(mhi_cntrl->pm_state),
> + to_mhi_pm_state_str(MHI_PM_SYS_ERR_PROCESS));
> +
> + /* We must notify MHI control driver so it can clean up first */
> + mhi_cntrl->status_cb(mhi_cntrl, MHI_CB_SYS_ERROR);
> +
> + mutex_lock(&mhi_cntrl->pm_mutex);
> + write_lock_irq(&mhi_cntrl->pm_lock);
> + prev_state = mhi_cntrl->pm_state;
> + cur_state = mhi_tryset_pm_state(mhi_cntrl, MHI_PM_SYS_ERR_PROCESS);
> + write_unlock_irq(&mhi_cntrl->pm_lock);
> +
> + if (cur_state != MHI_PM_SYS_ERR_PROCESS) {
> + dev_err(dev, "Failed to transition from PM state: %s to: %s\n",
> +
Re: [PATCH] pinctrl: at91-pio4: add support for fewer lines on last PIO bank
On Fri, Nov 13, 2020 at 03:24:29PM +0200, Eugen Hristev wrote:
> Some products, like sama7g5, do not have a full last bank of PIO lines.
> In this case for example, sama7g5 only has 8 lines for the PE bank.
> PA0-31, PB0-31, PC0-31, PD0-31, PE0-7, in total 136 lines.
> To cope with this situation, added a data attribute that is product dependent,
> to specify the number of lines of the last bank.
> In case this number is different from the macro ATMEL_PIO_NPINS_PER_BANK,
> adjust the total number of lines accordingly.
> This will avoid advertising 160 lines instead of the actual 136, as this
> product supports, and to avoid reading/writing to invalid register addresses.
>
> Signed-off-by: Eugen Hristev
Acked-by: Ludovic Desroches
Thanks.
> ---
> drivers/pinctrl/pinctrl-at91-pio4.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c
> b/drivers/pinctrl/pinctrl-at91-pio4.c
> index 578b387100d9..d267367d94b9 100644
> --- a/drivers/pinctrl/pinctrl-at91-pio4.c
> +++ b/drivers/pinctrl/pinctrl-at91-pio4.c
> @@ -71,8 +71,15 @@
> /* Custom pinconf parameters */
> #define ATMEL_PIN_CONFIG_DRIVE_STRENGTH (PIN_CONFIG_END + 1)
>
> +/**
> + * struct atmel_pioctrl_data - Atmel PIO controller (pinmux + gpio) data
> struct
> + * @nbanks: number of PIO banks
> + * @last_bank_count: number of lines in the last bank (can be less than
> + * the rest of the banks).
> + */
> struct atmel_pioctrl_data {
> unsigned nbanks;
> + unsigned last_bank_count;
> };
>
> struct atmel_group {
> @@ -980,11 +987,13 @@ static const struct dev_pm_ops atmel_pctrl_pm_ops = {
> * We can have up to 16 banks.
> */
> static const struct atmel_pioctrl_data atmel_sama5d2_pioctrl_data = {
> - .nbanks = 4,
> + .nbanks = 4,
> + .last_bank_count= ATMEL_PIO_NPINS_PER_BANK,
> };
>
> static const struct atmel_pioctrl_data microchip_sama7g5_pioctrl_data = {
> - .nbanks = 5,
> + .nbanks = 5,
> + .last_bank_count= 8, /* sama7g5 has only PE0 to PE7 */
> };
>
> static const struct of_device_id atmel_pctrl_of_match[] = {
> @@ -1025,6 +1034,11 @@ static int atmel_pinctrl_probe(struct platform_device
> *pdev)
> atmel_pioctrl_data = match->data;
> atmel_pioctrl->nbanks = atmel_pioctrl_data->nbanks;
> atmel_pioctrl->npins = atmel_pioctrl->nbanks * ATMEL_PIO_NPINS_PER_BANK;
> + /* if last bank has limited number of pins, adjust accordingly */
> + if (atmel_pioctrl_data->last_bank_count != ATMEL_PIO_NPINS_PER_BANK) {
> + atmel_pioctrl->npins -= ATMEL_PIO_NPINS_PER_BANK;
> + atmel_pioctrl->npins += atmel_pioctrl_data->last_bank_count;
> + }
>
> atmel_pioctrl->reg_base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(atmel_pioctrl->reg_base))
> --
> 2.25.1
>
Re: linux-next: build failure after merge of the akpm tree
Hi Mike,
On Sun, 15 Nov 2020 11:01:05 +0200 Mike Rapoport wrote:
>
> My preference would be to put the entire function body in '#ifdef
> CONFIG_MEMCG' here.
OK, so today I used this:
From: Stephen Rothwell
Date: Mon, 16 Nov 2020 16:55:10 +1100
Subject: [PATCH] secretmem-add-memcg-accounting-fix2
Signed-off-by: Stephen Rothwell
---
mm/secretmem.c | 4
1 file changed, 4 insertions(+)
diff --git a/mm/secretmem.c b/mm/secretmem.c
index 5ed6b2070136..c7a37b2d01ed 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -59,6 +59,7 @@ bool secretmem_active(void)
static int secretmem_memcg_charge(struct page *page, gfp_t gfp, int order)
{
+#ifdef CONFIG_MEMCG
unsigned long nr_pages = (1 << order);
int i, err;
@@ -72,11 +73,13 @@ static int secretmem_memcg_charge(struct page *page, gfp_t
gfp, int order)
p->memcg_data = page->memcg_data;
}
+#endif
return 0;
}
static void secretmem_memcg_uncharge(struct page *page, int order)
{
+#ifdef CONFIG_MEMCG
unsigned long nr_pages = (1 << order);
int i;
@@ -87,6 +90,7 @@ static void secretmem_memcg_uncharge(struct page *page, int
order)
}
memcg_kmem_uncharge_page(page, PMD_PAGE_ORDER);
+#endif
}
static int secretmem_pool_increase(struct secretmem_ctx *ctx, gfp_t gfp)
--
2.29.2
--
Cheers,
Stephen Rothwell
pgpWly60721G2.pgp
Description: OpenPGP digital signature
[PATCH 1/2] mmc: sdhci-of-arasan: Use Mask writes for Tap delays
Mask the ITAP and OTAP delay bits before updating with the new
tap value for Versal platform.
Fixes: 1a470721c8f5 ("sdhci: arasan: Add support for Versal Tap Delays")
Signed-off-by: Sai Krishna Potthuri
Signed-off-by: Manish Narani
---
drivers/mmc/host/sdhci-of-arasan.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 100621e55427..3ec5ecad637c 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -30,7 +30,10 @@
#define SDHCI_ARASAN_VENDOR_REGISTER 0x78
#define SDHCI_ARASAN_ITAPDLY_REGISTER 0xF0F8
+#define SDHCI_ARASAN_ITAPDLY_SEL_MASK 0xFF
+
#define SDHCI_ARASAN_OTAPDLY_REGISTER 0xF0FC
+#define SDHCI_ARASAN_OTAPDLY_SEL_MASK 0x3F
#define SDHCI_ARASAN_CQE_BASE_ADDR 0x200
#define VENDOR_ENHANCED_STROBE BIT(0)
@@ -755,6 +758,7 @@ static int sdhci_versal_sdcardclk_set_phase(struct clk_hw
*hw, int degrees)
regval = sdhci_readl(host, SDHCI_ARASAN_OTAPDLY_REGISTER);
regval |= SDHCI_OTAPDLY_ENABLE;
sdhci_writel(host, regval, SDHCI_ARASAN_OTAPDLY_REGISTER);
+ regval &= ~SDHCI_ARASAN_OTAPDLY_SEL_MASK;
regval |= tap_delay;
sdhci_writel(host, regval, SDHCI_ARASAN_OTAPDLY_REGISTER);
}
@@ -822,6 +826,7 @@ static int sdhci_versal_sampleclk_set_phase(struct clk_hw
*hw, int degrees)
sdhci_writel(host, regval, SDHCI_ARASAN_ITAPDLY_REGISTER);
regval |= SDHCI_ITAPDLY_ENABLE;
sdhci_writel(host, regval, SDHCI_ARASAN_ITAPDLY_REGISTER);
+ regval &= ~SDHCI_ARASAN_ITAPDLY_SEL_MASK;
regval |= tap_delay;
sdhci_writel(host, regval, SDHCI_ARASAN_ITAPDLY_REGISTER);
regval &= ~SDHCI_ITAPDLY_CHGWIN;
--
2.17.1
Re: [PATCH v4 04/12] bus: mhi: core: Move to SYS_ERROR regardless of RDDM capability
On Mon, Nov 09, 2020 at 12:47:23PM -0800, Bhaumik Bhatt wrote:
> In some cases, the entry of device to RDDM execution environment
> can occur after a significant amount of time has elapsed and a
> SYS_ERROR state change event has already arrived. This can result
> in scenarios where MHI controller and client drivers are unaware
> of the error state of the device. Remove the check for rddm_image
> when processing the SYS_ERROR state change as it is present in
> mhi_pm_sys_err_handler() already and prevent further activity
> until the expected RDDM execution environment change occurs or
> the controller driver decides further action.
>
> Signed-off-by: Bhaumik Bhatt
Reviewed-by: Manivannan Sadhasivam
Thanks,
Mani
> ---
> drivers/bus/mhi/core/main.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index f953e2a..91f8b8d 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -737,11 +737,6 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller
> *mhi_cntrl,
> {
> enum mhi_pm_state new_state;
>
> - /* skip SYS_ERROR handling if RDDM supported */
> - if (mhi_cntrl->ee == MHI_EE_RDDM ||
> - mhi_cntrl->rddm_image)
> - break;
> -
> dev_dbg(dev, "System error detected\n");
> write_lock_irq(&mhi_cntrl->pm_lock);
> new_state = mhi_tryset_pm_state(mhi_cntrl,
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
RE: [PATCH v2 0/3] Enable support IPI_CPU_CRASH_STOP to be pseudo-NMI
Hi Marc, Sumit What should I do to merge this patch. I would appreciate if you have any advice. I have not tested it with ThunderX2 yet. Best regards, Yuichi Ito > -Original Message- > From: Yuichi Ito > Sent: Wednesday, November 4, 2020 5:06 PM > To: m...@kernel.org; sumit.g...@linaro.org; t...@linutronix.de; > ja...@lakedaemon.net; catalin.mari...@arm.com; w...@kernel.org > Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Ito, > Yuichi/伊藤 有一 > Subject: [PATCH v2 0/3] Enable support IPI_CPU_CRASH_STOP to be > pseudo-NMI > > This patchset enables IPI_CPU_CRASH_STOP IPI to be pseudo-NMI. > This allows kdump to collect system information even when the CPU is in a > HARDLOCKUP state. > > Only IPI_CPU_CRASH_STOP uses NMI and the other IPIs remain normal > IRQs. > > The patch has been tested on FX1000. > > It also uses some of Sumit's IPI patch set for NMI.[1] > > [1] > https://lore.kernel.org/lkml/1603983387-8738-3-git-send-email-sumit.garg@l > inaro.org/ > > $ echo 1 > /proc/sys/kernel/panic_on_rcu_stal > $ echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT >: kernel panics and crash kernel boot >: makedumpfile saves the system state at HARDLOCKUP in vmcore. > > crash utility: > #7 [fe00290afd30] lkdtm_HARDLOCKUP at fe0010857ee8 > #8 [fe00290afd40] direct_entry at fe0010857c94 > #9 [fe00290afd90] full_proxy_write at fe001055dea0 > #10 [fe00290afdd0] vfs_write at fe001047533c > #11 [fe00290afe10] ksys_write at fe001047563c > #12 [fe00290afe60] __arm64_sys_write at fe00104756e8 > #13 [fe00290afe70] do_el0_svc at fe00101590cc > #14 [fe00290afea0] el0_svc at fe0010147a30 > #15 [fe00290afeb0] el0_sync_handler at fe001014835c > #16 [fe00290afff0] el0_sync at fe0010142c14 > > Changes in v1: > - Rebased to head of upstream master. > - Rebased to Sumit's latest IPIs patch-set [1]. > > [1] > https://lore.kernel.org/lkml/1603983387-8738-3-git-send-email-sumit.garg@l > inaro.org/ > > - Add conditional branch of local_irq_disable(). > > Sumit Garg (1): > irqchip/gic-v3: Enable support for SGIs to act as NMIs > > Yuichi Ito (2): > arch64: smp: Register IPI_CPU_CRASH_STOP IPI as pseudo-NMI > arch64: smp: Disable priority masking when received NMI on PSR.I section > > arch/arm64/kernel/smp.c | 44 > +++- > drivers/irqchip/irq-gic-v3.c | 29 + > 2 files changed, 56 insertions(+), 17 deletions(-) > > -- > 1.8.3.1
Re: [PATCH] NFS: only invalidate dentrys that are clearly invalid.
On Mon, Nov 16 2020, Trond Myklebust wrote:
> On Mon, 2020-11-16 at 16:12 +1100, NeilBrown wrote:
>> On Mon, Nov 16 2020, Trond Myklebust wrote:
>>
>> > On Mon, 2020-11-16 at 16:00 +1100, NeilBrown wrote:
>> > > On Mon, Nov 16 2020, Trond Myklebust wrote:
>> > >
>> > > > On Mon, 2020-11-16 at 15:43 +1100, NeilBrown wrote:
>> > > > > On Mon, Nov 16 2020, Trond Myklebust wrote:
>> > > > >
>> > > > > > On Mon, 2020-11-16 at 13:59 +1100, NeilBrown wrote:
>> > > > > > >
>> > > > > > > Prior to commit 5ceb9d7fdaaf ("NFS: Refactor
>> > > > > > > nfs_lookup_revalidate()")
>> > > > > > > and error from nfs_lookup_verify_inode() other than -
>> > > > > > > ESTALE
>> > > > > > > would
>> > > > > > > result
>> > > > > > > in nfs_lookup_revalidate() returning that error code (-
>> > > > > > > ESTALE
>> > > > > > > is
>> > > > > > > mapped
>> > > > > > > to zero).
>> > > > > > > Since that commit, all errors result in zero being
>> > > > > > > returned.
>> > > > > > >
>> > > > > > > When nfs_lookup_revalidate() returns zero, the dentry is
>> > > > > > > invalidated
>> > > > > > > and, significantly, if the dentry is a directory that is
>> > > > > > > mounted
>> > > > > > > on,
>> > > > > > > that mountpoint is lost.
>> > > > > > >
>> > > > > > > If you:
>> > > > > > > - mount an NFS filesystem which contains a directory
>> > > > > > > - mount something (e.g. tmpfs) on that directory
>> > > > > > > - use iptables (or scissors) to block traffic to the
>> > > > > > > server
>> > > > > > > - ls -l the-mounted-on-directory
>> > > > > > > - interrupt the 'ls -l'
>> > > > > > > you will find that the directory has been unmounted.
>> > > > > > >
>> > > > > > > This can be fixed by returning the actual error code from
>> > > > > > > nfs_lookup_verify_inode() rather then zero (except for -
>> > > > > > > ESTALE).
>> > > > > > >
>> > > > > > > Fixes: 5ceb9d7fdaaf ("NFS: Refactor
>> > > > > > > nfs_lookup_revalidate()")
>> > > > > > > Signed-off-by: NeilBrown
>> > > > > > > ---
>> > > > > > > fs/nfs/dir.c | 8 +---
>> > > > > > > 1 file changed, 5 insertions(+), 3 deletions(-)
>> > > > > > >
>> > > > > > > diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
>> > > > > > > index cb52db9a0cfb..d24acf556e9e 100644
>> > > > > > > --- a/fs/nfs/dir.c
>> > > > > > > +++ b/fs/nfs/dir.c
>> > > > > > > @@ -1350,7 +1350,7 @@ nfs_do_lookup_revalidate(struct
>> > > > > > > inode
>> > > > > > > *dir,
>> > > > > > > struct dentry *dentry,
>> > > > > > > unsigned int flags)
>> > > > > > > {
>> > > > > > > struct inode *inode;
>> > > > > > > - int error;
>> > > > > > > + int error = 0;
>> > > > > > >
>> > > > > > > nfs_inc_stats(dir, NFSIOS_DENTRYREVALIDATE);
>> > > > > > > inode = d_inode(dentry);
>> > > > > > > @@ -1372,8 +1372,10 @@ nfs_do_lookup_revalidate(struct
>> > > > > > > inode
>> > > > > > > *dir,
>> > > > > > > struct dentry *dentry,
>> > > > > > > nfs_check_verifier(dir, dentry, flags &
>> > > > > > > LOOKUP_RCU))
>> > > > > > > {
>> > > > > > > error = nfs_lookup_verify_inode(inode,
>> > > > > > > flags);
>> > > > > > > if (error) {
>> > > > > > > - if (error == -ESTALE)
>> > > > > > > + if (error == -ESTALE) {
>> > > > > > > nfs_zap_caches(dir);
>> > > > > > > + error = 0;
>> > > > > > > + }
>> > > > > > > goto out_bad;
>> > > > > > > }
>> > > > > > > nfs_advise_use_readdirplus(dir);
>> > > > > > > @@ -1395,7 +1397,7 @@ nfs_do_lookup_revalidate(struct
>> > > > > > > inode
>> > > > > > > *dir,
>> > > > > > > struct dentry *dentry,
>> > > > > > > out_bad:
>> > > > > > > if (flags & LOOKUP_RCU)
>> > > > > > > return -ECHILD;
>> > > > > > > - return nfs_lookup_revalidate_done(dir, dentry,
>> > > > > > > inode,
>> > > > > > > 0);
>> > > > > > > + return nfs_lookup_revalidate_done(dir, dentry,
>> > > > > > > inode,
>> > > > > > > error);
>> > > > > >
>> > > > > > Which errors do we actually need to return here? As far as
>> > > > > > I
>> > > > > > can
>> > > > > > tell,
>> > > > > > the only errors that nfs_lookup_verify_inode() is supposed
>> > > > > > to
>> > > > > > return is
>> > > > > > ENOMEM, ESTALE, ECHILD, and possibly EIO or ETiMEDOUT.
>> > > > > >
>> > > > > > Why would it be better to return those errors rather than
>> > > > > > just
>> > > > > > a 0
>> > > > > > when
>> > > > > > we need to invalidate the inode, particularly since we
>> > > > > > already
>> > > > > > have
>> > > > > > a
>> > > > > > special case in nfs_lookup_revalidate_done() when the
>> > > > > > dentry is
>> > > > > > root?
>> > > > >
>> > > > > ERESTARTSYS is the error that easily causes problems.
>> > > > >
>> > > > > Returning 0 causes d_invalidate() to be called which is quite
>> > > > > heavy
>> > > > > handed in m
Re: [PATCH] tick/nohz: Reduce the critical region for jiffies_seq
On 2020/11/16 3:43, Thomas Gleixner wrote:
> On Wed, Nov 11 2020 at 17:11, Yunfeng Ye wrote:
>> When nohz or nohz_full is configured, the concurrency calls of
>> tick_do_update_jiffies64 increases,
>
> Why?
>
When nohz=off, tick_do_update_jiffies64() is called by tick_sched_do_timer()
on the tick_do_timer_cpu only. But when nohz and nohz_full is on, the
concurrency calls of tick_do_update_jiffies64() increases, and it may be
called on every cpu cores, for example:
1)
irq_enter
tick_irq_enter
tick_nohz_irq_enter
tick_nohz_update_jiffies
2)
irq_exit
irq_exit_rcu
tick_irq_exit
tick_nohz_irq_exit
tick_nohz_full_update_tick
tick_nohz_restart_sched_tick
tick_do_update_jiffies64
3)
tick_nohz_idle_exit
__tick_nohz_idle_restart_tick
tick_nohz_restart_sched_tick
tick_do_update_jiffies64
>> and the conflict between jiffies_lock and jiffies_seq increases,
>> especially in multi-core scenarios.
>
> This does not make sense. The sequence counter is updated when holding
> the lock, so there is no conflict between the lock and the sequence
> count.
>
Yes, there is no conflict between the lock and the sequence count, but
when tick_do_update_jiffies64() is called one by one, the sequence count
will be updated, it will affect the latency of tick_nohz_next_event(),
because the priority of read seqcount is less than writer.
We meet a problem, the latency between irq_handler_exit and schedule cost
up to 9us, or more, we want to schedule quickly. below is the trace:
=>262651: <...>-87332 [013] dnh. 3773.487455: irq_handler_exit:
irq=4 ret=handled
=>262666: <...>-87332 [013] dn.. 3773.487464: rcu_utilization:
Start context switch
262667: <...>-87332 [013] dn.. 3773.487464: rcu_utilization:
End context switch
We use function_graph ftrace to find which function cost so much, and
find that it is tick_nohz_irq_exit():
80519.988765 | 31) | irq_exit() {
80519.988766 | 31) |tick_nohz_irq_exit() {
=>80519.988766 | 31) | tick_nohz_next_event() {
=>80519.988774 | 31) 0.570 us|get_next_timer_interrupt();
80519.988775 | 31) 0.390 us|timekeeping_max_deferment();
80519.988775 | 31) 9.200 us| }
80519.988776 | 31) 0.390 us| tick_nohz_stop_tick();
80519.988776 | 31) + 10.700 us |}
80519.988777 | 31) + 11.630 us | }
80519.988777 | 31) | /* rcu_utilization: Start context
switch */
The time between timestamp 80519.988766 and 80519.988774 is most, in function
tick_nohz_next_event(), there are the codes before calling
get_next_timer_interrupt():
static ktime_t tick_nohz_next_event(struct tick_sched *ts, int cpu)
{
u64 basemono, next_tick, next_tmr, next_rcu, delta, expires;
unsigned long basejiff;
unsigned int seq;
/* Read jiffies and the time when jiffies were updated last */
do {
seq = read_seqcount_begin(&jiffies_seq);
basemono = last_jiffies_update;
basejiff = jiffies;
} while (read_seqcount_retry(&jiffies_seq, seq));
ts->last_jiffies = basejiff;
ts->timer_expires_base = basemono;
So the reason is that the read_seqcount leading to the latency problem. we
want to reduce the critical region of the jiffies_seq.
We still to trace tick_do_update_jiffies64 function:
167044.988746 |5) + 34.720 us | } /* tick_do_update_jiffies64.part.2
*/
167044.988747 | 90) + 24.920 us | } /* tick_nohz_next_event */
167044.988747 |2) + 18.990 us | } /* tick_nohz_next_event */
167044.988747 | 84) + 17.430 us | } /* irq_exit */
167044.988748 | 92) + 34.150 us | } /* irq_exit */
167044.988749 | 63) 7.150 us| } /* generic_handle_irq */
167044.988750 |5) 3.120 us| } /* generic_handle_irq */
167044.988750 | 14) + 38.940 us | } /* tick_do_update_jiffies64.part.2
*/
167044.988751 | 61) 5.080 us| } /* tick_nohz_next_event */
167044.988751 | 23) + 35.010 us | } /* tick_nohz_next_event */
167044.988751 | 22) + 24.830 us | } /* tick_nohz_next_event */
167044.988751 | 28) + 40.140 us | } /* tick_do_update_jiffies64.part.2
*/
During a tick period, the tick_do_update_jiffies64() is called concurrency, and
the
time is up to 30+us. so the lockless quick check in tick_do_update_jiffies64()
cannot intercept all concurrency.
Currently we use the cmdline parameter "skew_tick=1" can reduce the the latency
mostly,
because the conflict is mainly caused by tick timer. But we still want to
reduce the
critical region of the jiffies_seq to reduce some latency, maybe many other
interrupt or timer happens at the same will still trigger the conflict.
>> However, it i
Re: [PATCH v2] bus: mhi: core: Add support MHI EE FP for download firmware
On Mon, Nov 02, 2020 at 08:34:14AM -0800, Bhaumik Bhatt wrote:
> On 2020-11-02 04:27, carl@quectel.com wrote:
> > From: "carl.yin"
> >
> > MHI wwan modems support download firmware to nand or emmc
> > by firehose protocol, process as next:
> > 1. modem boot up and enter EE AMSS, create DIAG channels (4, 5) device
> > 2. user space tool send EDL command via DIAG channel,
> >then modem enter EE EDL
> > 3. boot.c download 'flash programmer image' via BHI interface
> > 4. modem enter EE FP, and create EDL channels (34, 35) device
> > 5. user space tool download 'firmware image' to modem via EDL channels
> >by firehose protocol
> >
> > Signed-off-by: carl.yin
> > ---
> > drivers/bus/mhi/core/init.c | 2 ++
> > drivers/bus/mhi/core/internal.h | 1 +
> > drivers/bus/mhi/core/main.c | 5 -
> > drivers/bus/mhi/core/pm.c | 13 -
> > include/linux/mhi.h | 4 +++-
> > 5 files changed, 22 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> > index ac4aa5c..e34616b 100644
> > --- a/drivers/bus/mhi/core/init.c
> > +++ b/drivers/bus/mhi/core/init.c
> > @@ -26,6 +26,7 @@ const char * const mhi_ee_str[MHI_EE_MAX] = {
> > [MHI_EE_WFW] = "WFW",
> > [MHI_EE_PTHRU] = "PASS THRU",
> > [MHI_EE_EDL] = "EDL",
> > + [MHI_EE_FP] = "FLASH PROGRAMMER",
> > [MHI_EE_DISABLE_TRANSITION] = "DISABLE",
> > [MHI_EE_NOT_SUPPORTED] = "NOT SUPPORTED",
> > };
> > @@ -35,6 +36,7 @@ const char * const
> > dev_state_tran_str[DEV_ST_TRANSITION_MAX] = {
> > [DEV_ST_TRANSITION_READY] = "READY",
> > [DEV_ST_TRANSITION_SBL] = "SBL",
> > [DEV_ST_TRANSITION_MISSION_MODE] = "MISSION_MODE",
> > + [DEV_ST_TRANSITION_FP] = "FLASH_PROGRAMMER",
> > [DEV_ST_TRANSITION_SYS_ERR] = "SYS_ERR",
> > [DEV_ST_TRANSITION_DISABLE] = "DISABLE",
> > };
> > diff --git a/drivers/bus/mhi/core/internal.h
> > b/drivers/bus/mhi/core/internal.h
> > index 4abf0cf..6ae897a 100644
> > --- a/drivers/bus/mhi/core/internal.h
> > +++ b/drivers/bus/mhi/core/internal.h
> > @@ -386,6 +386,7 @@ enum dev_st_transition {
> > DEV_ST_TRANSITION_READY,
> > DEV_ST_TRANSITION_SBL,
> > DEV_ST_TRANSITION_MISSION_MODE,
> > + DEV_ST_TRANSITION_FP,
> > DEV_ST_TRANSITION_SYS_ERR,
> > DEV_ST_TRANSITION_DISABLE,
> > DEV_ST_TRANSITION_MAX,
> > diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> > index 3950792..a1e1561 100644
> > --- a/drivers/bus/mhi/core/main.c
> > +++ b/drivers/bus/mhi/core/main.c
> > @@ -422,7 +422,7 @@ irqreturn_t mhi_intvec_threaded_handler(int
> > irq_number, void *priv)
> > wake_up_all(&mhi_cntrl->state_event);
> >
> > /* For fatal errors, we let controller decide next step */
> > - if (MHI_IN_PBL(ee))
> > + if (MHI_IN_PBL(mhi_cntrl->ee))
> Let's please have this as a separate patch with a fixes tag, as it fixes a
> pre-existing bug. I am sure Mani would want this.
Yes. It is not recommended to club changes like this onto a single patch.
Thanks,
Mani
> > mhi_cntrl->status_cb(mhi_cntrl, MHI_CB_FATAL_ERROR);
> > else
> > mhi_pm_sys_err_handler(mhi_cntrl);
> > @@ -782,6 +782,9 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller
> > *mhi_cntrl,
> > case MHI_EE_SBL:
> > st = DEV_ST_TRANSITION_SBL;
> > break;
> > + case MHI_EE_FP:
> > + st = DEV_ST_TRANSITION_FP;
> > + break;
> When do you get this EE event on the control event ring? Does it come by
> after you
> have detected EE as FP from mhi_sync_power_up() and move to ready and then
> M0?
> > case MHI_EE_WFW:
> > case MHI_EE_AMSS:
> > st = DEV_ST_TRANSITION_MISSION_MODE;
> > diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> > index 3de7b16..2d68812 100644
> > --- a/drivers/bus/mhi/core/pm.c
> > +++ b/drivers/bus/mhi/core/pm.c
> > @@ -658,6 +658,12 @@ void mhi_pm_st_worker(struct work_struct *work)
> > case DEV_ST_TRANSITION_MISSION_MODE:
> > mhi_pm_mission_mode_transition(mhi_cntrl);
> > break;
> > + case DEV_ST_TRANSITION_FP:
> > + write_lock_irq(&mhi_cntrl->pm_lock);
> > + mhi_cntrl->ee = MHI_EE_FP;
> > + write_unlock_irq(&mhi_cntrl->pm_lock);
> > + mhi_create_devices(mhi_cntrl);
> > + break;
> > case DEV_ST_TRANSITION_READY:
> > mhi_ready_state_transition(mhi_cntrl);
> > break;
> > @@ -1077,10 +1083,15 @@ int mhi_sync_power_up(struct mhi_controller
> > *mhi_cntrl)
> >
> > wait_event_timeout(mhi_cntrl->state_event,
> >MHI_IN_MISSION_MODE(mhi_cntrl->ee) ||
> > +
Re: Error: invalid switch -me200
Christophe Leroy writes:
> Le 14/11/2020 à 01:20, Segher Boessenkool a écrit :
>> On Fri, Nov 13, 2020 at 12:14:18PM -0800, Nick Desaulniers wrote:
>> Error: invalid switch -me200
>> Error: unrecognized option -me200
>
> 251 cpu-as-$(CONFIG_E200) += -Wa,-me200
>
> Are those all broken configs, or is Kconfig messed up such that
> randconfig can select these when it should not?
Hmmm, looks like this flag does not exist in mainline binutils? There is
a thread in 2010 about this that Segher commented on:
https://lore.kernel.org/linuxppc-dev/9859e645-954d-4d07-8003-ffcd2391a...@kernel.crashing.org/
Guess this config should be eliminated?
>>
>> The help text for this config options says that e200 is used in 55xx,
>> and there *is* an -me5500 GAS flag (which probably does this same
>> thing, too). But is any of this tested, or useful, or wanted?
>>
>> Maybe Christophe knows, cc:ed.
>>
>
> I don't have much clue on this.
Me either.
> But I see on wikipedia that e5500 is a 64 bits powerpc
> (https://en.wikipedia.org/wiki/PowerPC_e5500)
>
> What I see is that NXP seems to provide a GCC version that includes
> aditionnal cpu (e200z0 e200z2
> e200z3 e200z4 e200z6 e200z7):
>
> valid arguments to '-mcpu=' are: 401 403 405 405fp 440 440fp 464 464fp 476
> 476fp 505 601 602 603
> 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4
> G5 a2 cell e200z0 e200z2
> e200z3 e200z4 e200z6 e200z7 e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e
> native power3 power4
> power5 power5+ power6 power6x power7 power8 powerpc powerpc64 powerpc64le
> rs64 titan "
>
> https://community.nxp.com/t5/MPC5xxx/GCC-generating-not-implemented-instructions/m-p/845049
>
> Apparently based on binutils 2.28
>
> https://www.nxp.com/docs/en/release-note/S32DS-POWER-v1-2-RN.pdf
>
> But that's not exactly -me200 though.
>
> Now, I can't see any defconfig that selects CONFIG_E200, so is that worth
> keeping it in the kernel
> at all ?
There was a commit in 2014 that suggests it worked at least to some
extent then:
3477e71d5319 ("powerpc/booke: Restrict SPE exception handlers to e200/e500
cores")
Presumably there was a non-upstream toolchain where it was supported?
AFAICS the kernel builds OK with just the cpu-as modification removed:
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index a4d56f0a41d9..16b8336f91dd 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -248,7 +248,6 @@ KBUILD_CFLAGS += $(call cc-option,-mno-string)
cpu-as-$(CONFIG_40x) += -Wa,-m405
cpu-as-$(CONFIG_44x) += -Wa,-m440
cpu-as-$(CONFIG_ALTIVEC) += $(call as-option,-Wa$(comma)-maltivec)
-cpu-as-$(CONFIG_E200) += -Wa,-me200
cpu-as-$(CONFIG_E500) += -Wa,-me500
# When using '-many -mpower4' gas will first try and find a matching power4
So that seems like the obvious fix for now.
I tried booting the resulting kernel in qemu, but I get:
$ qemu-system-ppc -M none -cpu e200 -kernel build\~/vmlinux
Error: Trying to register SPR 574 (23e) twice !
Which is not related AFAIK and indicates the qemu support is broken.
Unless we hear from someone that they're using mainline on an e200 then
it seems like it's a candidate for removal.
cheers
linux-next: build warning after merge of the jc_docs tree
Hi all,
After merging the jc_docs tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/translations/zh_CN/filesystems/tmpfs.rst:5: WARNING: undefined
label: tmpfs_index (if the link has no caption the label must precede a section
header)
Introduced by commit
09028e60fcea ("doc: zh_CN: add translatation for tmpfs")
--
Cheers,
Stephen Rothwell
pgpnqAmtXERrR.pgp
Description: OpenPGP digital signature
Fair Pay: Foundation in Philosophy
One needs a solid basis for Fair Pay. I have translated the prayer of La Quran. Using the concept Sino, that unifies science and Islam, represents a Fair Pay political unity of east and west. https://www.youtube.com/watch?v=-XHzklQnKhw Serenity, Ywe Cærlyn.
Re: [PATCH v5 2/5] phy: qcom-qmp: Add SM8250 PCIe QMP PHYs
On 27-10-20, 22:30, Manivannan Sadhasivam wrote: > SM8250 has multiple different PHY versions: > QMP GEN3x1 PHY - 1 lane > QMP GEN3x2 PHY - 2 lanes > QMP Modem PHY - 2 lanes > > Add support for these with relevant init sequence. In order to abstract > the init sequence, this commit introduces secondary tables which can > be used to factor out the unique sequence for each PHY while the former > tables can have the common sequence. Applied, thanks -- ~Vinod
