April 2020 - Linux-stable-mirror

by Greg KH

I'm announcing the release of the 4.19.117 kernel. All users of the 4.19 kernel series must upgrade. The updated 4.19.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Makefile | 2 arch/x86/include/asm/microcode_amd.h | 2 arch/x86/kernel/cpu/intel_rdt.c | 2 arch/x86/kernel/cpu/intel_rdt.h | 1 arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 16 +++- arch/x86/kvm/cpuid.c | 3 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 5 + drivers/net/dsa/mt7530.c | 18 +++- drivers/net/dsa/mt7530.h | 7 + drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 2 drivers/net/wireless/ath/wil6210/debugfs.c | 29 ------- drivers/net/wireless/ath/wil6210/interrupt.c | 12 ++- drivers/net/wireless/ath/wil6210/main.c | 5 + drivers/net/wireless/ath/wil6210/txrx.c | 4 - drivers/net/wireless/ath/wil6210/txrx_edma.c | 14 ++- drivers/net/wireless/ath/wil6210/wil6210.h | 3 drivers/net/wireless/ath/wil6210/wmi.c | 2 drivers/net/wireless/mac80211_hwsim.c | 12 +-- drivers/pwm/pwm-pca9685.c | 85 ++++++++++++---------- drivers/scsi/ufs/ufshcd.c | 5 + drivers/target/iscsi/iscsi_target.c | 79 +++++--------------- drivers/target/iscsi/iscsi_target.h | 1 drivers/target/iscsi/iscsi_target_configfs.c | 5 + drivers/target/iscsi/iscsi_target_login.c | 5 - drivers/usb/dwc3/gadget.c | 18 ++-- fs/btrfs/relocation.c | 4 - fs/ext4/extents.c | 8 +- fs/ext4/super.c | 6 - fs/jbd2/commit.c | 7 + fs/overlayfs/inode.c | 4 - include/net/ip6_route.h | 1 include/target/iscsi/iscsi_target_core.h | 2 kernel/trace/trace_events_trigger.c | 10 -- mm/vmalloc.c | 8 +- net/core/dev.c | 3 net/hsr/hsr_netlink.c | 10 ++ net/ipv4/devinet.c | 13 ++- net/qrtr/qrtr.c | 7 + security/keys/proc.c | 2 sound/soc/intel/atom/sst-atom-controls.c | 2 sound/soc/intel/atom/sst/sst_pci.c | 2 sound/usb/mixer.c | 31 ++++---- sound/usb/mixer_maps.c | 4 - 44 files changed, 251 insertions(+), 212 deletions(-) Alexei Avshalom Lazar (1): wil6210: add general initialization/size checks Amir Goldstein (1): ovl: fix value of i_ino for lower hardlink corner case Austin Kim (1): mm/vmalloc.c: move 'area->pages' after if statement Can Guo (1): scsi: ufs: Fix ufshcd_hold() caused scheduling while atomic Colin Ian King (2): ASoC: Intel: mrfld: fix incorrect check on p->sink ASoC: Intel: mrfld: return error codes when an error occurs DENG Qingfang (1): net: dsa: mt7530: fix tagged frames pass-through in VLAN-unaware mode Dedy Lansky (2): wil6210: check rx_buff_mgmt before accessing it wil6210: make sure Rx ring sizes are correlated Florian Fainelli (1): net: stmmac: dwmac-sunxi: Provide TX and RX fifo sizes Greg Kroah-Hartman (1): Linux 4.19.117 James Morse (1): x86/resctrl: Preserve CDP enable over CPU hotplug Jan Kara (1): ext4: do not zeroout extents beyond i_disksize Jim Mattson (1): kvm: x86: Host feature SSBD doesn't imply guest feature SPEC_CTRL_SSBD John Allen (1): x86/microcode/AMD: Increase microcode PATCH_MAX_SIZE Josef Bacik (1): btrfs: check commit root generation in should_ignore_root Josh Triplett (2): ext4: fix incorrect group count in ext4_fill_super error message ext4: fix incorrect inodes per group in error message Karthick Gopalasubramanian (1): wil6210: remove reset file from debugfs Konstantin Khlebnikov (1): net: revert default NAPI poll timeout to 2 jiffies Maurizio Lombardi (2): scsi: target: remove boilerplate code scsi: target: fix hang when multiple threads try to destroy the same iscsi session Maya Erez (1): wil6210: ignore HALP ICR if already handled Reinette Chatre (1): x86/resctrl: Fix invalid attempt at removing the default resource group Sasha Levin (1): usb: dwc3: gadget: don't enable interrupt when disabling endpoint Sebastian Andrzej Siewior (1): amd-xgbe: Use __napi_schedule() in BH context Sergei Lopatin (1): drm/amd/powerplay: force the trim of the mclk dpm_levels if OD is enabled Sven Van Asbroeck (1): pwm: pca9685: Fix PWM/GPIO inter-operation Taehee Yoo (1): hsr: check protocol version in hsr_newlink() Takashi Iwai (4): ALSA: usb-audio: Filter error from connector kctl ops, too ALSA: usb-audio: Don't override ignore_ctl_error value from the map ALSA: usb-audio: Don't create jack controls for PCM terminals ALSA: usb-audio: Check mapping at creating connector controls, too Taras Chornyi (1): net: ipv4: devinet: Fix crash when add/del multicast IP with autojoin Thinh Nguyen (1): usb: dwc3: gadget: Don't clear flags before transfer ended Tim Stallard (1): net: ipv6: do not consider routes via gateways for anycast address check Tuomas Tynkkynen (1): mac80211_hwsim: Use kstrndup() in place of kasprintf() Vasily Averin (1): keys: Fix proc_keys_next to increase position index Wang Wenhu (1): net: qrtr: send msgs from local of same id as broadcast Xiao Yang (1): tracing: Fix the race between registering 'snapshot' event trigger and triggering 'snapshot' operation zhangyi (F) (1): jbd2: improve comments about freeing data buffers whose page mapping is NULL

