Tegra210/Tegra186/Tegra194 has incorrectly enabled
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK from the beginning of their support.
Tegra210 and later SDMMC hardware default uses sdmmc_legacy_tm (TMCLK)
all the time for hardware data timeout instead of SDCLK and this TMCLK
need to be kept enabled by Tegra sdmmc driver.
This series includes patches to fix this for Tegra210/Tegra186/Tegra194.
These patches need to be manually backported to 4.19.
Will send patches for 4.19 backport separately.
Delta between patch versions:
[v7]: v7 has below change
- v6 has implementation for retrieving tmclk irrespective of
clocks order. But based in internal discussion with Thierry
this is not required as typically order specified in DT
bindings is the order validator want to see in DT.
[v6]: v5 is sent out mistakenly with incorrect patches.
v6 includes proper patches addressing v4 feedback
- updated dt-binding doc to be more clear
- updated Tegra sdhci driver to retrieve sdhci and tmclk clocks
based on no. of clocks in sdhci device node as old device trees
do not use sdhci clock name and this allows proper clock retrival
irrespective of sdhci and tmclk clocks order in device tree.
- Added separate quirk for identifying SoC's supporting separate
timeout clock to be more clear.
[v5]: Include below changes based on v4 feedback
- updated dt-binding doc to be more clear
- updated Tegra sdhci driver to retrieve sdhci and tmclk clocks
based on no. of clocks in sdhci device node as old device trees
do not use sdhci clock name and this allows proper clock retrival
irrespective of sdhci and tmclk clocks order in device tree.
- Added separate quirk for identifying SoC's supporting separate
timeout clock to be more clear.
[v4]: Include additional dt-binding patch
[v3]: Same as v2 with fixes tag
[v2]: Includes minor fix
- Patch-0006: parentheses around operand of '!'
Sowjanya Komatineni (7):
sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210
sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186
dt-bindings: mmc: tegra: Add tmclk for Tegra210 and later
arm64: tegra: Add missing timeout clock to Tegra210 SDMMC
arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes
arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes
sdhci: tegra: Add missing TMCLK for data timeout
.../bindings/mmc/nvidia,tegra20-sdhci.txt | 32 +++++++++++--
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 20 ++++----
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 15 +++---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 20 ++++----
drivers/mmc/host/sdhci-tegra.c | 55 ++++++++++++++++++++--
5 files changed, 113 insertions(+), 29 deletions(-)
--
2.7.4
Hi,
I'm adding stable(a)vger.kernel.org
On 2020-06-20 05:26, Martin K. Petersen wrote:
> On Thu, 18 Jun 2020 15:16:30 +0200, Bodo Stroesser wrote:
>
>> This small series of patches consists of:
>> [PATCH 1/2 v2] scsi: target: tcmu: Optimize use of flush_dcache_page
>> [PATCH 2/2 v2] scsi: target: tcmu: Fix crash in tcmu_flush_dcache_range
>>
>> Together with commit
>> 8c4e0f212398 scsi: target: tcmu: Fix size in calls to tcmu_flush_dcache_range
>> these patches fix crashes in tcmu on ARM.
>>
>> [...]
>
> Applied to 5.9/scsi-queue, thanks!
>
> [1/2] scsi: target: tcmu: Optimize use of flush_dcache_page
> https://git.kernel.org/mkp/scsi/c/3c58f737231e
> [2/2] scsi: target: tcmu: Fix crash in tcmu_flush_dcache_range on ARM
> https://git.kernel.org/mkp/scsi/c/3145550a7f8b
>
Patch 2/2 of this series already made it into 5.8, (5.7,) 5.4 and 4.19,
but patch 1/2 was not added yet. The crash will be fixed with with both
patches only. So please consider adding patch 1/2 also. The full commit
is 3c58f737231e2c8cbf543a09d84d8c8e80e05e43
Thank you
Bodo
This is a note to let you know that I've just added the patch titled
usb: storage: Add unusual_uas entry for Sony PSZ drives
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 20934c0de13b49a072fb1e0ca79fe0fe0e40eae5 Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Wed, 26 Aug 2020 10:32:29 -0400
Subject: usb: storage: Add unusual_uas entry for Sony PSZ drives
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The PSZ-HA* family of USB disk drives from Sony can't handle the
REPORT OPCODES command when using the UAS protocol. This patch adds
an appropriate quirks entry.
Reported-and-tested-by: Till Dörges <doerges(a)pre-sense.de>
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
CC: <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20200826143229.GB400430@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/unusual_uas.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h
index 971f8a4354c8..711ab240058c 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -28,6 +28,13 @@
* and don't forget to CC: the USB development list <linux-usb(a)vger.kernel.org>
*/
+/* Reported-by: Till Dörges <doerges(a)pre-sense.de> */
+UNUSUAL_DEV(0x054c, 0x087d, 0x0000, 0x9999,
+ "Sony",
+ "PSZ-HA*",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_NO_REPORT_OPCODES),
+
/* Reported-by: Julian Groß <julian.g(a)posteo.de> */
UNUSUAL_DEV(0x059f, 0x105f, 0x0000, 0x9999,
"LaCie",
--
2.28.0
From: Dirk Behme <dirk.behme(a)de.bosch.com>
The i2c-rcar driver utilizes the Generic Reset Controller kernel
feature, so select the RESET_CONTROLLER option when the I2C_RCAR
option is selected.
Fixes: 2b16fd63059ab9 ("i2c: rcar: handle RXDMA HW behaviour on Gen3")
Cc: Wolfram Sang <wsa+renesas(a)sang-engineering.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Dirk Behme <dirk.behme(a)de.bosch.com>
Signed-off-by: Andy Lowe <andy_lowe(a)mentor.com>
[erosca: Add "if ARCH_RCAR_GEN3" on Wolfram's request]
Signed-off-by: Eugeniu Rosca <erosca(a)de.adit-jv.com>
---
v2:
- Append "if ARCH_RCAR_GEN3" to "select", as requested by Wolfram
in https://lore.kernel.org/linux-i2c/20200824120734.GA2500@ninjato/
v1:
- https://lore.kernel.org/linux-i2c/20200824062623.9346-1-erosca@de.adit-jv.c…
---
drivers/i2c/busses/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 293e7a0760e7..7ccbfbcb02e9 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1181,6 +1181,7 @@ config I2C_RCAR
tristate "Renesas R-Car I2C Controller"
depends on ARCH_RENESAS || COMPILE_TEST
select I2C_SLAVE
+ select RESET_CONTROLLER if ARCH_RCAR_GEN3
help
If you say yes to this option, support will be included for the
R-Car I2C controller.
--
2.28.0
The GSC registers report temperature in decidegrees celcius so we
need to scale it to represent the hwmon sysfs API of millidegrees.
Cc: stable(a)vger.kernel.org
Signed-off-by: Tim Harvey <tharvey(a)gateworks.com>
---
drivers/hwmon/gsc-hwmon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hwmon/gsc-hwmon.c b/drivers/hwmon/gsc-hwmon.c
index 3dfe2ca..c6d4567 100644
--- a/drivers/hwmon/gsc-hwmon.c
+++ b/drivers/hwmon/gsc-hwmon.c
@@ -172,6 +172,7 @@ gsc_hwmon_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
case mode_temperature:
if (tmp > 0x8000)
tmp -= 0xffff;
+ tmp *= 100; /* convert to millidegrees celsius */
break;
case mode_voltage_raw:
tmp = clamp_val(tmp, 0, BIT(GSC_HWMON_RESOLUTION));
--
2.7.4
From: Randy Dunlap <rdunlap(a)infradead.org>
Fix build error when CONFIG_ACPI is not set/enabled by adding
the header file <asm/acpi.h> which contains a stub for the function
in the build error.
../arch/x86/pci/intel_mid_pci.c: In function ‘intel_mid_pci_init’:
../arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? [-Werror=implicit-function-declaration]
acpi_noirq_set();
Fixes: a912a7584ec3 ("x86/platform/intel-mid: Move PCI initialization to arch_init()")
Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
Cc: stable(a)vger.kernel.org # v4.16+
Cc: Jacob Pan <jacob.jun.pan(a)linux.intel.com>
Cc: Len Brown <lenb(a)kernel.org>
To: Bjorn Helgaas <bhelgaas(a)google.com>
Cc: Jesse Barnes <jsbarnes(a)google.com>
Cc: Arjan van de Ven <arjan(a)linux.intel.com>
Cc: linux-pci(a)vger.kernel.org
Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com>
Reviewed-by: Jesse Barnes <jsbarnes(a)google.com>
Acked-by: Thomas Gleixner <tglx(a)linutronix.de>
---
Found in linux-next, but applies to/exists in mainline also.
v2:
- add Reviewed-by: and Acked-by: tags
- drop alternatives
arch/x86/pci/intel_mid_pci.c | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20200813.orig/arch/x86/pci/intel_mid_pci.c
+++ linux-next-20200813/arch/x86/pci/intel_mid_pci.c
@@ -33,6 +33,7 @@
#include <asm/hw_irq.h>
#include <asm/io_apic.h>
#include <asm/intel-mid.h>
+#include <asm/acpi.h>
#define PCIE_CAP_OFFSET 0x100
Tegra210/Tegra186/Tegra194 has incorrectly enabled
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK from the beginning of their support.
Tegra210 and later SDMMC hardware default uses sdmmc_legacy_tm (TMCLK)
all the time for hardware data timeout instead of SDCLK and this TMCLK
need to be kept enabled by Tegra sdmmc driver.
This series includes patches to fix this for Tegra210/Tegra186/Tegra194.
These patches need to be manually backported for 4.9, 4.14 and 4.19.
Will send patches to backport separately once these patches are ack'd.
Delta between patch versions:
[v6]: v5 is sent out mistakenly with incorrect patches.
v6 includes proper patches addressing v4 feedback
- updated dt-binding doc to be more clear
- updated Tegra sdhci driver to retrieve sdhci and tmclk clocks
based on no. of clocks in sdhci device node as old device trees
do not use sdhci clock name and this allows proper clock retrival
irrespective of sdhci and tmclk clocks order in device tree.
- Added separate quirk for identifying SoC's supporting separate
timeout clock to be more clear.
[v5]: Include below changes based on v4 feedback
- updated dt-binding doc to be more clear
- updated Tegra sdhci driver to retrieve sdhci and tmclk clocks
based on no. of clocks in sdhci device node as old device trees
do not use sdhci clock name and this allows proper clock retrival
irrespective of sdhci and tmclk clocks order in device tree.
- Added separate quirk for identifying SoC's supporting separate
timeout clock to be more clear.
[v4]: Include additional dt-binding patch
[v3]: Same as v2 with fixes tag
[v2]: Includes minor fix
- Patch-0006: parentheses around operand of '!'
Sowjanya Komatineni (7):
sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210
sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186
dt-bindings: mmc: tegra: Add tmclk for Tegra210 and later
arm64: tegra: Add missing timeout clock to Tegra210 SDMMC
arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes
arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes
sdhci: tegra: Add missing TMCLK for data timeout
.../bindings/mmc/nvidia,tegra20-sdhci.txt | 32 +++++++-
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 20 +++--
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 15 ++--
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 20 +++--
drivers/mmc/host/sdhci-tegra.c | 92 +++++++++++++++++++---
5 files changed, 144 insertions(+), 35 deletions(-)
--
2.7.4
commit 90a9b102eddf6a3f987d15f4454e26a2532c1c98 upstream.
As per PAPR we have to look for both EPOW sensor value and event
modifier to identify the type of event and take appropriate action.
In LoPAPR v1.1 section 10.2.2 includes table 136 "EPOW Action Codes":
SYSTEM_SHUTDOWN 3
The system must be shut down. An EPOW-aware OS logs the EPOW error
log information, then schedules the system to be shut down to begin
after an OS defined delay internal (default is 10 minutes.)
Then in section 10.3.2.2.8 there is table 146 "Platform Event Log
Format, Version 6, EPOW Section", which includes the "EPOW Event
Modifier":
For EPOW sensor value = 3
0x01 = Normal system shutdown with no additional delay
0x02 = Loss of utility power, system is running on UPS/Battery
0x03 = Loss of system critical functions, system should be shutdown
0x04 = Ambient temperature too high
All other values = reserved
We have a user space tool (rtas_errd) on LPAR to monitor for
EPOW_SHUTDOWN_ON_UPS. Once it gets an event it initiates shutdown
after predefined time. It also starts monitoring for any new EPOW
events. If it receives "Power restored" event before predefined time
it will cancel the shutdown. Otherwise after predefined time it will
shutdown the system.
Commit 79872e35469b ("powerpc/pseries: All events of
EPOW_SYSTEM_SHUTDOWN must initiate shutdown") changed our handling of
the "on UPS/Battery" case, to immediately shutdown the system. This
breaks existing setups that rely on the userspace tool to delay
shutdown and let the system run on the UPS.
Fixes: 79872e35469b ("powerpc/pseries: All events of EPOW_SYSTEM_SHUTDOWN must initiate shutdown")
Cc: stable(a)vger.kernel.org # v4.0+
Signed-off-by: Vasant Hegde <hegdevasant(a)linux.vnet.ibm.com>
[mpe: Massage change log and add PAPR references]
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Link: https://lore.kernel.org/r/20200820061844.306460-1-hegdevasant@linux.vnet.ib…
Signed-off-by: Vasant Hegde <hegdevasant(a)linux.vnet.ibm.com>
---
Hi,
Please apply this patch to linux-stable-v4.4 branch. Its already applied to
other required stable branches.
-Vasant
arch/powerpc/platforms/pseries/ras.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
index 9e817c1b7808..1fa8e492ce27 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -90,7 +90,6 @@ static void handle_system_shutdown(char event_modifier)
pr_emerg("Loss of power reported by firmware, system is "
"running on UPS/battery");
pr_emerg("Check RTAS error log for details");
- orderly_poweroff(true);
break;
case EPOW_SHUTDOWN_LOSS_OF_CRITICAL_FUNCTIONS:
--
2.26.2