summaryrefslogtreecommitdiffstats
path: root/drivers (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'clk-fixes-for-linus' of ↵Linus Torvalds2020-04-195-41/+35
|\ | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "Two build fixes for a couple clk drivers and a fix for the Unisoc serial clk where we want to keep it on for earlycon" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: sprd: don't gate uart console clock clk: mmp2: fix link error without mmp2 clk: asm9260: fix __clk_hw_register_fixed_rate_with_accuracy typo
| * clk: sprd: don't gate uart console clockChunyan Zhang2020-04-131-1/+2
| | | | | | | | | | | | | | | | | | | | Don't gate uart1_eb which provides console clock, gating that clock would make serial stop working if serial driver didn't enable that explicitly. Fixes: 0e4b8a2349f3 ("clk: sprd: add clocks support for SC9863A") Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Link: https://lkml.kernel.org/r/20200408020234.31764-1-zhang.lyra@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
| * clk: mmp2: fix link error without mmp2Arnd Bergmann2020-04-133-39/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The newly added function is only built into the kernel if mmp2 is enabled, causing a link error otherwise. arm-linux-gnueabi-ld: drivers/clk/mmp/clk.o: in function `mmp_register_pll_clks': clk.c:(.text+0x6dc): undefined reference to `mmp_clk_register_pll' Move it to a different file to get it to link. Fixes: 5d34d0b32d6c ("clk: mmp2: Add support for PLL clock sources") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lkml.kernel.org/r/20200408160518.2798571-1-arnd@arndb.de Reported-by: Guenter Roeck <linux@roeck-us.net> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
| * clk: asm9260: fix __clk_hw_register_fixed_rate_with_accuracy typoArnd Bergmann2020-04-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The __clk_hw_register_fixed_rate_with_accuracy() function (with two '_') does not exist, and apparently never did: drivers/clk/clk-asm9260.c: In function 'asm9260_acc_init': drivers/clk/clk-asm9260.c:279:7: error: implicit declaration of function '__clk_hw_register_fixed_rate_with_accuracy'; did you mean 'clk_hw_register_fixed_rate_with_accuracy'? [-Werror=implicit-function-declaration] 279 | hw = __clk_hw_register_fixed_rate_with_accuracy(NULL, NULL, pll_clk, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | clk_hw_register_fixed_rate_with_accuracy drivers/clk/clk-asm9260.c:279:5: error: assignment to 'struct clk_hw *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion] 279 | hw = __clk_hw_register_fixed_rate_with_accuracy(NULL, NULL, pll_clk, | ^ From what I can tell, __clk_hw_register_fixed_rate() is the correct API here, so use that instead. Fixes: 728e3096741a ("clk: asm9260: Use parent accuracy in fixed rate clk") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lkml.kernel.org/r/20200408155402.2138446-1-arnd@arndb.de Signed-off-by: Stephen Boyd <sboyd@kernel.org>
* | Merge tag 'irq-urgent-2020-04-19' of ↵Linus Torvalds2020-04-198-17/+49
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fixes from Thomas Gleixner: "A set of fixes/updates for the interrupt subsystem: - Remove setup_irq() and remove_irq(). All users have been converted so remove them before new users surface. - A set of bugfixes for various interrupt chip drivers - Add a few missing static attributes to address sparse warnings" * tag 'irq-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/irq-bcm7038-l1: Make bcm7038_l1_of_init() static irqchip/irq-mvebu-icu: Make legacy_bindings static irqchip/meson-gpio: Fix HARDIRQ-safe -> HARDIRQ-unsafe lock order irqchip/sifive-plic: Fix maximum priority threshold value irqchip/ti-sci-inta: Fix processing of masked irqs irqchip/mbigen: Free msi_desc on device teardown irqchip/gic-v4.1: Update effective affinity of virtual SGIs irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signaling genirq: Remove setup_irq() and remove_irq()
| * \ Merge branch 'irq/gic-v4.1-fixes-5.7' into irq/irqchip-5.7Marc Zyngier2020-04-172-4/+27
| |\ \
| | * | irqchip/gic-v4.1: Update effective affinity of virtual SGIsMarc Zyngier2020-04-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although the vSGIs are not directly visible to the host, they still get moved around by the CPU hotplug, for example. This results in the kernel moaning on the console, such as: genirq: irq_chip GICv4.1-sgi did not update eff. affinity mask of irq 38 Updating the effective affinity on set_affinity() fixes it. Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
| | * | irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signalingMarc Zyngier2020-04-162-4/+26
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a vPE is made resident, the GIC starts parsing the virtual pending table to deliver pending interrupts. This takes place asynchronously, and can at times take a long while. Long enough that the vcpu enters the guest and hits WFI before any interrupt has been signaled yet. The vcpu then exits, blocks, and now gets a doorbell. Rince, repeat. In order to avoid the above, a (optional on GICv4, mandatory on v4.1) feature allows the GIC to feedback to the hypervisor whether it is done parsing the VPT by clearing the GICR_VPENDBASER.Dirty bit. The hypervisor can then wait until the GIC is ready before actually running the vPE. Plug the detection code as well as polling on vPE schedule. While at it, tidy-up the kernel message that displays the GICv4 optional features. Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
| * | irqchip/irq-bcm7038-l1: Make bcm7038_l1_of_init() staticJason Yan2020-04-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following sparse warning: drivers/irqchip/irq-bcm7038-l1.c:419:12: warning: symbol 'bcm7038_l1_of_init' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200417074036.46594-1-yanaijie@huawei.com
| * | irqchip/irq-mvebu-icu: Make legacy_bindings staticJason Yan2020-04-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following sparse warning: drivers/irqchip/irq-mvebu-icu.c:69:1: warning: symbol 'legacy_bindings' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200417074046.46771-1-yanaijie@huawei.com
| * | irqchip/meson-gpio: Fix HARDIRQ-safe -> HARDIRQ-unsafe lock orderMarc Zyngier2020-04-171-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Running a lockedp-enabled kernel on a vim3l board (Amlogic SM1) leads to the following splat: [ 13.557138] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 13.587485] ip/456 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 13.625922] ffff000059908cf0 (&irq_desc_lock_class){-.-.}-{2:2}, at: __setup_irq+0xf8/0x8d8 [ 13.632273] which would create a new lock dependency: [ 13.637272] (&irq_desc_lock_class){-.-.}-{2:2} -> (&ctl->lock){+.+.}-{2:2} [ 13.644209] [ 13.644209] but this new dependency connects a HARDIRQ-irq-safe lock: [ 13.654122] (&irq_desc_lock_class){-.-.}-{2:2} [ 13.654125] [ 13.654125] ... which became HARDIRQ-irq-safe at: [ 13.664759] lock_acquire+0xec/0x368 [ 13.666926] _raw_spin_lock+0x60/0x88 [ 13.669979] handle_fasteoi_irq+0x30/0x178 [ 13.674082] generic_handle_irq+0x38/0x50 [ 13.678098] __handle_domain_irq+0x6c/0xc8 [ 13.682209] gic_handle_irq+0x5c/0xb0 [ 13.685872] el1_irq+0xd0/0x180 [ 13.689010] arch_cpu_idle+0x40/0x220 [ 13.692732] default_idle_call+0x54/0x60 [ 13.696677] do_idle+0x23c/0x2e8 [ 13.699903] cpu_startup_entry+0x30/0x50 [ 13.703852] rest_init+0x1e0/0x2b4 [ 13.707301] arch_call_rest_init+0x18/0x24 [ 13.711449] start_kernel+0x4ec/0x51c [ 13.715167] [ 13.715167] to a HARDIRQ-irq-unsafe lock: [ 13.722426] (&ctl->lock){+.+.}-{2:2} [ 13.722430] [ 13.722430] ... which became HARDIRQ-irq-unsafe at: [ 13.732319] ... [ 13.732324] lock_acquire+0xec/0x368 [ 13.735985] _raw_spin_lock+0x60/0x88 [ 13.739452] meson_gpio_irq_domain_alloc+0xcc/0x290 [ 13.744392] irq_domain_alloc_irqs_hierarchy+0x24/0x60 [ 13.749586] __irq_domain_alloc_irqs+0x160/0x2f0 [ 13.754254] irq_create_fwspec_mapping+0x118/0x320 [ 13.759073] irq_create_of_mapping+0x78/0xa0 [ 13.763360] of_irq_get+0x6c/0x80 [ 13.766701] of_mdiobus_register_phy+0x10c/0x238 [of_mdio] [ 13.772227] of_mdiobus_register+0x158/0x380 [of_mdio] [ 13.777388] mdio_mux_init+0x180/0x2e8 [mdio_mux] [ 13.782128] g12a_mdio_mux_probe+0x290/0x398 [mdio_mux_meson_g12a] [ 13.788349] platform_drv_probe+0x5c/0xb0 [ 13.792379] really_probe+0xe4/0x448 [ 13.795979] driver_probe_device+0xe8/0x140 [ 13.800189] __device_attach_driver+0x94/0x120 [ 13.804639] bus_for_each_drv+0x84/0xd8 [ 13.808474] __device_attach+0xe4/0x168 [ 13.812361] device_initial_probe+0x1c/0x28 [ 13.816592] bus_probe_device+0xa4/0xb0 [ 13.820430] deferred_probe_work_func+0xa8/0x100 [ 13.825064] process_one_work+0x264/0x688 [ 13.829088] worker_thread+0x4c/0x458 [ 13.832768] kthread+0x154/0x158 [ 13.836018] ret_from_fork+0x10/0x18 [ 13.839612] [ 13.839612] other info that might help us debug this: [ 13.839612] [ 13.850354] Possible interrupt unsafe locking scenario: [ 13.850354] [ 13.855720] CPU0 CPU1 [ 13.858774] ---- ---- [ 13.863242] lock(&ctl->lock); [ 13.866330] local_irq_disable(); [ 13.872233] lock(&irq_desc_lock_class); [ 13.878705] lock(&ctl->lock); [ 13.884297] <Interrupt> [ 13.886857] lock(&irq_desc_lock_class); [ 13.891014] [ 13.891014] *** DEADLOCK *** The issue can occur when CPU1 is doing something like irq_set_type() and CPU0 performing an interrupt allocation, for example. Taking an interrupt (like the one being reconfigured) would lead to a deadlock. A solution to this is: - Reorder the locking so that meson_gpio_irq_update_bits takes the lock itself at all times, instead of relying on the caller to lock or not, hence making the RMW sequence atomic, - Rework the critical section in meson_gpio_irq_request_channel to only cover the allocation itself, and let the gpio_irq_sel_pin callback deal with its own locking if required, - Take the private spin-lock with interrupts disabled at all times Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
| * | irqchip/sifive-plic: Fix maximum priority threshold valueAtish Patra2020-04-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per the PLIC specification, maximum priority threshold value is 0x7 not 0xF. Even though it doesn't cause any error in qemu/hifive unleashed, there may be some implementation which checks the upper bound resulting in an illegal access. Fixes: ccbe80bad571 ("irqchip/sifive-plic: Enable/Disable external interrupts upon cpu online/offline") Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200403014609.71831-1-atish.patra@wdc.com
| * | irqchip/ti-sci-inta: Fix processing of masked irqsGrygorii Strashko2020-04-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ti_sci_inta_irq_handler() does not take into account INTA IRQs state (masked/unmasked) as it uses INTA_STATUS_CLEAR_j register to get INTA IRQs status, which provides raw status value. This causes hard IRQ handlers to be called or threaded handlers to be scheduled many times even if corresponding INTA IRQ is masked. Above, first of all, affects the LEVEL interrupts processing and causes unexpected behavior up the system stack or crash. Fix it by using the Interrupt Masked Status INTA_STATUSM_j register which provides masked INTA IRQs status. Fixes: 9f1463b86c13 ("irqchip/ti-sci-inta: Add support for Interrupt Aggregator driver") Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20200408191532.31252-1-grygorii.strashko@ti.com Cc: stable@vger.kernel.org
| * | irqchip/mbigen: Free msi_desc on device teardownZenghui Yu2020-04-171-1/+7
| |/ | | | | | | | | | | | | | | | | | | | | Using irq_domain_free_irqs_common() on the irqdomain free path will leave the MSI descriptor unfreed when platform devices get removed. Properly free it by MSI domain free function. Fixes: 9650c60ebfec0 ("irqchip/mbigen: Create irq domain for each mbigen device") Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200408114352.1604-1-yuzenghui@huawei.com
* | Merge tag 'scsi-fixes' of ↵Linus Torvalds2020-04-188-9/+10
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Seven fixes: three in target, one on a sg error leg, two in qla2xxx fixing warnings introduced in the last merge window and updating MAINTAINERS and one in hisi_sas fixing a problem introduced by libata" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: sg: add sg_remove_request in sg_common_write scsi: target: tcmu: reset_ring should reset TCMU_DEV_BIT_BROKEN scsi: target: fix PR IN / READ FULL STATUS for FC scsi: target: Write NULL to *port_nexus_ptr if no ISID scsi: MAINTAINERS: Update qla2xxx FC-SCSI driver maintainer scsi: qla2xxx: Fix regression warnings scsi: hisi_sas: Fix build error without SATA_HOST
| * | scsi: sg: add sg_remove_request in sg_common_writeLi Bin2020-04-141-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the dxfer_len is greater than 256M then the request is invalid and we need to call sg_remove_request in sg_common_write. Link: https://lore.kernel.org/r/1586777361-17339-1-git-send-email-huawei.libin@huawei.com Fixes: f930c7043663 ("scsi: sg: only check for dxfer_len greater than 256M") Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: Li Bin <huawei.libin@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: target: tcmu: reset_ring should reset TCMU_DEV_BIT_BROKENBodo Stroesser2020-04-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case command ring buffer becomes inconsistent, tcmu sets device flag TCMU_DEV_BIT_BROKEN. If the bit is set, tcmu rejects new commands from LIO core with TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE, and no longer processes completions from the ring. The reset_ring attribute can be used to completely clean up the command ring, so after reset_ring the ring no longer is inconsistent. Therefore reset_ring also should reset bit TCMU_DEV_BIT_BROKEN to allow normal processing. Link: https://lore.kernel.org/r/20200409101026.17872-1-bstroesser@ts.fujitsu.com Acked-by: Mike Christie <mchristi@redhat.com> Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: target: fix PR IN / READ FULL STATUS for FCBodo Stroesser2020-04-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Creation of the response to READ FULL STATUS fails for FC based reservations. Reason is the too high loop limit (< 24) in fc_get_pr_transport_id(). The string representation of FC WWPN is 23 chars long only ("11:22:33:44:55:66:77:88"). So when i is 23, the loop body is executed a last time for the ending '\0' of the string and thus hex2bin() reports an error. Link: https://lore.kernel.org/r/20200408132610.14623-3-bstroesser@ts.fujitsu.com Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com> Reviewed-by: Mike Christie <mchristi@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: target: Write NULL to *port_nexus_ptr if no ISIDBodo Stroesser2020-04-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a minor flaw that could be triggered by a PR OUT RESERVE on iSCSI, if TRANSPORT IDs with and without ISID are used in the same command. In case an ISCSI Transport ID has no ISID, port_nexus_ptr was not used to write NULL, so value from previous call might persist. I don't know if that ever could happen, but with the change the code is cleaner, I think. Link: https://lore.kernel.org/r/20200408132610.14623-2-bstroesser@ts.fujitsu.com Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com> Reviewed-by: Mike Christie <mchristi@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: qla2xxx: Fix regression warningsNilesh Javali2020-04-134-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drivers/scsi/qla2xxx/qla_dbg.c:2542:7: warning: The scope of the variable 'pbuf' can be reduced. [variableScope] drivers/scsi/qla2xxx/qla_init.c:3615:6: warning: Variable 'rc' is assigned a value that is never used. [unreadVariable] drivers/scsi/qla2xxx/qla_isr.c:81:11-29: WARNING: dma_alloc_coherent use in rsp_els already zeroes out memory, so memset is not needed drivers/scsi/qla2xxx/qla_mbx.c:4889:15-33: WARNING: dma_alloc_coherent use in els_cmd_map already zeroes out memory, so memset is not needed [mkp: added newline after variable declaration] Link: https://lore.kernel.org/r/20200403084018.30766-2-njavali@marvell.com Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Nilesh Javali <njavali@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: hisi_sas: Fix build error without SATA_HOSTYueHaibing2020-04-131-0/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If SATA_HOST is n, build fails: drivers/scsi/hisi_sas/hisi_sas_main.o: In function `hisi_sas_fill_ata_reset_cmd': hisi_sas_main.c:(.text+0x2500): undefined reference to `ata_tf_to_fis' Select SATA_HOST to fix this. Link: https://lore.kernel.org/r/20200402085812.32948-1-yuehaibing@huawei.com Fixes: bd322af15ce9 ("ata: make SATA_PMP option selectable only if any SATA host driver is enabled") Reported-by: Hulk Robot <hulkci@huawei.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: John Garry <john.garry@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
* | Merge tag 'hwmon-for-v5.7-rc2' of ↵Linus Torvalds2020-04-185-12/+96
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - Fix up chip IDs (isl68137) - error handling for invalid temperatures and use true module name (drivetemp) - Fix static symbol warnings (k10temp) - Use valid hwmon device name (jc42) * tag 'hwmon-for-v5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (jc42) Fix name to have no illegal characters hwmon: (k10temp) make some symbols static hwmon: (drivetemp) Return -ENODATA for invalid temperatures hwmon: (drivetemp) Use drivetemp's true module name in Kconfig section hwmon: (pmbus/isl68137) Fix up chip IDs
| * | hwmon: (jc42) Fix name to have no illegal charactersSascha Hauer2020-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The jc42 driver passes I2C client's name as hwmon device name. In case of device tree probed devices this ends up being part of the compatible string, "jc-42.4-temp". This name contains hyphens and the hwmon core doesn't like this: jc42 2-0018: hwmon: 'jc-42.4-temp' is not a valid name attribute, please fix This changes the name to "jc42" which doesn't have any illegal characters. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/r/20200417092853.31206-1-s.hauer@pengutronix.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * | hwmon: (k10temp) make some symbols staticJason Yan2020-04-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following sparse warning: drivers/hwmon/k10temp.c:189:12: warning: symbol 'k10temp_temp_label' was not declared. Should it be static? drivers/hwmon/k10temp.c:202:12: warning: symbol 'k10temp_in_label' was not declared. Should it be static? drivers/hwmon/k10temp.c:207:12: warning: symbol 'k10temp_curr_label' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200409084502.42126-1-yanaijie@huawei.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * | hwmon: (drivetemp) Return -ENODATA for invalid temperaturesGuenter Roeck2020-04-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Holger Hoffstätte observed that Samsung 850 Pro may return invalid temperatures for a short period of time after resume. Return -ENODATA to userspace if this is observed. Fixes: 5b46903d8bf3 ("hwmon: Driver for disk and solid state drives with temperature sensors") Reported-by: Holger Hoffstätte <holger@applied-asynchrony.com> Cc: Holger Hoffstätte <holger@applied-asynchrony.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * | hwmon: (drivetemp) Use drivetemp's true module name in Kconfig sectionAnn T Ropea2020-04-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The addition of the support for reading the temperature of ATA drives as per commit 5b46903d8bf3 ("hwmon: Driver for disk and solid state drives with temperature sensors") lists in the respective Kconfig section the name of the module to be optionally built as "satatemp". However, building the kernel modules with "CONFIG_SENSORS_DRIVETEMP=m", does not generate a file named "satatemp.ko". Instead, the rest of the original commit uses the term "drivetemp" and a file named "drivetemp.ko" ends up in the kernel's modules directory. This file has the right ingredients: $ strings /path/to/drivetemp.ko | grep ^description description=Hard drive temperature monitor and modprobing it produces the expected result: # drivetemp is not loaded $ sensors -u drivetemp-scsi-4-0 Specified sensor(s) not found! $ sudo modprobe drivetemp $ sensors -u drivetemp-scsi-4-0 drivetemp-scsi-4-0 Adapter: SCSI adapter temp1: temp1_input: 35.000 temp1_max: 60.000 temp1_min: 0.000 temp1_crit: 70.000 temp1_lcrit: -40.000 temp1_lowest: 20.000 temp1_highest: 36.000 Fix Kconfig by referring to the true name of the module. Fixes: 5b46903d8bf3 ("hwmon: Driver for disk and solid state drives with temperature sensors") Signed-off-by: Ann T Ropea <bedhanger@gmx.de> Link: https://lore.kernel.org/r/20200406235521.185309-1-bedhanger@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
| * | hwmon: (pmbus/isl68137) Fix up chip IDsGuenter Roeck2020-04-131-7/+85
| |/ | | | | | | | | | | | | | | I2C chip IDs need to reflect chip names, not chip functionality. Fixes: f621d61fd59f ("hwmon: (pmbus) add support for 2nd Gen Renesas digital multiphase") Cc: Grant Peltier <grantpeltier93@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
* | Merge branch 'i2c/for-current' of ↵Linus Torvalds2020-04-184-34/+38
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "Some driver bugfixes and an old API removal now that all users are gone" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: tegra: Synchronize DMA before termination i2c: tegra: Better handle case where CPU0 is busy for a long time i2c: remove i2c_new_probed_device API i2c: altera: use proper variable to hold errno i2c: designware: platdrv: Remove DPM_FLAG_SMART_SUSPEND flag on BYT and CHT
| * | i2c: tegra: Synchronize DMA before terminationDmitry Osipenko2020-04-151-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DMA transfer could be completed, but CPU (which handles DMA interrupt) may get too busy and can't handle the interrupt in a timely manner, despite of DMA IRQ being raised. In this case the DMA state needs to synchronized before terminating DMA transfer in order not to miss the DMA transfer completion. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | i2c: tegra: Better handle case where CPU0 is busy for a long timeDmitry Osipenko2020-04-151-12/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Boot CPU0 always handle I2C interrupt and under some rare circumstances (like running KASAN + NFS root) it may stuck in uninterruptible state for a significant time. In this case we will get timeout if I2C transfer is running on a sibling CPU, despite of IRQ being raised. In order to handle this rare condition, the IRQ status needs to be checked after completion timeout. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | i2c: remove i2c_new_probed_device APIWolfram Sang2020-04-151-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | All in-tree users have been converted to the new i2c_new_scanned_device function, so remove this deprecated one. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | i2c: altera: use proper variable to hold errnoWolfram Sang2020-04-151-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | device_property_read_u32() returns errno or 0, so we should use the integer variable 'ret' and not the u32 'val' to hold the retval. Fixes: 0560ad576268 ("i2c: altera: Add Altera I2C Controller driver") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Thor Thayer <thor.thayer@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| * | i2c: designware: platdrv: Remove DPM_FLAG_SMART_SUSPEND flag on BYT and CHTHans de Goede2020-04-151-4/+10
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already set DPM_FLAG_SMART_PREPARE, so we completely skip all callbacks (other then prepare) where possible, quoting from dw_i2c_plat_prepare(): /* * If the ACPI companion device object is present for this device, it * may be accessed during suspend and resume of other devices via I2C * operation regions, so tell the PM core and middle layers to avoid * skipping system suspend/resume callbacks for it in that case. */ return !has_acpi_companion(dev); Also setting the DPM_FLAG_SMART_SUSPEND will cause acpi_subsys_suspend() to leave the controller runtime-suspended even if dw_i2c_plat_prepare() returned 0. Leaving the controller runtime-suspended normally, when the I2C controller is suspended during the suspend_late phase, is not an issue because the pm_runtime_get_sync() done by i2c_dw_xfer() will (runtime-)resume it. But for dw I2C controllers on Bay- and Cherry-Trail devices acpi_lpss.c leaves the controller alive until the suspend_noirq phase, because it may be used by the _PS3 ACPI methods of PCI devices and PCI devices are left powered on until the suspend_noirq phase. Between the suspend_late and resume_early phases runtime-pm is disabled. So for any ACPI I2C OPRegion accesses done after the suspend_late phase, the pm_runtime_get_sync() done by i2c_dw_xfer() is a no-op and the controller is left runtime-suspended. i2c_dw_xfer() has a check to catch this condition (rather then waiting for the I2C transfer to timeout because the controller is suspended). acpi_subsys_suspend() leaving the controller runtime-suspended in combination with an ACPI I2C OPRegion access done after the suspend_late phase triggers this check, leading to the following error being logged on a Bay Trail based Lenovo Thinkpad 8 tablet: [ 93.275882] i2c_designware 80860F41:00: Transfer while suspended [ 93.275993] WARNING: CPU: 0 PID: 412 at drivers/i2c/busses/i2c-designware-master.c:429 i2c_dw_xfer+0x239/0x280 ... [ 93.276252] Workqueue: kacpi_notify acpi_os_execute_deferred [ 93.276267] RIP: 0010:i2c_dw_xfer+0x239/0x280 ... [ 93.276340] Call Trace: [ 93.276366] __i2c_transfer+0x121/0x520 [ 93.276379] i2c_transfer+0x4c/0x100 [ 93.276392] i2c_acpi_space_handler+0x219/0x510 [ 93.276408] ? up+0x40/0x60 [ 93.276419] ? i2c_acpi_notify+0x130/0x130 [ 93.276433] acpi_ev_address_space_dispatch+0x1e1/0x252 ... So since on BYT and CHT platforms we want ACPI I2c OPRegion accesses to work until the suspend_noirq phase, we need the controller to be runtime-resumed during the suspend phase if it is runtime-suspended suspended at that time. This means that we must not set the DPM_FLAG_SMART_SUSPEND on these platforms. On BYT and CHT we already have a special ACCESS_NO_IRQ_SUSPEND flag to make sure the controller stays functional until the suspend_noirq phase. This commit makes the driver not set the DPM_FLAG_SMART_SUSPEND flag when that flag is set. Cc: stable@vger.kernel.org Fixes: b30f2f65568f ("i2c: designware: Set IRQF_NO_SUSPEND flag for all BYT and CHT controllers") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
* | Merge tag 'drm-fixes-2020-04-18' of git://anongit.freedesktop.org/drm/drmLinus Torvalds2020-04-1813-94/+85
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm fixes from Dave Airlie: "Quiet enough for rc2, mostly amdgpu fixes, a couple of i915 fixes, and one nouveau module firmware fix: i915: - Fix guest page access by using the brand new VFIO dma r/w interface (Yan) - Fix for i915 perf read buffers (Ashutosh) amdgpu: - gfx10 fix - SMU7 overclocking fix - RAS fix - GPU reset fix - Fix a regression in a previous suspend/resume fix - Add a gfxoff quirk nouveau: - fix missing MODULE_FIRMWARE" * tag 'drm-fixes-2020-04-18' of git://anongit.freedesktop.org/drm/drm: drm/nouveau/sec2/gv100-: add missing MODULE_FIRMWARE() drm/amdgpu/gfx9: add gfxoff quirk drm/amdgpu: fix the hw hang during perform system reboot and reset drm/i915/gvt: switch to user vfio_group_pin/upin_pages drm/i915/gvt: subsitute kvm_read/write_guest with vfio_dma_rw drm/i915/gvt: hold reference of VFIO group during opening of vgpu drm/i915/perf: Do not clear pollin for small user read buffers drm/amdgpu: fix wrong vram lost counter increment V2 drm/amd/powerplay: unload mp1 for Arcturus RAS baco reset drm/amd/powerplay: force the trim of the mclk dpm_levels if OD is enabled Revert "drm/amdgpu: change SH MEM alignment mode for gfx10"
| * \ Merge branch 'linux-5.7' of git://github.com/skeggsb/linux into drm-fixesDave Airlie2020-04-162-0/+19
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add missing module firmware for turings. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/ <CACAvsv4njTRpiNqOC54iRjpd=nu3pBG8i_fp8o_dp7AZE6hFWA@mail.gmail.com
| | * | drm/nouveau/sec2/gv100-: add missing MODULE_FIRMWARE()Ben Skeggs2020-04-162-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ASB was failing to load on Turing GPUs when firmware is being loaded from initramfs, leaving the GPU in an odd state and causing suspend/ resume to fail. Add missing MODULE_FIRMWARE() lines for initramfs generators. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: <stable@vger.kernel.org> # 5.6
| * | | Merge tag 'amd-drm-fixes-5.7-2020-04-15' of ↵Dave Airlie2020-04-169-16/+33
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.7-2020-04-15: amdgpu: - gfx10 fix - SMU7 overclocking fix - RAS fix - GPU reset fix - Fix a regression in a previous s/r fix - Add a gfxoff quirk Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200415221631.3924-1-alexander.deucher@amd.com
| | * | | drm/amdgpu/gfx9: add gfxoff quirkAlex Deucher2020-04-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix screen corruption with firefox. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=207171 Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | drm/amdgpu: fix the hw hang during perform system reboot and resetPrike Liang2020-04-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The system reboot failed as some IP blocks enter power gate before perform hw resource destory. Meanwhile use unify interface to set device CGPG to ungate state can simplify the amdgpu poweroff or reset ungate guard. Fixes: 487eca11a321ef ("drm/amdgpu: fix gfx hang during suspend with video playback (v2)") Signed-off-by: Prike Liang <Prike.Liang@amd.com> Tested-by: Mengbing Wang <Mengbing.Wang@amd.com> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | drm/amdgpu: fix wrong vram lost counter increment V2Evan Quan2020-04-135-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vram lost counter is wrongly increased by two during baco reset. V2: assumed vram lost for mode1 reset on all ASICs Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/amd/powerplay: unload mp1 for Arcturus RAS baco resetEvan Quan2020-04-091-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This sequence is recommended by PMFW team for the baco reset with PMFW reloaded. And it seems able to address the random failure seen on Arcturus. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Reviewed-by: John Clements <John.Clements@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/amd/powerplay: force the trim of the mclk dpm_levels if OD is enabledSergei Lopatin2020-04-091-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Should prevent flicker if PP_OVERDRIVE_MASK is set. bug: https://bugs.freedesktop.org/show_bug.cgi?id=102646 bug: https://bugs.freedesktop.org/show_bug.cgi?id=108941 bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1088 bug: https://gitlab.freedesktop.org/drm/amd/-/issues/628 Signed-off-by: Sergei Lopatin <magist3r@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | Revert "drm/amdgpu: change SH MEM alignment mode for gfx10"Likun Gao2020-04-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit b74fb888f4927e2079be576ce6dcdbf0c420f1f8. Revert the auto alignment mode set of SH MEM config, as it will result to OCL Conformance Test fail. Signed-off-by: Likun Gao <Likun.Gao@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | | | drm/i915/gvt: switch to user vfio_group_pin/upin_pagesYan Zhao2020-04-141-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | substitute vfio_pin_pages() and vfio_unpin_pages() with vfio_group_pin_pages() and vfio_group_unpin_pages(), so that it will not go through looking up, checking, referencing, dereferencing of VFIO group in each call. Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200313031151.8042-1-yan.y.zhao@intel.com
| * | | | drm/i915/gvt: subsitute kvm_read/write_guest with vfio_dma_rwYan Zhao2020-04-141-21/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As a device model, it is better to read/write guest memory using vfio interface, so that vfio is able to maintain dirty info of device IOVAs. Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200313031109.7989-1-yan.y.zhao@intel.com
| * | | | drm/i915/gvt: hold reference of VFIO group during opening of vgpuYan Zhao2020-04-141-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hold reference count of the VFIO group for each vgpu at vgpu opening and release the reference at vgpu releasing. Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Reviewed-by: Zhenyu Wang<zhenyuw@linux.intel.com> Signed-off-by: Zhenyu Wang<zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200313031025.7936-1-yan.y.zhao@intel.com
| * | | | drm/i915/perf: Do not clear pollin for small user read buffersAshutosh Dixit2020-04-131-54/+11
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is wrong to block the user thread in the next poll when OA data is already available which could not fit in the user buffer provided in the previous read. In several cases the exact user buffer size is not known. Blocking user space in poll can lead to data loss when the buffer size used is smaller than the available data. This change fixes this issue and allows user space to read all OA data even when using a buffer size smaller than the available data using multiple non-blocking reads rather than staying blocked in poll till the next timer interrupt. v2: Fix ret value for blocking reads (Umesh) v3: Mistake during patch send (Ashutosh) v4: Remove -EAGAIN from comment (Umesh) v5: Improve condition for clearing pollin and return (Lionel) v6: Improve blocking read loop and other cleanups (Lionel) v7: Added Cc stable Testcase: igt/perf/polling-small-buf Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200403010120.3067-1-ashutosh.dixit@intel.com (cherry-picked from commit 6352219c39c04ed3f9a8d1cf93f87c21753a213e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
* | | | Merge tag 'mtd/fixes-for-5.7-rc2' of ↵Linus Torvalds2020-04-171-0/+2
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull mtd fix from Richard Weinberger: "spi-nor: fix for missing directory after code refactoring" * tag 'mtd/fixes-for-5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: spi-nor: Compile files in controllers/ directory
| * | | | mtd: spi-nor: Compile files in controllers/ directoryGuenter Roeck2020-04-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit a0900d0195d2 ("mtd: spi-nor: Prepare core / manufacturer code split") moved various files into a new directory, but did not add the new directory to its parent directory Makefile. The moved files no longer build, and affected flash chips no longer instantiate. Adding the new directory to the parent directory Makefile fixes the problem. Fixes: a0900d0195d2 ("mtd: spi-nor: Prepare core / manufacturer code split") Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Richard Weinberger <richard@nod.at>
* | | | | Merge tag 'linux-watchdog-5.7-rc2' of ↵Linus Torvalds2020-04-171-0/+4
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://www.linux-watchdog.org/linux-watchdog Pull watchdog fix from Wim Van Sebroeck: "Fix restart handler in sp805 driver" * tag 'linux-watchdog-5.7-rc2' of git://www.linux-watchdog.org/linux-watchdog: watchdog: sp805: fix restart handler