4 years, 8 months

1
1
0 0

[PATCH v2] platform/x86: intel_int0002_vgpio: Only bind to the INT0002 dev when using s2idle

by Hans de Goede

Commit 871f1f2bcb01 ("platform/x86: intel_int0002_vgpio: Only implement irq_set_wake on Bay Trail") stopped passing irq_set_wake requests on to the parents IRQ because this was breaking suspend (causing immediate wakeups) on an Asus E202SA. This workaround for this issue is mostly fine, on most Cherry Trail devices where we need the INT0002 device for wakeups by e.g. USB kbds, the parent IRQ is shared with the ACPI SCI and that is marked as wakeup anyways. But not on all devices, specifically on a Medion Akoya E1239T there is no SCI at all, and because the irq_set_wake request is not passed on to the parent IRQ, wake up by the builtin USB kbd does not work here. So the workaround for the Asus E202SA immediate wake problem is causing problems elsewhere; and in hindsight it is not the correct fix, the Asus E202SA uses Airmont CPU cores, but this does not mean it is a Cherry Trail based device, Brasswell uses Airmont CPU cores too and this actually is a Braswell device. Most (all?) Braswell devices use classic S3 mode suspend rather then s2idle suspend and in this case directly dealing with PME events as the INT0002 driver does likely is not the best idea, so that this is causing issues is not surprising. Replace the workaround of not passing irq_set_wake requests on to the parents IRQ, by not binding to the INT0002 device when s2idle is not used. This fixes USB kbd wakeups not working on some Cherry Trail devices, while still avoiding mucking with the wakeup flags on the Asus E202SA (and other Brasswell devices). Cc: Maxim Mikityanskiy <maxtram95(a)gmail.com> Cc: 5.3+ <stable(a)vger.kernel.org> # 5.3+ Fixes: 871f1f2bcb01 ("platform/x86: intel_int0002_vgpio: Only implement irq_set_wake on Bay Trail") Tested-by: Maxim Mikityanskiy <maxtram95(a)gmail.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- Changes in v2: - Rebase on top of 5.7-rc1 --- drivers/platform/x86/intel_int0002_vgpio.c | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/drivers/platform/x86/intel_int0002_vgpio.c b/drivers/platform/x86/intel_int0002_vgpio.c index 289c6655d425..30806046b664 100644 --- a/drivers/platform/x86/intel_int0002_vgpio.c +++ b/drivers/platform/x86/intel_int0002_vgpio.c @@ -143,21 +143,9 @@ static struct irq_chip int0002_byt_irqchip = { .irq_set_wake = int0002_irq_set_wake, }; -static struct irq_chip int0002_cht_irqchip = { - .name = DRV_NAME, - .irq_ack = int0002_irq_ack, - .irq_mask = int0002_irq_mask, - .irq_unmask = int0002_irq_unmask, - /* - * No set_wake, on CHT the IRQ is typically shared with the ACPI SCI - * and we don't want to mess with the ACPI SCI irq settings. - */ - .flags = IRQCHIP_SKIP_SET_WAKE, -}; - static const struct x86_cpu_id int0002_cpu_ids[] = { X86_MATCH_INTEL_FAM6_MODEL(ATOM_SILVERMONT, &int0002_byt_irqchip), - X86_MATCH_INTEL_FAM6_MODEL(ATOM_AIRMONT, &int0002_cht_irqchip), + X86_MATCH_INTEL_FAM6_MODEL(ATOM_AIRMONT, &int0002_byt_irqchip), {} }; @@ -181,6 +169,10 @@ static int int0002_probe(struct platform_device *pdev) if (!cpu_id) return -ENODEV; + /* We only need to directly deal with PMEs when using s2idle */ + if (!pm_suspend_default_s2idle()) + return -ENODEV; + irq = platform_get_irq(pdev, 0); if (irq < 0) return irq; -- 2.26.0

