Re: [RFC] mm: Proactive compaction
On 8/20/19 2:46 AM, Vlastimil Babka wrote: > +CC Khalid Aziz who proposed a different approach: > https://lore.kernel.org/linux-mm/20190813014012.30232-1-khalid.a...@oracle.com/T/#u > > On 8/16/19 11:43 PM, Nitin Gupta wrote: >> The patch has plenty of rough edges but posting it early to see if I'm >> going in the right direction and to get some early feedback. > > That's a lot of control knobs - how is an admin supposed to tune them to their > needs? > At a high level, this idea makes sense and is similar to the idea of watermarks for free pages. My concern is the same. We now have more knobs to tune and that increases complexity for sys admins as well as the chances of a misconfigured system. -- Khalid
[PATCH v2,0/3] arm64: meson-g12b: Add support for the Ugoos AM6
This patchset adds support for the Ugoos AM6, an Android STB based on the Amlogic W400 reference design with the S922X chipset. v2: correction of minor nits Christian Hewitt (3): dt-bindings: arm: amlogic: Add support for the Ugoos AM6 dt-bindings: Add vendor prefix for Ugoos arm64: dts: meson-g12b-ugoos-am6: add initial device-tree Documentation/devicetree/bindings/arm/amlogic.yaml | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm64/boot/dts/amlogic/Makefile | 1 + .../boot/dts/amlogic/meson-g12b-ugoos-am6.dts | 567 + 4 files changed, 571 insertions(+) create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts -- 2.7.4
Re: [linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC
Hi! Dne torek, 20. avgust 2019 ob 17:19:31 CEST je meg...@megous.com napisal(a): > From: Ondrej Jirman > > I went through the datasheets for H6 and H5, and compared the differences. > RTCs are largely similar, but not entirely compatible. Incompatibilities > are in details not yet implemented by the rtc driver though. > > I also corrected the clock tree in H6 DTSI. > > This patchset is necessary for implementing the WiFi/Bluetooth support > on boards using H6 SoC. > > There was some discussion previously of describing HOSC, DCXO and XO > oscillators and clocks as part of RTC in DT, but I decided against it > because it's not necessary, becuse information that would be provided > as a part of DT can already be determined at runtime from RTC registers, > so this woudn't add any value and would only introduce complications > to the driver. See: https://patchwork.kernel.org/cover/10898083/ > > Please take a look. > > > Thank you and regards, > Ondrej Jirman Sorry for a bit late test, but with your patches on Tanix TX6 box I get this in dmesg: [ 17.431742] sun6i-rtc 700.rtc: Failed to set rtc time. [ 20.439742] sun6i-rtc 700.rtc: rtc is still busy. [ 21.435744] sun6i-rtc 700.rtc: rtc is still busy. [ 24.055741] sun6i-rtc 700.rtc: rtc is still busy. [ 24.439752] sun6i-rtc 700.rtc: rtc is still busy. Last line is repeated non-stop. Any idea what could be wrong? Best regards, Jernej
[PATCH v2,1/3] dt-bindings: Add vendor prefix for Ugoos
Ugoos Industrial Co., Ltd. are a manufacturer of ARM based TV Boxes, Dongles, Digital Signage and Advertisement Solutions [0]. [0] (https://ugoos.com) Signed-off-by: Christian Hewitt --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 6992bbb..d962be9 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -965,6 +965,8 @@ patternProperties: description: Ubiquiti Networks "^udoo,.*": description: Udoo + "^ugoos,.*": +description: Ugoos Industrial Co., Ltd. "^uniwest,.*": description: United Western Technologies Corp (UniWest) "^upisemi,.*": -- 2.7.4
[PATCH v2,3/3] arm64: dts: meson-g12b-ugoos-am6: add initial device-tree
The Ugoos AM6 is based on the Amlogic W400 (G12B) reference design using the
S922X chipset. Hardware specifications:
- 2GB LPDDR4 RAM
- 16GB eMMC storage
- 10/100/1000 Base-T Ethernet using External RGMII PHY
- 802.11 a/b/g/b/ac + BT 5.0 sdio wireless (Ampak 6398S)
- HDMI 2.0 (4k@60p) video
- Composite video + 2-channel audio output on 3.5mm jack
- S/PDIF audio output
- Aux input
- 1x USB 3.0
- 3x USB 2.0
- 1x micro SD card slot
The device-tree is laregly based on meson-g12b-odroid-n2 but with audio
and USB config copied from meson-g12a-x96-max.
Tested-by: Oleg Ivanov
Signed-off-by: Christian Hewitt
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-g12b-ugoos-am6.dts | 567 +
2 files changed, 568 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
diff --git a/arch/arm64/boot/dts/amlogic/Makefile
b/arch/arm64/boot/dts/amlogic/Makefile
index 07b861f..21e2810 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12a-sei510.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-x96-max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-odroid-n2.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12b-ugoos-am6.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-nanopi-k2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-nexbox-a95x.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-odroidc2.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
new file mode 100644
index 000..27d1d62
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-ugoos-am6.dts
@@ -0,0 +1,567 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong
+ * Copyright (c) 2019 Christian Hewitt
+ */
+
+/dts-v1/;
+
+#include "meson-g12b.dtsi"
+#include "meson-g12b-s922x.dtsi"
+#include
+#include
+#include
+
+/ {
+ compatible = "ugoos,am6", "amlogic,g12b";
+ model = "Ugoos AM6";
+
+ aliases {
+ serial0 = &uart_AO;
+ ethernet0 = ðmac;
+ };
+
+ spdif_dit: audio-codec-1 {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ status = "okay";
+ sound-name-prefix = "DIT";
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x4000>;
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio BOOT_12 GPIO_ACTIVE_LOW>;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&wifi32k>;
+ clock-names = "ext_clock";
+ };
+
+ tflash_vdd: regulator-tflash_vdd {
+ compatible = "regulator-fixed";
+
+ regulator-name = "TFLASH_VDD";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+
+ gpio = <&gpio_ao GPIOAO_8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ tf_io: gpio-regulator-tf_io {
+ compatible = "regulator-gpio";
+
+ regulator-name = "TF_IO";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = <&gpio_ao GPIOAO_9 GPIO_ACTIVE_HIGH>;
+ gpios-states = <0>;
+
+ states = <330 0
+ 180 1>;
+ };
+
+ flash_1v8: regulator-flash_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "FLASH_1V8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ vin-supply = <&vcc_3v3>;
+ regulator-always-on;
+ };
+
+ main_12v: regulator-main_12v {
+ compatible = "regulator-fixed";
+ regulator-name = "12V";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ };
+
+ vcc_5v: regulator-vcc_5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ vin-supply = <&main_12v>;
+ };
+
+ vcc_1v8: regulator-vcc_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+
[PATCH v2,2/3] dt-bindings: arm: amlogic: Add support for the Ugoos AM6
The Ugoos AM6 is based on the Amlogic W400 (G12B) reference design using the S922X chipset. Signed-off-by: Christian Hewitt --- Documentation/devicetree/bindings/arm/amlogic.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 325c6fd..2ded61d 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -139,6 +139,7 @@ properties: items: - enum: - hardkernel,odroid-n2 + - ugoos,am6 - const: amlogic,g12b ... -- 2.7.4
Re: [linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC
Dne sobota, 24. avgust 2019 ob 10:04:24 CEST je Jernej Škrabec napisal(a): > Hi! > > Dne torek, 20. avgust 2019 ob 17:19:31 CEST je meg...@megous.com napisal(a): > > From: Ondrej Jirman > > > > I went through the datasheets for H6 and H5, and compared the differences. > > RTCs are largely similar, but not entirely compatible. Incompatibilities > > are in details not yet implemented by the rtc driver though. > > > > I also corrected the clock tree in H6 DTSI. > > > > This patchset is necessary for implementing the WiFi/Bluetooth support > > on boards using H6 SoC. > > > > There was some discussion previously of describing HOSC, DCXO and XO > > oscillators and clocks as part of RTC in DT, but I decided against it > > because it's not necessary, becuse information that would be provided > > as a part of DT can already be determined at runtime from RTC registers, > > so this woudn't add any value and would only introduce complications > > to the driver. See: https://patchwork.kernel.org/cover/10898083/ > > > > Please take a look. > > > > > > Thank you and regards, > > > > Ondrej Jirman > > Sorry for a bit late test, but with your patches on Tanix TX6 box I get this > in dmesg: > > [ 17.431742] sun6i-rtc 700.rtc: Failed to set rtc time. > [ 20.439742] sun6i-rtc 700.rtc: rtc is still busy. > [ 21.435744] sun6i-rtc 700.rtc: rtc is still busy. > [ 24.055741] sun6i-rtc 700.rtc: rtc is still busy. > [ 24.439752] sun6i-rtc 700.rtc: rtc is still busy. > > Last line is repeated non-stop. > > Any idea what could be wrong? Additional info - this is on kernel 5.2.6 with your patches applied. Best regards, Jernej
Re: WARNINGs in set_task_reclaim_state with memory cgroup and fullmemory usage
On Sat, Aug 24, 2019 at 12:51 PM Hillf Danton wrote: > > > On Sat, 24 Aug 2019 11:36:31 +0800 Yafang Shao wrote: > > On Sat, Aug 24, 2019 at 10:57 AM Hillf Danton wrote: > > > On Fri, 23 Aug 2019 18:00:15 -0400 Adric Blake wrote: > > > > Synopsis: > > > > A WARN_ON_ONCE is hit twice in set_task_reclaim_state under the > > > > following conditions: > > > > - a memory cgroup has been created and a task assigned it it > > > > - memory.limit_in_bytes has been set > > > > - memory has filled up, likely from cache > > > > > > > Thanks for report. > > > > > > > In my usage, I create a cgroup under the current session scope and > > > > assign a task to it. I then set memory.limit_in_bytes and > > > > memory.soft_limit_in_bytes for the cgroup to reasonable values, say > > > > 1G/512M. The program accesses large files frequently and gradually > > > > fills memory with the page cache. The warnings appears when the > > > > entirety of the system memory is filled, presumably from other > > > > programs. > > > > > > > > If I wait until the program has filled the entirety of system memory > > > > with cache and then assign a memory limit, the warnings appear > > > > immediately. > > > > > > > > I am building the linux git. I first noticed this issue with the > > > > drm-tip 5.3rc3 and 5.3rc4 kernels, and tested linux master after > > > > 5.3rc5 to confirm the bug more resoundingly. > > > > > > > > Here are the warnings. > > > > > > > > [38491.963105] WARNING: CPU: 7 PID: 175 at mm/vmscan.c:245 > > > > set_task_reclaim_state+0x1e/0x40 > > > > [38491.963106] Modules linked in: iwlmvm mac80211 libarc4 iwlwifi > > > > cfg80211 xt_comment nls_iso8859_1 nls_cp437 vfat fat xfs jfs btrfs xor > > > > raid6_pq libcrc32c ccm tun rfcomm fuse xt_tcpudp ip6t_REJECT > > > > nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_multiport xt_owner > > > > snd_hda_codec_hdmi ip6table_filter ip6_tables iptable_filter bnep ext4 > > > > crc32c_generic mbcache jbd2 snd_hda_codec_realtek > > > > snd_hda_codec_generic snd_soc_skl snd_soc_hdac_hda snd_hda_ext_core > > > > snd_soc_skl_ipc x86_pkg_temp_thermal intel_powerclamp snd_soc_sst_ipc > > > > coretemp snd_soc_sst_dsp snd_soc_acpi_intel_match kvm_intel > > > > snd_soc_acpi i915 snd_soc_core kvm snd_compress ac97_bus > > > > snd_pcm_dmaengine snd_hda_intel i2c_algo_bit btusb irqbypass > > > > drm_kms_helper btrtl snd_hda_codec dell_laptop btbcm crct10dif_pclmul > > > > snd_hda_core crc32c_intel btintel iTCO_wdt ghash_clmulni_intel drm > > > > ledtrig_audio aesni_intel iTCO_vendor_support snd_hwdep dell_wmi > > > > rtsx_usb_ms r8169 dell_smbios aes_x86_64 mei_hdcp crypto_simd > > > > intel_gtt bluetooth snd_pcm cryptd dcdbas > > > > [38491.963155] wmi_bmof dell_wmi_descriptor intel_rapl_msr > > > > glue_helper snd_timer joydev intel_cstate snd realtek memstick > > > > dell_smm_hwmon mousedev psmouse input_leds libphy intel_uncore > > > > ecdh_generic ecc crc16 rfkill intel_rapl_perf soundcore i2c_i801 > > > > agpgart mei_me tpm_crb syscopyarea sysfillrect sysimgblt mei > > > > intel_xhci_usb_role_switch fb_sys_fops idma64 tpm_tis roles > > > > processor_thermal_device intel_rapl_common i2c_hid tpm_tis_core > > > > int3403_thermal intel_soc_dts_iosf battery wmi intel_lpss_pci > > > > intel_lpss intel_pch_thermal tpm int3400_thermal int3402_thermal > > > > acpi_thermal_rel int340x_thermal_zone rng_core intel_hid ac > > > > sparse_keymap evdev mac_hid crypto_user ip_tables x_tables > > > > hid_multitouch rtsx_usb_sdmmc mmc_core rtsx_usb hid_logitech_hidpp > > > > sr_mod cdrom sd_mod uas usb_storage hid_logitech_dj hid_generic usbhid > > > > hid ahci serio_raw libahci atkbd libps2 libata xhci_pci scsi_mod > > > > xhci_hcd crc32_pclmul i8042 serio f2fs [last unloaded: cfg80211] > > > > [38491.963221] CPU: 7 PID: 175 Comm: kswapd0 Not tainted > > > > 5.3.0-rc5+149+gbb7ba8069de9 #1 > > > > [38491.963222] Hardware name: Dell Inc. Inspiron 5570/09YTN7, BIOS > > > > 1.2.3 05/15/2019 > > > > [38491.963226] RIP: 0010:set_task_reclaim_state+0x1e/0x40 > > > > [38491.963228] Code: 78 a9 e7 ff 0f 1f 84 00 00 00 00 00 0f 1f 44 00 > > > > 00 55 48 89 f5 53 48 89 fb 48 85 ed 48 8b 83 08 08 00 00 74 11 48 85 > > > > c0 74 02 <0f> 0b 48 89 ab 08 08 00 00 5b 5d c3 48 85 c0 75 f1 0f 0b 48 > > > > 89 ab > > > > [38491.963229] RSP: 0018:8c898031fc60 EFLAGS: 00010286 > > > > [38491.963230] RAX: 8c898031fe28 RBX: 892aa04ddc40 RCX: > > > > > > > > [38491.963231] RDX: 8c898031fc60 RSI: 8c898031fcd0 RDI: > > > > 892aa04ddc40 > > > > [38491.963233] RBP: 8c898031fcd0 R08: 8c898031fd48 R09: > > > > 89279674b800 > > > > [38491.963234] R10: R11: R12: > > > > 8c898031fd48 > > > > [38491.963235] R13: 892a842ef000 R14: 892aaf7fc000 R15: > > > > > > > > [38491.963236] FS: () GS:892aa33c() > > > > knlGS: > > > > [38491.963238] CS: 0010 DS: ES: CR0:
[PATCH v3] Russian entry is incorrect. According to the last regulations document of Feb 29, 2016, 160 MHz channels and 802.11ad are allowed.
http://rfs-rf.ru/upload/medialibrary/c1a/prilozhenie-1-k-resheniyu-gkrch-_-16_36_03.pdf Note that there was never a DFS requirement in Russia, but always was NO-OUTDOOR on 5GHz. Maximum power is 200mW that is ~23dBm on all 5GHz channels. Also Russia has never been regulated by ETSI. EIRP has been reduced by 4dBm because of TPC requirement. Signed-off-by: Dmitry Tunin --- db.txt | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/db.txt b/db.txt index 37393e6..9e4dc27 100644 --- a/db.txt +++ b/db.txt @@ -1097,14 +1097,12 @@ country RS: DFS-ETSI # 60 GHz band channels 1-4, ref: Etsi En 302 567 (57000 - 66000 @ 2160), (40) -country RU: DFS-ETSI - (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (20), AUTO-BW - (5250 - 5330 @ 80), (20), DFS, AUTO-BW - (5650 - 5730 @ 80), (30), DFS - (5735 - 5835 @ 80), (30) +country RU: + (2400 - 2483.5 @ 40), (20) + (5150 - 5350 @ 160), (20), NO-OUTDOOR + (5650 - 5850 @ 160), (20), NO-OUTDOOR # 60 GHz band channels 1-4, ref: Changes to NLA 124_Order ???129_22042015.pdf - (57000 - 66000 @ 2160), (40) + (57000 - 66000 @ 2160), (40), NO-OUTDOOR country RW: DFS-FCC (2402 - 2482 @ 40), (20) -- 2.7.4
Re: [PATCH v3] Russian entry is incorrect. According to the last regulations document of Feb 29, 2016, 160 MHz channels and 802.11ad are allowed.
> EIRP has been reduced by 4dBm because of TPC requirement. This is a typo. It's actuall 3dBm for 5 GHz.
Re: [PATCH] x86/microcode: Update microcode for all cores in parallel
On Thu, Aug 22, 2019 at 11:43:47PM +0300, Mihai Carabas wrote: > From: Ashok Raj > > Microcode update was changed to be serialized due to restrictions after > Spectre days. Updating serially on a large multi-socket system can be > painful since we do this one CPU at a time. Cloud customers have expressed > discontent as services disappear for a prolonged time. The restriction is > that only one core goes through the update while other cores are quiesced. > The update is now done only on the first thread of each core while other > siblings simply wait for this to complete. > > Signed-off-by: Ashok Raj > Signed-off-by: Mihai Carabas > --- > arch/x86/kernel/cpu/microcode/core.c | 44 > --- > arch/x86/kernel/cpu/microcode/intel.c | 14 --- > 2 files changed, 36 insertions(+), 22 deletions(-) Thanks, I did some cleaning up and smoke testing. It looks ok so far. The versions I'm going to hammer on more - and I'd appreciate it if you did so too, when possible - as a reply to this message. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH 1/2] x86/microcode: Update late microcode in parallel
From: Ashok Raj
Date: Thu, 22 Aug 2019 23:43:47 +0300
Microcode update was changed to be serialized due to restrictions after
Spectre days. Updating serially on a large multi-socket system can be
painful since it is being done on one CPU at a time.
Cloud customers have expressed discontent as services disappear for a
prolonged time. The restriction is that only one core goes through the
update while other cores are quiesced.
Do the microcode update only on the first thread of each core while
other siblings simply wait for this to complete.
[ bp: Simplify, massage, cleanup comments. ]
Signed-off-by: Ashok Raj
Signed-off-by: Mihai Carabas
Signed-off-by: Borislav Petkov
Cc: Boris Ostrovsky
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Jon Grimm
Cc: kanth.ghatr...@oracle.com
Cc: konrad.w...@oracle.com
Cc: patrick.c...@oracle.com
Cc: Thomas Gleixner
Cc: Tom Lendacky
Cc: x86-ml
Link:
https://lkml.kernel.org/r/1566506627-16536-2-git-send-email-mihai.cara...@oracle.com
---
arch/x86/kernel/cpu/microcode/core.c | 36
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/core.c
b/arch/x86/kernel/cpu/microcode/core.c
index cb0fdcaf1415..7019d4b2df0c 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -63,11 +63,6 @@ LIST_HEAD(microcode_cache);
*/
static DEFINE_MUTEX(microcode_mutex);
-/*
- * Serialize late loading so that CPUs get updated one-by-one.
- */
-static DEFINE_RAW_SPINLOCK(update_lock);
-
struct ucode_cpu_info ucode_cpu_info[NR_CPUS];
struct cpu_info_ctx {
@@ -566,11 +561,18 @@ static int __reload_late(void *info)
if (__wait_for_cpus(&late_cpus_in, NSEC_PER_SEC))
return -1;
- raw_spin_lock(&update_lock);
- apply_microcode_local(&err);
- raw_spin_unlock(&update_lock);
+ /*
+* On an SMT system, it suffices to load the microcode on one sibling of
+* the core because the microcode engine is shared between the threads.
+* Synchronization still needs to take place so that no concurrent
+* loading attempts happen on multiple threads of an SMT core. See
+* below.
+*/
+ if (cpumask_first(topology_sibling_cpumask(cpu)) == cpu)
+ apply_microcode_local(&err);
+ else
+ goto wait_for_siblings;
- /* siblings return UCODE_OK because their engine got updated already */
if (err > UCODE_NFOUND) {
pr_warn("Error reloading microcode on CPU %d\n", cpu);
ret = -1;
@@ -578,14 +580,18 @@ static int __reload_late(void *info)
ret = 1;
}
+wait_for_siblings:
+ if (__wait_for_cpus(&late_cpus_out, NSEC_PER_SEC))
+ panic("Timeout during microcode update!\n");
+
/*
-* Increase the wait timeout to a safe value here since we're
-* serializing the microcode update and that could take a while on a
-* large number of CPUs. And that is fine as the *actual* timeout will
-* be determined by the last CPU finished updating and thus cut short.
+* At least one thread has completed update on each core.
+* For others, simply call the update to make sure the
+* per-cpu cpuinfo can be updated with right microcode
+* revision.
*/
- if (__wait_for_cpus(&late_cpus_out, NSEC_PER_SEC * num_online_cpus()))
- panic("Timeout during microcode update!\n");
+ if (cpumask_first(topology_sibling_cpumask(cpu)) != cpu)
+ apply_microcode_local(&err);
return ret;
}
--
2.21.0
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH 2/2] x86/microcode/intel: Issue the revision updated message only on the BSP
From: Borislav Petkov
Date: Sat, 24 Aug 2019 10:01:53 +0200
... in order to not pollute dmesg with a line for each updated microcode
engine.
Signed-off-by: Borislav Petkov
Cc: Ashok Raj
Cc: Boris Ostrovsky
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Jon Grimm
Cc: kanth.ghatr...@oracle.com
Cc: konrad.w...@oracle.com
Cc: Mihai Carabas
Cc: patrick.c...@oracle.com
Cc: Thomas Gleixner
Cc: Tom Lendacky
Cc: x86-ml
---
arch/x86/kernel/cpu/microcode/intel.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c
b/arch/x86/kernel/cpu/microcode/intel.c
index ce799cfe9434..6a99535d7f37 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -791,6 +791,7 @@ static enum ucode_state apply_microcode_intel(int cpu)
{
struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
struct cpuinfo_x86 *c = &cpu_data(cpu);
+ bool bsp = c->cpu_index == boot_cpu_data.cpu_index;
struct microcode_intel *mc;
enum ucode_state ret;
static int prev_rev;
@@ -836,7 +837,7 @@ static enum ucode_state apply_microcode_intel(int cpu)
return UCODE_ERROR;
}
- if (rev != prev_rev) {
+ if (bsp && rev != prev_rev) {
pr_info("updated to revision 0x%x, date = %04x-%02x-%02x\n",
rev,
mc->hdr.date & 0x,
@@ -852,7 +853,7 @@ static enum ucode_state apply_microcode_intel(int cpu)
c->microcode = rev;
/* Update boot_cpu_data's revision too, if we're on the BSP: */
- if (c->cpu_index == boot_cpu_data.cpu_index)
+ if (bsp)
boot_cpu_data.microcode = rev;
return ret;
--
2.21.0
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH v2] sched/fair: don't assign runtime for throttled cfs_rq
do_sched_cfs_period_timer() will refill cfs_b runtime and call
distribute_cfs_runtime() to unthrottle cfs_rq, sometimes cfs_b->runtime
will allocate all quota to one cfs_rq incorrectly.
This will cause other cfs_rq can't get runtime and will be throttled.
We find that one throttled cfs_rq has non-negative
cfs_rq->runtime_remaining and cause an unexpetced cast from s64 to u64
in snippet: distribute_cfs_runtime() {
runtime = -cfs_rq->runtime_remaining + 1; }.
This cast will cause that runtime will be a large number and
cfs_b->runtime will be subtracted to be zero at last.
According to Ben Segall, the throttled cfs_rq can have
account_cfs_rq_runtime called on it because it is throttled before
idle_balance, and the idle_balance calls update_rq_clock to add time
that is accounted to the task.
This commit prevents cfs_rq to be assgined new runtime if it has been
throttled to avoid the above incorrect type cast.
Signed-off-by: Liangyan
Reviewed-by: Ben Segall
Reviewed-by: Valentin Schneider
---
kernel/sched/fair.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bc9cfeaac8bd..ac3ae694d850 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4470,6 +4470,8 @@ static void __account_cfs_rq_runtime(struct cfs_rq
*cfs_rq, u64 delta_exec)
if (likely(cfs_rq->runtime_remaining > 0))
return;
+ if (cfs_rq->throttled)
+ return;
/*
* if we're unable to extend our runtime we resched so that the active
* hierarchy can be throttled
@@ -4673,6 +4675,9 @@ static u64 distribute_cfs_runtime(struct cfs_bandwidth
*cfs_b,
if (!cfs_rq_throttled(cfs_rq))
goto next;
+ /* By the above check, this should never be true */
+ WARN_ON(cfs_rq->runtime_remaining > 0);
+
runtime = -cfs_rq->runtime_remaining + 1;
if (runtime > remaining)
runtime = remaining;
--
2.14.4.44.g2045bb6
[GIT PULL] SCSI fixes for 5.3-rc5
Four fixes, three for edge conditions which don't occur very often.
The lpfc fix mitigates memory exhaustion for some high CPU systems.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Adrian Hunter (1):
scsi: ufs: Fix NULL pointer dereference in ufshcd_config_vreg_hpm()
Bill Kuzeja (1):
scsi: qla2xxx: Fix gnl.l memory leak on adapter init failure
Dmitry Fomichev (1):
scsi: target: tcmu: avoid use-after-free after command timeout
James Smart (1):
scsi: lpfc: Mitigate high memory pre-allocation by SCSI-MQ
and the diffstat:
drivers/scsi/lpfc/lpfc.h | 1 +
drivers/scsi/lpfc/lpfc_attr.c | 15 +++
drivers/scsi/lpfc/lpfc_init.c | 10 ++
drivers/scsi/lpfc/lpfc_sli4.h | 5 +
drivers/scsi/qla2xxx/qla_attr.c | 2 ++
drivers/scsi/qla2xxx/qla_os.c | 11 ++-
drivers/scsi/ufs/ufshcd.c | 3 +++
drivers/target/target_core_user.c | 9 +++--
8 files changed, 49 insertions(+), 7 deletions(-)
With full diff below.
James
---
diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index 2c3bb8a966e5..bade2e025ecf 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -824,6 +824,7 @@ struct lpfc_hba {
uint32_t cfg_cq_poll_threshold;
uint32_t cfg_cq_max_proc_limit;
uint32_t cfg_fcp_cpu_map;
+ uint32_t cfg_fcp_mq_threshold;
uint32_t cfg_hdw_queue;
uint32_t cfg_irq_chann;
uint32_t cfg_suppress_rsp;
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index ea62322ffe2b..8d8c495b5b60 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -5708,6 +5708,19 @@ LPFC_ATTR_RW(nvme_oas, 0, 0, 1,
LPFC_ATTR_RW(nvme_embed_cmd, 1, 0, 2,
"Embed NVME Command in WQE");
+/*
+ * lpfc_fcp_mq_threshold: Set the maximum number of Hardware Queues
+ * the driver will advertise it supports to the SCSI layer.
+ *
+ * 0= Set nr_hw_queues by the number of CPUs or HW queues.
+ * 1,128 = Manually specify the maximum nr_hw_queue value to be set,
+ *
+ * Value range is [0,128]. Default value is 8.
+ */
+LPFC_ATTR_R(fcp_mq_threshold, LPFC_FCP_MQ_THRESHOLD_DEF,
+ LPFC_FCP_MQ_THRESHOLD_MIN, LPFC_FCP_MQ_THRESHOLD_MAX,
+ "Set the number of SCSI Queues advertised");
+
/*
* lpfc_hdw_queue: Set the number of Hardware Queues the driver
* will advertise it supports to the NVME and SCSI layers. This also
@@ -6030,6 +6043,7 @@ struct device_attribute *lpfc_hba_attrs[] = {
&dev_attr_lpfc_cq_poll_threshold,
&dev_attr_lpfc_cq_max_proc_limit,
&dev_attr_lpfc_fcp_cpu_map,
+ &dev_attr_lpfc_fcp_mq_threshold,
&dev_attr_lpfc_hdw_queue,
&dev_attr_lpfc_irq_chann,
&dev_attr_lpfc_suppress_rsp,
@@ -7112,6 +7126,7 @@ lpfc_get_cfgparam(struct lpfc_hba *phba)
/* Initialize first burst. Target vs Initiator are different. */
lpfc_nvme_enable_fb_init(phba, lpfc_nvme_enable_fb);
lpfc_nvmet_fb_size_init(phba, lpfc_nvmet_fb_size);
+ lpfc_fcp_mq_threshold_init(phba, lpfc_fcp_mq_threshold);
lpfc_hdw_queue_init(phba, lpfc_hdw_queue);
lpfc_irq_chann_init(phba, lpfc_irq_chann);
lpfc_enable_bbcr_init(phba, lpfc_enable_bbcr);
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index a7549ae32542..1ac98becb5ba 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -4309,10 +4309,12 @@ lpfc_create_port(struct lpfc_hba *phba, int instance,
struct device *dev)
shost->max_cmd_len = 16;
if (phba->sli_rev == LPFC_SLI_REV4) {
- if (phba->cfg_fcp_io_sched == LPFC_FCP_SCHED_BY_HDWQ)
- shost->nr_hw_queues = phba->cfg_hdw_queue;
- else
- shost->nr_hw_queues = phba->sli4_hba.num_present_cpu;
+ if (!phba->cfg_fcp_mq_threshold ||
+ phba->cfg_fcp_mq_threshold > phba->cfg_hdw_queue)
+ phba->cfg_fcp_mq_threshold = phba->cfg_hdw_queue;
+
+ shost->nr_hw_queues = min_t(int, 2 * num_possible_nodes(),
+ phba->cfg_fcp_mq_threshold);
shost->dma_boundary =
phba->sli4_hba.pc_sli4_params.sge_supp_len-1;
diff --git a/drivers/scsi/lpfc/lpfc_sli4.h b/drivers/scsi/lpfc/lpfc_sli4.h
index 3aeca387b22a..329f7aa7e169 100644
--- a/drivers/scsi/lpfc/lpfc_sli4.h
+++ b/drivers/scsi/lpfc/lpfc_sli4.h
@@ -44,6 +44,11 @@
#define LPFC_HBA_HDWQ_MAX 128
#define LPFC_HBA_HDWQ_DEF 0
+/* FCP MQ queue count limiting */
+#define LPFC_FCP_MQ_THRESHOLD_MIN 0
+#define LPFC_FCP_MQ_THRESHOLD_MAX 128
+#define LPFC_FCP_MQ_THRESHOLD_DEF 8
+
/* Common buffer size to accomidate SCSI and NVME IO buffers */
#define LPFC_COMMON_IO_BUF_SZ 768
diff --git a/drivers/scsi/qla2
Re: [alsa-devel] [RESEND PATCH v4 1/4] dt-bindings: soundwire: add slave bindings
On 23/08/2019 17:44, Pierre-Louis Bossart wrote:
On 8/23/19 10:57 AM, Srinivas Kandagatla wrote:
On 23/08/2019 16:41, Pierre-Louis Bossart wrote:
On 8/22/19 6:37 PM, Srinivas Kandagatla wrote:
This patch adds bindings for Soundwire Slave devices that includes how
SoundWire enumeration address and Link ID are used to represented in
SoundWire slave device tree nodes.
Signed-off-by: Srinivas Kandagatla
---
.../soundwire/soundwire-controller.yaml | 75
+++
1 file changed, 75 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml
diff --git
a/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml
b/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml
new file mode 100644
index ..91aa6c6d6266
--- /dev/null
+++
b/Documentation/devicetree/bindings/soundwire/soundwire-controller.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/soundwire/soundwire-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SoundWire Controller Generic Binding
+
+maintainers:
+ - Srinivas Kandagatla
+
+description: |
+ SoundWire busses can be described with a node for the SoundWire
controller
+ device and a set of child nodes for each SoundWire slave on the bus.
+
+properties:
+ $nodename:
+ pattern: "^soundwire(@.*|-[0-9a-f])*$"
re-reading this, it looks like you are defining the controller bindings,
but there are no real controller-level properties except for the fact
that they include slave bindings?
Yes, Each vendor specific master can have there specific properties
here, this is just to represent how slave nodes represented w.r.t to
master nodes.
In MIPI the notion of controller is that it can deal with multiple
links, each of which having specific properties (clock speed, clock stop
properties, etc).
+
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^.*@[0-9a-f]+$":
+ type: object
+
+ properties:
+ compatible:
+ pattern: "^sdw[0-9][0-9a-f]{4}[0-9a-f]{4}[0-9a-f]{2}$"
So is this a 64-bit value, as in the MIPI spec, or is this part of
the _ADR description?
Rob did not like encoding compatible string exactly like _ADR encoding.
https://lkml.org/lkml/2019/8/22/490
Wondering if we are talking about different concepts?
Rob's point was about the InstanceID
"Assuming you could have more than 1 of the same device on the bus,
then you need some way to distinguish them and the way that's done for
DT is unit-address/reg. And compatible strings should be constant for
each instance."
You can use the MIPI encoding *except* for the InstanceID, that'd be
fine. It'll just be a bit weird since the Slave device will report the
48 bits that include the Instance ID, so you'll have to special case
this field, but if this is a DT requirement then fine.
Rob's point does not apply to the link ID - which is used when you have
multiple masters in your controller. The Slave device is attached in one
location and will never move, so that is a constant value.
Point is that this compatible is for slave device, it should not matter
where and how the slave is connected, compatible should be constant
irrespective of Link ID.
Lets say for example if WSA881x slave device is connected to a
single-Link Controller and the same device is connected to a
MultiLink-controller then we would endup in more than one compatible
string for WSA881x driver.
From Disco Specic it clearly says that LinkID values are relative
to the immediate parent Device. So having LinkID in compatible string is
very fragile.
I also don't get why the first item in in base10?
As this corresponds to Soundwire Version, and I have no visibility of
version number encoding after reaching number 9 in this field.
This can be updated once we have more info on how the Version encoding
will look like in future.
Idea of limiting regex to [0-9] for version is to enforce some checking!
the version is a 4 bit value starting at 1 for SoundWire 1.0. There is
nothing in the spec that talks about a limit to 9.
It's unlikely we'll ever reach that but you are interpreting a spec
here. plus just below you mention all fields as being hexadecimal.
Am happy to change this to
pattern: "^sdw[0-9a-f][0-9a-f]{4}[0-9a-f]{4}[0-9a-f]{2}$"
if you are okay with rest of the stuff.
thanks,
srini
--srini
+ description:
+ Is the textual representation of SoundWire Enumeration
+ address. compatible string should contain SoundWire Version ID,
+ Manufacturer ID, Part ID and Class ID in order and shall be in
+ lower-case hexadecimal with leading zeroes.
+ Valid sizes of these fields are
+ Version ID is 1 nibble, number '0x1' represents SoundWire 1.0
+ and '0x2' represents SoundWire 1.1 and so on.
+ MFD is 4 nibbles
+
Que le Seigneur vous bénisse!
Bonjour, Je soussignée Mme Mellie CARIUS de nationalité française. Je vous envoie ce présent message afin de solliciter votre accord pour la réalisation d'un projet de donation. Ayant perdu mon époux et mon enfant de 8 ans au cours d'un accident tragique et mortel Il y a quelques années, je n'ai ni famille ni enfant qui pourra bénéficier de ma fortune. Actuellement hospitalisée aux États-Unis pour un cancer en phase terminale, je décide de faire don de ma fortune afin que vous puissiez réaliser les œuvres de charité de votre choix. Pour cela je vous lègue à titre de don.une somme de un million cinq cent mille dollars américain en banque en Afrique de l’ouest où je m’étais installée après la mort de mon mari et mon enfant. Merci me de répondre pour plus de détails. Sincèrement Mme Mellie C.
Re: [RESEND PATCH 1/1] rtc: sun6i: Allow using as wakeup source from suspend
Alejandro González wrote:
> This patch allows userspace to set up wakeup alarms on any RTC handled by the
> sun6i driver, and adds the necessary PM operations to allow resuming from
> suspend when the configured wakeup alarm fires a IRQ. Of course, that the
> device actually resumes depends on the suspend state and how a particular
> hardware reacts to it, but that is out of scope for this patch.
>
> I've tested these changes on a Pine H64 model B, which contains a
> Allwinner H6 SoC, with the help of CONFIG_PM_TEST_SUSPEND kernel option.
> These are the interesting outputs from the kernel and commands which
> show that it works. As every RTC handled by this driver is largely the
> same, I think that it shouldn't introduce any regression on other SoCs,
> but I may be wrong.
>
> [1.092705] PM: test RTC wakeup from 'freeze' suspend
> [1.098230] PM: suspend entry (s2idle)
> [1.212907] PM: suspend devices took 0.080 seconds
> (The SoC freezes for some seconds)
> [3.197604] PM: resume devices took 0.104 seconds
> [3.215937] PM: suspend exit
>
> [1.092812] PM: test RTC wakeup from 'mem' suspend
> [1.098089] PM: suspend entry (deep)
> [1.102033] PM: suspend exit
> [1.105205] PM: suspend test failed, error -22
>
> In any case, the RTC alarm interrupt gets fired as exptected:
>
> $ echo +5 > /sys/class/rtc/rtc0/wakealarm && sleep 5 && grep rtc
> /proc/interrupts
> 29: 1 0 0 0 GICv2 133 Level
> 700.rtc
>
> Signed-off-by: Alejandro González
> ---
> drivers/rtc/rtc-sun6i.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> index c0e75c373605..b7611e5dea3f 100644
> --- a/drivers/rtc/rtc-sun6i.c
> +++ b/drivers/rtc/rtc-sun6i.c
> @@ -598,6 +598,33 @@ static const struct rtc_class_ops sun6i_rtc_ops = {
> .alarm_irq_enable = sun6i_rtc_alarm_irq_enable
> };
>
> +#ifdef CONFIG_PM_SLEEP
> +/* Enable IRQ wake on suspend, to wake up from RTC. */
> +static int sun6i_rtc_suspend(struct device *dev)
> +{
> + struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
> +
> + if (device_may_wakeup(dev))
> + enable_irq_wake(chip->irq);
> +
> + return 0;
> +}
> +
> +/* Disable IRQ wake on resume. */
> +static int sun6i_rtc_resume(struct device *dev)
> +{
> + struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
> +
> + if (device_may_wakeup(dev))
> + disable_irq_wake(chip->irq);
> +
> + return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(sun6i_rtc_pm_ops,
> + sun6i_rtc_suspend, sun6i_rtc_resume);
> +
> static int sun6i_rtc_probe(struct platform_device *pdev)
> {
> struct sun6i_rtc_dev *chip = sun6i_rtc;
> @@ -650,6 +677,8 @@ static int sun6i_rtc_probe(struct platform_device *pdev)
>
> clk_prepare_enable(chip->losc);
>
> + device_init_wakeup(&pdev->dev, 1);
> +
> chip->rtc = devm_rtc_device_register(&pdev->dev, "rtc-sun6i",
>&sun6i_rtc_ops, THIS_MODULE);
> if (IS_ERR(chip->rtc)) {
> @@ -684,6 +713,7 @@ static struct platform_driver sun6i_rtc_driver = {
> .driver = {
> .name = "sun6i-rtc",
> .of_match_table = sun6i_rtc_dt_ids,
> + .pm = &sun6i_rtc_pm_ops,
> },
> };
> builtin_platform_driver(sun6i_rtc_driver);
>
I'd be grateful if someone can test this patch on different boards to the Pine
H64 model B. I'm afraid that board is the only one I have to test this.
Regards.
Re: 5.3-rc3-ish VM crash: RIP: 0010:tcp_trim_head+0x20/0xe0
On 17/08/2019 18:35, Eric Dumazet wrote: > > > On 8/17/19 10:24 AM, Sander Eikelenboom wrote: >> On 12/08/2019 19:56, Eric Dumazet wrote: >>> >>> >>> On 8/12/19 2:50 PM, Sander Eikelenboom wrote: L.S., While testing a somewhere-after-5.3-rc3 kernel (which included the latest net merge (33920f1ec5bf47c5c0a1d2113989bdd9dfb3fae9), one of my Xen VM's (which gets quite some network load) crashed. See below for the stacktrace. Unfortunately I haven't got a clear trigger, so bisection doesn't seem to be an option at the moment. I haven't encountered this on 5.2, so it seems to be an regression against 5.2. Any ideas ? -- Sander [16930.653595] general protection fault: [#1] SMP NOPTI [16930.653624] CPU: 0 PID: 3275 Comm: rsync Not tainted 5.3.0-rc3-20190809-doflr+ #1 [16930.653657] RIP: 0010:tcp_trim_head+0x20/0xe0 [16930.653677] Code: 2e 0f 1f 84 00 00 00 00 00 90 41 54 41 89 d4 55 48 89 fd 53 48 89 f3 f6 46 7e 01 74 2f 8b 86 bc 00 00 00 48 03 86 c0 00 00 00 <8b> 40 20 66 83 f8 01 74 19 31 d2 31 f6 b9 20 0a 00 00 48 89 df e8 [16930.653741] RSP: :c9003ad8 EFLAGS: 00010286 [16930.653762] RAX: fffe888005bf62c0 RBX: 8880115fb800 RCX: 801b >>> >>> crash in " mov0x20(%rax),%eax" and RAX=fffe888005bf62c0 (not a valid >>> kernel address) >>> >>> Look like one bit corruption maybe. >>> >>> Nothing comes to mind really between 5.2 and 53 that could explain this. >>> [16930.653791] RDX: 05a0 RSI: 8880115fb800 RDI: 888016b00880 [16930.653819] RBP: 888016b00880 R08: 0001 R09: [16930.653848] R10: 88800ae00800 R11: bfe632e6 R12: 05a0 [16930.653875] R13: 0001 R14: bfe62d46 R15: 0004 [16930.653913] FS: 7fe71fe2cb80() GS:88801f20() knlGS: [16930.653943] CS: 0010 DS: ES: CR0: 80050033 [16930.653965] CR2: 55de0f3e7000 CR3: 11f32000 CR4: 06f0 [16930.653993] Call Trace: [16930.654005] [16930.654018] tcp_ack+0xbb0/0x1230 [16930.654033] tcp_rcv_established+0x2e8/0x630 [16930.654053] tcp_v4_do_rcv+0x129/0x1d0 [16930.654070] tcp_v4_rcv+0xac9/0xcb0 [16930.654088] ip_protocol_deliver_rcu+0x27/0x1b0 [16930.654109] ip_local_deliver_finish+0x3f/0x50 [16930.654128] ip_local_deliver+0x4d/0xe0 [16930.654145] ? ip_protocol_deliver_rcu+0x1b0/0x1b0 [16930.654163] ip_rcv+0x4c/0xd0 [16930.654179] __netif_receive_skb_one_core+0x79/0x90 [16930.654200] netif_receive_skb_internal+0x2a/0xa0 [16930.654219] napi_gro_receive+0xe7/0x140 [16930.654237] xennet_poll+0x9be/0xae0 [16930.654254] net_rx_action+0x136/0x340 [16930.654271] __do_softirq+0xdd/0x2cf [16930.654287] irq_exit+0x7a/0xa0 [16930.654304] xen_evtchn_do_upcall+0x27/0x40 [16930.654320] xen_hvm_callback_vector+0xf/0x20 [16930.654339] [16930.654349] RIP: 0033:0x55de0d87db99 [16930.654364] Code: 00 00 48 89 7c 24 f8 45 39 fe 45 0f 42 fe 44 89 7c 24 f4 eb 09 0f 1f 40 00 83 e9 01 74 3e 89 f2 48 63 f8 4c 01 d2 44 38 1c 3a <75> 25 44 38 6c 3a ff 75 1e 41 0f b6 3c 24 40 38 3a 75 14 41 0f b6 [16930.654432] RSP: 002b:7ffd5531eec8 EFLAGS: 0a87 ORIG_RAX: ff0c [16930.655004] RAX: 0002 RBX: 55de0f3e8e50 RCX: 007f [16930.655034] RDX: 55de0f3dc2d2 RSI: 3492 RDI: 0002 [16930.655062] RBP: 7fff R08: 80ea R09: 01f0 [16930.655089] R10: 55de0f3d8e40 R11: 0094 R12: 55de0f3e0f2a [16930.655116] R13: 0010 R14: 7f16 R15: 0080 [16930.655144] Modules linked in: [16930.655200] ---[ end trace 533367c95501b645 ]--- [16930.655223] RIP: 0010:tcp_trim_head+0x20/0xe0 [16930.655243] Code: 2e 0f 1f 84 00 00 00 00 00 90 41 54 41 89 d4 55 48 89 fd 53 48 89 f3 f6 46 7e 01 74 2f 8b 86 bc 00 00 00 48 03 86 c0 00 00 00 <8b> 40 20 66 83 f8 01 74 19 31 d2 31 f6 b9 20 0a 00 00 48 89 df e8 [16930.655312] RSP: :c9003ad8 EFLAGS: 00010286 [16930.655331] RAX: fffe888005bf62c0 RBX: 8880115fb800 RCX: 801b [16930.655360] RDX: 05a0 RSI: 8880115fb800 RDI: 888016b00880 [16930.655387] RBP: 888016b00880 R08: 0001 R09: [16930.655414] R10: 88800ae00800 R11: bfe632e6 R12: 05a0 [16930.655441] R13: 0001 R14: bfe62d46 R15: 0004 [16930.655475] FS: 7fe71fe2cb80() GS:88801f20() knlGS:00
Re: [PATCH v5 1/4] clk: core: link consumer with clock driver
Hi Stephen,
Stephen Boyd wrote on Wed, 14 Aug 2019 17:03:00
-0700:
> Quoting Miquel Raynal (2019-05-21 05:51:10)
> > One major concern when, for instance, suspending/resuming a platform
> > is to never access registers before the underlying clock has been
> > resumed, otherwise most of the time the kernel will just crash. One
> > solution is to use syscore operations when registering clock drivers
> > suspend/resume callbacks. One problem of using syscore_ops is that the
> > suspend/resume scheduling will depend on the order of the
> > registrations, which brings (unacceptable) randomness in the process.
> >
> > A feature called device links has been introduced to handle such
> > situation. It creates dependencies between consumers and providers,
> > enforcing e.g. the suspend/resume order when needed. Such feature is
> > already in use for regulators.
> >
> > Add device links support in the clock subsystem by creating/deleting
> > the links at get/put time.
> >
> > Example of a boot (ESPRESSObin, A3700 SoC) with devices linked to clocks:
> >
> > marvell-armada-3700-tbg-clock d0013200.tbg: Linked as a consumer to
> > d0013800.pinctrl:xtal-clk
> > marvell-armada-3700-tbg-clock d0013200.tbg: Dropping the link to
> > d0013800.pinctrl:xtal-clk
> > marvell-armada-3700-tbg-clock d0013200.tbg: Linked as a consumer to
> > d0013800.pinctrl:xtal-clk
> > marvell-armada-3700-periph-clock d0013000.nb-periph-clk: Linked as a
> > consumer to d0013200.tbg
> > marvell-armada-3700-periph-clock d0013000.nb-periph-clk: Linked as a
> > consumer to d0013800.pinctrl:xtal-clk
> > marvell-armada-3700-periph-clock d0018000.sb-periph-clk: Linked as a
> > consumer to d0013200.tbg
> > mvneta d003.ethernet: Linked as a consumer to d0018000.sb-periph-clk
> > xhci-hcd d0058000.usb: Linked as a consumer to d0018000.sb-periph-clk
> > xenon-sdhci d00d.sdhci: Linked as a consumer to d0013000.nb-periph-clk
> > xenon-sdhci d00d.sdhci: Dropping the link to d0013000.nb-periph-clk
> > mvebu-uart d0012000.serial: Linked as a consumer to
> > d0013800.pinctrl:xtal-clk
> > advk-pcie d007.pcie: Linked as a consumer to d0018000.sb-periph-clk
> > xenon-sdhci d00d.sdhci: Linked as a consumer to d0013000.nb-periph-clk
> > xenon-sdhci d00d.sdhci: Linked as a consumer to regulator.1
> > cpu cpu0: Linked as a consumer to d0013000.nb-periph-clk
> > cpu cpu0: Dropping the link to d0013000.nb-periph-clk
> > cpu cpu0: Linked as a consumer to d0013000.nb-periph-clk
> >
> > Signed-off-by: Miquel Raynal
> > ---
>
> This patch doesn't apply. Things have changed upstream.
>
> >
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index ec6f04dcf5e6..e6b84ab43f9f 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -1676,6 +1710,8 @@ static void clk_reparent(struct clk_core *core,
> > struct clk_core *new_parent)
> >
> > if (was_orphan != becomes_orphan)
> > clk_core_update_orphan_status(core, becomes_orphan);
> > +
> > + clk_link_hierarchy(core, new_parent);
>
> This isn't going to work.
Strange, I didn't had that problem (on Marvell platforms).
>
> BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:909
> in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper/0
> 3 locks held by swapper/0/1:
> #0: (ptrval) (&dev->mutex){}, at: __device_driver_lock+0x40/0x4c
> #1: (ptrval) (prepare_lock){+.+.}, at: clk_prepare_lock+0x18/0x94
> #2: (ptrval) (enable_lock){}, at: clk_enable_lock+0x34/0xdc
> irq event stamp: 311516
> hardirqs last enabled at (311515): []
> _raw_spin_unlock_irqrestore+0x54/0x90
> hardirqs last disabled at (311516): []
> clk_enable_lock+0x28/0xdc
> softirqs last enabled at (311348): []
> __do_softirq+0x4cc/0x514
> softirqs last disabled at (311341): [] irq_exit+0xd8/0xf8
> CPU: 4 PID: 1 Comm: swapper/0 Tainted: GW
> 5.3.0-rc4-5-g6be06bbec80ef #10
> Hardware name: Google Cheza (rev3+) (DT)
> Call trace:
> dump_backtrace+0x0/0x13c
> show_stack+0x20/0x2c
> dump_stack+0xc4/0x12c
> ___might_sleep+0x1b4/0x1c4
> __might_sleep+0x50/0x88
> __mutex_lock_common+0x5c/0xbfc
> mutex_lock_nested+0x40/0x50
> device_link_add+0x88/0x3ac
> clk_reparent+0xc4/0x114
> __clk_set_parent_before+0x74/0x90
> clk_change_rate+0x98/0x854
> clk_core_set_rate_nolock+0x1b0/0x21c
> clk_set_rate+0x3c/0x6c
> of_clk_set_defaults+0x29c/0x364
> platform_drv_probe+0x28/0xb0
> really_probe+0x130/0x2b4
> driver_probe_device+0x64/0xfc
> device_driver_attach+0x4c/0x6c
> __driver_attach+0xb0/0xc4
> bus_for_each_dev+0x84/0xcc
> driver_attach+0x2c/0x38
> bus_add_driver+0xfc/0x1d0
> driver_register+0x64/0xf0
> __platform_driver_register+0x4c/0x58
> msm_drm_register+0x5c/0x60
> do_one_initcall+0x1e0/0x478
> do_initcall_level+0x21c/0x25c
> do_basic_setup+0x60/0x78
> kernel_init_freeable+0x128/0x1b0
> kernel_init
Re: [PATCH] staging: vt6656: Use common error handling code in vnt_alloc_bufs()
The original code is fine. There was no chance we were going to apply the patch so there is no need for any discussion. I don't know why Markus sent it when he knows. regards, dan carpenter
Re: [PATCH] mtd: hyperbus: fix dependency and build error
Hi Vignesh,
Randy Dunlap wrote on Tue, 13 Aug 2019 16:03:13
-0700:
> From: Randy Dunlap
>
> lib/devres.c, which implements devm_ioremap_resource(), is only built
> when CONFIG_HAS_IOMEM is set/enabled, so MTD_HYPERBUS should depend
> on HAS_IOMEM. Fixes a build error and a Kconfig warning (as seen on
> UML builds):
>
> WARNING: unmet direct dependencies detected for MTD_COMPLEX_MAPPINGS
> Depends on [n]: MTD [=m] && HAS_IOMEM [=n]
> Selected by [m]:
> - MTD_HYPERBUS [=m] && MTD [=m]
>
> ERROR: "devm_ioremap_resource" [drivers/mtd/hyperbus/hyperbus-core.ko]
> undefined!
>
> Fixes: dcc7d3446a0f ("mtd: Add support for HyperBus memory devices")
> Signed-off-by: Randy Dunlap
> Cc: Vignesh Raghavendra
> Cc: Miquel Raynal
> Cc: Geert Uytterhoeven
> Cc: linux-...@lists.infradead.org
> ---
This patch looks like a good candidate for fixes, shall I send a fixes
PR next week with it? (Acked-by wished)
Miquèl
Re: [v5 1/2] mtd: nand: Add new Cadence NAND driver to MTD subsystem
Hi Dmitry, Dmitry Osipenko wrote on Thu, 25 Jul 2019 18:11:43 +0300: > 25.07.2019 18:00, Piotr Sroka пишет: > > Add new Cadence NAND driver to MTD subsystem > > > > Signed-off-by: Piotr Sroka > > --- > > Changes for v5: > > - fix "ecc config strength" field size > > - remove unused macros > > - fix address of timing2 register > > - add guard for accessing data_control_size register > > - simplify the driver by use the same function > > for accessing main area and oob area > > - add comment to the driver describing main controller modes > > - change compatible name from cdns,hpnfc to cdns,hp-nfc > > Changes for v4: > > - fix comments issues like typos, missing capitals, missing dots etc. > > - remove unnecessary PHY options phy_dll_aging and phy_per_bit_deskew > > - replace all register access functions to "relaxed" version > > - remove all unnecessary variables initializations > > - handle error inside cadence_nand_get_ecc_strength_idx function in case > > correnction strength is not found > > - add commit message > > Changes for v3: > > - remove definitions of unused registers > > - remove configuring registers which are not expected to be configured in > > asynchronous mode > > - remove not needed function reading timing registers > > - remove information about oob size and write size from cdns_nand_chip type > > and use vales from mtd_info directly > > - use nand_cleanup instead of nand_release if mtd device is not registered > > yet > > - fix cadence_nand_chips_init function add garbage collection > > if a chip init fails > > - simplify PHY calculations > > Changes for v2: > > - create one universal wait function for all events instead of one > > function per event. > > - split one big function executing nand operations to separate > > functions one per each type of operation. > > - add erase atomic operation to nand operation parser > > - remove unnecessary includes. > > - remove unused register defines > > - add support for multiple nand chips > > - remove all code using legacy functions > > - remove chip dependents parameters from dts bindings, they were > > attached to the SoC specific compatible at the driver level > > - simplify interrupt handling > > - simplify timing calculations > > - fix calculation of maximum supported cs signals > > - simplify ecc size calculation > > - remove header file and put whole code to one c file > > --- > > drivers/mtd/nand/raw/Kconfig |7 + > > drivers/mtd/nand/raw/Makefile |1 + > > drivers/mtd/nand/raw/cadence-nand-controller.c | 3021 > > > > 3 files changed, 3029 insertions(+) > > create mode 100644 drivers/mtd/nand/raw/cadence-nand-controller.c > > > > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig > > index e604625e2dfa..4d2ce3b5b2ae 100644 > > --- a/drivers/mtd/nand/raw/Kconfig > > +++ b/drivers/mtd/nand/raw/Kconfig > > @@ -557,5 +557,12 @@ config MTD_NAND_MESON > > help > > Enables support for NAND controller on Amlogic's Meson SoCs. > > This controller is found on Meson SoCs. > > +config MTD_NAND_CADENCE > > + tristate "Support Cadence NAND (HPNFC) controller" > > + depends on OF > > + help > > + Enable the driver for NAND flash on platforms using a Cadence NAND > > + controller. > > + > > > > endif # MTD_NAND > > diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile > > index 5a5a72f0793e..f4b099f276f7 100644 > > --- a/drivers/mtd/nand/raw/Makefile > > +++ b/drivers/mtd/nand/raw/Makefile > > @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_MTK)+= mtk_ecc.o > > mtk_nand.o > > obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o > > obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o > > obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o > > +obj-$(CONFIG_MTD_NAND_CADENCE) += cadence-nand-controller.o > > > > nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o > > nand-objs += nand_onfi.o > > diff --git a/drivers/mtd/nand/raw/cadence-nand-controller.c > > b/drivers/mtd/nand/raw/cadence-nand-controller.c > > new file mode 100644 > > index ..a7ff4e4585d3 > > --- /dev/null > > +++ b/drivers/mtd/nand/raw/cadence-nand-controller.c > > @@ -0,0 +1,3021 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * Cadence NAND flash controller driver > > + * > > + * Copyright (C) 2019 Cadence > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +/* > > + * HPNFC can work in 3 modes: > > + * - PIO - can work in master or slave DMA. > > + * - CDMA - needs Master DMA for accessing command descriptors. > > + * - Generic mode - can use only slave DMA. > > + * CDMA and PIO modes can be used to execute only base commands. > > + * Generic mode can be used to execute any command > > + * on NAND f
Re: [PATCH] gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist
On Sat, 24 Aug 2019 at 07:53, Hans de Goede wrote: > > To avoid problems like this, this commit adds a new > gpiolib_acpi_run_edge_events_on_boot kernel commandline option which > can be "on", "off", or "auto" (default). > > In auto mode the default is on and a DMI based blacklist is used, > the initial version of this blacklist contains the Minix Neo Z83-4 > fixing the HDMI being broken on this device. > Many thanks Hans. I've tested the patch including the command line option with both v5.3-rc5 and linux-next on a Minix Neo Z83-4 and it works fine. Best regards, Ian
Re: [PATCH] Add support for Macronix NAND randomizer
Hi Mason, Mason Yang wrote on Tue, 20 Aug 2019 13:53:48 +0800: > Macronix NANDs support randomizer operation for user data scrambled, > which can be enabled with a SET_FEATURE. > > User data written to the NAND device without randomizer is still readable > after randomizer function enabled. > The penalty of randomizer are NOP = 1 instead of NOP = 4 and more time period please don't use 'NOP' here, use 'subpage accesses' instead, otherwise people might not understand what it means while it has a real impact. > is needed in program operation and entering deep power-down mode. > i.e., tPROG 300us to 340us(randomizer enabled) > > If subpage write not available with hardware ECC, for example, > NAND chip options NAND_NO_SUBPAGE_WRITE be set in driver and > randomizer function is recommended for high-reliability. > Driver checks byte 167 of Vendor Blocks in ONFI parameter page table > to see if this high-reliability function is supported. > You did not flagged this patch as a v2 and forgot about the changelog. You did not listen to our comments in the last version neither. I was open to a solution with a specific DT property for warned users but I don't see it coming. Thanks, Miquèl
Re: [PATCH 1/2] media: imx: Move capture device init to registered
Hi Steve,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[cannot apply to v5.3-rc5 next-20190823]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Steve-Longerbeam/media-imx-Move-capture-device-init-to-registered/20190824-182241
base: git://linuxtv.org/media_tree.git master
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sparc64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
Note: the
linux-review/Steve-Longerbeam/media-imx-Move-capture-device-init-to-registered/20190824-182241
HEAD 7c4284abbf1ba252792db5645a7004bd033dd3b0 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/staging/media/imx/imx-ic-prpencvf.c: In function 'prp_registered':
>> drivers/staging/media/imx/imx-ic-prpencvf.c:1274:45: error: 'ic_priv'
>> undeclared (first use in this function); did you mean 'priv'?
priv->vdev = imx_media_capture_device_init(ic_priv->ipu_dev,
^~~
priv
drivers/staging/media/imx/imx-ic-prpencvf.c:1274:45: note: each undeclared
identifier is reported only once for each function it appears in
vim +1274 drivers/staging/media/imx/imx-ic-prpencvf.c
1242
1243 /*
1244 * retrieve our pads parsed from the OF graph by the media device
1245 */
1246 static int prp_registered(struct v4l2_subdev *sd)
1247 {
1248 struct prp_priv *priv = sd_to_priv(sd);
1249 int i, ret;
1250 u32 code;
1251
1252 for (i = 0; i < PRPENCVF_NUM_PADS; i++) {
1253 priv->pad[i].flags = (i == PRPENCVF_SINK_PAD) ?
1254 MEDIA_PAD_FL_SINK : MEDIA_PAD_FL_SOURCE;
1255
1256 /* set a default mbus format */
1257 imx_media_enum_ipu_format(&code, 0, CS_SEL_YUV);
1258 ret = imx_media_init_mbus_fmt(&priv->format_mbus[i],
1259640, 480, code,
V4L2_FIELD_NONE,
1260&priv->cc[i]);
1261 if (ret)
1262 return ret;
1263 }
1264
1265 /* init default frame interval */
1266 priv->frame_interval.numerator = 1;
1267 priv->frame_interval.denominator = 30;
1268
1269 ret = media_entity_pads_init(&sd->entity, PRPENCVF_NUM_PADS,
1270 priv->pad);
1271 if (ret)
1272 return ret;
1273
> 1274 priv->vdev = imx_media_capture_device_init(ic_priv->ipu_dev,
1275 &ic_priv->sd,
1276 PRPENCVF_SRC_PAD);
1277 if (IS_ERR(priv->vdev))
1278 return PTR_ERR(priv->vdev);
1279
1280 ret = imx_media_capture_device_register(priv->vdev);
1281 if (ret)
1282 goto remove_vdev;
1283
1284 ret = prp_init_controls(priv);
1285 if (ret)
1286 goto unreg_vdev;
1287
1288 return 0;
1289
1290 unreg_vdev:
1291 imx_media_capture_device_unregister(priv->vdev);
1292 remove_vdev:
1293 imx_media_capture_device_remove(priv->vdev);
1294 return ret;
1295 }
1296
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 12/16] arm64: prefer __section from compiler_attributes.h
On Fri, Aug 23, 2019 at 09:35:08PM +0200, Miguel Ojeda wrote: > On Thu, Aug 15, 2019 at 11:12 AM Miguel Ojeda > wrote: > > > > Btw, I guess that is the Oops you were mentioning in the cover letter? > > Pinging about this... Which bit are you pinging about? This patch (12/16) has been in -next for a while and is queued in the arm64 tree for 5.4. The Oops/boot issue is addressed in patch 14 which probably needs to be sent as a separate patch (with a commit message) if it's targetting 5.3 and, I assume, routed via somebody like akpm. Will
[PATCH v2 4/7] mtd: spi-nor: Split spi_nor_init_params()
From: Tudor Ambarus
Add functions to delimit what the chunks of code do:
static void spi_nor_init_params()
{
spi_nor_legacy_init_params()
spi_nor_manufacturer_init_params()
spi_nor_sfdp_init_params()
}
Add descriptions to all methods.
spi_nor_init_params() becomes of type void, as all its children
return void.
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 83 ---
1 file changed, 63 insertions(+), 20 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index c9514dfd7d6d..93424f914159 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -4186,7 +4186,34 @@ static void spi_nor_manufacturer_init_params(struct
spi_nor *nor)
nor->info->fixups->default_init(nor);
}
-static int spi_nor_init_params(struct spi_nor *nor)
+/**
+ * spi_nor_sfdp_init_params() - Initialize the flash's parameters and settings
+ * based on JESD216 SFDP standard.
+ * @nor: pointer to a 'struct spi-nor'.
+ *
+ * The method has a roll-back mechanism: in case the SFDP parsing fails, the
+ * legacy flash parameters and settings will be restored.
+ */
+static void spi_nor_sfdp_init_params(struct spi_nor *nor)
+{
+ struct spi_nor_flash_parameter sfdp_params;
+
+ memcpy(&sfdp_params, &nor->params, sizeof(sfdp_params));
+
+ if (spi_nor_parse_sfdp(nor, &sfdp_params)) {
+ nor->addr_width = 0;
+ nor->flags &= ~SNOR_F_4B_OPCODES;
+ } else {
+ memcpy(&nor->params, &sfdp_params, sizeof(nor->params));
+ }
+}
+
+/**
+ * spi_nor_legacy_init_params() - Initialize the flash's parameters and
settings
+ * based on nor->info data.
+ * @nor: pointer to a 'struct spi-nor'.
+ */
+static void spi_nor_legacy_init_params(struct spi_nor *nor)
{
struct spi_nor_flash_parameter *params = &nor->params;
struct spi_nor_erase_map *map = ¶ms->erase_map;
@@ -4260,25 +4287,43 @@ static int spi_nor_init_params(struct spi_nor *nor)
spi_nor_set_erase_type(&map->erase_type[i], info->sector_size,
SPINOR_OP_SE);
spi_nor_init_uniform_erase_map(map, erase_mask, params->size);
+}
+/**
+ * spi_nor_init_params() - Initialize the flash's parameters and settings.
+ * @nor: pointer to a 'struct spi-nor'.
+ *
+ * The flash parameters and settings are initialized based on a sequence of
+ * calls that are ordered by priority:
+ *
+ * 1/ Legacy flash parameters initialization. The initializations are done
+ *based on nor->info data:
+ * spi_nor_legacy_init_params()
+ *
+ * which can be overwritten by:
+ * 2/ Manufacturer flash parameters initialization. The initializations are
+ *done based on MFR register, or when the decisions can not be done solely
+ *based on MFR, by using specific flash_info tweeks, ->default_init():
+ * spi_nor_manufacturer_init_params()
+ *
+ * which can be overwritten by:
+ * 3/ SFDP flash parameters initialization. JESD216 SFDP is a standard and
+ *should be more accurate that the above.
+ * spi_nor_sfdp_init_params()
+ *
+ *Please not that there is a ->post_bfpt() fixup hook that can overwrite
the
+ *flash parameters and settings imediately after parsing the Basic Flash
+ *Parameter Table.
+ */
+static void spi_nor_init_params(struct spi_nor *nor)
+{
+ spi_nor_legacy_init_params(nor);
spi_nor_manufacturer_init_params(nor);
- if ((info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)) &&
- !(info->flags & SPI_NOR_SKIP_SFDP)) {
- struct spi_nor_flash_parameter sfdp_params;
-
- memcpy(&sfdp_params, params, sizeof(sfdp_params));
-
- if (spi_nor_parse_sfdp(nor, &sfdp_params)) {
- nor->addr_width = 0;
- nor->flags &= ~SNOR_F_4B_OPCODES;
- } else {
- memcpy(params, &sfdp_params, sizeof(*params));
- }
- }
-
- return 0;
+ if ((nor->info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)) &&
+ !(nor->info->flags & SPI_NOR_SKIP_SFDP))
+ spi_nor_sfdp_init_params(nor);
}
static int spi_nor_select_read(struct spi_nor *nor,
@@ -4693,10 +4738,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
nor->info->flags & SPI_NOR_HAS_LOCK)
nor->params.disable_block_protection = spi_nor_clear_sr_bp;
- /* Parse the Serial Flash Discoverable Parameters table. */
- ret = spi_nor_init_params(nor);
- if (ret)
- return ret;
+ /* Init flash parameters based on flash_info struct and SFDP */
+ spi_nor_init_params(nor);
if (!mtd->name)
mtd->name = dev_name(dev);
--
2.9.5
[PATCH v2 1/7] mtd: spi-nor: Add default_init() hook to tweak flash parameters
From: Tudor Ambarus
As of now, the flash parameters initialization logic is as following:
a/ default flash parameters init in spi_nor_init_params()
b/ manufacturer specific flash parameters updates, split across entire
spi-nor core code
c/ flash parameters updates based on SFDP tables
d/ post BFPT flash parameter updates
In the quest of removing the manufacturer specific code from the spi-nor
core, we want to impose a timeline/priority on how the flash parameters
are updated. The following sequence of calls is pursued:
1/ spi-nor core legacy flash parameters init:
spi_nor_default_init_params()
2/ MFR-based manufacturer flash parameters init:
nor->manufacturer->fixups->default_init()
3/ specific flash_info tweeks done when decisions can not be done just on
MFR:
nor->info->fixups->default_init()
4/ SFDP tables flash parameters init - SFDP knows better:
spi_nor_sfdp_init_params()
5/ post SFDP tables flash parameters updates - in case manufacturers get
the serial flash tables wrong or incomplete.
nor->info->fixups->post_sfdp()
The later can be extended to nor->manufacturer->fixups->post_sfdp() if
needed.
This patch opens doors for steps 2/ and 3/.
Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
---
drivers/mtd/spi-nor/spi-nor.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 7c02eddad9fd..016bfe2fb592 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -154,12 +154,16 @@ struct sfdp_bfpt {
/**
* struct spi_nor_fixups - SPI NOR fixup hooks
+ * @default_init: called after default flash parameters init. Used to tweak
+ *flash parameters when information provided by the flash_info
+ *table is incomplete or wrong.
* @post_bfpt: called after the BFPT table has been parsed
*
* Those hooks can be used to tweak the SPI NOR configuration when the SFDP
* table is broken or not available.
*/
struct spi_nor_fixups {
+ void (*default_init)(struct spi_nor *nor);
int (*post_bfpt)(struct spi_nor *nor,
const struct sfdp_parameter_header *bfpt_header,
const struct sfdp_bfpt *bfpt,
@@ -4133,6 +4137,17 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
return err;
}
+/**
+ * spi_nor_manufacturer_init_params() - Initialize the flash's parameters and
+ * settings based on ->default_init() hook.
+ * @nor: pointer to a 'struct spi-nor'.
+ */
+static void spi_nor_manufacturer_init_params(struct spi_nor *nor)
+{
+ if (nor->info->fixups && nor->info->fixups->default_init)
+ nor->info->fixups->default_init(nor);
+}
+
static int spi_nor_init_params(struct spi_nor *nor)
{
struct spi_nor_flash_parameter *params = &nor->params;
@@ -4233,6 +4248,8 @@ static int spi_nor_init_params(struct spi_nor *nor)
params->quad_enable = info->quad_enable;
}
+ spi_nor_manufacturer_init_params(nor);
+
if ((info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)) &&
!(info->flags & SPI_NOR_SKIP_SFDP)) {
struct spi_nor_flash_parameter sfdp_params;
--
2.9.5
[PATCH v2 3/7] mtd: spi_nor: Move manufacturer quad_enable() in ->default_init()
From: Tudor Ambarus
The goal is to move the quad_enable manufacturer specific init in the
nor->manufacturer->fixups->default_init()
The legacy quad_enable() implementation is spansion_quad_enable(),
select this method by default.
Set specific manufacturer fixups->default_init() hooks to overwrite
the default quad_enable() implementation when needed.
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 48 ++-
1 file changed, 29 insertions(+), 19 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 27951e5a01e2..c9514dfd7d6d 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -4150,13 +4150,38 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
return err;
}
+static void macronix_set_default_init(struct spi_nor *nor)
+{
+ nor->params.quad_enable = macronix_quad_enable;
+}
+
+static void st_micron_set_default_init(struct spi_nor *nor)
+{
+ nor->params.quad_enable = NULL;
+}
+
/**
* spi_nor_manufacturer_init_params() - Initialize the flash's parameters and
- * settings based on ->default_init() hook.
+ * settings based on MFR register and ->default_init() hook.
* @nor: pointer to a 'struct spi-nor'.
*/
static void spi_nor_manufacturer_init_params(struct spi_nor *nor)
{
+ /* Init flash parameters based on MFR */
+ switch (JEDEC_MFR(nor->info)) {
+ case SNOR_MFR_MACRONIX:
+ macronix_set_default_init(nor);
+ break;
+
+ case SNOR_MFR_ST:
+ case SNOR_MFR_MICRON:
+ st_micron_set_default_init(nor);
+ break;
+
+ default:
+ break;
+ }
+
if (nor->info->fixups && nor->info->fixups->default_init)
nor->info->fixups->default_init(nor);
}
@@ -4168,6 +4193,9 @@ static int spi_nor_init_params(struct spi_nor *nor)
const struct flash_info *info = nor->info;
u8 i, erase_mask;
+ /* Initialize legacy flash parameters and settings. */
+ params->quad_enable = spansion_quad_enable;
+
/* Set SPI NOR sizes. */
params->size = (u64)info->sector_size * info->n_sectors;
params->page_size = info->page_size;
@@ -4233,24 +4261,6 @@ static int spi_nor_init_params(struct spi_nor *nor)
SPINOR_OP_SE);
spi_nor_init_uniform_erase_map(map, erase_mask, params->size);
- /* Select the procedure to set the Quad Enable bit. */
- if (params->hwcaps.mask & (SNOR_HWCAPS_READ_QUAD |
- SNOR_HWCAPS_PP_QUAD)) {
- switch (JEDEC_MFR(info)) {
- case SNOR_MFR_MACRONIX:
- params->quad_enable = macronix_quad_enable;
- break;
-
- case SNOR_MFR_ST:
- case SNOR_MFR_MICRON:
- break;
-
- default:
- /* Kept only for backward compatibility purpose. */
- params->quad_enable = spansion_quad_enable;
- break;
- }
- }
spi_nor_manufacturer_init_params(nor);
--
2.9.5
[PATCH v2 2/7] mtd: spi-nor: Add a default_init() fixup hook for gd25q256
From: Boris Brezillon
gd25q256 needs to tweak the ->quad_enable() implementation and the
->default_init() fixup hook is the perfect place to do that. This way,
if we ever need to tweak more things for this flash, we won't have to
add new fields in flash_info.
We can get rid of the flash_info->quad_enable field as gd25q256 was
the only user.
Signed-off-by: Boris Brezillon
[tudor.amba...@microchip.com: use ->default_init() hook instead of
->post_sfdp()]
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 016bfe2fb592..27951e5a01e2 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -222,8 +222,6 @@ struct flash_info {
/* Part specific fixup hooks. */
const struct spi_nor_fixups *fixups;
-
- int (*quad_enable)(struct spi_nor *nor);
};
#define JEDEC_MFR(info)((info)->id[0])
@@ -2126,6 +2124,21 @@ static struct spi_nor_fixups mx25l25635_fixups = {
.post_bfpt = mx25l25635_post_bfpt_fixups,
};
+static void gd25q256_default_init(struct spi_nor *nor)
+{
+ /*
+* Some manufacturer like GigaDevice may use different
+* bit to set QE on different memories, so the MFR can't
+* indicate the quad_enable method for this case, we need
+* to set it in the default_init fixup hook.
+*/
+ nor->params.quad_enable = macronix_quad_enable;
+}
+
+static struct spi_nor_fixups gd25q256_fixups = {
+ .default_init = gd25q256_default_init,
+};
+
/* NOTE: double check command sets and memory organization when you add
* more nor chips. This current list focusses on newer chips, which
* have been converging on command sets which including JEDEC ID.
@@ -2218,7 +2231,7 @@ static const struct flash_info spi_nor_ids[] = {
"gd25q256", INFO(0xc84019, 0, 64 * 1024, 512,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
- .quad_enable = macronix_quad_enable,
+ .fixups = &gd25q256_fixups,
},
/* Intel/Numonyx -- xxxs33b */
@@ -4237,15 +4250,6 @@ static int spi_nor_init_params(struct spi_nor *nor)
params->quad_enable = spansion_quad_enable;
break;
}
-
- /*
-* Some manufacturer like GigaDevice may use different
-* bit to set QE on different memories, so the MFR can't
-* indicate the quad_enable method for this case, we need
-* set it in flash info list.
-*/
- if (info->quad_enable)
- params->quad_enable = info->quad_enable;
}
spi_nor_manufacturer_init_params(nor);
--
2.9.5
[PATCH v2 0/7] mtd: spi-nor: move manuf out of the core - batch 1
From: Tudor Ambarus Depends on 'mtd: spi-nor: move manuf out of the core - batch 0' series: https://patchwork.ozlabs.org/project/linux-mtd/list/?series=127030 v2: - addressed all the comments - all flash parameters and settings are now set in 'struct spi_nor_flash_parameter', for a clearer separation between the SPI NOR layer and the flash params. The scope of the "mtd: spi-nor: move manuf out of the core" batches, is to move all manufacturer specific code out of the spi-nor core. In the quest of removing the manufacturer specific code from the spi-nor core, we want to impose a timeline/priority on how the flash parameters are updated. As of now. the flash parameters initialization logic is as following: a/ default flash parameters init in spi_nor_init_params() b/ manufacturer specific flash parameters updates, split across entire spi-nor core code c/ flash parameters updates based on SFDP tables d/ post BFPT flash parameter updates With the "mtd: spi-nor: move manuf out of the core" batches, we want to impose the following sequence of calls: 1/ spi-nor core legacy flash parameters init: spi_nor_default_init_params() 2/ MFR-based manufacturer flash parameters init: nor->manufacturer->fixups->default_init() 3/ specific flash_info tweeks done when decisions can not be done just on MFR: nor->info->fixups->default_init() 4/ SFDP tables flash parameters init - SFDP knows better: spi_nor_sfdp_init_params() 5/ post SFDP tables flash parameters updates - in case manufacturers get the serial flash tables wrong or incomplete. nor->info->fixups->post_sfdp() The later can be extended to nor->manufacturer->fixups->post_sfdp() if needed. Setting of flash parameters will no longer be spread interleaved across the spi-nor core, there will be a clear separation on who and when will update the flash parameters. Tested on sst26vf064b with atmel-quadspi SPIMEM driver. Boris Brezillon (3): mtd: spi-nor: Add a default_init() fixup hook for gd25q256 mtd: spi-nor: Create a ->set_4byte() method mtd: spi-nor: Rework the SPI NOR lock/unlock logic Tudor Ambarus (4): mtd: spi-nor: Add default_init() hook to tweak flash parameters mtd: spi_nor: Move manufacturer quad_enable() in ->default_init() mtd: spi-nor: Split spi_nor_init_params() mtd: spi-nor: Rework the disabling of block write protection drivers/mtd/spi-nor/spi-nor.c | 320 -- include/linux/mtd/spi-nor.h | 25 +++- 2 files changed, 233 insertions(+), 112 deletions(-) -- 2.9.5
[PATCH v2 6/7] mtd: spi-nor: Rework the SPI NOR lock/unlock logic
From: Boris Brezillon
Add the SNOR_F_HAS_LOCK flag and set it when SPI_NOR_HAS_LOCK is set
in the flash_info entry or when it's a Micron or ST flash.
Move the locking hooks in a separate struct so that we have just
one field to update when we change the locking implementation.
Signed-off-by: Boris Brezillon
[tudor.amba...@microchip.com: use ->default_init() hook, introduce
spi_nor_late_init_params(), set ops in nor->params]
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 50 ---
include/linux/mtd/spi-nor.h | 23 ++--
2 files changed, 53 insertions(+), 20 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 1629584be30e..fc9e14777212 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1598,6 +1598,12 @@ static int stm_is_locked(struct spi_nor *nor, loff_t
ofs, uint64_t len)
return stm_is_locked_sr(nor, ofs, len, status);
}
+static const struct spi_nor_locking_ops stm_locking_ops = {
+ .lock = stm_lock,
+ .unlock = stm_unlock,
+ .is_locked = stm_is_locked,
+};
+
static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
@@ -1607,7 +1613,7 @@ static int spi_nor_lock(struct mtd_info *mtd, loff_t ofs,
uint64_t len)
if (ret)
return ret;
- ret = nor->flash_lock(nor, ofs, len);
+ ret = nor->params.locking_ops->lock(nor, ofs, len);
spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_UNLOCK);
return ret;
@@ -1622,7 +1628,7 @@ static int spi_nor_unlock(struct mtd_info *mtd, loff_t
ofs, uint64_t len)
if (ret)
return ret;
- ret = nor->flash_unlock(nor, ofs, len);
+ ret = nor->params.locking_ops->unlock(nor, ofs, len);
spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_LOCK);
return ret;
@@ -1637,7 +1643,7 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t
ofs, uint64_t len)
if (ret)
return ret;
- ret = nor->flash_is_locked(nor, ofs, len);
+ ret = nor->params.locking_ops->is_locked(nor, ofs, len);
spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_LOCK);
return ret;
@@ -4148,6 +4154,7 @@ static void macronix_set_default_init(struct spi_nor *nor)
static void st_micron_set_default_init(struct spi_nor *nor)
{
+ nor->flags = SNOR_F_HAS_LOCK;
nor->params.quad_enable = NULL;
nor->params.set_4byte = st_micron_set_4byte;
}
@@ -4292,6 +4299,23 @@ static void spi_nor_legacy_init_params(struct spi_nor
*nor)
}
/**
+ * spi_nor_late_init_params() - Late initialization of legacy flash parameters.
+ * @nor: pointer to a 'struct spi_nor'
+ *
+ * Used to set legacy flash parameters and settings when the ->default_init()
+ * hook or the SFDP parser let voids.
+ */
+static void spi_nor_late_init_params(struct spi_nor *nor)
+{
+ /*
+* NOR protection support. When locking_ops are not provided, we pick
+* the default ones.
+*/
+ if (nor->flags & SNOR_F_HAS_LOCK && !nor->params.locking_ops)
+ nor->params.locking_ops = &stm_locking_ops;
+}
+
+/**
* spi_nor_init_params() - Initialize the flash's parameters and settings.
* @nor: pointer to a 'struct spi-nor'.
*
@@ -4316,6 +4340,10 @@ static void spi_nor_legacy_init_params(struct spi_nor
*nor)
*Please not that there is a ->post_bfpt() fixup hook that can overwrite
the
*flash parameters and settings imediately after parsing the Basic Flash
*Parameter Table.
+ *
+ * 4/ Late legacy flash parameters initialization, used when the
+ * ->default_init() hook or the SFDP parser do not set specific params.
+ * spi_nor_late_init_params()
*/
static void spi_nor_init_params(struct spi_nor *nor)
{
@@ -4326,6 +4354,8 @@ static void spi_nor_init_params(struct spi_nor *nor)
if ((nor->info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)) &&
!(nor->info->flags & SPI_NOR_SKIP_SFDP))
spi_nor_sfdp_init_params(nor);
+
+ spi_nor_late_init_params(nor);
}
static int spi_nor_select_read(struct spi_nor *nor,
@@ -4730,6 +4760,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
if (info->flags & SPI_S3AN)
nor->flags |= SNOR_F_READY_XSR_RDY;
+ if (info->flags & SPI_NOR_HAS_LOCK)
+ nor->flags |= SNOR_F_HAS_LOCK;
+
/*
* Atmel, SST, Intel/Numonyx, and others serial NOR tend to power up
* with the software protection bits set.
@@ -4754,16 +4787,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
mtd->_read = spi_nor_read;
mtd->_resume = spi_nor_resume;
- /* NOR protection support for STmicro/Micron chips and similar */
- if (JEDEC_MFR(info) == SNOR_MFR_ST ||
- JEDEC_MFR(info) == SNOR_MFR_MICRON ||
- info->flags &
[PATCH v2 7/7] mtd: spi-nor: Rework the disabling of block write protection
From: Tudor Ambarus
Get rid of MFR handling and implement specific manufacturer
default_init() fixup hooks.
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index fc9e14777212..f4e9fcca619f 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -4146,6 +4146,16 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
return err;
}
+static void atmel_set_default_init(struct spi_nor *nor)
+{
+ nor->params.disable_block_protection = spi_nor_clear_sr_bp;
+}
+
+static void intel_set_default_init(struct spi_nor *nor)
+{
+ nor->params.disable_block_protection = spi_nor_clear_sr_bp;
+}
+
static void macronix_set_default_init(struct spi_nor *nor)
{
nor->params.quad_enable = macronix_quad_enable;
@@ -4173,6 +4183,14 @@ static void spi_nor_manufacturer_init_params(struct
spi_nor *nor)
{
/* Init flash parameters based on MFR */
switch (JEDEC_MFR(nor->info)) {
+ case SNOR_MFR_ATMEL:
+ atmel_set_default_init(nor);
+ break;
+
+ case SNOR_MFR_INTEL:
+ intel_set_default_init(nor);
+ break;
+
case SNOR_MFR_MACRONIX:
macronix_set_default_init(nor);
break;
@@ -4760,18 +4778,10 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
if (info->flags & SPI_S3AN)
nor->flags |= SNOR_F_READY_XSR_RDY;
- if (info->flags & SPI_NOR_HAS_LOCK)
+ if (info->flags & SPI_NOR_HAS_LOCK) {
nor->flags |= SNOR_F_HAS_LOCK;
-
- /*
-* Atmel, SST, Intel/Numonyx, and others serial NOR tend to power up
-* with the software protection bits set.
-*/
- if (JEDEC_MFR(nor->info) == SNOR_MFR_ATMEL ||
- JEDEC_MFR(nor->info) == SNOR_MFR_INTEL ||
- JEDEC_MFR(nor->info) == SNOR_MFR_SST ||
- nor->info->flags & SPI_NOR_HAS_LOCK)
nor->params.disable_block_protection = spi_nor_clear_sr_bp;
+ }
/* Init flash parameters based on flash_info struct and SFDP */
spi_nor_init_params(nor);
--
2.9.5
[PATCH v2 5/7] mtd: spi-nor: Create a ->set_4byte() method
From: Boris Brezillon
The procedure used to enable 4 byte addressing mode depends on the NOR
device, so let's provide a hook so that manufacturer specific handling
can be implemented in a sane way.
Signed-off-by: Boris Brezillon
[tudor.amba...@microchip.com: use nor->params.set_4byte() instead of
nor->set_4byte()]
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 76 ++-
include/linux/mtd/spi-nor.h | 2 ++
2 files changed, 41 insertions(+), 37 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 93424f914159..1629584be30e 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -633,6 +633,17 @@ static int macronix_set_4byte(struct spi_nor *nor, bool
enable)
NULL, 0);
}
+static int st_micron_set_4byte(struct spi_nor *nor, bool enable)
+{
+ int ret;
+
+ write_enable(nor);
+ ret = macronix_set_4byte(nor, enable);
+ write_disable(nor);
+
+ return ret;
+}
+
static int spansion_set_4byte(struct spi_nor *nor, bool enable)
{
nor->bouncebuf[0] = enable << 7;
@@ -667,45 +678,24 @@ static int spi_nor_write_ear(struct spi_nor *nor, u8 ear)
return nor->write_reg(nor, SPINOR_OP_WREAR, nor->bouncebuf, 1);
}
-/* Enable/disable 4-byte addressing mode. */
-static int set_4byte(struct spi_nor *nor, bool enable)
+static int winbond_set_4byte(struct spi_nor *nor, bool enable)
{
- int status;
- bool need_wren = false;
-
- switch (JEDEC_MFR(nor->info)) {
- case SNOR_MFR_ST:
- case SNOR_MFR_MICRON:
- /* Some Micron need WREN command; all will accept it */
- need_wren = true;
- /* fall through */
- case SNOR_MFR_MACRONIX:
- case SNOR_MFR_WINBOND:
- if (need_wren)
- write_enable(nor);
+ int ret;
- status = macronix_set_4byte(nor, enable);
- if (need_wren)
- write_disable(nor);
+ ret = macronix_set_4byte(nor, enable);
+ if (ret || enable)
+ return ret;
- if (!status && !enable &&
- JEDEC_MFR(nor->info) == SNOR_MFR_WINBOND) {
- /*
-* On Winbond W25Q256FV, leaving 4byte mode causes
-* the Extended Address Register to be set to 1, so all
-* 3-byte-address reads come from the second 16M.
-* We must clear the register to enable normal behavior.
-*/
- write_enable(nor);
- spi_nor_write_ear(nor, 0);
- write_disable(nor);
- }
+ /*
+* On Winbond W25Q256FV, leaving 4byte mode causes the Extended Address
+* Register to be set to 1, so all 3-byte-address reads come from the
+* second 16M. We must clear the register to enable normal behavior.
+*/
+ write_enable(nor);
+ ret = spi_nor_write_ear(nor, 0);
+ write_disable(nor);
- return status;
- default:
- /* Spansion style */
- return spansion_set_4byte(nor, enable);
- }
+ return ret;
}
static int spi_nor_xread_sr(struct spi_nor *nor, u8 *sr)
@@ -4153,11 +4143,18 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
static void macronix_set_default_init(struct spi_nor *nor)
{
nor->params.quad_enable = macronix_quad_enable;
+ nor->params.set_4byte = macronix_set_4byte;
}
static void st_micron_set_default_init(struct spi_nor *nor)
{
nor->params.quad_enable = NULL;
+ nor->params.set_4byte = st_micron_set_4byte;
+}
+
+static void winbond_set_default_init(struct spi_nor *nor)
+{
+ nor->params.set_4byte = winbond_set_4byte;
}
/**
@@ -4178,6 +4175,10 @@ static void spi_nor_manufacturer_init_params(struct
spi_nor *nor)
st_micron_set_default_init(nor);
break;
+ case SNOR_MFR_WINBOND:
+ winbond_set_default_init(nor);
+ break;
+
default:
break;
}
@@ -4222,6 +4223,7 @@ static void spi_nor_legacy_init_params(struct spi_nor
*nor)
/* Initialize legacy flash parameters and settings. */
params->quad_enable = spansion_quad_enable;
+ params->set_4byte = spansion_set_4byte;
/* Set SPI NOR sizes. */
params->size = (u64)info->sector_size * info->n_sectors;
@@ -4610,7 +4612,7 @@ static int spi_nor_init(struct spi_nor *nor)
*/
WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET,
"enabling reset hack; may not recover from unexpected
reboots\n");
- set_4byte(nor, true);
+ nor->params.set_4byte(nor, true);
}
return 0;
@@ -4634,7 +4636,7 @@ void spi_nor_restore
Re: [GIT PULL rcu/next + tools/memory-model] RCU and LKMM commits for 5.4
* Paul E. McKenney wrote: > On Thu, Aug 22, 2019 at 08:54:29PM +0200, Ingo Molnar wrote: > > [ . . . ] > > > Pulled into tip:core/rcu, thanks a lot Paul! > > Thank you! > > > The merge commit is a bit non-standard: > > > > 07f038a408fb: Merge LKMM and RCU commits > > > > but clear enough IMHO. Usually we try to keep this format: > > > > 6c06b66e957c: Merge branch 'X' into Y > > > > even for internal merge commits. > > Please accept my apologies! How about as shown below? If this works > for you, I will rebase my development commits on top this merge commit > in order to make sure I don't revert back to my old format for next > merge window. Looks good - but I don't think we should create a new merge commit just for this. > Ah, speaking of reminding me... There is likely to be one more small RCU > commit requested by the RISC-V guys. If testing and review goes well, > I will send you a pull request for it by the middle of next week. Thanks! Ingo
[PATCH v2 2/6] mtd: spi-nor: Add spansion_post_sfdp_fixups()
From: Boris Brezillon
Add a spansion_post_sfdp_fixups() function to fix the erase opcode,
erase sector size and set the SNOR_F_4B_OPCODES flag.
This way, all spansion related quirks are placed in the
spansion_post_sfdp_fixups() function.
Signed-off-by: Boris Brezillon
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 41dc95415260..bd31d6529892 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -591,18 +591,6 @@ static u8 spi_nor_convert_3to4_erase(u8 opcode)
static void spi_nor_set_4byte_opcodes(struct spi_nor *nor)
{
- /* Do some manufacturer fixups first */
- switch (JEDEC_MFR(nor->info)) {
- case SNOR_MFR_SPANSION:
- /* No small sector erase for 4-byte command set */
- nor->erase_opcode = SPINOR_OP_SE;
- nor->mtd.erasesize = nor->info->sector_size;
- break;
-
- default:
- break;
- }
-
nor->read_opcode = spi_nor_convert_3to4_read(nor->read_opcode);
nor->program_opcode = spi_nor_convert_3to4_program(nor->program_opcode);
nor->erase_opcode = spi_nor_convert_3to4_erase(nor->erase_opcode);
@@ -4322,6 +4310,19 @@ static void spi_nor_legacy_init_params(struct spi_nor
*nor)
spi_nor_init_uniform_erase_map(map, erase_mask, params->size);
}
+static void spansion_post_sfdp_fixups(struct spi_nor *nor)
+{
+ struct mtd_info *mtd = &nor->mtd;
+
+ if (mtd->size <= SZ_16M)
+ return;
+
+ nor->flags |= SNOR_F_4B_OPCODES;
+ /* No small sector erase for 4-byte command set */
+ nor->erase_opcode = SPINOR_OP_SE;
+ nor->mtd.erasesize = nor->info->sector_size;
+}
+
/**
* spi_nor_post_sfdp_fixups() - Updates the flash's parameters and settings
* after SFDP has been parsed (is also called for SPI NORs that do not
@@ -4334,6 +4335,15 @@ static void spi_nor_legacy_init_params(struct spi_nor
*nor)
*/
static void spi_nor_post_sfdp_fixups(struct spi_nor *nor)
{
+ switch (JEDEC_MFR(nor->info)) {
+ case SNOR_MFR_SPANSION:
+ spansion_post_sfdp_fixups(nor);
+ break;
+
+ default:
+ break;
+ }
+
if (nor->info->fixups && nor->info->fixups->post_sfdp)
nor->info->fixups->post_sfdp(nor);
}
@@ -4895,8 +4905,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
nor->addr_width = 3;
}
- if (info->flags & SPI_NOR_4B_OPCODES ||
- (JEDEC_MFR(info) == SNOR_MFR_SPANSION && mtd->size > SZ_16M))
+ if (info->flags & SPI_NOR_4B_OPCODES)
nor->flags |= SNOR_F_4B_OPCODES;
if (nor->addr_width == 4 && nor->flags & SNOR_F_4B_OPCODES &&
--
2.9.5
[PATCH v2 0/6] mtd: spi-nor: move manuf out of the core - batch 2
From: Tudor Ambarus Depends on 'mtd: spi-nor: move manuf out of the core - batch 1' series: https://patchwork.ozlabs.org/project/linux-mtd/list/?series=127121 which depends on: Depends on 'mtd: spi-nor: move manuf out of the core - batch 0' series: https://patchwork.ozlabs.org/project/linux-mtd/list/?series=127030 v2: - addressed all the comments - all flash parameters and settings are now set in 'struct spi_nor_flash_parameter', for a clearer separation between the SPI NOR layer and the flash params. Add post_sfdp() hook to tweak flash config. This series opens doors for 5/ from below. In the quest of moving the manufacturer code out of the spi-nor core, we want to impose the following sequence of calls: 1/ spi-nor core legacy flash parameters init: spi_nor_default_init_params() 2/ MFR-based manufacturer flash parameters init: nor->manufacturer->fixups->default_init() 3/ specific flash_info tweeks done when decisions can not be done just on MFR: nor->info->fixups->default_init() 4/ SFDP tables flash parameters init - SFDP knows better: spi_nor_sfdp_init_params() 5/ post SFDP tables flash parameters updates - in case manufacturers get the serial flash tables wrong or incomplete. nor->info->fixups->post_sfdp() The later can be extended to nor->manufacturer->fixups->post_sfdp() if needed. Tested on sst26vf064b with atmel-quadspi SPIMEM driver. Boris Brezillon (4): mtd: spi-nor: Add post_sfdp() hook to tweak flash config mtd: spi-nor: Add spansion_post_sfdp_fixups() mtd: spi-nor: Add a ->convert_addr() method mtd: spi-nor: Add the SPI_NOR_XSR_RDY flag Tudor Ambarus (2): mtd: spi_nor: Add a ->setup() method mtd: spi-nor: Add s3an_post_sfdp_fixups() drivers/mtd/spi-nor/spi-nor.c | 549 +++--- include/linux/mtd/spi-nor.h | 22 +- 2 files changed, 322 insertions(+), 249 deletions(-) -- 2.9.5
[PATCH v2 1/6] mtd: spi-nor: Add post_sfdp() hook to tweak flash config
From: Boris Brezillon
SFDP tables are sometimes wrong and we need a way to override the
config chosen by the SFDP parsing logic without discarding all of it.
Add a new hook called after the SFDP parsing has taken place to deal
with such problems.
Signed-off-by: Boris Brezillon
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index f4e9fcca619f..41dc95415260 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -158,6 +158,11 @@ struct sfdp_bfpt {
*flash parameters when information provided by the flash_info
*table is incomplete or wrong.
* @post_bfpt: called after the BFPT table has been parsed
+ * @post_sfdp: called after SFDP has been parsed (is also called for SPI NORs
+ * that do not support RDSFDP). Typically used to tweak various
+ * parameters that could not be extracted by other means (i.e.
+ * when information provided by the SFDP/flash_info tables are
+ * incomplete or wrong).
*
* Those hooks can be used to tweak the SPI NOR configuration when the SFDP
* table is broken or not available.
@@ -168,6 +173,7 @@ struct spi_nor_fixups {
const struct sfdp_parameter_header *bfpt_header,
const struct sfdp_bfpt *bfpt,
struct spi_nor_flash_parameter *params);
+ void (*post_sfdp)(struct spi_nor *nor);
};
struct flash_info {
@@ -4317,6 +4323,22 @@ static void spi_nor_legacy_init_params(struct spi_nor
*nor)
}
/**
+ * spi_nor_post_sfdp_fixups() - Updates the flash's parameters and settings
+ * after SFDP has been parsed (is also called for SPI NORs that do not
+ * support RDSFDP).
+ * @nor: pointer to a 'struct spi_nor'
+ *
+ * Typically used to tweak various parameters that could not be extracted by
+ * other means (i.e. when information provided by the SFDP/flash_info tables
+ * are incomplete or wrong).
+ */
+static void spi_nor_post_sfdp_fixups(struct spi_nor *nor)
+{
+ if (nor->info->fixups && nor->info->fixups->post_sfdp)
+ nor->info->fixups->post_sfdp(nor);
+}
+
+/**
* spi_nor_late_init_params() - Late initialization of legacy flash parameters.
* @nor: pointer to a 'struct spi_nor'
*
@@ -4359,7 +4381,14 @@ static void spi_nor_late_init_params(struct spi_nor *nor)
*flash parameters and settings imediately after parsing the Basic Flash
*Parameter Table.
*
- * 4/ Late legacy flash parameters initialization, used when the
+ * which can be overwritten by:
+ * 4/ Post SFDP flash parameters initialization. Used to tweak various
+ *parameters that could not be extracted by other means (i.e. when
+ *information provided by the SFDP/flash_info tables are incomplete or
+ *wrong).
+ * spi_nor_post_sfdp_fixups()
+ *
+ * 5/ Late legacy flash parameters initialization, used when the
* ->default_init() hook or the SFDP parser do not set specific params.
* spi_nor_late_init_params()
*/
@@ -4373,6 +4402,8 @@ static void spi_nor_init_params(struct spi_nor *nor)
!(nor->info->flags & SPI_NOR_SKIP_SFDP))
spi_nor_sfdp_init_params(nor);
+ spi_nor_post_sfdp_fixups(nor);
+
spi_nor_late_init_params(nor);
}
--
2.9.5
[PATCH v2 6/6] mtd: spi-nor: Add the SPI_NOR_XSR_RDY flag
From: Boris Brezillon
S3AN flashes use a specific opcode to read the status register.
We currently use the SPI_S3AN flag to decide whether this specific
SR read opcode should be used, but SPI_S3AN is about to disappear, so
let's add a new flag.
Note that we use the same bit as SPI_S3AN implies SPI_NOR_XSR_RDY and
vice versa.
Signed-off-by: Boris Brezillon
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 5e16f293a83b..e76c23d1c54a 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -211,6 +211,14 @@ struct flash_info {
* bit. Must be used with
* SPI_NOR_HAS_LOCK.
*/
+#define SPI_NOR_XSR_RDYBIT(10) /*
+* S3AN flashes have specific opcode to
+* read the status register.
+* Flags SPI_NOR_XSR_RDY and SPI_S3AN
+* use the same bit as one implies the
+* other, but we will get rid of
+* SPI_S3AN soon.
+*/
#defineSPI_S3ANBIT(10) /*
* Xilinx Spartan 3AN In-System Flash
* (MFR cannot be used for probing
@@ -4839,7 +4847,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
* spi_nor_wait_till_ready(). Xilinx S3AN share MFR
* with Atmel spi-nor
*/
- if (info->flags & SPI_S3AN)
+ if (info->flags & SPI_NOR_XSR_RDY)
nor->flags |= SNOR_F_READY_XSR_RDY;
if (info->flags & SPI_NOR_HAS_LOCK) {
--
2.9.5
[PATCH v2 4/6] mtd: spi_nor: Add a ->setup() method
From: Tudor Ambarus
nor->params.setup() configures the SPI NOR memory. Useful for SPI NOR
flashes that have peculiarities to the SPI NOR standard, e.g.
different opcodes, specific address calculation, page size, etc.
Right now the only user will be the S3AN chips, but other
manufacturers can implement it if needed.
Move spi_nor_setup() related code in order to avoid a forward
declaration to spi_nor_default_setup().
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 428 +-
include/linux/mtd/spi-nor.h | 5 +
2 files changed, 224 insertions(+), 209 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 0dc6a683719e..17e6c96f9f9a 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -4144,6 +4144,224 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
return err;
}
+static int spi_nor_select_read(struct spi_nor *nor,
+ u32 shared_hwcaps)
+{
+ int cmd, best_match = fls(shared_hwcaps & SNOR_HWCAPS_READ_MASK) - 1;
+ const struct spi_nor_read_command *read;
+
+ if (best_match < 0)
+ return -EINVAL;
+
+ cmd = spi_nor_hwcaps_read2cmd(BIT(best_match));
+ if (cmd < 0)
+ return -EINVAL;
+
+ read = &nor->params.reads[cmd];
+ nor->read_opcode = read->opcode;
+ nor->read_proto = read->proto;
+
+ /*
+* In the spi-nor framework, we don't need to make the difference
+* between mode clock cycles and wait state clock cycles.
+* Indeed, the value of the mode clock cycles is used by a QSPI
+* flash memory to know whether it should enter or leave its 0-4-4
+* (Continuous Read / XIP) mode.
+* eXecution In Place is out of the scope of the mtd sub-system.
+* Hence we choose to merge both mode and wait state clock cycles
+* into the so called dummy clock cycles.
+*/
+ nor->read_dummy = read->num_mode_clocks + read->num_wait_states;
+ return 0;
+}
+
+static int spi_nor_select_pp(struct spi_nor *nor,
+u32 shared_hwcaps)
+{
+ int cmd, best_match = fls(shared_hwcaps & SNOR_HWCAPS_PP_MASK) - 1;
+ const struct spi_nor_pp_command *pp;
+
+ if (best_match < 0)
+ return -EINVAL;
+
+ cmd = spi_nor_hwcaps_pp2cmd(BIT(best_match));
+ if (cmd < 0)
+ return -EINVAL;
+
+ pp = &nor->params.page_programs[cmd];
+ nor->program_opcode = pp->opcode;
+ nor->write_proto = pp->proto;
+ return 0;
+}
+
+/**
+ * spi_nor_select_uniform_erase() - select optimum uniform erase type
+ * @map: the erase map of the SPI NOR
+ * @wanted_size: the erase type size to search for. Contains the value of
+ * info->sector_size or of the "small sector" size in case
+ * CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is defined.
+ *
+ * Once the optimum uniform sector erase command is found, disable all the
+ * other.
+ *
+ * Return: pointer to erase type on success, NULL otherwise.
+ */
+static const struct spi_nor_erase_type *
+spi_nor_select_uniform_erase(struct spi_nor_erase_map *map,
+const u32 wanted_size)
+{
+ const struct spi_nor_erase_type *tested_erase, *erase = NULL;
+ int i;
+ u8 uniform_erase_type = map->uniform_erase_type;
+
+ for (i = SNOR_ERASE_TYPE_MAX - 1; i >= 0; i--) {
+ if (!(uniform_erase_type & BIT(i)))
+ continue;
+
+ tested_erase = &map->erase_type[i];
+
+ /*
+* If the current erase size is the one, stop here:
+* we have found the right uniform Sector Erase command.
+*/
+ if (tested_erase->size == wanted_size) {
+ erase = tested_erase;
+ break;
+ }
+
+ /*
+* Otherwise, the current erase size is still a valid canditate.
+* Select the biggest valid candidate.
+*/
+ if (!erase && tested_erase->size)
+ erase = tested_erase;
+ /* keep iterating to find the wanted_size */
+ }
+
+ if (!erase)
+ return NULL;
+
+ /* Disable all other Sector Erase commands. */
+ map->uniform_erase_type &= ~SNOR_ERASE_TYPE_MASK;
+ map->uniform_erase_type |= BIT(erase - map->erase_type);
+ return erase;
+}
+
+static int spi_nor_select_erase(struct spi_nor *nor, u32 wanted_size)
+{
+ struct spi_nor_erase_map *map = &nor->params.erase_map;
+ const struct spi_nor_erase_type *erase = NULL;
+ struct mtd_info *mtd = &nor->mtd;
+ int i;
+
+ /*
+* The previous implementation handling Sector Erase commands assumed
+* that the SPI flash memory has an uniform layo
[PATCH v2 3/6] mtd: spi-nor: Add a ->convert_addr() method
From: Boris Brezillon
In order to separate manufacturer quirks from the core we need to get
rid of all the manufacturer specific flags, like the
SNOR_F_S3AN_ADDR_DEFAULT one.
This can easily be replaced by a ->convert_addr() hook, which when
implemented will provide the core with an easy way to convert an
absolute address into something the flash understands.
Right now the only user are the S3AN chips, but other manufacturers
can implement it if needed.
Signed-off-by: Boris Brezillon
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 24 ++--
include/linux/mtd/spi-nor.h | 17 ++---
2 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index bd31d6529892..0dc6a683719e 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -899,10 +899,9 @@ static void spi_nor_unlock_and_unprep(struct spi_nor *nor,
enum spi_nor_ops ops)
* Addr can safely be unsigned int, the biggest S3AN device is smaller than
* 4 MiB.
*/
-static loff_t spi_nor_s3an_addr_convert(struct spi_nor *nor, unsigned int addr)
+static u32 s3an_convert_addr(struct spi_nor *nor, u32 addr)
{
- unsigned int offset;
- unsigned int page;
+ u32 offset, page;
offset = addr % nor->page_size;
page = addr / nor->page_size;
@@ -911,6 +910,14 @@ static loff_t spi_nor_s3an_addr_convert(struct spi_nor
*nor, unsigned int addr)
return page | offset;
}
+static u32 spi_nor_convert_addr(struct spi_nor *nor, loff_t addr)
+{
+ if (!nor->params.convert_addr)
+ return addr;
+
+ return nor->params.convert_addr(nor, addr);
+}
+
/*
* Initiate the erasure of a single sector
*/
@@ -918,8 +925,7 @@ static int spi_nor_erase_sector(struct spi_nor *nor, u32
addr)
{
int i;
- if (nor->flags & SNOR_F_S3AN_ADDR_DEFAULT)
- addr = spi_nor_s3an_addr_convert(nor, addr);
+ addr = spi_nor_convert_addr(nor, addr);
if (nor->erase)
return nor->erase(nor, addr);
@@ -2535,8 +2541,7 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t
from, size_t len,
while (len) {
loff_t addr = from;
- if (nor->flags & SNOR_F_S3AN_ADDR_DEFAULT)
- addr = spi_nor_s3an_addr_convert(nor, addr);
+ addr = spi_nor_convert_addr(nor, addr);
ret = spi_nor_read_data(nor, addr, len, buf);
if (ret == 0) {
@@ -2680,8 +2685,7 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t to,
size_t len,
page_remain = min_t(size_t,
nor->page_size - page_offset, len - i);
- if (nor->flags & SNOR_F_S3AN_ADDR_DEFAULT)
- addr = spi_nor_s3an_addr_convert(nor, addr);
+ addr = spi_nor_convert_addr(nor, addr);
write_enable(nor);
ret = spi_nor_write_data(nor, addr, page_remain, buf + i);
@@ -2748,7 +2752,7 @@ static int s3an_nor_scan(struct spi_nor *nor)
nor->mtd.erasesize = 8 * nor->page_size;
} else {
/* Flash in Default addressing mode */
- nor->flags |= SNOR_F_S3AN_ADDR_DEFAULT;
+ nor->params.convert_addr = s3an_convert_addr;
}
return 0;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 6c5eaf607b50..f9f1947f7aeb 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -237,13 +237,12 @@ enum spi_nor_option_flags {
SNOR_F_USE_FSR = BIT(0),
SNOR_F_HAS_SR_TB= BIT(1),
SNOR_F_NO_OP_CHIP_ERASE = BIT(2),
- SNOR_F_S3AN_ADDR_DEFAULT = BIT(3),
- SNOR_F_READY_XSR_RDY= BIT(4),
- SNOR_F_USE_CLSR = BIT(5),
- SNOR_F_BROKEN_RESET = BIT(6),
- SNOR_F_4B_OPCODES = BIT(7),
- SNOR_F_HAS_4BAIT= BIT(8),
- SNOR_F_HAS_LOCK = BIT(9),
+ SNOR_F_READY_XSR_RDY= BIT(3),
+ SNOR_F_USE_CLSR = BIT(4),
+ SNOR_F_BROKEN_RESET = BIT(5),
+ SNOR_F_4B_OPCODES = BIT(6),
+ SNOR_F_HAS_4BAIT= BIT(7),
+ SNOR_F_HAS_LOCK = BIT(8),
};
/**
@@ -496,6 +495,9 @@ struct spi_nor_locking_ops {
* Table.
* @quad_enable: enables SPI NOR quad mode.
* @set_4byte: puts the SPI NOR in 4 byte addressing mode.
+ * @convert_addr: converts an absolute address into something the flash
+ * will understand. Particularly useful when pagesize is
+ * not a power-of-2.
* @disable_block_protection: disables block protection during power-up.
* @locking_ops: SPI NOR locking methods.
*/
@@ -511,6 +513,7 @@ struct spi_nor_flash_parameter {
int (*quad_enable)(struct spi_nor *nor);
int (*set_4byte)(struct spi_nor *nor, bool ena
[PATCH v2 5/6] mtd: spi-nor: Add s3an_post_sfdp_fixups()
From: Tudor Ambarus
s3an_nor_scan() was overriding the opcode selection done in
spi_nor_default_setup(). Set nor->setup() method in order to
avoid the unnecessary call to spi_nor_default_setup().
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 17e6c96f9f9a..5e16f293a83b 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2718,7 +2718,8 @@ static int spi_nor_check(struct spi_nor *nor)
return 0;
}
-static int s3an_nor_scan(struct spi_nor *nor)
+static int s3an_nor_setup(struct spi_nor *nor,
+ const struct spi_nor_hwcaps *hwcaps)
{
int ret;
@@ -4546,6 +4547,11 @@ static void spansion_post_sfdp_fixups(struct spi_nor
*nor)
nor->mtd.erasesize = nor->info->sector_size;
}
+static void s3an_post_sfdp_fixups(struct spi_nor *nor)
+{
+ nor->params.setup = s3an_nor_setup;
+}
+
/**
* spi_nor_post_sfdp_fixups() - Updates the flash's parameters and settings
* after SFDP has been parsed (is also called for SPI NORs that do not
@@ -4567,6 +4573,9 @@ static void spi_nor_post_sfdp_fixups(struct spi_nor *nor)
break;
}
+ if (nor->info->flags & SPI_S3AN)
+ s3an_post_sfdp_fixups(nor);
+
if (nor->info->fixups && nor->info->fixups->post_sfdp)
nor->info->fixups->post_sfdp(nor);
}
@@ -4932,12 +4941,6 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
return -EINVAL;
}
- if (info->flags & SPI_S3AN) {
- ret = s3an_nor_scan(nor);
- if (ret)
- return ret;
- }
-
/* Send all the required SPI flash commands to initialize device */
ret = spi_nor_init(nor);
if (ret)
--
2.9.5
Re: [PATCH 5.2 000/135] 5.2.10-stable review
On Sat, Aug 24, 2019 at 01:48:35AM -0400, Sasha Levin wrote: > On Fri, Aug 23, 2019 at 07:32:58PM -0700, Greg KH wrote: > > On Fri, Aug 23, 2019 at 09:18:05PM -0400, Sasha Levin wrote: > > > On Fri, Aug 23, 2019 at 10:36:27AM -0700, Greg KH wrote: > > > > On Fri, Aug 23, 2019 at 02:28:53AM -0400, Sasha Levin wrote: > > > > > On Fri, Aug 23, 2019 at 02:42:48AM +0200, Stefan Lippers-Hollmann > > > > > wrote: > > > > > > Hi > > > > > > > > > > > > On 2019-08-22, Greg KH wrote: > > > > > > > On Fri, Aug 23, 2019 at 12:05:27AM +0200, Stefan Lippers-Hollmann > > > > > > > wrote: > > > > > > > > On 2019-08-22, Greg KH wrote: > > > > > > > > > On Thu, Aug 22, 2019 at 01:05:56PM -0400, Sasha Levin wrote: > > > > > > [...] > > > > > > > > It might be down to kernel.org mirroring, but the patch file > > > > > > > > doesn't > > > > > > > > seem to be available yet (404), both in the wrong location > > > > > > > > listed > > > > > > > > above - and the expected one under > > > > > > > > > > > > > > > > > > > > > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.10-rc1.gz > > > > > > [...] > > > > > > > Ah, no, it's not a mirroring problem, Sasha and I didn't know if > > > > > > > anyone > > > > > > > was actually using the patch files anymore, so it was simpler to > > > > > > > do a > > > > > > > release without them to see what happens. :) > > > > > > > > > > > > > > Do you rely on these, or can you use the -rc git tree or the quilt > > > > > > > series? If you do rely on them, we will work to fix this, it just > > > > > > > involves some scripting that we didn't get done this morning. > > > > > > > > > > > > "Rely" is a strong word, I can adapt if they're going away, but > > > > > > I've been using them so far, as in (slightly simplified): > > > > > > > > > > > > $ cd patches/upstream/ > > > > > > $ wget https://cdn.kernel.org/pub/linux/kernel/v5.x/patch-5.2.9.xz > > > > > > $ xz -d patch-5.2.9.xz > > > > > > $ wget > > > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.10-rc1.gz > > > > > > $ gunzip patch-5.2.10-rc1.gz > > > > > > $ vim ../series > > > > > > $ quilt ... > > > > > > > > > > > > I can switch to importing the quilt queue with some sed magic (and I > > > > > > already do that, if interesting or just a larger amounts of patches > > > > > > are > > > > > > queuing up for more than a day or two), but using the -rc patches > > > > > > has > > > > > > been convenient in that semi-manual workflow, also to make sure to > > > > > > really > > > > > > get and test the formal -rc patch, rather than something inbetween. > > > > > > > > > > An easy way to generate a patch is to just use the git.kernel.org web > > > > > interface. A patch for 5.2.10-rc1 would be: > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-5.2.y&id2=v5.2.9 > > > > > > > > > > Personally this patch upload story sounded to me like a pre-git era > > > > > artifact... > > > > > > > > Given that we no longer do patches for Linus's -rc releases for the past > > > > few years, maybe it is time to move to do the same for the stable > > > > releases to be consistent. > > > > > > Or tarballs? Why do we generate tarballs (and go through kup)? > > > git.kernel.org already does it for us. > > > > As I mentioned yesterday, but writing it down here for posterity, > > there's a number of reasons. > > > > First off, the release process doesn't require kup for when a "real" > > release happens, that's all now donw on git.kernel.org with a process > > involving a signed note and some other fun backend stuff. We are > > working on expanding that in the future with some other signature > > validation as well, to make it easier to verify tarballs are "correct" > > as what we do today is a bit different than other projects. > > I think that I made it read like I want to remove tarballs altogether. > That's not the case: I just want to get rid of the magical signed note > process. That "signed note process" is _way_ better than what we used to do. > The way I understand it, we generate tarballs twice: once during the > magical signed note process, and once by the git interface. I'm just > suggesting we reduce that down to happen once. How about we make it even better, we never generate it at all! That's how the "signed note" process works, the only thing that does the tarball generation is in the kernel.org infrastructure itself, when it receives a properly signed note. I never create it locally or anywhere else and we do not use 'kup' anymore for the process either. > Right now you can fetch tarballs from two different links on kernel.org. > For example, a 5.2.9 tarball is available at: > > - https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.2.9.tar.xz > - > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot/linux-5.2.9.tar.gz > > Can't we symlink one to the other? Those are two different hosts/cd
[PATCH v2 0/3] mtd: spi-nor: move manuf out of the core - batch 3
From: Tudor Ambarus Trim spi_nor_scan() huge function. Depends on 'mtd: spi-nor: move manuf out of the core - batch 2' series: https://patchwork.ozlabs.org/project/linux-mtd/list/?series=127122 which depends on: Depends on 'mtd: spi-nor: move manuf out of the core - batch 1' series: https://patchwork.ozlabs.org/project/linux-mtd/list/?series=127121 which depends on: Depends on 'mtd: spi-nor: move manuf out of the core - batch 0' series: https://patchwork.ozlabs.org/project/linux-mtd/list/?series=127030 All batches can be found at: https://github.com/ambarus/linux-0day/tree/spi-nor/manuf-drv Tudor Ambarus (3): mtd: spi-nor: Bring flash params init together mtd: spi_nor: Introduce spi_nor_set_addr_width() mtd: spi-nor: Introduce spi_nor_get_flash_info() drivers/mtd/spi-nor/spi-nor.c | 155 +++--- 1 file changed, 85 insertions(+), 70 deletions(-) -- 2.9.5
[PATCH v2 1/3] mtd: spi-nor: Bring flash params init together
From: Tudor Ambarus
Bring all flash parameters default initialization in
spi_nor_legacy_params_init().
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index e76c23d1c54a..7e6da0ace2c7 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -4469,6 +4469,7 @@ static void spi_nor_legacy_init_params(struct spi_nor
*nor)
struct spi_nor_flash_parameter *params = &nor->params;
struct spi_nor_erase_map *map = ¶ms->erase_map;
const struct flash_info *info = nor->info;
+ struct device_node *np = spi_nor_get_flash_node(nor);
u8 i, erase_mask;
/* Initialize legacy flash parameters and settings. */
@@ -4480,18 +4481,25 @@ static void spi_nor_legacy_init_params(struct spi_nor
*nor)
params->size = (u64)info->sector_size * info->n_sectors;
params->page_size = info->page_size;
+ if (!(info->flags & SPI_NOR_NO_FR)) {
+ /* Default to Fast Read for DT and non-DT platform devices. */
+ params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
+
+ /* Mask out Fast Read if not requested at DT instantiation. */
+ if (np && !of_property_read_bool(np, "m25p,fast-read"))
+ params->hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
+ }
+
/* (Fast) Read settings. */
params->hwcaps.mask |= SNOR_HWCAPS_READ;
spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ],
0, 0, SPINOR_OP_READ,
SNOR_PROTO_1_1_1);
- if (!(info->flags & SPI_NOR_NO_FR)) {
- params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
+ if (params->hwcaps.mask & SNOR_HWCAPS_READ_FAST)
spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_FAST],
0, 8, SPINOR_OP_READ_FAST,
SNOR_PROTO_1_1_1);
- }
if (info->flags & SPI_NOR_DUAL_READ) {
params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_2;
@@ -4897,24 +4905,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
nor->page_size = params->page_size;
mtd->writebufsize = nor->page_size;
- if (np) {
- /* If we were instantiated by DT, use it */
- if (of_property_read_bool(np, "m25p,fast-read"))
- params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
- else
- params->hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
- } else {
- /* If we weren't instantiated by DT, default to fast-read */
- params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
- }
-
if (of_property_read_bool(np, "broken-flash-reset"))
nor->flags |= SNOR_F_BROKEN_RESET;
- /* Some devices cannot do fast-read, no matter what DT tells us */
- if (info->flags & SPI_NOR_NO_FR)
- params->hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
-
/*
* Configure the SPI memory:
* - select op codes for (Fast) Read, Page Program and Sector Erase.
--
2.9.5
[PATCH v2 3/3] mtd: spi-nor: Introduce spi_nor_get_flash_info()
From: Tudor Ambarus
Dedicate a function for getting the pointer to the flash_info
const struct. Trim a bit the spi_nor_scan() huge function.
Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
---
drivers/mtd/spi-nor/spi-nor.c | 76 +--
1 file changed, 44 insertions(+), 32 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 449d2c4918ca..1896d36a7d11 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -4807,10 +4807,50 @@ static int spi_nor_set_addr_width(struct spi_nor *nor)
return 0;
}
+static const struct flash_info *spi_nor_get_flash_info(struct spi_nor *nor,
+ const char *name)
+{
+ const struct flash_info *info = NULL;
+
+ if (name)
+ info = spi_nor_match_id(name);
+ /* Try to auto-detect if chip name wasn't specified or not found */
+ if (!info)
+ info = spi_nor_read_id(nor);
+ if (IS_ERR_OR_NULL(info))
+ return ERR_PTR(-ENOENT);
+
+ /*
+* If caller has specified name of flash model that can normally be
+* detected using JEDEC, let's verify it.
+*/
+ if (name && info->id_len) {
+ const struct flash_info *jinfo;
+
+ jinfo = spi_nor_read_id(nor);
+ if (IS_ERR(jinfo)) {
+ return jinfo;
+ } else if (jinfo != info) {
+ /*
+* JEDEC knows better, so overwrite platform ID. We
+* can't trust partitions any longer, but we'll let
+* mtd apply them anyway, since some partitions may be
+* marked read-only, and we don't want to lose that
+* information, even if it's not 100% accurate.
+*/
+ dev_warn(nor->dev, "found %s, expected %s\n",
+jinfo->name, info->name);
+ info = jinfo;
+ }
+ }
+
+ return info;
+}
+
int spi_nor_scan(struct spi_nor *nor, const char *name,
const struct spi_nor_hwcaps *hwcaps)
{
- const struct flash_info *info = NULL;
+ const struct flash_info *info;
struct device *dev = nor->dev;
struct mtd_info *mtd = &nor->mtd;
struct device_node *np = spi_nor_get_flash_node(nor);
@@ -4841,37 +4881,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
if (!nor->bouncebuf)
return -ENOMEM;
- if (name)
- info = spi_nor_match_id(name);
- /* Try to auto-detect if chip name wasn't specified or not found */
- if (!info)
- info = spi_nor_read_id(nor);
- if (IS_ERR_OR_NULL(info))
- return -ENOENT;
-
- /*
-* If caller has specified name of flash model that can normally be
-* detected using JEDEC, let's verify it.
-*/
- if (name && info->id_len) {
- const struct flash_info *jinfo;
-
- jinfo = spi_nor_read_id(nor);
- if (IS_ERR(jinfo)) {
- return PTR_ERR(jinfo);
- } else if (jinfo != info) {
- /*
-* JEDEC knows better, so overwrite platform ID. We
-* can't trust partitions any longer, but we'll let
-* mtd apply them anyway, since some partitions may be
-* marked read-only, and we don't want to lose that
-* information, even if it's not 100% accurate.
-*/
- dev_warn(dev, "found %s, expected %s\n",
-jinfo->name, info->name);
- info = jinfo;
- }
- }
+ info = spi_nor_get_flash_info(nor, name);
+ if (IS_ERR(info))
+ return PTR_ERR(info);
nor->info = info;
--
2.9.5
[PATCH v2 2/3] mtd: spi_nor: Introduce spi_nor_set_addr_width()
From: Tudor Ambarus
Parsing of flash parameters were interleaved with setting of the
nor addr width. Dedicate a function for setting nor addr width.
Signed-off-by: Tudor Ambarus
Reviewed-by: Boris Brezillon
---
drivers/mtd/spi-nor/spi-nor.c | 50 ++-
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 7e6da0ace2c7..449d2c4918ca 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -4780,6 +4780,33 @@ static const struct flash_info *spi_nor_match_id(const
char *name)
return NULL;
}
+static int spi_nor_set_addr_width(struct spi_nor *nor)
+{
+ if (nor->addr_width) {
+ /* already configured from SFDP */
+ } else if (nor->info->addr_width) {
+ nor->addr_width = nor->info->addr_width;
+ } else if (nor->mtd.size > 0x100) {
+ /* enable 4-byte addressing if the device exceeds 16MiB */
+ nor->addr_width = 4;
+ } else {
+ nor->addr_width = 3;
+ }
+
+ if (nor->addr_width > SPI_NOR_MAX_ADDR_WIDTH) {
+ dev_err(nor->dev, "address width is too large: %u\n",
+ nor->addr_width);
+ return -EINVAL;
+ }
+
+ /* Set 4byte opcodes when possible. */
+ if (nor->addr_width == 4 && nor->flags & SNOR_F_4B_OPCODES &&
+ !(nor->flags & SNOR_F_HAS_4BAIT))
+ spi_nor_set_4byte_opcodes(nor);
+
+ return 0;
+}
+
int spi_nor_scan(struct spi_nor *nor, const char *name,
const struct spi_nor_hwcaps *hwcaps)
{
@@ -4918,29 +4945,12 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
if (ret)
return ret;
- if (nor->addr_width) {
- /* already configured from SFDP */
- } else if (info->addr_width) {
- nor->addr_width = info->addr_width;
- } else if (mtd->size > 0x100) {
- /* enable 4-byte addressing if the device exceeds 16MiB */
- nor->addr_width = 4;
- } else {
- nor->addr_width = 3;
- }
-
if (info->flags & SPI_NOR_4B_OPCODES)
nor->flags |= SNOR_F_4B_OPCODES;
- if (nor->addr_width == 4 && nor->flags & SNOR_F_4B_OPCODES &&
- !(nor->flags & SNOR_F_HAS_4BAIT))
- spi_nor_set_4byte_opcodes(nor);
-
- if (nor->addr_width > SPI_NOR_MAX_ADDR_WIDTH) {
- dev_err(dev, "address width is too large: %u\n",
- nor->addr_width);
- return -EINVAL;
- }
+ ret = spi_nor_set_addr_width(nor);
+ if (ret)
+ return ret;
/* Send all the required SPI flash commands to initialize device */
ret = spi_nor_init(nor);
--
2.9.5
[PATCH v2 1/2] mtd: spi-nor: add Global Block Unlock support
From: Tudor Ambarus
To avoid inadvertent writes during power-up, some flashes are
write-protected by default after a power-on reset cycle.
A Global Block-Protection Unlock command offers a single
command cycle that unlocks the entire memory array. This is
identical with what other nor flashes are doing by clearing
the block protection bits from the status register: disable
the write protection after a power-on reset cycle.
We can't determine this purely by manufacturer type and it's not
autodetectable by anything like SFDP, so make a new flag for it:
UNLOCK_GLOBAL_BLOCK.
Note that the Global Block Unlock command has different names
depending on the manufacturer, but always the same command value:
0x98. Macronix's MX25U12835F names it Gang Block Unlock,
Winbound's W25Q128FV names it Global Block Unlock and
Microchip's SST26VF064B names it Global Block Protection Unlock.
Signed-off-by: Tudor Ambarus
---
v2: the check for UNLOCK_GLOBAL_BLOCK should be done the first
thing in spi_nor_disable_block_protection(). We use it for a faster
throughput, a single command cycle that unlocks the entire memory
array. Fix it.
drivers/mtd/spi-nor/spi-nor.c | 46 ++-
include/linux/mtd/spi-nor.h | 1 +
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 1896d36a7d11..c0ba6fe62461 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -196,7 +196,7 @@ struct flash_info {
u16 page_size;
u16 addr_width;
- u16 flags;
+ u32 flags;
#define SECT_4KBIT(0) /* SPINOR_OP_BE_4K works
uniformly */
#define SPI_NOR_NO_ERASE BIT(1) /* No erase command needed */
#define SST_WRITE BIT(2) /* use SST byte programming */
@@ -233,6 +233,7 @@ struct flash_info {
#define SPI_NOR_SKIP_SFDP BIT(13) /* Skip parsing of SFDP tables */
#define USE_CLSR BIT(14) /* use CLSR command */
#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */
+#define UNLOCK_GLOBAL_BLOCKBIT(16) /* Unlock global block protection */
/* Part specific fixup hooks. */
const struct spi_nor_fixups *fixups;
@@ -2031,6 +2032,41 @@ static int spi_nor_spansion_clear_sr_bp(struct spi_nor
*nor)
return spi_nor_clear_sr_bp(nor);
}
+/**
+ * spi_nor_unlock_global_block_protection() - Unlock the Global Block
Protection
+ * @nor:pointer to a 'struct spi_nor'
+ *
+ * The Global Block-Protection Unlock command offers a single command cycle
+ * that unlocks the entire memory array.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_unlock_global_block_protection(struct spi_nor *nor)
+{
+ int ret;
+
+ write_enable(nor);
+
+ if (nor->spimem) {
+ struct spi_mem_op op =
+ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_ULBPR, 1),
+ SPI_MEM_OP_NO_ADDR,
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_NO_DATA);
+
+ ret = spi_mem_exec_op(nor->spimem, &op);
+ } else {
+ ret = nor->write_reg(nor, SPINOR_OP_ULBPR, NULL, 0);
+ }
+
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d on ULBPR\n", ret);
+ return ret;
+ }
+
+ return spi_nor_wait_till_ready(nor);
+}
+
/* Used when the "_ext_id" is two bytes at most */
#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
.id = { \
@@ -4697,6 +4733,14 @@ static int spi_nor_quad_enable(struct spi_nor *nor)
*/
static int spi_nor_disable_block_protection(struct spi_nor *nor)
{
+ /*
+* If the flash supports the Global Block-Protection Unlock command,
+* use it for faster throughput: a single command cycle that unlocks
+* the entire memory array.
+*/
+ if (nor->info->flags & UNLOCK_GLOBAL_BLOCK)
+ return spi_nor_unlock_global_block_protection(nor);
+
if (!nor->params.disable_block_protection)
return 0;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 4752d08e9a3e..31b99a7743fc 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -66,6 +66,7 @@
#define SPINOR_OP_CLFSR0x50/* Clear flag status register */
#define SPINOR_OP_RDEAR0xc8/* Read Extended Address
Register */
#define SPINOR_OP_WREAR0xc5/* Write Extended Address
Register */
+#define SPINOR_OP_ULBPR0x98/* Global Block Unlock
Protection */
/* 4-byte address opcodes - used on Spansion and some Macronix flashes. */
#define SPINOR_OP_READ_4B 0x13/* Read data bytes (low frequency) */
--
2.9.5
[PATCH v2 0/2] mtd: spi-nor: add Global Block Unlock support
From: Tudor Ambarus v2: the check for UNLOCK_GLOBAL_BLOCK should be done the first thing in spi_nor_disable_block_protection(). We use it for a faster throughput, a single command cycle that unlocks the entire memory array. Fix it. This is similar with what other nor flashes are doing by clearing the block protection bits from the status register: disable the write protection after a power-on reset cycle. The Global Block-Protection Unlock command offers a single command cycle that unlocks the entire memory array. Prefer this method for higher throughput. Tested on the sst26vf064b flash using the atmel-quadspi driver. This has nothing to do with the move manufacturer out of the spi-nor core pursue, but depends on 'mtd: spi-nor: move manuf out of the core - batch 0' https://patchwork.ozlabs.org/project/linux-mtd/list/?series=127030 Tudor Ambarus (2): mtd: spi-nor: add Global Block Unlock support mtd: spi-nor: unlock global block protection on sst26vf064b drivers/mtd/spi-nor/spi-nor.c | 50 +-- include/linux/mtd/spi-nor.h | 1 + 2 files changed, 49 insertions(+), 2 deletions(-) -- 2.9.5
[PATCH v2 2/2] mtd: spi-nor: unlock global block protection on sst26vf064b
From: Tudor Ambarus
To avoid inadvertent writes during power-up, sst26vf064b is
write-protected by default after a power-on reset cycle.
Unlock the serial flash memory by using the Global Block Protection
Unlock command - it offers a single command cycle that unlocks
the entire memory array.
Signed-off-by: Tudor Ambarus
---
drivers/mtd/spi-nor/spi-nor.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index c0ba6fe62461..f92202fa094d 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2419,7 +2419,9 @@ static const struct flash_info spi_nor_ids[] = {
{ "sst25wf080", INFO(0xbf2505, 0, 64 * 1024, 16, SECT_4K | SST_WRITE)
},
{ "sst26wf016b", INFO(0xbf2651, 0, 64 * 1024, 32, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
- { "sst26vf064b", INFO(0xbf2643, 0, 64 * 1024, 128, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { "sst26vf064b", INFO(0xbf2643, 0, 64 * 1024, 128,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+ UNLOCK_GLOBAL_BLOCK) },
/* ST Microelectronics -- newer production may have feature updates */
{ "m25p05", INFO(0x202010, 0, 32 * 1024, 2, 0) },
--
2.9.5
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Hi!
Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com napisal(a):
> From: Ondrej Jirman
>
> RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> mostly in features that are not yet supported by this driver.
>
> Some differences are already stated in the comments in existing code.
> One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
>
> It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> external low speed oscillator is working correctly.
>
> This patch adds support for enabling LOSC when necessary:
>
> - during reparenting
> - when probing the clock
>
> H6 also has capacbility to automatically reparent RTC clock from
> external crystal oscillator, to internal RC oscillator, if external
> oscillator fails. This is enabled by default. Disable it during
> probe.
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Chen-Yu Tsai
> ---
> drivers/rtc/rtc-sun6i.c | 40 ++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> index d50ee023b559..b0c3752bed3f 100644
> --- a/drivers/rtc/rtc-sun6i.c
> +++ b/drivers/rtc/rtc-sun6i.c
> @@ -32,9 +32,11 @@
> /* Control register */
> #define SUN6I_LOSC_CTRL 0x
> #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
User manual says that above field is bit 14.
Best regards,
Jernej
> #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
> #define SUN6I_LOSC_CTRL_RTC_HMS_ACC BIT(8)
> #define SUN6I_LOSC_CTRL_RTC_YMD_ACC BIT(7)
> +#define SUN6I_LOSC_CTRL_EXT_LOSC_EN BIT(4)
> #define SUN6I_LOSC_CTRL_EXT_OSC BIT(0)
> #define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
>
> @@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
> unsigned int has_prescaler : 1;
> unsigned int has_out_clk : 1;
> unsigned int export_iosc : 1;
> + unsigned int has_losc_en : 1;
> + unsigned int has_auto_swt : 1;
> };
>
> struct sun6i_rtc_dev {
> @@ -190,6 +194,10 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw *hw,
> u8 index) val &= ~SUN6I_LOSC_CTRL_EXT_OSC;
> val |= SUN6I_LOSC_CTRL_KEY;
> val |= index ? SUN6I_LOSC_CTRL_EXT_OSC : 0;
> + if (rtc->data->has_losc_en) {
> + val &= ~SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> + val |= index ? SUN6I_LOSC_CTRL_EXT_LOSC_EN : 0;
> + }
> writel(val, rtc->base + SUN6I_LOSC_CTRL);
> spin_unlock_irqrestore(&rtc->lock, flags);
>
> @@ -215,6 +223,7 @@ static void __init sun6i_rtc_clk_init(struct device_node
> *node, const char *iosc_name = "rtc-int-osc";
> const char *clkout_name = "osc32k-out";
> const char *parents[2];
> + u32 reg;
>
> rtc = kzalloc(sizeof(*rtc), GFP_KERNEL);
> if (!rtc)
> @@ -235,9 +244,18 @@ static void __init sun6i_rtc_clk_init(struct
> device_node *node, goto err;
> }
>
> + reg = SUN6I_LOSC_CTRL_KEY;
> + if (rtc->data->has_auto_swt) {
> + /* Bypass auto-switch to int osc, on ext losc failure */
> + reg |= SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS;
> + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> + }
> +
> /* Switch to the external, more precise, oscillator */
> - writel(SUN6I_LOSC_CTRL_KEY | SUN6I_LOSC_CTRL_EXT_OSC,
> -rtc->base + SUN6I_LOSC_CTRL);
> + reg |= SUN6I_LOSC_CTRL_EXT_OSC;
> + if (rtc->data->has_losc_en)
> + reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
>
> /* Yes, I know, this is ugly. */
> sun6i_rtc = rtc;
> @@ -345,6 +363,23 @@ CLK_OF_DECLARE_DRIVER(sun8i_h3_rtc_clk,
> "allwinner,sun8i-h3-rtc", CLK_OF_DECLARE_DRIVER(sun50i_h5_rtc_clk,
> "allwinner,sun50i-h5-rtc", sun8i_h3_rtc_clk_init);
>
> +static const struct sun6i_rtc_clk_data sun50i_h6_rtc_data = {
> + .rc_osc_rate = 1600,
> + .fixed_prescaler = 32,
> + .has_prescaler = 1,
> + .has_out_clk = 1,
> + .export_iosc = 1,
> + .has_losc_en = 1,
> + .has_auto_swt = 1,
> +};
> +
> +static void __init sun50i_h6_rtc_clk_init(struct device_node *node)
> +{
> + sun6i_rtc_clk_init(node, &sun50i_h6_rtc_data);
> +}
> +CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
> + sun50i_h6_rtc_clk_init);
> +
> static const struct sun6i_rtc_clk_data sun8i_v3_rtc_data = {
> .rc_osc_rate = 32000,
> .has_out_clk = 1,
> @@ -675,6 +710,7 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
> { .compatible = "allwinner,sun8i-r40-rtc" },
> { .compatible = "allwinner,sun8i-v3-rtc" },
> { .compatible = "allwinner,sun50i-h5-rtc" },
> + { .compatible = "allwinner,sun50i-h6-rtc" },
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, sun6i
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Hi,
On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote:
> Hi!
>
> Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com napisal(a):
> > From: Ondrej Jirman
> >
> > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > mostly in features that are not yet supported by this driver.
> >
> > Some differences are already stated in the comments in existing code.
> > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> >
> > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > external low speed oscillator is working correctly.
> >
> > This patch adds support for enabling LOSC when necessary:
> >
> > - during reparenting
> > - when probing the clock
> >
> > H6 also has capacbility to automatically reparent RTC clock from
> > external crystal oscillator, to internal RC oscillator, if external
> > oscillator fails. This is enabled by default. Disable it during
> > probe.
> >
> > Signed-off-by: Ondrej Jirman
> > Reviewed-by: Chen-Yu Tsai
> > ---
> > drivers/rtc/rtc-sun6i.c | 40 ++--
> > 1 file changed, 38 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > index d50ee023b559..b0c3752bed3f 100644
> > --- a/drivers/rtc/rtc-sun6i.c
> > +++ b/drivers/rtc/rtc-sun6i.c
> > @@ -32,9 +32,11 @@
> > /* Control register */
> > #define SUN6I_LOSC_CTRL0x
> > #define SUN6I_LOSC_CTRL_KEY(0x16aa << 16)
> > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASSBIT(15)
>
> User manual says that above field is bit 14.
See the previous discussion, this is from BSP.
regards,
o.
> Best regards,
> Jernej
>
> > #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
> > #define SUN6I_LOSC_CTRL_RTC_HMS_ACCBIT(8)
> > #define SUN6I_LOSC_CTRL_RTC_YMD_ACCBIT(7)
> > +#define SUN6I_LOSC_CTRL_EXT_LOSC_ENBIT(4)
> > #define SUN6I_LOSC_CTRL_EXT_OSCBIT(0)
> > #define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
> >
> > @@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
> > unsigned int has_prescaler : 1;
> > unsigned int has_out_clk : 1;
> > unsigned int export_iosc : 1;
> > + unsigned int has_losc_en : 1;
> > + unsigned int has_auto_swt : 1;
> > };
> >
> > struct sun6i_rtc_dev {
> > @@ -190,6 +194,10 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw *hw,
> > u8 index) val &= ~SUN6I_LOSC_CTRL_EXT_OSC;
> > val |= SUN6I_LOSC_CTRL_KEY;
> > val |= index ? SUN6I_LOSC_CTRL_EXT_OSC : 0;
> > + if (rtc->data->has_losc_en) {
> > + val &= ~SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > + val |= index ? SUN6I_LOSC_CTRL_EXT_LOSC_EN : 0;
> > + }
> > writel(val, rtc->base + SUN6I_LOSC_CTRL);
> > spin_unlock_irqrestore(&rtc->lock, flags);
> >
> > @@ -215,6 +223,7 @@ static void __init sun6i_rtc_clk_init(struct device_node
> > *node, const char *iosc_name = "rtc-int-osc";
> > const char *clkout_name = "osc32k-out";
> > const char *parents[2];
> > + u32 reg;
> >
> > rtc = kzalloc(sizeof(*rtc), GFP_KERNEL);
> > if (!rtc)
> > @@ -235,9 +244,18 @@ static void __init sun6i_rtc_clk_init(struct
> > device_node *node, goto err;
> > }
> >
> > + reg = SUN6I_LOSC_CTRL_KEY;
> > + if (rtc->data->has_auto_swt) {
> > + /* Bypass auto-switch to int osc, on ext losc failure */
> > + reg |= SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS;
> > + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> > + }
> > +
> > /* Switch to the external, more precise, oscillator */
> > - writel(SUN6I_LOSC_CTRL_KEY | SUN6I_LOSC_CTRL_EXT_OSC,
> > - rtc->base + SUN6I_LOSC_CTRL);
> > + reg |= SUN6I_LOSC_CTRL_EXT_OSC;
> > + if (rtc->data->has_losc_en)
> > + reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> >
> > /* Yes, I know, this is ugly. */
> > sun6i_rtc = rtc;
> > @@ -345,6 +363,23 @@ CLK_OF_DECLARE_DRIVER(sun8i_h3_rtc_clk,
> > "allwinner,sun8i-h3-rtc", CLK_OF_DECLARE_DRIVER(sun50i_h5_rtc_clk,
> > "allwinner,sun50i-h5-rtc", sun8i_h3_rtc_clk_init);
> >
> > +static const struct sun6i_rtc_clk_data sun50i_h6_rtc_data = {
> > + .rc_osc_rate = 1600,
> > + .fixed_prescaler = 32,
> > + .has_prescaler = 1,
> > + .has_out_clk = 1,
> > + .export_iosc = 1,
> > + .has_losc_en = 1,
> > + .has_auto_swt = 1,
> > +};
> > +
> > +static void __init sun50i_h6_rtc_clk_init(struct device_node *node)
> > +{
> > + sun6i_rtc_clk_init(node, &sun50i_h6_rtc_data);
> > +}
> > +CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
> > + sun50i_h6_rtc_clk_init);
> > +
> > static const struct sun6i_rtc_clk_data sun8i_v3_rtc_data = {
> > .rc_osc_rate = 32000,
> > .has_out_clk = 1,
> > @@ -675,6 +710,7 @@ static cons
Re: [PATCH 12/16] arm64: prefer __section from compiler_attributes.h
On Sat, Aug 24, 2019 at 1:25 PM Will Deacon wrote: > > Which bit are you pinging about? This patch (12/16) has been in -next for a > while and is queued in the arm64 tree for 5.4. The Oops/boot issue is > addressed in patch 14 which probably needs to be sent as a separate patch > (with a commit message) if it's targetting 5.3 and, I assume, routed via > somebody like akpm. I was pinging about the bit I was quoting, i.e. whether the Oops in the cover letter was #14 indeed. Also, since Nick said he wanted to get this ASAP through compiler-attributes, I assumed he wanted it to be in 5.3, but I have not seen the independent patch. Since he seems busy, I will write a better commit message myself and send it to Linus next week. Cheers, Miguel
Re: [PATCH 14/16] include/linux: prefer __section from compiler_attributes.h
On Tue, Aug 13, 2019 at 10:33 AM Will Deacon wrote: > > -ENOCOMMITMESSAGE > > Otherwise, patch looks good to me. Do you want Ack, Review or nothing? Cheers, Miguel
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a):
> Hi,
>
> On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote:
> > Hi!
> >
> > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com
napisal(a):
> > > From: Ondrej Jirman
> > >
> > > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > > mostly in features that are not yet supported by this driver.
> > >
> > > Some differences are already stated in the comments in existing code.
> > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> > >
> > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > > external low speed oscillator is working correctly.
> > >
> > > This patch adds support for enabling LOSC when necessary:
> > >
> > > - during reparenting
> > > - when probing the clock
> > >
> > > H6 also has capacbility to automatically reparent RTC clock from
> > > external crystal oscillator, to internal RC oscillator, if external
> > > oscillator fails. This is enabled by default. Disable it during
> > > probe.
> > >
> > > Signed-off-by: Ondrej Jirman
> > > Reviewed-by: Chen-Yu Tsai
> > > ---
> > >
> > > drivers/rtc/rtc-sun6i.c | 40 ++--
> > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > > index d50ee023b559..b0c3752bed3f 100644
> > > --- a/drivers/rtc/rtc-sun6i.c
> > > +++ b/drivers/rtc/rtc-sun6i.c
> > > @@ -32,9 +32,11 @@
> > >
> > > /* Control register */
> > > #define SUN6I_LOSC_CTRL 0x
> > > #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> > >
> > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
> >
> > User manual says that above field is bit 14.
>
> See the previous discussion, this is from BSP.
I have two versions of BSP (don't ask me which) which have this set as bit 14
and changing this to 14 actually solves all my problems with LOSC (no more
issues with setting RTC and HDMI-CEC works now - it uses LOSC as parent) on
Tanix TX6 box.
Best regards,
Jernej
>
> regards,
> o.
>
> > Best regards,
> > Jernej
> >
> > > #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
> > > #define SUN6I_LOSC_CTRL_RTC_HMS_ACC BIT(8)
> > > #define SUN6I_LOSC_CTRL_RTC_YMD_ACC BIT(7)
> > >
> > > +#define SUN6I_LOSC_CTRL_EXT_LOSC_EN BIT(4)
> > >
> > > #define SUN6I_LOSC_CTRL_EXT_OSC BIT(0)
> > > #define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
> > >
> > > @@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
> > >
> > > unsigned int has_prescaler : 1;
> > > unsigned int has_out_clk : 1;
> > > unsigned int export_iosc : 1;
> > >
> > > + unsigned int has_losc_en : 1;
> > > + unsigned int has_auto_swt : 1;
> > >
> > > };
> > >
> > > struct sun6i_rtc_dev {
> > >
> > > @@ -190,6 +194,10 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw
> > > *hw,
> > > u8 index) val &= ~SUN6I_LOSC_CTRL_EXT_OSC;
> > >
> > > val |= SUN6I_LOSC_CTRL_KEY;
> > > val |= index ? SUN6I_LOSC_CTRL_EXT_OSC : 0;
> > >
> > > + if (rtc->data->has_losc_en) {
> > > + val &= ~SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > > + val |= index ? SUN6I_LOSC_CTRL_EXT_LOSC_EN : 0;
> > > + }
> > >
> > > writel(val, rtc->base + SUN6I_LOSC_CTRL);
> > > spin_unlock_irqrestore(&rtc->lock, flags);
> > >
> > > @@ -215,6 +223,7 @@ static void __init sun6i_rtc_clk_init(struct
> > > device_node *node, const char *iosc_name = "rtc-int-osc";
> > >
> > > const char *clkout_name = "osc32k-out";
> > > const char *parents[2];
> > >
> > > + u32 reg;
> > >
> > > rtc = kzalloc(sizeof(*rtc), GFP_KERNEL);
> > > if (!rtc)
> > >
> > > @@ -235,9 +244,18 @@ static void __init sun6i_rtc_clk_init(struct
> > > device_node *node, goto err;
> > >
> > > }
> > >
> > > + reg = SUN6I_LOSC_CTRL_KEY;
> > > + if (rtc->data->has_auto_swt) {
> > > + /* Bypass auto-switch to int osc, on ext losc failure
*/
> > > + reg |= SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS;
> > > + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> > > + }
> > > +
> > >
> > > /* Switch to the external, more precise, oscillator */
> > >
> > > - writel(SUN6I_LOSC_CTRL_KEY | SUN6I_LOSC_CTRL_EXT_OSC,
> > > -rtc->base + SUN6I_LOSC_CTRL);
> > > + reg |= SUN6I_LOSC_CTRL_EXT_OSC;
> > > + if (rtc->data->has_losc_en)
> > > + reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > > + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> > >
> > > /* Yes, I know, this is ugly. */
> > > sun6i_rtc = rtc;
> > >
> > > @@ -345,6 +363,23 @@ CLK_OF_DECLARE_DRIVER(sun8i_h3_rtc_clk,
> > > "allwinner,sun8i-h3-rtc", CLK_OF_DECLARE_DRIVER(sun50i_h5_rtc_clk,
> > > "allwinner,sun50i-h5-rtc", sun8i_h3_rtc_clk_init);
> > >
> > > +static const struct sun6i_rtc_clk_data sun50i_h6_rtc_data = {
> > > +
Re: [PATCH 2/2] uacce: add uacce module
On 2019/8/20 下午10:33, Greg Kroah-Hartman wrote:
On Tue, Aug 20, 2019 at 08:36:50PM +0800, zhangfei wrote:
Hi, Greg
On 2019/8/19 下午6:24, Greg Kroah-Hartman wrote:
+static int uacce_create_chrdev(struct uacce *uacce)
+{
+ int ret;
+
+ ret = idr_alloc(&uacce_idr, uacce, 0, 0, GFP_KERNEL);
+ if (ret < 0)
+ return ret;
+
Shouldn't this function create the memory needed for this structure?
You are relying ont he caller to do it for you, why?
I think you mean uacce structure here.
Yes, currently we count on caller to prepare uacce structure and call
uacce_register(uacce).
We still think this method is simpler, prepare uacce, register uacce.
And there are other system using the same method, like crypto
(crypto_register_acomp), nand, etc.
crypto is not a subsystem to ever try to emulate :)
You are creating a structure with a lifetime that you control, don't
have someone else create your memory, that's almost never what you want
to do. Most all driver subsystems create their own memory chunks for
what they need to do, it's a much better pattern.
Especially when you get into pointer lifetime issues...
OK, understand now, thanks for your patience.
will use this instead.
struct uacce_interface {
char name[32];
unsigned int flags;
struct uacce_ops *ops;
};
struct uacce *uacce_register(struct device *dev, struct uacce_interface
*interface);
What? Why do you need a structure? A pointer to the name and the ops
should be all that is needed, right?
We are thinking transfer structure will be more flexible.
And modify api later would be difficult, requiring many drivers modify
together.
Currently parameters need a flag, a pointer to the name, and ops, but in
case more requirement from future drivers usage.
Also refer usb_register_dev, sdhci_pltfm_init etc, and the structure
para can be set as static.
And 'dev' here is a pointer to the parent, right? Might want to make
that explicit in the name of the variable :)
Yes, 'dev' is parent, will change to 'pdev', thanks.
+
+static int uacce_dev_match(struct device *dev, void *data)
+{
+ if (dev->parent == data)
+ return -EBUSY;
There should be in-kernel functions for this now, no need for you to
roll your own.
Sorry, do not find this function.
Only find class_find_device, which still require match.
It is in linux-next, look there...
Suppose you mean the funcs: device_match_name,
device_match_of_node,device_match_devt etc.
Here we need dev->parent, there still no such func.
You should NEVER be matching on a parent. If so, your use of the driver
model is wrong :)
Remind me to really review the use of the driver core code in your next
submission of this series please, I think it needs it.
OK, thanks Greg.
Re: [linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC
Hi, On Sat, Aug 24, 2019 at 10:06:14AM +0200, Jernej Škrabec wrote: > Dne sobota, 24. avgust 2019 ob 10:04:24 CEST je Jernej Škrabec napisal(a): > > Hi! > > > > Dne torek, 20. avgust 2019 ob 17:19:31 CEST je meg...@megous.com napisal(a): > > > From: Ondrej Jirman > > > > > > I went through the datasheets for H6 and H5, and compared the differences. > > > RTCs are largely similar, but not entirely compatible. Incompatibilities > > > are in details not yet implemented by the rtc driver though. > > > > > > I also corrected the clock tree in H6 DTSI. > > > > > > This patchset is necessary for implementing the WiFi/Bluetooth support > > > on boards using H6 SoC. > > > > > > There was some discussion previously of describing HOSC, DCXO and XO > > > oscillators and clocks as part of RTC in DT, but I decided against it > > > because it's not necessary, becuse information that would be provided > > > as a part of DT can already be determined at runtime from RTC registers, > > > so this woudn't add any value and would only introduce complications > > > to the driver. See: https://patchwork.kernel.org/cover/10898083/ > > > > > > Please take a look. > > > > > > > > > Thank you and regards, > > > > > > Ondrej Jirman > > > > Sorry for a bit late test, but with your patches on Tanix TX6 box I get this > > in dmesg: > > > > [ 17.431742] sun6i-rtc 700.rtc: Failed to set rtc time. > > [ 20.439742] sun6i-rtc 700.rtc: rtc is still busy. > > [ 21.435744] sun6i-rtc 700.rtc: rtc is still busy. > > [ 24.055741] sun6i-rtc 700.rtc: rtc is still busy. > > [ 24.439752] sun6i-rtc 700.rtc: rtc is still busy. > > > > Last line is repeated non-stop. > > > > Any idea what could be wrong? > > Additional info - this is on kernel 5.2.6 with your patches applied. Do you have schematics, or a FEX file for the board or any other info on how the RTC is set up on that board? Can you dump the RTC register range? regards, o. > Best regards, > Jernej > > > > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC
Dne sobota, 24. avgust 2019 ob 14:56:12 CEST je Ondřej Jirman napisal(a): > Hi, > > On Sat, Aug 24, 2019 at 10:06:14AM +0200, Jernej Škrabec wrote: > > Dne sobota, 24. avgust 2019 ob 10:04:24 CEST je Jernej Škrabec napisal(a): > > > Hi! > > > > > > Dne torek, 20. avgust 2019 ob 17:19:31 CEST je meg...@megous.com napisal(a): > > > > From: Ondrej Jirman > > > > > > > > I went through the datasheets for H6 and H5, and compared the > > > > differences. > > > > RTCs are largely similar, but not entirely compatible. > > > > Incompatibilities > > > > are in details not yet implemented by the rtc driver though. > > > > > > > > I also corrected the clock tree in H6 DTSI. > > > > > > > > This patchset is necessary for implementing the WiFi/Bluetooth support > > > > on boards using H6 SoC. > > > > > > > > There was some discussion previously of describing HOSC, DCXO and XO > > > > oscillators and clocks as part of RTC in DT, but I decided against it > > > > because it's not necessary, becuse information that would be provided > > > > as a part of DT can already be determined at runtime from RTC > > > > registers, > > > > so this woudn't add any value and would only introduce complications > > > > to the driver. See: https://patchwork.kernel.org/cover/10898083/ > > > > > > > > Please take a look. > > > > > > > > > > > > Thank you and regards, > > > > > > > > Ondrej Jirman > > > > > > Sorry for a bit late test, but with your patches on Tanix TX6 box I get > > > this in dmesg: > > > > > > [ 17.431742] sun6i-rtc 700.rtc: Failed to set rtc time. > > > [ 20.439742] sun6i-rtc 700.rtc: rtc is still busy. > > > [ 21.435744] sun6i-rtc 700.rtc: rtc is still busy. > > > [ 24.055741] sun6i-rtc 700.rtc: rtc is still busy. > > > [ 24.439752] sun6i-rtc 700.rtc: rtc is still busy. > > > > > > Last line is repeated non-stop. > > > > > > Any idea what could be wrong? > > > > Additional info - this is on kernel 5.2.6 with your patches applied. > > Do you have schematics, or a FEX file for the board or any other info on how > the RTC is set up on that board? > > Can you dump the RTC register range? I have only Android DT, but as I already said in latest reply to patch 2, changing switch bypass to bit 14 instead of 15 solved all issues. Best regards, Jernej > > regards, > o. > > > Best regards, > > Jernej > > > > > > > > > > > > ___ > > linux-arm-kernel mailing list > > linux-arm-ker...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
On Sat, Aug 24, 2019 at 02:51:54PM +0200, Jernej Škrabec wrote:
> Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a):
> > Hi,
> >
> > On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote:
> > > Hi!
> > >
> > > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com
> napisal(a):
> > > > From: Ondrej Jirman
> > > >
> > > > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > > > mostly in features that are not yet supported by this driver.
> > > >
> > > > Some differences are already stated in the comments in existing code.
> > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> > > >
> > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > > > external low speed oscillator is working correctly.
> > > >
> > > > This patch adds support for enabling LOSC when necessary:
> > > >
> > > > - during reparenting
> > > > - when probing the clock
> > > >
> > > > H6 also has capacbility to automatically reparent RTC clock from
> > > > external crystal oscillator, to internal RC oscillator, if external
> > > > oscillator fails. This is enabled by default. Disable it during
> > > > probe.
> > > >
> > > > Signed-off-by: Ondrej Jirman
> > > > Reviewed-by: Chen-Yu Tsai
> > > > ---
> > > >
> > > > drivers/rtc/rtc-sun6i.c | 40 ++--
> > > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > > > index d50ee023b559..b0c3752bed3f 100644
> > > > --- a/drivers/rtc/rtc-sun6i.c
> > > > +++ b/drivers/rtc/rtc-sun6i.c
> > > > @@ -32,9 +32,11 @@
> > > >
> > > > /* Control register */
> > > > #define SUN6I_LOSC_CTRL0x
> > > > #define SUN6I_LOSC_CTRL_KEY(0x16aa << 16)
> > > >
> > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASSBIT(15)
> > >
> > > User manual says that above field is bit 14.
> >
> > See the previous discussion, this is from BSP.
>
> I have two versions of BSP (don't ask me which) which have this set as bit 14
> and changing this to 14 actually solves all my problems with LOSC (no more
> issues with setting RTC and HDMI-CEC works now - it uses LOSC as parent) on
> Tanix TX6 box.
Interesting. Is LOSC fed externally generated clock, or is it setup as a crystal
oscillator on your board?
Anyway, see here:
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.h?h=h6-4.9-bsp#n649
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n652
It would be nice to know what's really happening.
My output is:
[0.832252] sun6i-rtc 700.rtc: registered as rtc0
[0.832257] sun6i-rtc 700.rtc: RTC enabled
[1.728968] sun6i-rtc 700.rtc: setting system clock to
1970-01-01T00:00:07 UTC (7)
I think, you may have just enabled the auto switch feature, and running the
clock from low precision RC oscillator with your patch.
The real issue probably is that the mainline driver is missing this:
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n650
regards,
o.
> Best regards,
> Jernej
>
> >
> > regards,
> > o.
> >
> > > Best regards,
> > > Jernej
> > >
> > > > #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
> > > > #define SUN6I_LOSC_CTRL_RTC_HMS_ACCBIT(8)
> > > > #define SUN6I_LOSC_CTRL_RTC_YMD_ACCBIT(7)
> > > >
> > > > +#define SUN6I_LOSC_CTRL_EXT_LOSC_ENBIT(4)
> > > >
> > > > #define SUN6I_LOSC_CTRL_EXT_OSCBIT(0)
> > > > #define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
> > > >
> > > > @@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
> > > >
> > > > unsigned int has_prescaler : 1;
> > > > unsigned int has_out_clk : 1;
> > > > unsigned int export_iosc : 1;
> > > >
> > > > + unsigned int has_losc_en : 1;
> > > > + unsigned int has_auto_swt : 1;
> > > >
> > > > };
> > > >
> > > > struct sun6i_rtc_dev {
> > > >
> > > > @@ -190,6 +194,10 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw
> > > > *hw,
> > > > u8 index) val &= ~SUN6I_LOSC_CTRL_EXT_OSC;
> > > >
> > > > val |= SUN6I_LOSC_CTRL_KEY;
> > > > val |= index ? SUN6I_LOSC_CTRL_EXT_OSC : 0;
> > > >
> > > > + if (rtc->data->has_losc_en) {
> > > > + val &= ~SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > > > + val |= index ? SUN6I_LOSC_CTRL_EXT_LOSC_EN : 0;
> > > > + }
> > > >
> > > > writel(val, rtc->base + SUN6I_LOSC_CTRL);
> > > > spin_unlock_irqrestore(&rtc->lock, flags);
> > > >
> > > > @@ -215,6 +223,7 @@ static void __init sun6i_rtc_clk_init(struct
> > > > device_node *node, const char *iosc_name = "rtc-int-osc";
> > > >
> > > > const char *clkout_name = "osc32k-out";
> > > > const char *parents[2];
> > > >
[PATCH] kallsyms: Don't let kallsyms_lookup_size_offset() fail on retrieving the first symbol
An arm64 kernel configured with
CONFIG_KPROBES=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_BASE_RELATIVE=y
reports the following kprobe failure:
[0.032677] kprobes: failed to populate blacklist: -22
[0.033376] Please take care of using kprobes.
It appears that kprobe fails to retrieve the symbol at address
0x10081000, despite this symbol being in System.map:
10081000 T __exception_text_start
This symbol is part of the first group of aliases in the
kallsyms_offsets array (symbol names generated using ugly hacks in
scripts/kallsyms.c):
kallsyms_offsets:
.long 0x1000 // do_undefinstr
.long 0x1000 // efi_header_end
.long 0x1000 // _stext
.long 0x1000 // __exception_text_start
.long 0x12b0 // do_cp15instr
Looking at the implementation of get_symbol_pos(), it returns the
lowest index for aliasing symbols. In this case, it return 0.
But kallsyms_lookup_size_offset() considers 0 as a failure, which
is obviously wrong (there is definitely a valid symbol living there).
In turn, the kprobe blacklisting stops abruptly, hence the original
error.
A CONFIG_KALLSYMS_ALL kernel wouldn't fail as there is always
some random symbols at the beginning of this array, which are never
looked up via kallsyms_lookup_size_offset.
Fix it by considering that get_symbol_pos() is always successful
(which is consistent with the other uses of this function).
Fixes: ffc5089196446 ("[PATCH] Create kallsyms_lookup_size_offset()")
Cc: Masami Hiramatsu
Cc: Arnaldo Carvalho de Melo
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Catalin Marinas
Signed-off-by: Marc Zyngier
---
kernel/kallsyms.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 95a260f9214b..136ce049c4ad 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -263,8 +263,10 @@ int kallsyms_lookup_size_offset(unsigned long addr,
unsigned long *symbolsize,
{
char namebuf[KSYM_NAME_LEN];
- if (is_ksym_addr(addr))
- return !!get_symbol_pos(addr, symbolsize, offset);
+ if (is_ksym_addr(addr)) {
+ get_symbol_pos(addr, symbolsize, offset);
+ return 1;
+ }
return !!module_address_lookup(addr, symbolsize, offset, NULL, namebuf)
||
!!__bpf_address_lookup(addr, symbolsize, offset, namebuf);
}
--
2.20.1
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Dne sobota, 24. avgust 2019 ob 15:05:44 CEST je Ondřej Jirman napisal(a):
> On Sat, Aug 24, 2019 at 02:51:54PM +0200, Jernej Škrabec wrote:
> > Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a):
> > > Hi,
> > >
> > > On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote:
> > > > Hi!
> > > >
> > > > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com
> >
> > napisal(a):
> > > > > From: Ondrej Jirman
> > > > >
> > > > > RTC on H6 is mostly the same as on H5 and H3. It has slight
> > > > > differences
> > > > > mostly in features that are not yet supported by this driver.
> > > > >
> > > > > Some differences are already stated in the comments in existing
> > > > > code.
> > > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG,
> > > > > called
> > > > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> > > > >
> > > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check
> > > > > whether
> > > > > external low speed oscillator is working correctly.
> > > > >
> > > > > This patch adds support for enabling LOSC when necessary:
> > > > >
> > > > > - during reparenting
> > > > > - when probing the clock
> > > > >
> > > > > H6 also has capacbility to automatically reparent RTC clock from
> > > > > external crystal oscillator, to internal RC oscillator, if external
> > > > > oscillator fails. This is enabled by default. Disable it during
> > > > > probe.
> > > > >
> > > > > Signed-off-by: Ondrej Jirman
> > > > > Reviewed-by: Chen-Yu Tsai
> > > > > ---
> > > > >
> > > > > drivers/rtc/rtc-sun6i.c | 40
> > > > > ++--
> > > > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > > > > index d50ee023b559..b0c3752bed3f 100644
> > > > > --- a/drivers/rtc/rtc-sun6i.c
> > > > > +++ b/drivers/rtc/rtc-sun6i.c
> > > > > @@ -32,9 +32,11 @@
> > > > >
> > > > > /* Control register */
> > > > > #define SUN6I_LOSC_CTRL 0x
> > > > > #define SUN6I_LOSC_CTRL_KEY (0x16aa
<< 16)
> > > > >
> > > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
> > > >
> > > > User manual says that above field is bit 14.
> > >
> > > See the previous discussion, this is from BSP.
> >
> > I have two versions of BSP (don't ask me which) which have this set as bit
> > 14 and changing this to 14 actually solves all my problems with LOSC (no
> > more issues with setting RTC and HDMI-CEC works now - it uses LOSC as
> > parent) on Tanix TX6 box.
>
> Interesting. Is LOSC fed externally generated clock, or is it setup as a
> crystal oscillator on your board?
I really don't know, but here is DT: http://ix.io/1ThI
>
> Anyway, see here:
>
> https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.h?h=h6-4.9-bsp#n649
> https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n652
Interesting, 4.9 BSP has additional bit definition, which is not documented in
manual and 3.10 BSP to which I refer.
I was referring to 3.10 BSP, which uses only bit 14. I thought that you named
it differently.
>
> It would be nice to know what's really happening.
>
> My output is:
>
> [0.832252] sun6i-rtc 700.rtc: registered as rtc0
> [0.832257] sun6i-rtc 700.rtc: RTC enabled
> [1.728968] sun6i-rtc 700.rtc: setting system clock to
> 1970-01-01T00:00:07 UTC (7)
With change, I get same output.
>
> I think, you may have just enabled the auto switch feature, and running the
> clock from low precision RC oscillator with your patch.
True, now I think there is no external crystal, but I'm still not sure how to
confirm that.
>
> The real issue probably is that the mainline driver is missing this:
>
> https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n650
>
Not sure what you mean by that. ext vs. int source selection?
Best regards,
Jernej
> regards,
> o.
>
> > Best regards,
> > Jernej
> >
> > > regards,
> > >
> > > o.
> > >
> > > > Best regards,
> > > > Jernej
> > > >
> > > > > #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
> > > > > #define SUN6I_LOSC_CTRL_RTC_HMS_ACC BIT(8)
> > > > > #define SUN6I_LOSC_CTRL_RTC_YMD_ACC BIT(7)
> > > > >
> > > > > +#define SUN6I_LOSC_CTRL_EXT_LOSC_EN BIT(4)
> > > > >
> > > > > #define SUN6I_LOSC_CTRL_EXT_OSC BIT(0)
> > > > > #define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
> > > > >
> > > > > @@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
> > > > >
> > > > > unsigned int has_prescaler : 1;
> > > > > unsigned int has_out_clk : 1;
> > > > > unsigned int export_iosc : 1;
> > > > >
> > > > > + unsigned int has_losc_en : 1;
> > > > > + unsigned int has_auto_swt : 1;
> > > > >
> > > > > };
> > > > >
> > > > > struct sun6i_rtc_dev {
> > > > >
> > > > > @@ -190,6 +194,10 @
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
On Sat, Aug 24, 2019 at 03:16:41PM +0200, Jernej Škrabec wrote: > Dne sobota, 24. avgust 2019 ob 15:05:44 CEST je Ondřej Jirman napisal(a): > > On Sat, Aug 24, 2019 at 02:51:54PM +0200, Jernej Škrabec wrote: > > > Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a): > > > > Hi, > > > > > > > > On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote: > > > > > Hi! > > > > > > > > > > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com > > > > > > napisal(a): > > > > > > From: Ondrej Jirman > > > > > > > > > > > > RTC on H6 is mostly the same as on H5 and H3. It has slight > > > > > > differences > > > > > > mostly in features that are not yet supported by this driver. > > > > > > > > > > > > Some differences are already stated in the comments in existing > > > > > > code. > > > > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, > > > > > > called > > > > > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator. > > > > > > > > > > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check > > > > > > whether > > > > > > external low speed oscillator is working correctly. > > > > > > > > > > > > This patch adds support for enabling LOSC when necessary: > > > > > > > > > > > > - during reparenting > > > > > > - when probing the clock > > > > > > > > > > > > H6 also has capacbility to automatically reparent RTC clock from > > > > > > external crystal oscillator, to internal RC oscillator, if external > > > > > > oscillator fails. This is enabled by default. Disable it during > > > > > > probe. > > > > > > > > > > > > Signed-off-by: Ondrej Jirman > > > > > > Reviewed-by: Chen-Yu Tsai > > > > > > --- > > > > > > > > > > > > drivers/rtc/rtc-sun6i.c | 40 > > > > > > ++-- > > > > > > 1 file changed, 38 insertions(+), 2 deletions(-) > > > > > > > > > > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c > > > > > > index d50ee023b559..b0c3752bed3f 100644 > > > > > > --- a/drivers/rtc/rtc-sun6i.c > > > > > > +++ b/drivers/rtc/rtc-sun6i.c > > > > > > @@ -32,9 +32,11 @@ > > > > > > > > > > > > /* Control register */ > > > > > > #define SUN6I_LOSC_CTRL0x > > > > > > #define SUN6I_LOSC_CTRL_KEY(0x16aa > << 16) > > > > > > > > > > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASSBIT(15) > > > > > > > > > > User manual says that above field is bit 14. > > > > > > > > See the previous discussion, this is from BSP. > > > > > > I have two versions of BSP (don't ask me which) which have this set as bit > > > 14 and changing this to 14 actually solves all my problems with LOSC (no > > > more issues with setting RTC and HDMI-CEC works now - it uses LOSC as > > > parent) on Tanix TX6 box. > > > > Interesting. Is LOSC fed externally generated clock, or is it setup as a > > crystal oscillator on your board? > > I really don't know, but here is DT: http://ix.io/1ThI > > > > > Anyway, see here: > > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.h?h=h6-4.9-bsp#n649 > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n652 > > Interesting, 4.9 BSP has additional bit definition, which is not documented > in > manual and 3.10 BSP to which I refer. > > I was referring to 3.10 BSP, which uses only bit 14. I thought that you named > it differently. > > > > > It would be nice to know what's really happening. > > > > My output is: > > > > [0.832252] sun6i-rtc 700.rtc: registered as rtc0 > > [0.832257] sun6i-rtc 700.rtc: RTC enabled > > [1.728968] sun6i-rtc 700.rtc: setting system clock to > > 1970-01-01T00:00:07 UTC (7) > > With change, I get same output. > > > > > I think, you may have just enabled the auto switch feature, and running the > > clock from low precision RC oscillator with your patch. > > True, now I think there is no external crystal, but I'm still not sure how to > confirm that. Visually? That would explain why it doesn't work for you. The mainline RTC driver disables auto-switch feature, and if your board doesn't have a crystal for LOSC, RTC will not generate a clock for the RTC. H6's dtsi describes by default a situatiuon with external 32k crystal oscillator. See ext_osc32k node. That's incorrect for your board if it doesn't have the crystal. You need to fix this in the DTS for your board instead of patching the driver. The driver has parent clock selection logic in case the LOSC crystal is not used. Your patch enables automatic detection of LOSC failure and RTC changes clock to LOSC automatically, despite what's described in the DTS. That may fix the issue, but is not the correct solution. Registers on my board look like this (external 32k osc is used) for reference: LOSC_CTRL_REG[700]: 8011 KEY_FIELD ??? (0) LOSC_AUTO_SWT_BYPASS EN (1
Re: [PATCH] mips: avoid explicit UB in assignment of mips_io_port_base
Hi Nick, On Fri, Aug 23, 2019 at 10:16:04AM -0700, Nick Desaulniers wrote: > On Tue, Aug 20, 2019 at 10:15 AM Nick Desaulniers > wrote: > > Hi Paul, > > Bumping this thread; we'd really like to be able to boot test another > > ISA in our CI. This lone patch is affecting our ability to boot. Can > > you please pick it up? > > https://lore.kernel.org/lkml/20190729211014.39333-1-ndesaulni...@google.com/ > > Hi Paul, > Following up with this link that explains the undefined behavior issue more: > https://wiki.sei.cmu.edu/confluence/display/c/EXP05-C.+Do+not+cast+away+a+const+qualification > Please reconsider accepting this patch. Sorry, it's been a crazy few months & I'm currently away awaiting my father's funeral so I'm working through a backlog & catching up on things. It will be a shame to lose the optimization opportunities const offers us, but it is an ugly hack & so I'm OK with applying this. It's likely to affect older machines more than newer ones (which tend to use less or no I/O port access) so I'm not too worried about the impact, but if we find it matters we can always try the fixmap approach I suggested previously. Thanks, Paul
Re: [PATCH] mips: avoid explicit UB in assignment of mips_io_port_base
Hello,
Nick Desaulniers wrote:
> The code in question is modifying a variable declared const through
> pointer manipulation. Such code is explicitly undefined behavior, and
> is the lone issue preventing malta_defconfig from booting when built
> with Clang:
>
> If an attempt is made to modify an object defined with a const-qualified
> type through use of an lvalue with non-const-qualified type, the
> behavior is undefined.
>
> LLVM is removing such assignments. A simple fix is to not declare
> variables const that you plan on modifying. Limiting the scope would be
> a better method of preventing unwanted writes to such a variable.
>
> Further, the code in question mentions "compiler bugs" without any links
> to bug reports, so it is difficult to know if the issue is resolved in
> GCC. The patch was authored in 2006, which would have been GCC 4.0.3 or
> 4.1.1. The minimal supported version of GCC in the Linux kernel is
> currently 4.6.
>
> For what its worth, there was UB before the commit in question, it just
> added a barrier and got lucky IRT codegen. I don't think there's any
> actual compiler bugs related, just runtime bugs due to UB.
>
> Fixes: 966f4406d903 ("[MIPS] Work around bad code generation for .")
Applied to mips-next.
> commit 12051b318bc3
> https://git.kernel.org/mips/c/12051b318bc3
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/610
> Fixes: 966f4406d903 ("[MIPS] Work around bad code generation for .")
> Reported-by: Nathan Chancellor
> Debugged-by: Nathan Chancellor
> Suggested-by: Eli Friedman
> Signed-off-by: Nick Desaulniers
> Reviewed-by: Nathan Chancellor
> Tested-by: Nathan Chancellor
> Signed-off-by: Paul Burton
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.bur...@mips.com to report it. ]
Re: [PATCH v3 4/4] MIPS: lantiq: update the clock alias' for the mainline PCIe PHY driver
Hello, Martin Blumenstingl wrote: > The mainline PCIe PHY driver has it's own devicetree node. Update the > clock alias so the mainline driver finds the clocks. > > The first PCIe PHY is located at 0x1f106800 and exists on VRX200, ARX300 > and GRX390. > The second PCIe PHY is located at 0x1f700400 and exists on ARX300 and > GRX390. > The third PCIe PHY is located at 0x1f106a00 and exists onl on GRX390. > Lantiq's board support package (called "UGW") names these registers > "PDI". Applied to mips-next. > commit ed90302be64a > https://git.kernel.org/mips/c/ed90302be64a > > Signed-off-by: Martin Blumenstingl > Signed-off-by: Paul Burton Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.bur...@mips.com to report it. ]
Re: [PATCH] mtd: hyperbus: fix dependency and build error
Hi Miquel,
On 24-Aug-19 4:18 PM, Miquel Raynal wrote:
> Hi Vignesh,
>
> Randy Dunlap wrote on Tue, 13 Aug 2019 16:03:13
> -0700:
>
>> From: Randy Dunlap
>>
>> lib/devres.c, which implements devm_ioremap_resource(), is only built
>> when CONFIG_HAS_IOMEM is set/enabled, so MTD_HYPERBUS should depend
>> on HAS_IOMEM. Fixes a build error and a Kconfig warning (as seen on
>> UML builds):
>>
>> WARNING: unmet direct dependencies detected for MTD_COMPLEX_MAPPINGS
>> Depends on [n]: MTD [=m] && HAS_IOMEM [=n]
>> Selected by [m]:
>> - MTD_HYPERBUS [=m] && MTD [=m]
>>
>> ERROR: "devm_ioremap_resource" [drivers/mtd/hyperbus/hyperbus-core.ko]
>> undefined!
>>
>> Fixes: dcc7d3446a0f ("mtd: Add support for HyperBus memory devices")
>> Signed-off-by: Randy Dunlap
>> Cc: Vignesh Raghavendra
>> Cc: Miquel Raynal
>> Cc: Geert Uytterhoeven
>> Cc: linux-...@lists.infradead.org
>> ---
>
> This patch looks like a good candidate for fixes, shall I send a fixes
> PR next week with it? (Acked-by wished)
>
Yes, that would be great. I was about to send across patch bundle myself.
Acked-by: Vignesh Raghavendra
Thanks
Vignesh
Re: [PATCH] igb/igc: Don't warn on fatal read failures when the device is removed
On 8/22/2019 21:33, Lyude Paul wrote:
Fatal read errors are worth warning about, unless of course the device
was just unplugged from the machine - something that's a rather normal
occurence when the igb/igc adapter is located on a Thunderbolt dock. So,
let's only WARN() if there's a fatal read error while the device is
still present.
This fixes the following WARN splat that's been appearing whenever I
unplug my Caldigit TS3 Thunderbolt dock from my laptop:
igb :09:00.0 enp9s0: PCIe link lost
[ cut here ]
igb: Failed to read reg 0x18!
WARNING: CPU: 7 PID: 516 at
drivers/net/ethernet/intel/igb/igb_main.c:756 igb_rd32+0x57/0x6a [igb]
Modules linked in: igb dca thunderbolt fuse vfat fat elan_i2c mei_wdt
mei_hdcp i915 wmi_bmof intel_wmi_thunderbolt iTCO_wdt
iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp joydev
coretemp crct10dif_pclmul crc32_pclmul i2c_algo_bit ghash_clmulni_intel
intel_cstate drm_kms_helper intel_uncore syscopyarea sysfillrect
sysimgblt fb_sys_fops intel_rapl_perf intel_xhci_usb_role_switch mei_me
drm roles idma64 i2c_i801 ucsi_acpi typec_ucsi mei intel_lpss_pci
processor_thermal_device typec intel_pch_thermal intel_soc_dts_iosf
intel_lpss int3403_thermal thinkpad_acpi wmi int340x_thermal_zone
ledtrig_audio int3400_thermal acpi_thermal_rel acpi_pad video
pcc_cpufreq ip_tables serio_raw nvme nvme_core crc32c_intel uas
usb_storage e1000e i2c_dev
CPU: 7 PID: 516 Comm: kworker/u16:3 Not tainted 5.2.0-rc1Lyude-Test+ #14
Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018
Workqueue: kacpi_hotplug acpi_hotplug_work_fn
RIP: 0010:igb_rd32+0x57/0x6a [igb]
Code: 87 b8 fc ff ff 48 c7 47 08 00 00 00 00 48 c7 c6 33 42 9b c0 4c 89
c7 e8 47 45 cd dc 89 ee 48 c7 c7 43 42 9b c0 e8 c1 94 71 dc <0f> 0b eb
08 8b 00 ff c0 75 b0 eb c8 44 89 e0 5d 41 5c c3 0f 1f 44
RSP: 0018:ba5801cf7c48 EFLAGS: 00010286
RAX: RBX: 9e7956608840 RCX: 0007
RDX: RSI: ba5801cf7b24 RDI: 9e795e3d6a00
RBP: 0018 R08: 9dec4a01 R09: 9e61018f
R10: R11: ba5801cf7ae5 R12:
R13: 9e7956608840 R14: 9e795a6f10b0 R15:
FS: () GS:9e795e3c() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 564317bc4088 CR3: 00010e00a006 CR4: 003606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
igb_release_hw_control+0x1a/0x30 [igb]
igb_remove+0xc5/0x14b [igb]
pci_device_remove+0x3b/0x93
device_release_driver_internal+0xd7/0x17e
pci_stop_bus_device+0x36/0x75
pci_stop_bus_device+0x66/0x75
pci_stop_bus_device+0x66/0x75
pci_stop_and_remove_bus_device+0xf/0x19
trim_stale_devices+0xc5/0x13a
? __pm_runtime_resume+0x6e/0x7b
trim_stale_devices+0x103/0x13a
? __pm_runtime_resume+0x6e/0x7b
trim_stale_devices+0x103/0x13a
acpiphp_check_bridge+0xd8/0xf5
acpiphp_hotplug_notify+0xf7/0x14b
? acpiphp_check_bridge+0xf5/0xf5
acpi_device_hotplug+0x357/0x3b5
acpi_hotplug_work_fn+0x1a/0x23
process_one_work+0x1a7/0x296
worker_thread+0x1a8/0x24c
? process_scheduled_works+0x2c/0x2c
kthread+0xe9/0xee
? kthread_destroy_worker+0x41/0x41
ret_from_fork+0x35/0x40
---[ end trace 252bf10352c63d22 ]---
Signed-off-by: Lyude Paul
Fixes: 47e16692b26b ("igb/igc: warn when fatal read failure happens")
Cc: Feng Tang
Cc: Sasha Neftin
Cc: Jeff Kirsher
Cc: intel-wired-...@lists.osuosl.org
---
drivers/net/ethernet/intel/igb/igb_main.c | 3 ++-
drivers/net/ethernet/intel/igc/igc_main.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index e5b7e638df28..1a7f7cd28df9 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -753,7 +753,8 @@ u32 igb_rd32(struct e1000_hw *hw, u32 reg)
struct net_device *netdev = igb->netdev;
hw->hw_addr = NULL;
netdev_err(netdev, "PCIe link lost\n");
- WARN(1, "igb: Failed to read reg 0x%x!\n", reg);
+ WARN(pci_device_is_present(igb->pdev),
+"igb: Failed to read reg 0x%x!\n", reg);
}
return value;
diff --git a/drivers/net/ethernet/intel/igc/igc_main.c
b/drivers/net/ethernet/intel/igc/igc_main.c
index 28072b9aa932..f873a4b35eaf 100644
--- a/drivers/net/ethernet/intel/igc/igc_main.c
+++ b/drivers/net/ethernet/intel/igc/igc_main.c
@@ -3934,7 +3934,8 @@ u32 igc_rd32(struct igc_hw *hw, u32 reg)
hw->hw_addr = NULL;
netif_device_detach(netdev);
netdev_err(netdev, "PCIe link lost,
[PATCH] scsi: aic7xxx: Remove dead code
These are dead code since 2.6.13. If there is no plan
to use it further, these can be removed forever.
Signed-off-by: Souptick Joarder
---
drivers/scsi/aic7xxx/aic7xxx_osm.c | 68 --
1 file changed, 68 deletions(-)
diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm.c
b/drivers/scsi/aic7xxx/aic7xxx_osm.c
index d5c4a0d..98d2e14 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_osm.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_osm.c
@@ -2445,68 +2445,6 @@ static void ahc_linux_set_dt(struct scsi_target
*starget, int dt)
ahc_unlock(ahc, &flags);
}
-#if 0
-/* FIXME: This code claims to support IU and QAS. However, the actual
- * sequencer code and aic7xxx_core have no support for these parameters and
- * will get into a bad state if they're negotiated. Do not enable this
- * unless you know what you're doing */
-static void ahc_linux_set_qas(struct scsi_target *starget, int qas)
-{
- struct Scsi_Host *shost = dev_to_shost(starget->dev.parent);
- struct ahc_softc *ahc = *((struct ahc_softc **)shost->hostdata);
- struct ahc_tmode_tstate *tstate;
- struct ahc_initiator_tinfo *tinfo
- = ahc_fetch_transinfo(ahc,
- starget->channel + 'A',
- shost->this_id, starget->id, &tstate);
- struct ahc_devinfo devinfo;
- unsigned int ppr_options = tinfo->goal.ppr_options
- & ~MSG_EXT_PPR_QAS_REQ;
- unsigned int period = tinfo->goal.period;
- unsigned long flags;
- struct ahc_syncrate *syncrate;
-
- if (qas)
- ppr_options |= MSG_EXT_PPR_QAS_REQ;
-
- ahc_compile_devinfo(&devinfo, shost->this_id, starget->id, 0,
- starget->channel + 'A', ROLE_INITIATOR);
- syncrate = ahc_find_syncrate(ahc, &period, &ppr_options,
AHC_SYNCRATE_DT);
- ahc_lock(ahc, &flags);
- ahc_set_syncrate(ahc, &devinfo, syncrate, period, tinfo->goal.offset,
-ppr_options, AHC_TRANS_GOAL, FALSE);
- ahc_unlock(ahc, &flags);
-}
-
-static void ahc_linux_set_iu(struct scsi_target *starget, int iu)
-{
- struct Scsi_Host *shost = dev_to_shost(starget->dev.parent);
- struct ahc_softc *ahc = *((struct ahc_softc **)shost->hostdata);
- struct ahc_tmode_tstate *tstate;
- struct ahc_initiator_tinfo *tinfo
- = ahc_fetch_transinfo(ahc,
- starget->channel + 'A',
- shost->this_id, starget->id, &tstate);
- struct ahc_devinfo devinfo;
- unsigned int ppr_options = tinfo->goal.ppr_options
- & ~MSG_EXT_PPR_IU_REQ;
- unsigned int period = tinfo->goal.period;
- unsigned long flags;
- struct ahc_syncrate *syncrate;
-
- if (iu)
- ppr_options |= MSG_EXT_PPR_IU_REQ;
-
- ahc_compile_devinfo(&devinfo, shost->this_id, starget->id, 0,
- starget->channel + 'A', ROLE_INITIATOR);
- syncrate = ahc_find_syncrate(ahc, &period, &ppr_options,
AHC_SYNCRATE_DT);
- ahc_lock(ahc, &flags);
- ahc_set_syncrate(ahc, &devinfo, syncrate, period, tinfo->goal.offset,
-ppr_options, AHC_TRANS_GOAL, FALSE);
- ahc_unlock(ahc, &flags);
-}
-#endif
-
static void ahc_linux_get_signalling(struct Scsi_Host *shost)
{
struct ahc_softc *ahc = *(struct ahc_softc **)shost->hostdata;
@@ -2545,12 +2483,6 @@ static void ahc_linux_get_signalling(struct Scsi_Host
*shost)
.show_width = 1,
.set_dt = ahc_linux_set_dt,
.show_dt= 1,
-#if 0
- .set_iu = ahc_linux_set_iu,
- .show_iu= 1,
- .set_qas= ahc_linux_set_qas,
- .show_qas = 1,
-#endif
.get_signalling = ahc_linux_get_signalling,
};
--
1.9.1
Re: [PATCH net-next 0/1] Add BASE-T1 PHY support
On 22.08.2019 09:18, Christian Herber wrote: > On 21.08.2019 20:57, Andrew Lunn wrote: >> >>> The current patch set IMO is a little bit hacky. I'm not 100% happy >>> with the implicit assumption that there can't be devices supporting >>> T1 and classic BaseT modes or fiber modes. >> >>> Andrew: Do you have an opinion on that? >> >> Hi Heiner >> >> I would also like cleaner integration. I doubt here is anything in the >> standard which says you cannot combine these modes. It is more a >> marketing question if anybody would build such a device. Maybe not >> directly into a vehicle, but you could imaging a mobile test device >> which uses T1 to talk to the car and T4 to connect to the garage >> network? >> >> So i don't think we should limit ourselves. phylib should provide a >> clean, simple set of helpers to perform standard operations for >> various modes. Drivers can make use of those helpers. That much should >> be clear. If we try to make genphy support them all simultaneously, is >> less clear. >> >> Andrew >> > > If you want to go down this path, then i think we have to ask some more > questions. Clause 45 is a very scalable register scheme, it is not a > specific class of devices and will be extended and extended. > > Currently, the phy-c45.c supports 10/100/1000/2500/5000/1 Mbps > consumer/enterprise PHYs. This is also an implicit assumption. The > register set (e.g. on auto-neg) used for this will also only support > these modes and nothing more, as it is done scaling. > > Currently not supported, but already present in IEEE 802.3: > - MultiGBASE-T (25/40 Gbps) (see e.g. MultiGBASE-T AN control 1 register) > - BASE-T1 > - 10BASE-T1 > - NGBASE-T1 > > And surely there are some on the way or already there that I am not > aware of. > > To me, one architectural decision point is if you want to have generic > support for all C45 PHYs in one file, or if you want to split it by > device class. I went down the first path with my patch, as this is the > road gone also with the existing code. > > If you want to split BASE-T1, i think you will need one basic C45 > library (genphy_c45_pma_read_abilities() is a good example of a function > that is not specific to a device class). On the other hand, > genphy_c45_pma_setup_forced() is not a generic function at this point as > it supports only a subset of devices managed in C45. > > I tend to agree with you that splitting is the best way to go in the > long run, but that also requires a split of the existing phy-c45.c into > two IMHO. > BASE-T1 seems to be based on Clause 45 (at least Clause 45 MDIO), but it's not fully compliant with Clause 45. Taking AN link status as an example: 45.2.7.2.7 states that link-up is signaled in bit 7.1.2. If BASE-T1 uses a different register, then it's not fully Clause 45 compatible. Therefore also my question for the datasheet of an actual BASE-T1 PHY, as I would be curious whether it shadows the link-up bit from 7.513.2 to 7.1.2 to be Clause 45 compliant. Definitely reading bit 7.513.2 is nothing that belongs into a genphy_c45_ function. The extension to genphy_c45_pma_read_abilities() looks good to me, for the other parts I'd like to see first how real world BASE-T1 PHYs handle it. If they shadow the T1-specific bits to the Clause 45 standard ones, we should be fine. Otherwise IMO we have to add separate T1 functions to phylib. Heiner
[PATCH v2 0/2] Add PDC Global and AOSS reset support
This patch series adds PDC Global and AOSS reset support on SC7180 SoCs. v2: * Addressed Philipp's review comments Sibi Sankar (2): dt-bindings: reset: aoss: Add AOSS reset binding for SC7180 SoCs dt-bindings: reset: pdc: Add PDC Global binding for SC7180 SoCs Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt | 4 ++-- Documentation/devicetree/bindings/reset/qcom,pdc-global.txt | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v2 1/2] dt-bindings: reset: aoss: Add AOSS reset binding for SC7180 SoCs
Add SC7180 AOSS reset to the list of possible bindings. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt index 510c748656ec5..438a3e5173846 100644 --- a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt +++ b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt @@ -8,8 +8,8 @@ Required properties: - compatible: Usage: required Value type: - Definition: must be: - "qcom,sdm845-aoss-cc" + Definition: must be on of: + "qcom,sc7180-aoss-cc", "qcom,sdm845-aoss-cc" - reg: Usage: required -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v2 2/2] dt-bindings: reset: pdc: Add PDC Global binding for SC7180 SoCs
Add SC7180 PDC global to the list of possible bindings. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/reset/qcom,pdc-global.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/reset/qcom,pdc-global.txt b/Documentation/devicetree/bindings/reset/qcom,pdc-global.txt index a62a492843e70..0faa8e1396f5d 100644 --- a/Documentation/devicetree/bindings/reset/qcom,pdc-global.txt +++ b/Documentation/devicetree/bindings/reset/qcom,pdc-global.txt @@ -8,8 +8,8 @@ Required properties: - compatible: Usage: required Value type: - Definition: must be: - "qcom,sdm845-pdc-global" + Definition: must be on of: + "qcom,sc7180-pdc-global", "qcom,sdm845-pdc-global" - reg: Usage: required -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] leds: ti-lmu-common: Fix coccinelle issue in TI LMU
Hi Dan,
Thank you for the patch.
On 8/23/19 9:55 PM, Dan Murphy wrote:
> Fix the coccinelle issues found in the TI LMU common code
>
> drivers/leds/leds-ti-lmu-common.c:97:20-29: WARNING: Unsigned expression
> compared with zero: ramp_down < 0
> drivers/leds/leds-ti-lmu-common.c:97:5-12: WARNING: Unsigned expression
> compared with zero: ramp_up < 0
Wouldn't it make more sense to remove those pointless checks?
Clearly a correct index of an array cannot be negative.
Looking at the code I would make more int -> unsigned int conversions:
- ramp_table should be unsigned int
- ti_lmu_common_convert_ramp_to_index should return unsigned int
> Fixes: f717460ba4d7 ("leds: TI LMU: Add common code for TI LMU devices")
> Signed-off-by: Dan Murphy
> ---
> drivers/leds/leds-ti-lmu-common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/leds/leds-ti-lmu-common.c
> b/drivers/leds/leds-ti-lmu-common.c
> index adc7293004f1..c9ab40d5a6ba 100644
> --- a/drivers/leds/leds-ti-lmu-common.c
> +++ b/drivers/leds/leds-ti-lmu-common.c
> @@ -84,7 +84,7 @@ static int ti_lmu_common_convert_ramp_to_index(unsigned int
> usec)
> int ti_lmu_common_set_ramp(struct ti_lmu_bank *lmu_bank)
> {
> struct regmap *regmap = lmu_bank->regmap;
> - u8 ramp, ramp_up, ramp_down;
> + int ramp, ramp_up, ramp_down;
>
> if (lmu_bank->ramp_up_usec == 0 && lmu_bank->ramp_down_usec == 0) {
> ramp_up = 0;
>
--
Best regards,
Jacek Anaszewski
[PATCH] scripts/gcc-plugins: Add SPDX header for files without
Replace boilerplate with approproate SPDX header. Vim also auto-trimmed
whitespace from one line.
Signed-off-by: Alex Dewar
---
scripts/gcc-plugins/cyc_complexity_plugin.c | 2 +-
scripts/gcc-plugins/latent_entropy_plugin.c | 2 +-
scripts/gcc-plugins/randomize_layout_plugin.c | 4 ++--
scripts/gcc-plugins/sancov_plugin.c | 2 +-
scripts/gcc-plugins/stackleak_plugin.c| 2 +-
scripts/gcc-plugins/structleak_plugin.c | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/scripts/gcc-plugins/cyc_complexity_plugin.c
b/scripts/gcc-plugins/cyc_complexity_plugin.c
index 1909ec617431..870266f36b5c 100644
--- a/scripts/gcc-plugins/cyc_complexity_plugin.c
+++ b/scripts/gcc-plugins/cyc_complexity_plugin.c
@@ -1,6 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright 2011-2016 by Emese Revfy
- * Licensed under the GPL v2, or (at your option) v3
*
* Homepage:
* https://github.com/ephox-gcc-plugins/cyclomatic_complexity
diff --git a/scripts/gcc-plugins/latent_entropy_plugin.c
b/scripts/gcc-plugins/latent_entropy_plugin.c
index cbe1d6c4b1a5..c693ac27ddf1 100644
--- a/scripts/gcc-plugins/latent_entropy_plugin.c
+++ b/scripts/gcc-plugins/latent_entropy_plugin.c
@@ -1,7 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright 2012-2016 by the PaX Team
* Copyright 2016 by Emese Revfy
- * Licensed under the GPL v2
*
* Note: the choice of the license means that the compilation process is
* NOT 'eligible' as defined by gcc's library exception to the GPL v3,
diff --git a/scripts/gcc-plugins/randomize_layout_plugin.c
b/scripts/gcc-plugins/randomize_layout_plugin.c
index bd29e4e7a524..f46d049da26c 100644
--- a/scripts/gcc-plugins/randomize_layout_plugin.c
+++ b/scripts/gcc-plugins/randomize_layout_plugin.c
@@ -1,7 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright 2014-2016 by Open Source Security, Inc., Brad Spengler
* and PaX Team
- * Licensed under the GPL v2
*
* Note: the choice of the license means that the compilation process is
* NOT 'eligible' as defined by gcc's library exception to the GPL v3,
@@ -909,7 +909,7 @@ static unsigned int find_bad_casts_execute(void)
} else {
const_tree ssa_name_var = SSA_NAME_VAR(rhs1);
/* skip bogus type casts introduced by
container_of */
- if (ssa_name_var != NULL_TREE &&
DECL_NAME(ssa_name_var) &&
+ if (ssa_name_var != NULL_TREE &&
DECL_NAME(ssa_name_var) &&
!strcmp((const char
*)DECL_NAME_POINTER(ssa_name_var), "__mptr"))
continue;
#ifndef __DEBUG_PLUGIN
diff --git a/scripts/gcc-plugins/sancov_plugin.c
b/scripts/gcc-plugins/sancov_plugin.c
index 0f98634c20a0..9845ad67a7d8 100644
--- a/scripts/gcc-plugins/sancov_plugin.c
+++ b/scripts/gcc-plugins/sancov_plugin.c
@@ -1,6 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright 2011-2016 by Emese Revfy
- * Licensed under the GPL v2, or (at your option) v3
*
* Homepage:
* https://github.com/ephox-gcc-plugins/sancov
diff --git a/scripts/gcc-plugins/stackleak_plugin.c
b/scripts/gcc-plugins/stackleak_plugin.c
index dbd37460c573..3abaea274651 100644
--- a/scripts/gcc-plugins/stackleak_plugin.c
+++ b/scripts/gcc-plugins/stackleak_plugin.c
@@ -1,7 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright 2011-2017 by the PaX Team
* Modified by Alexander Popov
- * Licensed under the GPL v2
*
* Note: the choice of the license means that the compilation process is
* NOT 'eligible' as defined by gcc's library exception to the GPL v3,
diff --git a/scripts/gcc-plugins/structleak_plugin.c
b/scripts/gcc-plugins/structleak_plugin.c
index e89be8f5c859..eb8d6b5c83b5 100644
--- a/scripts/gcc-plugins/structleak_plugin.c
+++ b/scripts/gcc-plugins/structleak_plugin.c
@@ -1,6 +1,6 @@
+// Licensed under the GPL v2
/*
* Copyright 2013-2017 by PaX Team
- * Licensed under the GPL v2
*
* Note: the choice of the license means that the compilation process is
* NOT 'eligible' as defined by gcc's library exception to the GPL v3,
--
2.23.0
Re: [PATCH 5.2 000/135] 5.2.10-stable review
On 8/23/19 8:38 PM, Greg KH wrote: On Fri, Aug 23, 2019 at 12:41:03PM -0600, shuah wrote: On 8/22/19 11:05 AM, Sasha Levin wrote: This is the start of the stable review cycle for the 5.2.10 release. There are 135 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat 24 Aug 2019 05:07:10 PM UTC. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-5.2.10-rc1.gz I am seeing "Sorry I can't find your kernels". Is this posted? Ah, Sasha didn't generate the patch but it was still listed here, oops. He copied my format and we didn't notice this, sorry about that. As the thread shows, we didn't generate this file this time to see what would happen. If your test process requires it, we can generate it as I don't want to break it. It will make it lot easier for me to have continued support for patch generation. My scripts do "wget" to pull the patch and apply. thanks, -- Shuah
[RESEND PATCH v2 1/2] dt-bindings: reset: aoss: Add AOSS reset binding for SC7180 SoCs
Add SC7180 AOSS reset to the list of possible bindings. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt index 510c748656ec5..3eb6a22ced4bc 100644 --- a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt +++ b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt @@ -8,8 +8,8 @@ Required properties: - compatible: Usage: required Value type: - Definition: must be: - "qcom,sdm845-aoss-cc" + Definition: must be one of: + "qcom,sc7180-aoss-cc", "qcom,sdm845-aoss-cc" - reg: Usage: required -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[RESEND PATCH v2 0/2] Add PDC Global and AOSS reset support
This patch series adds PDC Global and AOSS reset support on SC7180 SoCs. v2: * Addressed Philipp's review comments Sibi Sankar (2): dt-bindings: reset: aoss: Add AOSS reset binding for SC7180 SoCs dt-bindings: reset: pdc: Add PDC Global binding for SC7180 SoCs Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt | 4 ++-- Documentation/devicetree/bindings/reset/qcom,pdc-global.txt | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[RESEND PATCH v2 2/2] dt-bindings: reset: pdc: Add PDC Global binding for SC7180 SoCs
Add SC7180 PDC global to the list of possible bindings. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/reset/qcom,pdc-global.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/reset/qcom,pdc-global.txt b/Documentation/devicetree/bindings/reset/qcom,pdc-global.txt index a62a492843e70..c1fef349f0faf 100644 --- a/Documentation/devicetree/bindings/reset/qcom,pdc-global.txt +++ b/Documentation/devicetree/bindings/reset/qcom,pdc-global.txt @@ -8,8 +8,8 @@ Required properties: - compatible: Usage: required Value type: - Definition: must be: - "qcom,sdm845-pdc-global" + Definition: must be one of: + "qcom,sc7180-pdc-global", "qcom,sdm845-pdc-global" - reg: Usage: required -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH RESEND] scripts/gcc-plugins: Add SPDX header for files without
Replace boilerplate with approproate SPDX header. Vim also auto-trimmed
whitespace from one line.
Ignore the previous email -- there was a typo in the patch. Sorry!
Signed-off-by: Alex Dewar
---
scripts/gcc-plugins/cyc_complexity_plugin.c | 2 +-
scripts/gcc-plugins/latent_entropy_plugin.c | 2 +-
scripts/gcc-plugins/randomize_layout_plugin.c | 4 ++--
scripts/gcc-plugins/sancov_plugin.c | 2 +-
scripts/gcc-plugins/stackleak_plugin.c| 2 +-
scripts/gcc-plugins/structleak_plugin.c | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/scripts/gcc-plugins/cyc_complexity_plugin.c
b/scripts/gcc-plugins/cyc_complexity_plugin.c
index 1909ec617431..870266f36b5c 100644
--- a/scripts/gcc-plugins/cyc_complexity_plugin.c
+++ b/scripts/gcc-plugins/cyc_complexity_plugin.c
@@ -1,6 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright 2011-2016 by Emese Revfy
- * Licensed under the GPL v2, or (at your option) v3
*
* Homepage:
* https://github.com/ephox-gcc-plugins/cyclomatic_complexity
diff --git a/scripts/gcc-plugins/latent_entropy_plugin.c
b/scripts/gcc-plugins/latent_entropy_plugin.c
index cbe1d6c4b1a5..c693ac27ddf1 100644
--- a/scripts/gcc-plugins/latent_entropy_plugin.c
+++ b/scripts/gcc-plugins/latent_entropy_plugin.c
@@ -1,7 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright 2012-2016 by the PaX Team
* Copyright 2016 by Emese Revfy
- * Licensed under the GPL v2
*
* Note: the choice of the license means that the compilation process is
* NOT 'eligible' as defined by gcc's library exception to the GPL v3,
diff --git a/scripts/gcc-plugins/randomize_layout_plugin.c
b/scripts/gcc-plugins/randomize_layout_plugin.c
index bd29e4e7a524..f46d049da26c 100644
--- a/scripts/gcc-plugins/randomize_layout_plugin.c
+++ b/scripts/gcc-plugins/randomize_layout_plugin.c
@@ -1,7 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright 2014-2016 by Open Source Security, Inc., Brad Spengler
* and PaX Team
- * Licensed under the GPL v2
*
* Note: the choice of the license means that the compilation process is
* NOT 'eligible' as defined by gcc's library exception to the GPL v3,
@@ -909,7 +909,7 @@ static unsigned int find_bad_casts_execute(void)
} else {
const_tree ssa_name_var = SSA_NAME_VAR(rhs1);
/* skip bogus type casts introduced by
container_of */
- if (ssa_name_var != NULL_TREE &&
DECL_NAME(ssa_name_var) &&
+ if (ssa_name_var != NULL_TREE &&
DECL_NAME(ssa_name_var) &&
!strcmp((const char
*)DECL_NAME_POINTER(ssa_name_var), "__mptr"))
continue;
#ifndef __DEBUG_PLUGIN
diff --git a/scripts/gcc-plugins/sancov_plugin.c
b/scripts/gcc-plugins/sancov_plugin.c
index 0f98634c20a0..9845ad67a7d8 100644
--- a/scripts/gcc-plugins/sancov_plugin.c
+++ b/scripts/gcc-plugins/sancov_plugin.c
@@ -1,6 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright 2011-2016 by Emese Revfy
- * Licensed under the GPL v2, or (at your option) v3
*
* Homepage:
* https://github.com/ephox-gcc-plugins/sancov
diff --git a/scripts/gcc-plugins/stackleak_plugin.c
b/scripts/gcc-plugins/stackleak_plugin.c
index dbd37460c573..3abaea274651 100644
--- a/scripts/gcc-plugins/stackleak_plugin.c
+++ b/scripts/gcc-plugins/stackleak_plugin.c
@@ -1,7 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright 2011-2017 by the PaX Team
* Modified by Alexander Popov
- * Licensed under the GPL v2
*
* Note: the choice of the license means that the compilation process is
* NOT 'eligible' as defined by gcc's library exception to the GPL v3,
diff --git a/scripts/gcc-plugins/structleak_plugin.c
b/scripts/gcc-plugins/structleak_plugin.c
index e89be8f5c859..eb8d6b5c83b5 100644
--- a/scripts/gcc-plugins/structleak_plugin.c
+++ b/scripts/gcc-plugins/structleak_plugin.c
@@ -1,6 +1,6 @@
+// Licensed under the GPL v2
/*
* Copyright 2013-2017 by PaX Team
- * Licensed under the GPL v2
*
* Note: the choice of the license means that the compilation process is
* NOT 'eligible' as defined by gcc's library exception to the GPL v3,
--
2.23.0
[PATCH RESEND v3] scripts/gcc-plugins: Add SPDX header for files without
Replace boilerplate with approproate SPDX header. Vim also auto-trimmed
whitespace from one line.
Ignore the previous emails. I'm still trying to get the hang of the
tools. Really sorry!
Signed-off-by: Alex Dewar
---
scripts/gcc-plugins/cyc_complexity_plugin.c | 2 +-
scripts/gcc-plugins/latent_entropy_plugin.c | 2 +-
scripts/gcc-plugins/randomize_layout_plugin.c | 4 ++--
scripts/gcc-plugins/sancov_plugin.c | 2 +-
scripts/gcc-plugins/stackleak_plugin.c| 2 +-
scripts/gcc-plugins/structleak_plugin.c | 2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/scripts/gcc-plugins/cyc_complexity_plugin.c
b/scripts/gcc-plugins/cyc_complexity_plugin.c
index 1909ec617431..870266f36b5c 100644
--- a/scripts/gcc-plugins/cyc_complexity_plugin.c
+++ b/scripts/gcc-plugins/cyc_complexity_plugin.c
@@ -1,6 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright 2011-2016 by Emese Revfy
- * Licensed under the GPL v2, or (at your option) v3
*
* Homepage:
* https://github.com/ephox-gcc-plugins/cyclomatic_complexity
diff --git a/scripts/gcc-plugins/latent_entropy_plugin.c
b/scripts/gcc-plugins/latent_entropy_plugin.c
index cbe1d6c4b1a5..c693ac27ddf1 100644
--- a/scripts/gcc-plugins/latent_entropy_plugin.c
+++ b/scripts/gcc-plugins/latent_entropy_plugin.c
@@ -1,7 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright 2012-2016 by the PaX Team
* Copyright 2016 by Emese Revfy
- * Licensed under the GPL v2
*
* Note: the choice of the license means that the compilation process is
* NOT 'eligible' as defined by gcc's library exception to the GPL v3,
diff --git a/scripts/gcc-plugins/randomize_layout_plugin.c
b/scripts/gcc-plugins/randomize_layout_plugin.c
index bd29e4e7a524..f46d049da26c 100644
--- a/scripts/gcc-plugins/randomize_layout_plugin.c
+++ b/scripts/gcc-plugins/randomize_layout_plugin.c
@@ -1,7 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright 2014-2016 by Open Source Security, Inc., Brad Spengler
* and PaX Team
- * Licensed under the GPL v2
*
* Note: the choice of the license means that the compilation process is
* NOT 'eligible' as defined by gcc's library exception to the GPL v3,
@@ -909,7 +909,7 @@ static unsigned int find_bad_casts_execute(void)
} else {
const_tree ssa_name_var = SSA_NAME_VAR(rhs1);
/* skip bogus type casts introduced by
container_of */
- if (ssa_name_var != NULL_TREE &&
DECL_NAME(ssa_name_var) &&
+ if (ssa_name_var != NULL_TREE &&
DECL_NAME(ssa_name_var) &&
!strcmp((const char
*)DECL_NAME_POINTER(ssa_name_var), "__mptr"))
continue;
#ifndef __DEBUG_PLUGIN
diff --git a/scripts/gcc-plugins/sancov_plugin.c
b/scripts/gcc-plugins/sancov_plugin.c
index 0f98634c20a0..9845ad67a7d8 100644
--- a/scripts/gcc-plugins/sancov_plugin.c
+++ b/scripts/gcc-plugins/sancov_plugin.c
@@ -1,6 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Copyright 2011-2016 by Emese Revfy
- * Licensed under the GPL v2, or (at your option) v3
*
* Homepage:
* https://github.com/ephox-gcc-plugins/sancov
diff --git a/scripts/gcc-plugins/stackleak_plugin.c
b/scripts/gcc-plugins/stackleak_plugin.c
index dbd37460c573..3abaea274651 100644
--- a/scripts/gcc-plugins/stackleak_plugin.c
+++ b/scripts/gcc-plugins/stackleak_plugin.c
@@ -1,7 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright 2011-2017 by the PaX Team
* Modified by Alexander Popov
- * Licensed under the GPL v2
*
* Note: the choice of the license means that the compilation process is
* NOT 'eligible' as defined by gcc's library exception to the GPL v3,
diff --git a/scripts/gcc-plugins/structleak_plugin.c
b/scripts/gcc-plugins/structleak_plugin.c
index e89be8f5c859..708d21f5392b 100644
--- a/scripts/gcc-plugins/structleak_plugin.c
+++ b/scripts/gcc-plugins/structleak_plugin.c
@@ -1,6 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright 2013-2017 by PaX Team
- * Licensed under the GPL v2
*
* Note: the choice of the license means that the compilation process is
* NOT 'eligible' as defined by gcc's library exception to the GPL v3,
--
2.23.0
Re: [PATCH 5.2 000/135] 5.2.10-stable review
On Sat, Aug 24, 2019 at 09:21:53AM -0600, shuah wrote: > On 8/23/19 8:38 PM, Greg KH wrote: > > On Fri, Aug 23, 2019 at 12:41:03PM -0600, shuah wrote: > > > On 8/22/19 11:05 AM, Sasha Levin wrote: > > > > > > > > This is the start of the stable review cycle for the 5.2.10 release. > > > > There are 135 patches in this series, all will be posted as a response > > > > to this one. If anyone has any issues with these being applied, please > > > > let me know. > > > > > > > > Responses should be made by Sat 24 Aug 2019 05:07:10 PM UTC. > > > > Anything received after that time might be too late. > > > > > > > > The whole patch series can be found in one patch at: > > > > > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-5.2.10-rc1.gz > > > > > > I am seeing "Sorry I can't find your kernels". Is this posted? > > > > Ah, Sasha didn't generate the patch but it was still listed here, oops. > > He copied my format and we didn't notice this, sorry about that. > > > > As the thread shows, we didn't generate this file this time to see what > > would happen. If your test process requires it, we can generate it as I > > don't want to break it. > > > > It will make it lot easier for me to have continued support for patch > generation. My scripts do "wget" to pull the patch and apply. Ok, we will get this back and working, sorry about that. greg k-h
Re: [PATCH 2/2] uacce: add uacce module
On Sat, Aug 24, 2019 at 08:53:01PM +0800, zhangfei wrote:
>
>
> On 2019/8/20 下午10:33, Greg Kroah-Hartman wrote:
> > On Tue, Aug 20, 2019 at 08:36:50PM +0800, zhangfei wrote:
> > > Hi, Greg
> > >
> > > On 2019/8/19 下午6:24, Greg Kroah-Hartman wrote:
> > > > > > > +static int uacce_create_chrdev(struct uacce *uacce)
> > > > > > > +{
> > > > > > > + int ret;
> > > > > > > +
> > > > > > > + ret = idr_alloc(&uacce_idr, uacce, 0, 0, GFP_KERNEL);
> > > > > > > + if (ret < 0)
> > > > > > > + return ret;
> > > > > > > +
> > > > > > Shouldn't this function create the memory needed for this structure?
> > > > > > You are relying ont he caller to do it for you, why?
> > > > > I think you mean uacce structure here.
> > > > > Yes, currently we count on caller to prepare uacce structure and call
> > > > > uacce_register(uacce).
> > > > > We still think this method is simpler, prepare uacce, register uacce.
> > > > > And there are other system using the same method, like crypto
> > > > > (crypto_register_acomp), nand, etc.
> > > > crypto is not a subsystem to ever try to emulate :)
> > > >
> > > > You are creating a structure with a lifetime that you control, don't
> > > > have someone else create your memory, that's almost never what you want
> > > > to do. Most all driver subsystems create their own memory chunks for
> > > > what they need to do, it's a much better pattern.
> > > >
> > > > Especially when you get into pointer lifetime issues...
> > > OK, understand now, thanks for your patience.
> > > will use this instead.
> > > struct uacce_interface {
> > > char name[32];
> > > unsigned int flags;
> > > struct uacce_ops *ops;
> > > };
> > > struct uacce *uacce_register(struct device *dev, struct uacce_interface
> > > *interface);
> > What? Why do you need a structure? A pointer to the name and the ops
> > should be all that is needed, right?
> We are thinking transfer structure will be more flexible.
> And modify api later would be difficult, requiring many drivers modify
> together.
> Currently parameters need a flag, a pointer to the name, and ops, but in
> case more requirement from future drivers usage.
> Also refer usb_register_dev, sdhci_pltfm_init etc, and the structure para
> can be set as static.
Ok, I can live with that, but it is a bit more complex. However, if you
are creating a new device structure, your "core" has to do it, do not
rely on the driver to do it for you as that is just lots of duplicated
logic everywhere. Not to mention a reference counting nightmare.
> > And 'dev' here is a pointer to the parent, right? Might want to make
> > that explicit in the name of the variable :)
> Yes, 'dev' is parent, will change to 'pdev', thanks.
Use "struct device *parent" it's much more obvious that way and does not
look like crazy hungarian notation :)
thanks,
greg k-h
[RESEND PATCH] perf: Remove duplicate headers
Removed duplicate headers which are included twice. Signed-off-by: Souptick Joarder Reviewed-by: Mukesh Ojha --- tools/perf/util/data.c | 1 - tools/perf/util/get_current_dir_name.c | 1 - tools/perf/util/stat-display.c | 1 - 3 files changed, 3 deletions(-) diff --git a/tools/perf/util/data.c b/tools/perf/util/data.c index 6a64f71..509a41e 100644 --- a/tools/perf/util/data.c +++ b/tools/perf/util/data.c @@ -8,7 +8,6 @@ #include #include #include -#include #include #include "data.h" diff --git a/tools/perf/util/get_current_dir_name.c b/tools/perf/util/get_current_dir_name.c index 267aa60..ebb80cd 100644 --- a/tools/perf/util/get_current_dir_name.c +++ b/tools/perf/util/get_current_dir_name.c @@ -5,7 +5,6 @@ #include "util.h" #include #include -#include /* Android's 'bionic' library, for one, doesn't have this */ diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c index 6d043c7..7b3a16c 100644 --- a/tools/perf/util/stat-display.c +++ b/tools/perf/util/stat-display.c @@ -12,7 +12,6 @@ #include "string2.h" #include "sane_ctype.h" #include "cgroup.h" -#include #include #define CNTR_NOT_SUPPORTED "" -- 1.9.1
Re: [PATCH] /dev/mem: Bail out upon SIGKILL when reading memory.
* Linus Torvalds wrote:
> On Fri, Aug 23, 2019 at 2:16 AM Ingo Molnar wrote:
> >
> > > + */
> > > + if (fatal_signal_pending(current)) {
> > > + if (!(error_code & X86_PF_USER))
> > > + no_context(regs, error_code, address, 0, 0);
> >
> > Since the 'signal' parameter to no_context() is 0, will there be another
> > signal generated? I don't think so - so the comment looks wrong to me,
> > unless I'm missing something.
>
> The old case only handled the kernel case - which never added a signal
> at all, it just failed the access (and results in EFAULT or similar,
> but nobody cares since the whole point is that the process is going to
> be killed).
>
> The *changed* case handles user space accesses too - by just returning
> without any new signal being generated. The old case would fall
> through to the "generate SIGSEGV", which seems pointless and wrong
> (and also possibly generates misleading messages in the kernel logs).
Indeed!
> > Other than that, what we are skipping here if a KILL signal is pending is
> > the printout of oops information if the fault is a kernel one.
> >
> > Not sure that's a good idea in general: carefully timing a KILL signal
> > would allow the 'stealth probing' of otherwise oops generating addresses?
>
> That sounds really like a non-issue to me. Plus the old code ALREADY
> did that exact thing. The only _new_ case is that it does is silently
> for user page faults.
>
> > I.e. I'm not sure this hunk is necessary or even a good idea.
>
> As mentioned, the new code doesn't change the case you are talking about at
> all.
>
> The new code only changes the case of this happening from user space,
> when it doesn't generate a pointless signal and a pointless possible
> show_signal_msg() garbage for a user mode access that was denied due
> to the new
>
> > > + if (flags & FAULT_FLAG_KILLABLE) {
> > > + if (fatal_signal_pending(current))
> > > + return VM_FAULT_SIGSEGV;
> > > + }
>
> code in handle_mm_fault().
>
> And you said that new code looks fine to you, but you didn't seem to
> realize that it causes stupid incorrect kernel messages to be printed
> ("segfault at xyz" etc) that are completely wrong.
>
> Because it's not a "real" SIGSEGV. It gets repressed by the fact that
> there's a fatal signal pending.
>
> Otherwise we'd have to add a whole new case of VM_FAULT_xyz..
Indeed :-/
At least I can report that I was able to reproduce a probable variant of
the bug Tetsuo reported on a regular PC as well, with this command:
dd if=/dev/mem of=/dev/null status=progress conv=noerror bs=100M
The 'noerror' is needed to skip unreadable holes early in the memory map.
What I noticed is that while reading regular RAM is reasonably fast even
in very large chunks, accesses become very slow once they hit iomem - and
delays even longer than the reported 145 seconds become possible if
bs=100M is increased to say bs=1000M.
With your patch applied these large read chunks are still possible and
not interruptible within read_mem(), and because the source of the
slowdown is the iomem access and memcpy()s, not the paging overhead, the
new page fault code doesn't even trigger and the delays remain.
I.e. this hypothesis is not true, on my testbox at least - and with my
different testcase:
> > > Also, if it takes minutes to delay killing things, that implies
> > > that we're probably still faulting in pages for the read_mem().
> > > Which points to another possible thing we could do in general: just
> > > don't bother to handle page faults when a fatal signal is pending.
With Tetsuo's approach the delays are fixed, because the fatal signal is
noticed within the 4K chunks of read_mem() immediately:
[pid 1674] 152105.052485 write(1,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 104857600) =
104857600 <0.08>
[pid 1674] 152105.052512 read(0,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
104857600) = 104857600 <17.006740>
[pid 1674] 152122.059306 write(1,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
104857600) = 104857600 <0.09>
) = 1 <0.10>662122.059334 write(2, "\r", 1
[pid 1674] 152122.059372 write(2, "3145728000 bytes (3.1 GB) copied",
323145728000 bytes (3.1 GB) copied) = 32 <0.09>
[pid 1674] 152122.059411 write(2, ", 18.214699 s, 173 MB/s", 23, 18.214699
s, 173 MB/s) = 23 <0.08>
[pid 1674] 152122.059433 read(0,
[pid 1674] 152123.082491 +++ killed by SIGKILL +++
Note how the first 100MB chunk took 17 seconds, the second chunk was
interrupted within ~2 seconds after I sent a SIGKILL.
Find below a variant of Tetsuo's patch, that uses a more regular signal
return pattern that you suggested in your other mail:
> (Ok, in this case I think it wants
>
> err = -EINTR;
> if (fatal_signal_pending(current))
> break;
>
> instead, b
[GIT PULL] xfs: fix for 5.3-rc6
Hi Linus, Please pull this single patch that fixes a xfs lockup problem when a chown/chgrp operation fails due to running out of quota. It has survived the usual xfstests runs and merges cleanly with this morning's master. Please let me know if anything strange happens. --D The following changes since commit b68271609c4f16a79eae8069933f64345afcf888: fs/xfs: Fix return code of xfs_break_leased_layouts() (2019-08-19 18:15:28 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-5.3-fixes-6 for you to fetch changes up to 1fb254aa983bf190cfd685d40c64a480a9bafaee: xfs: fix missing ILOCK unlock when xfs_setattr_nonsize fails due to EDQUOT (2019-08-22 20:55:54 -0700) Changes since last time: - Fix a forgotten inode unlock when chown/chgrp fail due to quota. Darrick J. Wong (1): xfs: fix missing ILOCK unlock when xfs_setattr_nonsize fails due to EDQUOT fs/xfs/xfs_iops.c | 1 + 1 file changed, 1 insertion(+)
[PATCH v2 2/2] media: imx: Move pads init to probe
If a subdevice is unregistered and then registered again without the
driver being removed and re-probed (which will happen when the media
device is removed and re-probed without also removing/re-probing the
subdevice), media_device_register_entity() is called with a non-zero
entity->num_pads, and then the subdevice's .registered callback calls
media_entity_pads_init(). Thus the subdevice's pad objects are added
to the media device pad list twice, causing list corruption.
One way to fix this would be to create media_entity_pads_destroy(),
and call it in the subdevice's .unregistered callback. But calling
media_entity_pads_init() in the .registered callbacks was done for
legacy reasons and is no longer necessary, so move the call to
media_entity_pads_init() into the subdevice's probe functions. This
fixes the duplicate pad obejcts in the media device pad list.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-ic-prp.c| 25 ++---
drivers/staging/media/imx/imx-ic-prpencvf.c | 28 +--
drivers/staging/media/imx/imx-media-capture.c | 15 +-
drivers/staging/media/imx/imx-media-csi.c | 21 +++---
drivers/staging/media/imx/imx-media-vdic.c| 27 --
drivers/staging/media/imx/imx6-mipi-csi2.c| 27 --
drivers/staging/media/imx/imx7-media-csi.c| 18 ++--
drivers/staging/media/imx/imx7-mipi-csis.c| 23 +--
8 files changed, 81 insertions(+), 103 deletions(-)
diff --git a/drivers/staging/media/imx/imx-ic-prp.c
b/drivers/staging/media/imx/imx-ic-prp.c
index 35e60a120dc1..2a4f77e83ed3 100644
--- a/drivers/staging/media/imx/imx-ic-prp.c
+++ b/drivers/staging/media/imx/imx-ic-prp.c
@@ -428,32 +428,19 @@ static int prp_s_frame_interval(struct v4l2_subdev *sd,
return 0;
}
-/*
- * retrieve our pads parsed from the OF graph by the media device
- */
static int prp_registered(struct v4l2_subdev *sd)
{
struct prp_priv *priv = sd_to_priv(sd);
- int i, ret;
u32 code;
- for (i = 0; i < PRP_NUM_PADS; i++) {
- priv->pad[i].flags = (i == PRP_SINK_PAD) ?
- MEDIA_PAD_FL_SINK : MEDIA_PAD_FL_SOURCE;
- }
-
/* init default frame interval */
priv->frame_interval.numerator = 1;
priv->frame_interval.denominator = 30;
/* set a default mbus format */
imx_media_enum_ipu_format(&code, 0, CS_SEL_YUV);
- ret = imx_media_init_mbus_fmt(&priv->format_mbus, 640, 480, code,
- V4L2_FIELD_NONE, NULL);
- if (ret)
- return ret;
-
- return media_entity_pads_init(&sd->entity, PRP_NUM_PADS, priv->pad);
+ return imx_media_init_mbus_fmt(&priv->format_mbus, 640, 480, code,
+ V4L2_FIELD_NONE, NULL);
}
static const struct v4l2_subdev_pad_ops prp_pad_ops = {
@@ -487,6 +474,7 @@ static const struct v4l2_subdev_internal_ops
prp_internal_ops = {
static int prp_init(struct imx_ic_priv *ic_priv)
{
struct prp_priv *priv;
+ int i;
priv = devm_kzalloc(ic_priv->ipu_dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -496,7 +484,12 @@ static int prp_init(struct imx_ic_priv *ic_priv)
ic_priv->task_priv = priv;
priv->ic_priv = ic_priv;
- return 0;
+ for (i = 0; i < PRP_NUM_PADS; i++)
+ priv->pad[i].flags = (i == PRP_SINK_PAD) ?
+ MEDIA_PAD_FL_SINK : MEDIA_PAD_FL_SOURCE;
+
+ return media_entity_pads_init(&ic_priv->sd.entity, PRP_NUM_PADS,
+ priv->pad);
}
static void prp_remove(struct imx_ic_priv *ic_priv)
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index f8a0b21fcd02..09c4e3f33807 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -1240,9 +1240,6 @@ static int prp_s_frame_interval(struct v4l2_subdev *sd,
return 0;
}
-/*
- * retrieve our pads parsed from the OF graph by the media device
- */
static int prp_registered(struct v4l2_subdev *sd)
{
struct prp_priv *priv = sd_to_priv(sd);
@@ -1250,12 +1247,9 @@ static int prp_registered(struct v4l2_subdev *sd)
int i, ret;
u32 code;
+ /* set a default mbus format */
+ imx_media_enum_ipu_format(&code, 0, CS_SEL_YUV);
for (i = 0; i < PRPENCVF_NUM_PADS; i++) {
- priv->pad[i].flags = (i == PRPENCVF_SINK_PAD) ?
- MEDIA_PAD_FL_SINK : MEDIA_PAD_FL_SOURCE;
-
- /* set a default mbus format */
- imx_media_enum_ipu_format(&code, 0, CS_SEL_YUV);
ret = imx_media_init_mbus_fmt(&priv->format_mbus[i],
640, 480, code, V4L2_FIELD_NONE,
&priv->cc[i]);
@@ -1267,11 +1261,6 @@ static int prp_regist
[PATCH v2 1/2] media: imx: Move capture device init to registered
If the CSI is unregistered and then registered again without the
driver being removed and re-probed (which will happen when the media
device is removed and re-probed without also removing/re-probing the
CSI), the result is the kobject error and backtrace "tried to init an
initialized object". This is because the video device is left in an
initialized state after being unregistered, thus the video device's
underlying kobject is also left in an initialized state when the device
is registered again.
Fix this by moving imx_media_capture_device_init() and _remove()
into csi_registered() and csi_unregistered(). This will create a new
un-initialized video device when the CSI is re-registered. Do this for
all the subdevices that register a capture device.
Reported-by: Russell King
Signed-off-by: Steve Longerbeam
---
Changes in v2:
Add missing local var ic_priv in prp_registered().
Reported-by: kbuild test robot
---
drivers/staging/media/imx/imx-ic-prpencvf.c | 25 -
drivers/staging/media/imx/imx-media-csi.c | 20 ++---
drivers/staging/media/imx/imx7-media-csi.c | 22 +-
3 files changed, 38 insertions(+), 29 deletions(-)
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index 67ffa46a8e96..f8a0b21fcd02 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -1246,6 +1246,7 @@ static int prp_s_frame_interval(struct v4l2_subdev *sd,
static int prp_registered(struct v4l2_subdev *sd)
{
struct prp_priv *priv = sd_to_priv(sd);
+ struct imx_ic_priv *ic_priv = priv->ic_priv;
int i, ret;
u32 code;
@@ -1271,17 +1272,26 @@ static int prp_registered(struct v4l2_subdev *sd)
if (ret)
return ret;
+ priv->vdev = imx_media_capture_device_init(ic_priv->ipu_dev,
+ &ic_priv->sd,
+ PRPENCVF_SRC_PAD);
+ if (IS_ERR(priv->vdev))
+ return PTR_ERR(priv->vdev);
+
ret = imx_media_capture_device_register(priv->vdev);
if (ret)
- return ret;
+ goto remove_vdev;
ret = prp_init_controls(priv);
if (ret)
- goto unreg;
+ goto unreg_vdev;
return 0;
-unreg:
+
+unreg_vdev:
imx_media_capture_device_unregister(priv->vdev);
+remove_vdev:
+ imx_media_capture_device_remove(priv->vdev);
return ret;
}
@@ -1290,6 +1300,8 @@ static void prp_unregistered(struct v4l2_subdev *sd)
struct prp_priv *priv = sd_to_priv(sd);
imx_media_capture_device_unregister(priv->vdev);
+ imx_media_capture_device_remove(priv->vdev);
+
v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
}
@@ -1336,12 +1348,6 @@ static int prp_init(struct imx_ic_priv *ic_priv)
spin_lock_init(&priv->irqlock);
timer_setup(&priv->eof_timeout_timer, prp_eof_timeout, 0);
- priv->vdev = imx_media_capture_device_init(ic_priv->ipu_dev,
- &ic_priv->sd,
- PRPENCVF_SRC_PAD);
- if (IS_ERR(priv->vdev))
- return PTR_ERR(priv->vdev);
-
mutex_init(&priv->lock);
return 0;
@@ -1352,7 +1358,6 @@ static void prp_remove(struct imx_ic_priv *ic_priv)
struct prp_priv *priv = ic_priv->task_priv;
mutex_destroy(&priv->lock);
- imx_media_capture_device_remove(priv->vdev);
}
struct imx_ic_ops imx_ic_prpencvf_ops = {
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index 367e39f5b382..b3f1cf08a102 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1797,12 +1797,22 @@ static int csi_registered(struct v4l2_subdev *sd)
if (ret)
goto free_fim;
+ priv->vdev = imx_media_capture_device_init(priv->sd.dev,
+ &priv->sd,
+ CSI_SRC_PAD_IDMAC);
+ if (IS_ERR(priv->vdev)) {
+ ret = PTR_ERR(priv->vdev);
+ goto free_fim;
+ }
+
ret = imx_media_capture_device_register(priv->vdev);
if (ret)
- goto free_fim;
+ goto remove_vdev;
return 0;
+remove_vdev:
+ imx_media_capture_device_remove(priv->vdev);
free_fim:
if (priv->fim)
imx_media_fim_free(priv->fim);
@@ -1816,6 +1826,7 @@ static void csi_unregistered(struct v4l2_subdev *sd)
struct csi_priv *priv = v4l2_get_subdevdata(sd);
imx_media_capture_device_unregister(priv->vdev);
+ imx_media_capture_device_remove(priv->vdev);
if (priv->fim)
imx_media_fim_free(priv->fim);
@@ -1963,11 +1974,6 @@ static int imx_csi_probe(struct platf
[PATCH] RDMA/mlx5: Merge two enums into a single one
These two enums can be merged into a single one wihtout effecting
their caller if those were created without intension.
Signed-off-by: Souptick Joarder
---
include/uapi/rdma/mlx5-abi.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/uapi/rdma/mlx5-abi.h b/include/uapi/rdma/mlx5-abi.h
index 624f5b53..c89363a 100644
--- a/include/uapi/rdma/mlx5-abi.h
+++ b/include/uapi/rdma/mlx5-abi.h
@@ -461,13 +461,10 @@ enum mlx5_ib_mmap_cmd {
MLX5_IB_MMAP_DEVICE_MEM = 8,
};
-enum {
- MLX5_IB_CLOCK_INFO_KERNEL_UPDATING = 1,
-};
-
/* Bit indexes for the mlx5_alloc_ucontext_resp.clock_info_versions bitmap */
enum {
MLX5_IB_CLOCK_INFO_V1 = 0,
+ MLX5_IB_CLOCK_INFO_KERNEL_UPDATING = 1,
};
struct mlx5_ib_flow_counters_desc {
--
1.9.1
Re: [PATCH 5.2 000/135] 5.2.10-stable review
On 8/24/19 9:33 AM, Greg KH wrote: On Sat, Aug 24, 2019 at 09:21:53AM -0600, shuah wrote: On 8/23/19 8:38 PM, Greg KH wrote: On Fri, Aug 23, 2019 at 12:41:03PM -0600, shuah wrote: On 8/22/19 11:05 AM, Sasha Levin wrote: This is the start of the stable review cycle for the 5.2.10 release. There are 135 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat 24 Aug 2019 05:07:10 PM UTC. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-5.2.10-rc1.gz I am seeing "Sorry I can't find your kernels". Is this posted? Ah, Sasha didn't generate the patch but it was still listed here, oops. He copied my format and we didn't notice this, sorry about that. As the thread shows, we didn't generate this file this time to see what would happen. If your test process requires it, we can generate it as I don't want to break it. It will make it lot easier for me to have continued support for patch generation. My scripts do "wget" to pull the patch and apply. Ok, we will get this back and working, sorry about that. Great. Thanks for accommodating my workflow. thanks, -- Shuah
[GIT PULL] Hyper-V commits for v5.3-rc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The following changes since commit d1abaeb3be7b5fa6d7a1fbbd2e14e3310005c4c1: Linux 5.3-rc5 (2019-08-18 14:31:08 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git tags/hyperv-fixes-signed for you to fetch changes up to a9fc4340aee041dd186d1fb8f1b5d1e9caf28212: Drivers: hv: vmbus: Fix virt_to_hvpfn() for X86_PAE (2019-08-20 12:49:57 -0400) - - - Fix for panics and network failures on PAE guests by Dexuan Cui. - - Fix of a memory leak (and related cleanups) in the hyper-v keyboard driver by Dexuan Cui. - - Code cleanups for hyper-v clocksource driver during the merge window by Dexuan Cui. - - Fix for a false positive warning in the userspace hyper-v KVP store by Vitaly Kuznetsov. - Dexuan Cui (3): Drivers: hv: vmbus: Remove the unused "tsc_page" from struct hv_context Input: hyperv-keyboard: Use in-place iterator API in the channel callback Drivers: hv: vmbus: Fix virt_to_hvpfn() for X86_PAE Vitaly Kuznetsov (1): Tools: hv: kvp: eliminate 'may be used uninitialized' warning drivers/hv/channel.c | 2 +- drivers/hv/hyperv_vmbus.h | 2 -- drivers/input/serio/hyperv-keyboard.c | 35 ++- tools/hv/hv_kvp_daemon.c | 2 +- 4 files changed, 8 insertions(+), 33 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAl1hUC4ACgkQ3qZv95d3 LNzfPQ/7B2htJA7ZjiRqqoTFN6yQBGuuyCeoJyZhYOTRc5CZ3IPnEg7wcZ5cJ9xi 3ByRiRPWn3hqYgZXDA7pS6K4vAk/Gkafnq9E7d3SGhSNF9d+n9YzcIG5haRpFCfM nenQ1WCP6wXeF/VlwOCLnTIKPqWEzwaFAANvhbS/19Ab/6n8ww1J+jilvI1QOBCR hcUjP6+4Q/QuBZLQ/451ol7KMbAJkCdlq8tNJ2/OUm5dExajJuTVU55W/Qozmf9o X3Q7nKkK54N+iIj0N2oh8kaH0HzTLWM64qy48KDN5czgiQtTeesHq8BTkAldokPZ xZgK0jkJkZQL43ZzYs257rslr59j8Ol7CgnnIPrtM0YIE9tCiZdwBblKV0XgL/7m Op1cQheZc0gavm1ynq3/w0kOOdkBM32LExnJI112LfNP7nQPZ8MX+efT7z2IsMbh QK/NxcQL7pbgPs640uWqFicMQR+umwwQomEb39LDUh1/uzQEw9YCgVZU1JkcxJjd Se+ldSi1yEQJ66p1Jf2lyAdDiDg5OwvjZhL1SNmAvvwpw/tSY0t94cwpJxVZ8WuI pRDvWcVdxBJUExr7u0BaUWu3J8hYl+974GFCt+66M7tKDf8bsCOsfeBEqfPN5PNb /qU0a5pnQolJmEqdxY7TU0qBgA1xfaNbdJNrBOvsPr0dSRz4ElQ= =Dwtt -END PGP SIGNATURE-
Re: [PATCH] /dev/mem: Bail out upon SIGKILL when reading memory.
On Sat, Aug 24, 2019 at 9:14 AM Ingo Molnar wrote: > > What I noticed is that while reading regular RAM is reasonably fast even > in very large chunks, accesses become very slow once they hit iomem - and > delays even longer than the reported 145 seconds become possible if > bs=100M is increased to say bs=1000M. Ok, that makes sense. So for IOMEM, we actually have two independent issues: (a) for normal unmapped IOMEM (ie no device), which is probably the case your test triggers anyway, it quite possibly ends up having ISA timings (ie around 1us per read) (b) we use "probe_kernel_read()" to a temporary buffer avoid page faults, which uses __copy_from_user_inatomic(). So far so good. But on modern x86, because we treat it as just a regular memcpy, we probably have ERMS and do "rep movsb". So (a) means that each access is slow to begin with, and then (b) means that we don't use "copy_from_io()" but a slow byte-by-byte access. > With Tetsuo's approach the delays are fixed, because the fatal signal is > noticed within the 4K chunks of read_mem() immediately: Yeah. that's the size of the temp buffer. > Note how the first 100MB chunk took 17 seconds, the second chunk was > interrupted within ~2 seconds after I sent a SIGKILL. It looks closer to 1 second from that trace, but that actually is still within the basic noise above: a 4kB buffer being copied one byte at a time would take about 4s, but maybe it's not *quite* as bad as traditional ISA PIO timings. > Except that I think the regular pattern here is not 'break' but 'goto > failed' - 'break' would just result in a partial read and 'err' gets > ignored. That's actually the correct signal handling pattern: either a partial read, or -EINTR. In the case of SIGKILL, the return value doesn't matter, of course, but *if* we were to decide that we can make it interruptible, then it would. > I also agree that we should probably allow regular interrupts to > interrupt /dev/mem accesses - while the 'dd' process is killable, it's > not Ctrl-C-able. I'm a bit nervous about it, but there probably aren't all that many actual /dev/mem users. The main ones I can see are things like "dmidecode" etc. > If I change the fatal_signal_pending() to signal_pending() it all behaves > much better IMHO - assuming that no utility learned rely on > non-interruptibility ... So I cloned the dmidecode git tree, and it does "myread()" on the /dev/mem file as far as I can tell. And that one correctly hanles partial reads. It still makes me a bit nervous, but just plain "signal_pending()" is not just nicer, it's technically the right thing to do (it's not a regular file, so partial reads are permissible, and other files like it - eg /dev/zero - already does exactly that). I also wonder if we should just not use that crazy "probe_kernel_read()" to begin with. The /dev/mem code uses it to avoid faults - and that's the intent of it - but it's not meant for IO-memory at all. But "read()" on /dev/mem does that off "xlate_dev_mem_ptr()", which is a bastardized "kernel address or ioremap" thing. It works, but it's all kinds of stupid. We'd be a *lot* better off using kmap(), I think. So my gut feel is that this is something worth trying to do bigger and more fundamental changes to. But changing it to use "signal_pending()" at least as a trial looks ok. The only user *should* be things like dmidecode that apparently already do the right thing. And if we changed the bounce buffering to do things at least a 32-bit word at a time, that would help latency for IO by a factor of 4. And if the signal_pending() is at the end of the copy, then we'd guarantee that at least _small_ reads still work the way they did before, so people who do things like "lspci()" with direct hardware accesses wouldn't be impacted - if they exist. So I'd be willing to try that (and then if somebody reports a regression we can make it use "fatal_signal_pending()" instead) Linus
[PATCH] bus: sunxi-rsb: Make interrupt handling more robust
The RSB controller has two registers for controlling interrupt inputs:
RSB_INTE, which has bits for each possible interrupt, and the global
interrupt enable bit in RSB_CTRL.
Currently, we enable the bits in RSB_INTE before each transfer, but this
is unnecessary because we never disable them. Move the initialization of
RSB_INTE so it is done only once.
We also set the global interrupt enable bit before each transfer. Unlike
other bits in RSB_CTRL, this bit is cleared by writing a zero. Thus, we
clear the bit in the post-timeout cleanup code, so note that in the
comment.
However, if we do receive an interrupt, we do not clear the bit. Nor do
we clear interrupt statuses before starting a transfer. Thus, if some
other driver uses the RSB bus while Linux is suspended (as both Trusted
Firmware and SCP firmware do to control the PMIC), we receive spurious
interrupts upon resume. This causes false completion of a transfer, and
the next transfer starts prematurely, causing a LOAD_BSY condition. The
end result is that some transfers at resume fail with -EBUSY.
With this patch, all transfers reliably succeed during/after resume.
Signed-off-by: Samuel Holland
---
drivers/bus/sunxi-rsb.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
index be79d6c6a4e4..b8043b58568a 100644
--- a/drivers/bus/sunxi-rsb.c
+++ b/drivers/bus/sunxi-rsb.c
@@ -274,7 +274,7 @@ static int _sunxi_rsb_run_xfer(struct sunxi_rsb *rsb)
reinit_completion(&rsb->complete);
writel(RSB_INTS_LOAD_BSY | RSB_INTS_TRANS_ERR | RSB_INTS_TRANS_OVER,
- rsb->regs + RSB_INTE);
+ rsb->regs + RSB_INTS);
writel(RSB_CTRL_START_TRANS | RSB_CTRL_GLOBAL_INT_ENB,
rsb->regs + RSB_CTRL);
@@ -282,7 +282,7 @@ static int _sunxi_rsb_run_xfer(struct sunxi_rsb *rsb)
msecs_to_jiffies(100))) {
dev_dbg(rsb->dev, "RSB timeout\n");
- /* abort the transfer */
+ /* abort the transfer and disable interrupts */
writel(RSB_CTRL_ABORT_TRANS, rsb->regs + RSB_CTRL);
/* clear any interrupt flags */
@@ -480,6 +480,9 @@ static irqreturn_t sunxi_rsb_irq(int irq, void *dev_id)
status = readl(rsb->regs + RSB_INTS);
rsb->status = status;
+ /* Disable any further interrupts */
+ writel(0, rsb->regs + RSB_CTRL);
+
/* Clear interrupts */
status &= (RSB_INTS_LOAD_BSY | RSB_INTS_TRANS_ERR |
RSB_INTS_TRANS_OVER);
@@ -718,6 +721,9 @@ static int sunxi_rsb_probe(struct platform_device *pdev)
goto err_reset_assert;
}
+ writel(RSB_INTS_LOAD_BSY | RSB_INTS_TRANS_ERR | RSB_INTS_TRANS_OVER,
+ rsb->regs + RSB_INTE);
+
/* initialize all devices on the bus into RSB mode */
ret = sunxi_rsb_init_device_mode(rsb);
if (ret)
--
2.21.0
Re: [PATCH 4.19 00/85] 4.19.68-stable review
On 8/22/19 11:18 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.19.68 release. There are 85 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat 24 Aug 2019 05:15:49 PM UTC. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.68-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH] x86/Hyper-V: Fix build error with CONFIG_HYPERV_TSCPAGE=N
On Thu, Aug 22, 2019 at 10:39:46AM +0200, Vitaly Kuznetsov wrote: lantianyu1...@gmail.com writes: From: Tianyu Lan Both Hyper-V tsc page and Hyper-V tsc MSR code use variable hv_sched_clock_offset for their sched clock callback and so define the variable regardless of CONFIG_HYPERV_TSCPAGE setting. CONFIG_HYPERV_TSCPAGE is gone after my "x86/hyper-v: enable TSC page clocksource on 32bit" patch. Do we still have an issue to fix? Yes. Let's get it fixed on older kernels (as such we need to tag this one for stable). The 32bit TSC patch won't come in before 5.4 anyway. Vitaly, does can you ack this patch? It might require you to re-spin your patch. -- Thanks, Sasha
Re: [PATCH 4.14 00/71] 4.14.140-stable review
On 8/22/19 11:18 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.140 release. There are 71 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat 24 Aug 2019 05:15:46 PM UTC. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.140-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.9 000/103] 4.9.190-stable review
On 8/22/19 11:17 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.190 release. There are 103 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat 24 Aug 2019 05:15:44 PM UTC. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.190-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.4 00/78] 4.4.190-stable review
On 8/22/19 11:18 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.190 release. There are 78 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat 24 Aug 2019 05:18:13 PM UTC. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.190-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [GIT PULL rcu/next + tools/memory-model] RCU and LKMM commits for 5.4
On Sat, Aug 24, 2019 at 02:01:02PM +0200, Ingo Molnar wrote: > > * Paul E. McKenney wrote: > > > On Thu, Aug 22, 2019 at 08:54:29PM +0200, Ingo Molnar wrote: > > > > [ . . . ] > > > > > Pulled into tip:core/rcu, thanks a lot Paul! > > > > Thank you! > > > > > The merge commit is a bit non-standard: > > > > > > 07f038a408fb: Merge LKMM and RCU commits > > > > > > but clear enough IMHO. Usually we try to keep this format: > > > > > > 6c06b66e957c: Merge branch 'X' into Y > > > > > > even for internal merge commits. > > > > Please accept my apologies! How about as shown below? If this works > > for you, I will rebase my development commits on top this merge commit > > in order to make sure I don't revert back to my old format for next > > merge window. > > Looks good - but I don't think we should create a new merge commit just > for this. Ah, right -- I need to keep my development commits on top of the old merge commit to enable the likely additional pull request that I mentioned below. Good point! ;-) Thanx, Paul > > Ah, speaking of reminding me... There is likely to be one more small RCU > > commit requested by the RISC-V guys. If testing and review goes well, > > I will send you a pull request for it by the middle of next week. > > Thanks! > > Ingo
Re: [PATCH RT v2 1/3] rcu: Acquire RCU lock when disabling BHs
On Thu, Aug 22, 2019 at 10:23:23PM -0500, Scott Wood wrote:
> On Thu, 2019-08-22 at 09:39 -0400, Joel Fernandes wrote:
> > On Wed, Aug 21, 2019 at 04:33:58PM -0700, Paul E. McKenney wrote:
> > > On Wed, Aug 21, 2019 at 06:19:04PM -0500, Scott Wood wrote:
[ . . . ]
> > > > include/linux/rcupdate.h | 4
> > > > kernel/rcu/update.c | 4
> > > > kernel/softirq.c | 12 +---
> > > > 3 files changed, 17 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > > index 388ace315f32..d6e357378732 100644
> > > > --- a/include/linux/rcupdate.h
> > > > +++ b/include/linux/rcupdate.h
> > > > @@ -615,10 +615,12 @@ static inline void rcu_read_unlock(void)
> > > > static inline void rcu_read_lock_bh(void)
> > > > {
> > > > local_bh_disable();
> > > > +#ifndef CONFIG_PREEMPT_RT_FULL
> > > > __acquire(RCU_BH);
> > > > rcu_lock_acquire(&rcu_bh_lock_map);
> > > > RCU_LOCKDEP_WARN(!rcu_is_watching(),
> > > > "rcu_read_lock_bh() used illegally while
> > > > idle");
> > > > +#endif
> > >
> > > Any chance of this using "if (!IS_ENABLED(CONFIG_PREEMPT_RT_FULL))"?
> > > We should be OK providing a do-nothing __maybe_unused rcu_bh_lock_map
> > > for lockdep-enabled -rt kernels, right?
> >
> > Since this function is small, I prefer if -rt defines their own
> > rcu_read_lock_bh() which just does the local_bh_disable(). That would be
> > way
> > cleaner IMO. IIRC, -rt does similar things for spinlocks, but it has been
> > sometime since I look at the -rt patchset.
>
> I'll do it whichever way you all decide, though I'm not sure I agree about
> it being cleaner (especially while RT is still out-of-tree and a change to
> the non-RT version that fails to trigger a merge conflict is a concern).
>
> What about moving everything but the local_bh_disable into a separate
> function called from rcu_read_lock_bh, and making that a no-op on RT?
That makes a lot of sense to me!
Thanx, Paul