4 years, 8 months

2
5
0 0

[PATCH AUTOSEL 5.5 01/35] ARM: dts: sun8i-a83t-tbs-a711: HM5065 doesn't like such a high voltage

by Sasha Levin

From: Ondrej Jirman <megous(a)megous.com> [ Upstream commit a40550952c000667b20082d58077bc647da6c890 ] Lowering the voltage solves the quick image degradation over time (minutes), that was probably caused by overheating. Signed-off-by: Ondrej Jirman <megous(a)megous.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts index f781d330cff50..e8b3669e0e5d8 100644 --- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts +++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts @@ -374,8 +374,8 @@ }; &reg_dldo3 { - regulator-min-microvolt = <2800000>; - regulator-max-microvolt = <2800000>; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; regulator-name = "vdd-csi"; }; -- 2.20.1

4 years, 8 months

4
40
0 0

[PATCH AUTOSEL 5.5 01/75] iommu/amd: Fix the configuration of GCR3 table root pointer

by Sasha Levin

From: Adrian Huang <ahuang12(a)lenovo.com> [ Upstream commit c20f36534666e37858a14e591114d93cc1be0d34 ] The SPA of the GCR3 table root pointer[51:31] masks 20 bits. However, this requires 21 bits (Please see the AMD IOMMU specification). This leads to the potential failure when the bit 51 of SPA of the GCR3 table root pointer is 1'. Signed-off-by: Adrian Huang <ahuang12(a)lenovo.com> Fixes: 52815b75682e2 ("iommu/amd: Add support for IOMMUv2 domain mode") Signed-off-by: Joerg Roedel <jroedel(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/iommu/amd_iommu_types.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h index 798e1533a1471..d336ae8f5c73b 100644 --- a/drivers/iommu/amd_iommu_types.h +++ b/drivers/iommu/amd_iommu_types.h @@ -348,7 +348,7 @@ #define DTE_GCR3_VAL_A(x) (((x) >> 12) & 0x00007ULL) #define DTE_GCR3_VAL_B(x) (((x) >> 15) & 0x0ffffULL) -#define DTE_GCR3_VAL_C(x) (((x) >> 31) & 0xfffffULL) +#define DTE_GCR3_VAL_C(x) (((x) >> 31) & 0x1fffffULL) #define DTE_GCR3_INDEX_A 0 #define DTE_GCR3_INDEX_B 1 -- 2.20.1

4 years, 8 months

3
77
0 0

[PATCH AUTOSEL 4.19 01/47] iommu/amd: Fix the configuration of GCR3 table root pointer

by Sasha Levin

From: Adrian Huang <ahuang12(a)lenovo.com> [ Upstream commit c20f36534666e37858a14e591114d93cc1be0d34 ] The SPA of the GCR3 table root pointer[51:31] masks 20 bits. However, this requires 21 bits (Please see the AMD IOMMU specification). This leads to the potential failure when the bit 51 of SPA of the GCR3 table root pointer is 1'. Signed-off-by: Adrian Huang <ahuang12(a)lenovo.com> Fixes: 52815b75682e2 ("iommu/amd: Add support for IOMMUv2 domain mode") Signed-off-by: Joerg Roedel <jroedel(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/iommu/amd_iommu_types.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h index 69f3d4c95b530..859b06424e5c4 100644 --- a/drivers/iommu/amd_iommu_types.h +++ b/drivers/iommu/amd_iommu_types.h @@ -352,7 +352,7 @@ #define DTE_GCR3_VAL_A(x) (((x) >> 12) & 0x00007ULL) #define DTE_GCR3_VAL_B(x) (((x) >> 15) & 0x0ffffULL) -#define DTE_GCR3_VAL_C(x) (((x) >> 31) & 0xfffffULL) +#define DTE_GCR3_VAL_C(x) (((x) >> 31) & 0x1fffffULL) #define DTE_GCR3_INDEX_A 0 #define DTE_GCR3_INDEX_B 1 -- 2.20.1

4 years, 8 months

2
47
0 0

FAILED: patch "[PATCH] tracing: Fix the race between registering 'snapshot' event" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 0bbe7f719985efd9adb3454679ecef0984cb6800 Mon Sep 17 00:00:00 2001 From: Xiao Yang <yangx.jy(a)cn.fujitsu.com> Date: Tue, 14 Apr 2020 09:51:45 +0800 Subject: [PATCH] tracing: Fix the race between registering 'snapshot' event trigger and triggering 'snapshot' operation Traced event can trigger 'snapshot' operation(i.e. calls snapshot_trigger() or snapshot_count_trigger()) when register_snapshot_trigger() has completed registration but doesn't allocate buffer for 'snapshot' event trigger. In the rare case, 'snapshot' operation always detects the lack of allocated buffer so make register_snapshot_trigger() allocate buffer first. trigger-snapshot.tc in kselftest reproduces the issue on slow vm: ----------------------------------------------------------- cat trace ... ftracetest-3028 [002] .... 236.784290: sched_process_fork: comm=ftracetest pid=3028 child_comm=ftracetest child_pid=3036 <...>-2875 [003] .... 240.460335: tracing_snapshot_instance_cond: *** SNAPSHOT NOT ALLOCATED *** <...>-2875 [003] .... 240.460338: tracing_snapshot_instance_cond: *** stopping trace here! *** ----------------------------------------------------------- Link: http://lkml.kernel.org/r/20200414015145.66236-1-yangx.jy@cn.fujitsu.com Cc: stable(a)vger.kernel.org Fixes: 93e31ffbf417a ("tracing: Add 'snapshot' event trigger command") Signed-off-by: Xiao Yang <yangx.jy(a)cn.fujitsu.com> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c index dd34a1b46a86..3a74736da363 100644 --- a/kernel/trace/trace_events_trigger.c +++ b/kernel/trace/trace_events_trigger.c @@ -1088,14 +1088,10 @@ register_snapshot_trigger(char *glob, struct event_trigger_ops *ops, struct event_trigger_data *data, struct trace_event_file *file) { - int ret = register_trigger(glob, ops, data, file); - - if (ret > 0 && tracing_alloc_snapshot_instance(file->tr) != 0) { - unregister_trigger(glob, ops, data, file); - ret = 0; - } + if (tracing_alloc_snapshot_instance(file->tr) != 0) + return 0; - return ret; + return register_trigger(glob, ops, data, file); } static int

4 years, 8 months

3
2
0 0

[PATCH v2] x86/hyperv: Suspend/resume the VP assist page for hibernation

by Dexuan Cui

Unlike the other CPUs, CPU0 is never offlined during hibernation, so in the resume path, the "new" kernel's VP assist page is not suspended (i.e. not disabled), and later when we jump to the "old" kernel, the page is not properly re-enabled for CPU0 with the allocated page from the old kernel. So far, the VP assist page is used by hv_apic_eoi_write(), and is also used in the case of nested virtualization (running KVM atop Hyper-V). For hv_apic_eoi_write(), when the page is not properly re-enabled, hvp->apic_assist is always 0, so the HV_X64_MSR_EOI MSR is always written. This is not ideal with respect to performance, but Hyper-V can still correctly handle this according to the Hyper-V spec; nevertheless, Linux still must update the Hyper-V hypervisor with the correct VP assist page to prevent Hyper-V from writing to the stale page, which causes guest memory corruption and consequently may have caused the hangs and triple faults seen during non-boot CPUs resume. Fix the issue by calling hv_cpu_die()/hv_cpu_init() in the syscore ops. Without the fix, hibernation can fail at a rate of 1/300 ~ 1/500. With the fix, hibernation can pass a long-haul test of 2000 runs. In the case of nested virtualization, disabling/reenabling the assist page upon hibernation may be unsafe if there are active L2 guests. It looks KVM should be enhanced to abort the hibernation request if there is any active L2 guest. Fixes: 05bd330a7fd8 ("x86/hyperv: Suspend/resume the hypercall page for hibernation") Cc: stable(a)vger.kernel.org Signed-off-by: Dexuan Cui <decui(a)microsoft.com> --- Changes in v2: Used alloc_page(irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL) [Wei Liu] Improved the changelog per comments from Wei Liu and Vitaly Kuznetsov. arch/x86/hyperv/hv_init.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c index b0da5320bcff..a151ec7feb4b 100644 --- a/arch/x86/hyperv/hv_init.c +++ b/arch/x86/hyperv/hv_init.c @@ -72,7 +72,8 @@ static int hv_cpu_init(unsigned int cpu) struct page *pg; input_arg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg); - pg = alloc_page(GFP_KERNEL); + /* hv_cpu_init() can be called with IRQs disabled from hv_resume() */ + pg = alloc_page(irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL); if (unlikely(!pg)) return -ENOMEM; *input_arg = page_address(pg); @@ -253,6 +254,7 @@ static int __init hv_pci_init(void) static int hv_suspend(void) { union hv_x64_msr_hypercall_contents hypercall_msr; + int ret; /* * Reset the hypercall page as it is going to be invalidated @@ -269,12 +271,17 @@ static int hv_suspend(void) hypercall_msr.enable = 0; wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); - return 0; + ret = hv_cpu_die(0); + return ret; } static void hv_resume(void) { union hv_x64_msr_hypercall_contents hypercall_msr; + int ret; + + ret = hv_cpu_init(0); + WARN_ON(ret); /* Re-enable the hypercall page */ rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64); @@ -287,6 +294,7 @@ static void hv_resume(void) hv_hypercall_pg_saved = NULL; } +/* Note: when the ops are called, only CPU0 is online and IRQs are disabled. */ static struct syscore_ops hv_syscore_ops = { .suspend = hv_suspend, .resume = hv_resume, -- 2.19.1

4 years, 8 months

2
1
0 0

[PATCH] nvme/pci: Use Discard instead of Write Zeroes on SK hynix SC300

by Kai-Heng Feng

After commit 6e02318eaea5 ("nvme: add support for the Write Zeroes command"), SK hynix SC300 becomes very slow with the following error message: [ 224.567695] blk_update_request: operation not supported error, dev nvme1n1, sector 499384320 op 0x9:(WRITE_ZEROES) flags 0x1000000 phys_seg 0 prio class 0] Use quirk NVME_QUIRK_DEALLOCATE_ZEROES to workaround this issue. BugLink: https://bugs.launchpad.net/bugs/1872383 Cc: linux-stable <stable(a)vger.kernel.org> # >= 5.1 Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- drivers/nvme/host/pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 4e79e412b276..e3f4dac823d8 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -3068,6 +3068,8 @@ static const struct pci_device_id nvme_id_table[] = { .driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, }, { PCI_DEVICE(0x1c58, 0x0023), /* WDC SN200 adapter */ .driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, }, + { PCI_DEVICE(0x1c5c, 0x1504), /* SK hynix SC300 */ + .driver_data = NVME_QUIRK_DEALLOCATE_ZEROES, }, { PCI_DEVICE(0x1c5f, 0x0540), /* Memblaze Pblaze4 adapter */ .driver_data = NVME_QUIRK_DELAY_BEFORE_CHK_RDY, }, { PCI_DEVICE(0x144d, 0xa821), /* Samsung PM1725 */ -- 2.17.1

4 years, 8 months

3
4
0 0

[PATCH] ARM: imx: provide v7_cpu_resume() only on ARM_CPU_SUSPEND=y

by Ahmad Fatoum

512a928affd5 ("ARM: imx: build v7_cpu_resume() unconditionally") introduced an unintended linker error for i.MX6 configurations that have ARM_CPU_SUSPEND=n which can happen if neither CONFIG_PM, CONFIG_CPU_IDLE, nor ARM_PSCI_FW are selected. Fix this by having v7_cpu_resume() compiled only when cpu_resume() it calls is available as well. The C declaration for the function remains unguarded to avoid future code inadvertently using a stub and introducing a regression to the bug the original commit fixed. Cc: <stable(a)vger.kernel.org> Fixes: 512a928affd5 ("ARM: imx: build v7_cpu_resume() unconditionally") Reported-by: Clemens Gruber <clemens.gruber(a)pqgruber.com> Signed-off-by: Ahmad Fatoum <a.fatoum(a)pengutronix.de> --- arch/arm/mach-imx/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile index 03506ce46149..e7364e6c8c6b 100644 --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -91,8 +91,10 @@ AFLAGS_suspend-imx6.o :=-Wa,-march=armv7-a obj-$(CONFIG_SOC_IMX6) += suspend-imx6.o obj-$(CONFIG_SOC_IMX53) += suspend-imx53.o endif +ifeq ($(CONFIG_ARM_CPU_SUSPEND),y) AFLAGS_resume-imx6.o :=-Wa,-march=armv7-a obj-$(CONFIG_SOC_IMX6) += resume-imx6.o +endif obj-$(CONFIG_SOC_IMX6) += pm-imx6.o obj-$(CONFIG_SOC_IMX1) += mach-imx1.o -- 2.25.1

4 years, 8 months

3
4
0 0

[PATCH AUTOSEL 4.9 01/26] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware

by Sasha Levin

From: Masahiro Yamada <masahiroy(a)kernel.org> [ Upstream commit 63b903dfebdea92aa92ad337d8451a6fbfeabf9d ] As far as I understood from the Kconfig help text, this build rule is used to rebuild the driver firmware, which runs on an old m68k-based chip. So, you need m68k tools for the firmware rebuild. wanxl.c is a PCI driver, but CONFIG_M68K does not select CONFIG_HAVE_PCI. So, you cannot enable CONFIG_WANXL_BUILD_FIRMWARE for ARCH=m68k. In other words, ifeq ($(ARCH),m68k) is false here. I am keeping the dead code for now, but rebuilding the firmware requires 'as68k' and 'ld68k', which I do not have in hand. Instead, the kernel.org m68k GCC [1] successfully built it. Allowing a user to pass in CROSS_COMPILE_M68K= is handier. [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/9.2.0/… Suggested-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/wan/Kconfig | 2 +- drivers/net/wan/Makefile | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig index 4e9fe75d70675..21190dfbabb16 100644 --- a/drivers/net/wan/Kconfig +++ b/drivers/net/wan/Kconfig @@ -199,7 +199,7 @@ config WANXL_BUILD_FIRMWARE depends on WANXL && !PREVENT_FIRMWARE_BUILD help Allows you to rebuild firmware run by the QUICC processor. - It requires as68k, ld68k and hexdump programs. + It requires m68k toolchains and hexdump programs. You should never need this option, say N. diff --git a/drivers/net/wan/Makefile b/drivers/net/wan/Makefile index 73c2326603fcc..fbe8b2815a87c 100644 --- a/drivers/net/wan/Makefile +++ b/drivers/net/wan/Makefile @@ -40,17 +40,17 @@ $(obj)/wanxl.o: $(obj)/wanxlfw.inc ifeq ($(CONFIG_WANXL_BUILD_FIRMWARE),y) ifeq ($(ARCH),m68k) - AS68K = $(AS) - LD68K = $(LD) + M68KAS = $(AS) + M68KLD = $(LD) else - AS68K = as68k - LD68K = ld68k + M68KAS = $(CROSS_COMPILE_M68K)as + M68KLD = $(CROSS_COMPILE_M68K)ld endif quiet_cmd_build_wanxlfw = BLD FW $@ cmd_build_wanxlfw = \ - $(CPP) -D__ASSEMBLY__ -Wp,-MD,$(depfile) -I$(srctree)/include/uapi $< | $(AS68K) -m68360 -o $(obj)/wanxlfw.o; \ - $(LD68K) --oformat binary -Ttext 0x1000 $(obj)/wanxlfw.o -o $(obj)/wanxlfw.bin; \ + $(CPP) -D__ASSEMBLY__ -Wp,-MD,$(depfile) -I$(srctree)/include/uapi $< | $(M68KAS) -m68360 -o $(obj)/wanxlfw.o; \ + $(M68KLD) --oformat binary -Ttext 0x1000 $(obj)/wanxlfw.o -o $(obj)/wanxlfw.bin; \ hexdump -ve '"\n" 16/1 "0x%02X,"' $(obj)/wanxlfw.bin | sed 's/0x ,//g;1s/^/static const u8 firmware[]={/;$$s/,$$/\n};\n/' >$(obj)/wanxlfw.inc; \ rm -f $(obj)/wanxlfw.bin $(obj)/wanxlfw.o -- 2.20.1

4 years, 8 months

9
72
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2020