summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-09-11gpio: creg-snps: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190906131032.22148-1-yuehaibing@huawei.com Acked-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-11gpio: devres: Switch to EXPORT_SYMBOL_GPL()Geert Uytterhoeven
Change all exported symbols for managed GPIO functions from EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL(), like is used for their non-managed counterparts. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20190906084539.21838-5-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-11gpio: of: Switch to EXPORT_SYMBOL_GPL()Geert Uytterhoeven
All exported functions provide genuine Linux-specific functionality. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20190906084539.21838-4-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-11gpio: of: Make of_gpio_simple_xlate() privateGeert Uytterhoeven
Since commit 9a95e8d25a140ba9 ("gpio: remove etraxfs driver"), there are no more users of of_gpio_simple_xlate() outside gpiolib-of.c. All GPIO drivers that need it now rely on of_gpiochip_add() setting it up as the default translate function. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20190906084539.21838-3-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-11gpio: of: Make of_get_named_gpiod_flags() privateGeert Uytterhoeven
Since commit f626d6dfb7098525 ("gpio: of: Break out OF-only code"), there are no more users of of_get_named_gpiod_flags() outside gpiolib-of.c. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20190906084539.21838-2-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-11Merge branches 'arm/omap', 'arm/exynos', 'arm/smmu', 'arm/mediatek', ↵Joerg Roedel
'arm/qcom', 'arm/renesas', 'x86/amd', 'x86/vt-d' and 'core' into next
2019-09-11iommu/vt-d: Declare Broadwell igfx dmar support snafuChris Wilson
Despite the widespread and complete failure of Broadwell integrated graphics when DMAR is enabled, known over the years, we have never been able to root cause the issue. Instead, we let the failure undermine our confidence in the iommu system itself when we should be pushing for it to be always enabled. Quirk away Broadwell and remove the rotten apple. References: https://bugs.freedesktop.org/show_bug.cgi?id=89360 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lu Baolu <baolu.lu@linux.intel.com> Cc: Martin Peres <martin.peres@linux.intel.com> Cc: Joerg Roedel <joro@8bytes.org> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-09-11iommu/vt-d: Add Scalable Mode fault informationKyung Min Park
Intel VT-d specification revision 3 added support for Scalable Mode Translation for DMA remapping. Add the Scalable Mode fault reasons to show detailed fault reasons when the translation fault happens. Link: https://software.intel.com/sites/default/files/managed/c5/15/vt-directed-io-spec.pdf Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Signed-off-by: Kyung Min Park <kyung.min.park@intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-09-11iommu/vt-d: Use bounce buffer for untrusted devicesLu Baolu
The Intel VT-d hardware uses paging for DMA remapping. The minimum mapped window is a page size. The device drivers may map buffers not filling the whole IOMMU window. This allows the device to access to possibly unrelated memory and a malicious device could exploit this to perform DMA attacks. To address this, the Intel IOMMU driver will use bounce pages for those buffers which don't fill whole IOMMU pages. Cc: Ashok Raj <ashok.raj@intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Tested-by: Xu Pengfei <pengfei.xu@intel.com> Tested-by: Mika Westerberg <mika.westerberg@intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-09-11iommu/vt-d: Add trace events for device dma map/unmapLu Baolu
This adds trace support for the Intel IOMMU driver. It also declares some events which could be used to trace the events when an IOVA is being mapped or unmapped in a domain. Cc: Ashok Raj <ashok.raj@intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-09-11iommu/vt-d: Don't switch off swiotlb if bounce page is usedLu Baolu
The bounce page implementation depends on swiotlb. Hence, don't switch off swiotlb if the system has untrusted devices or could potentially be hot-added with any untrusted devices. Cc: Ashok Raj <ashok.raj@intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-09-11iommu/vt-d: Check whether device requires bounce bufferLu Baolu
This adds a helper to check whether a device needs to use bounce buffer. It also provides a boot time option to disable the bounce buffer. Users can use this to prevent the iommu driver from using the bounce buffer for performance gain. Cc: Ashok Raj <ashok.raj@intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Tested-by: Xu Pengfei <pengfei.xu@intel.com> Tested-by: Mika Westerberg <mika.westerberg@intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-09-11swiotlb: Split size parameter to map/unmap APIsLu Baolu
This splits the size parameter to swiotlb_tbl_map_single() and swiotlb_tbl_unmap_single() into an alloc_size and a mapping_size parameter, where the latter one is rounded up to the iommu page size. Suggested-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-09-11regulator: core: Fix error return for /sys accessH. Nikolaus Schaller
regulator_uV_show() is missing error handling if regulator_get_voltage_rdev() returns negative values. Instead it prints the errno as a string, e.g. -EINVAL as "-22" which could be interpreted as -22 µV. We also do not need to hold the lock while converting the integer to a string. Reported-by: Adam Ford <aford173@gmail.com> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Tested-by: Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/f37f2a1276efcb34cf3b7f1a25481175be048806.1568143348.git.hns@goldelico.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-11regulator: da9211: fix obtaining "enable" GPIODmitry Torokhov
This fixes 11da04af0d3b, as devm_gpiod_get_from_of_node() does not do translation "con-id" -> "con-id-gpios" that our bindings expects, and therefore it was wrong to change connection ID to be simply "enable" when moving to using devm_gpiod_get_from_of_node(). Fixes: 11da04af0d3b ("regulator: da9211: Pass descriptors instead of GPIO numbers") Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20190910170246.GA56792@dtor-ws Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-11regulator: max77686: fix obtaining "maxim,ena" GPIODmitry Torokhov
This fixes 96392c3d8ca4, as devm_gpiod_get_from_of_node() does not do translation "con-id" -> "con-id-gpios" that our bindings expects, and therefore it was wrong to change connection ID to be simply "maxim,ena" when moving to using devm_gpiod_get_from_of_node(). Fixes: 96392c3d8ca4 ("regulator: max77686: Pass descriptor instead of GPIO number") Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20190910170050.GA55530@dtor-ws Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-11gpio: aspeed: Add in ast2600 details to Aspeed driverRashmica Gupta
The ast2600 is a new generation of SoC from ASPEED. Similarly to the ast2400 and ast2500, it has a GPIO controller for it's 3.3V GPIO pins. Additionally, it has a GPIO controller for 1.8V GPIO pins. As the register names for both controllers are the same and the 36 1.8V GPIOs and the first 36 of the 3.3V GPIOs are all bidirectional, we can use the same configuration struct and use the ngpio property to differentiate between the two sets of GPIOs. Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com> Link: https://lore.kernel.org/r/20190906063737.15428-1-rashmica.g@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-11gpio: aspeed: Use ngpio property from device tree if availableRashmica Gupta
Use the ngpio property from the device tree if it exists. If it doesn't then fallback to the hardcoded value in the config. This is in preparation for adding ast2600 support. The ast2600 SoC has two GPIO controllers and so requires two instances of the GPIO driver. We use the ngpio property to different between them as they have different numbers of GPIOs. Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com> Link: https://lore.kernel.org/r/20190906062727.13521-1-rashmica.g@gmail.com Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-11gpio: aspeed: Setup irqchip dynamicallyRashmica Gupta
This is in preparation for adding ast2600 support. The ast2600 SoC requires two instances of the GPIO driver as it has two GPIO controllers. Each instance needs it's own irqchip. Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com> Link: https://lore.kernel.org/r/20190906062644.13445-1-rashmica.g@gmail.com Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-11gpio/aspeed: Fix incorrect number of banksRashmica Gupta
The current calculation for the number of GPIO banks is only correct if the number of GPIOs is a multiple of 32 (if there were 31 GPIOs we would currently say there are 0 banks, which is incorrect). Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver') Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190906062623.13354-1-rashmica.g@gmail.com Reviewed-by: Joel Stanley <joel@jms.d.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-11gpio: aspeed: Update documentation with ast2600 controllersRashmica Gupta
The ast2600 is a new generation of SoC from ASPEED. Similarly to the ast2400 and ast2500, it has a GPIO controller for it's 3.3V GPIO pins. Additionally, it has a GPIO controller for 36 1.8V GPIO pins. We use the ngpio property to differentiate between these controllers. Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com> Link: https://lore.kernel.org/r/20190906062547.13264-1-rashmica.g@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-11gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklistHans de Goede
Another day; another DSDT bug we need to workaround... Since commit ca876c7483b6 ("gpiolib-acpi: make sure we trigger edge events at least once on boot") we call _AEI edge handlers at boot. In some rare cases this causes problems. One example of this is the Minix Neo Z83-4 mini PC, this device has a clear DSDT bug where it has some copy and pasted code for dealing with Micro USB-B connector host/device role switching, while the mini PC does not even have a micro-USB connector. This code, which should not be there, messes with the DDC data pin from the HDMI connector (switching it to GPIO mode) breaking HDMI support. To avoid problems like this, this commit adds a new gpiolib_acpi.run_edge_events_on_boot kernel commandline option, which allows disabling the running of _AEI edge event handlers at boot. The default value is -1/auto which uses a DMI based blacklist, the initial version of this blacklist contains the Neo Z83-4 fixing the HDMI breakage. Cc: stable@vger.kernel.org Cc: Daniel Drake <drake@endlessm.com> Cc: Ian W MORRISON <ianwmorrison@gmail.com> Reported-by: Ian W MORRISON <ianwmorrison@gmail.com> Suggested-by: Ian W MORRISON <ianwmorrison@gmail.com> Fixes: ca876c7483b6 ("gpiolib-acpi: make sure we trigger edge events at least once on boot") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20190827202835.213456-1-hdegoede@redhat.com Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Ian W MORRISON <ianwmorrison@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-11lib/Kconfig: fix OBJAGG in lib/ menu structureRandy Dunlap
Keep the "Library routines" menu intact by moving OBJAGG into it. Otherwise OBJAGG is displayed/presented as an orphan in the various config menus. Fixes: 0a020d416d0a ("lib: introduce initial implementation of object aggregation manager") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jiri Pirko <jiri@mellanox.com> Cc: Ido Schimmel <idosch@mellanox.com> Cc: David S. Miller <davem@davemloft.net> Tested-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-11net: sonic: replace dev_kfree_skb in sonic_send_packetMao Wenan
sonic_send_packet will be processed in irq or non-irq context, so it would better use dev_kfree_skb_any instead of dev_kfree_skb. Fixes: d9fb9f384292 ("*sonic/natsemi/ns83829: Move the National Semi-conductor drivers") Signed-off-by: Mao Wenan <maowenan@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-11wimax: i2400: fix memory leakNavid Emamdoost
In i2400m_op_rfkill_sw_toggle cmd buffer should be released along with skb response. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-11gpio: Initialize the irqchip valid_mask with a callbackLinus Walleij
After changing the valid_mask for the struct gpio_chip to detect the need and presence of a valid mask with the presence of a .init_valid_mask() callback to fill it in, we augment the gpio_irq_chip to use the same logic. Switch all driver using the gpio_irq_chio valid_mask over to this new method. This makes sure the valid_mask for the gpio_irq_chip gets filled in when we add the gpio_chip, which makes it a little easier to switch over drivers using the old way of setting up gpio_irq_chip over to the new method of passing the gpio_irq_chip along with the gpio_chip. (See drivers/gpio/TODO for details.) Cc: Joel Stanley <joel@jms.id.au> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Link: https://lore.kernel.org/r/20190904140104.32426-1-linus.walleij@linaro.org
2019-09-10hwmon: (shtc1) add support for the SHTC3 sensorDan Robertson
Add support for the Sensirion SHTC3 humidity and temperature sensor to the shtc1 module. Signed-off-by: Dan Robertson <dan@dlrobertson.com> Link: https://lore.kernel.org/r/20190905014554.21658-2-dan@dlrobertson.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2019-09-10hwmon: (shtc1) fix shtc1 and shtw1 id maskDan Robertson
Fix an error in the bitmaskfor the shtc1 and shtw1 bitmask used to retrieve the chip ID from the ID register. See section 5.7 of the shtw1 or shtc1 datasheet for details. Fixes: 1a539d372edd9832444e7a3daa710c444c014dc9 ("hwmon: add support for Sensirion SHTC1 sensor") Signed-off-by: Dan Robertson <dan@dlrobertson.com> Link: https://lore.kernel.org/r/20190905014554.21658-3-dan@dlrobertson.com [groeck: Reordered to be first in series and adjusted accordingly] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2019-09-10iocost_monitor: Report debtTejun Heo
Report debt and rename del_ms row to delay for consistency. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-09-10iocost_monitor: Report more info with higher accuracyTejun Heo
When outputting json: * Don't truncate numbers. * Report address of iocg to ease drilling down further. When outputting table: * Use math.ceil() for delay_ms so that small delays don't read as 0. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-09-10iocost_monitor: Always use strings for json valuesTejun Heo
Json has limited accuracy for numbers and can silently truncate 64bit values, which can be extremely confusing. Let's consistently use string encapsulated values for json output. While at it, convert an unnecesary f-string to str(). Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-09-10blk-iocost: Don't let merges push vtime into the futureTejun Heo
Merges have the same problem that forced-bios had which is fixed by the previous patch. The cost of a merge is calculated at the time of issue and force-advances vtime into the future. Until global vtime catches up, how the cgroup's hweight changes in the meantime doesn't matter and it often leads to situations where the cost is calculated at one hweight and paid at a very different one. See the previous patch for more details. Fix it by never advancing vtime into the future for merges. If budget is available, vtime is advanced. Otherwise, the cost is charged as debt. This brings merge cost handling in line with issue cost handling in ioc_rqos_throttle(). Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-09-10blk-iocost: Account force-charged overage in absolute vtimeTejun Heo
Currently, when a bio needs to be force-charged and there isn't enough budget, vtime is simply pushed into the future. This means that the cost of the whole bio is scaled using the current hweight and then charged immediately. Until the global vtime advances beyond this future vtime, the cgroup won't be allowed to issue normal IOs. This is incorrect and can lead to, for example, exploding vrate or extended stalls if vrate range is constrained. Consider the following scenario. 1. A cgroup with a very low hweight runs out of budget. 2. A storm of swap-out happens on it. All of them are scaled according to the current low hweight and charged to vtime pushing it to a far future. 3. All other cgroups go idle and now the above cgroup has access to the whole device. However, because vtime is already wound using the past low hweight, what its current hweight is doesn't matter until global vtime catches up to the local vtime. 4. As a result, either vrate gets ramped up extremely or the IOs stall while the underlying device is idle. This is because the hweight the overage is calculated at is different from the hweight that it's being paid at. Fix it by remembering the overage in absoulte vtime and continuously paying with the actual budget according to the current hweight at each period. Note that non-forced bios which wait already remembers the cost in absolute vtime. This brings forced-bio accounting in line. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-09-10blk-iocost: Fix incorrect operation order during iocg freeTejun Heo
ioc_pd_free() first cancels the hrtimers and then deactivates the iocg. However, the iocg timer can run inbetween and reschedule the hrtimers which will end up running after the iocg is freed leading to crashes like the following. general protection fault: 0000 [#1] SMP ... RIP: 0010:iocg_kick_delay+0xbe/0x1b0 RSP: 0018:ffffc90003598ea0 EFLAGS: 00010046 RAX: 1cee00fd69512b54 RBX: ffff8881bba48400 RCX: 00000000000003e8 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881bba48400 RBP: 0000000000004e20 R08: 0000000000000002 R09: 00000000000003e8 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90003598ef0 R13: 00979f3810ad461f R14: ffff8881bba4b400 R15: 25439f950d26e1d1 FS: 0000000000000000(0000) GS:ffff88885f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f64328c7e40 CR3: 0000000002409005 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> iocg_delay_timer_fn+0x3d/0x60 __hrtimer_run_queues+0xfe/0x270 hrtimer_interrupt+0xf4/0x210 smp_apic_timer_interrupt+0x5e/0x120 apic_timer_interrupt+0xf/0x20 </IRQ> Fix it by canceling hrtimers after deactivating the iocg. Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Reported-by: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-09-10sctp: fix the missing put_user when dumping transport thresholdsXin Long
This issue causes SCTP_PEER_ADDR_THLDS sockopt not to be able to dump a transport thresholds info. Fix it by adding 'goto' put_user in sctp_getsockopt_paddr_thresholds. Fixes: 8add543e369d ("sctp: add SCTP_FUTURE_ASSOC for SCTP_PEER_ADDR_THLDS sockopt") Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-10sch_hhf: ensure quantum and hhf_non_hh_weight are non-zeroCong Wang
In case of TCA_HHF_NON_HH_WEIGHT or TCA_HHF_QUANTUM is zero, it would make no progress inside the loop in hhf_dequeue() thus kernel would get stuck. Fix this by checking this corner case in hhf_change(). Fixes: 10239edf86f1 ("net-qdisc-hhf: Heavy-Hitter Filter (HHF) qdisc") Reported-by: syzbot+bc6297c11f19ee807dc2@syzkaller.appspotmail.com Reported-by: syzbot+041483004a7f45f1f20a@syzkaller.appspotmail.com Reported-by: syzbot+55be5f513bed37fc4367@syzkaller.appspotmail.com Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Cc: Terry Lam <vtlam@google.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-10net_sched: check cops->tcf_block in tc_bind_tclass()Cong Wang
At least sch_red and sch_tbf don't implement ->tcf_block() while still have a non-zero tc "class". Instead of adding nop implementations to each of such qdisc's, we can just relax the check of cops->tcf_block() in tc_bind_tclass(). They don't support TC filter anyway. Reported-by: syzbot+21b29db13c065852f64b@syzkaller.appspotmail.com Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-10io_uring: limit parallelism of buffered writesJens Axboe
All the popular filesystems need to grab the inode lock for buffered writes. With io_uring punting buffered writes to async context, we observe a lot of contention with all workers hamming this mutex. For buffered writes, we generally don't need a lot of parallelism on the submission side, as the flushing will take care of that for us. Hence we don't need a deep queue on the write side, as long as we can safely punt from the original submission context. Add a workqueue with a limit of 2 that we can use for buffered writes. This greatly improves the performance and efficiency of higher queue depth buffered async writes with io_uring. Reported-by: Andres Freund <andres@anarazel.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-09-10io_uring: add io_queue_async_work() helperJens Axboe
Add a helper for queueing a request for async execution, in preparation for optimizing it. No functional change in this patch. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-09-10waitid: Add support for waiting for the current process groupEric W. Biederman
It was recently discovered that the linux version of waitid is not a superset of the other wait functions because it does not include support for waiting for the current process group. This has two downsides: 1. An extra system call is needed to get the current process group. 2. After the current process group is received and before it is passed to waitid a signal could arrive causing the current process group to change. Inherent race-conditions as these make it impossible for userspace to emulate this functionaly and thus violate async-signal safety requirements for waitpid. Arguments can be made for using a different choice of idtype and id for this case but the BSDs already use this P_PGID and 0 to indicate waiting for the current process's process group. So be nice to user space programmers and don't introduce an unnecessary incompatibility. Some people have noted that the posix description is that waitpid will wait for the current process group, and that in the presence of pthreads that process group can change. To get clarity on this issue I looked at XNU, FreeBSD, and Luminos. All of those flavors of unix waited for the current process group at the time of call and as written could not adapt to the process group changing after the call. At one point Linux did adapt to the current process group changing but that stopped in 161550d74c07 ("pid: sys_wait... fixes"). It has been over 11 years since Linux has that behavior, no programs that fail with the change in behavior have been reported, and I could not find any other unix that does this. So I think it is safe to clarify the definition of current process group, to current process group at the time of the wait function. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Rich Felker <dalias@libc.org> Cc: Alistair Francis <alistair23@gmail.com> Cc: Zong Li <zongbox@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Florian Weimer <fweimer@redhat.com> Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org> Cc: GNU C Library <libc-alpha@sourceware.org> Link: https://lore.kernel.org/r/20190814154400.6371-2-christian.brauner@ubuntu.com
2019-09-10io_uring: optimize submit_and_wait APIJens Axboe
For some applications that end up using a submit-and-wait type of approach for certain batches of IO, we can make that a bit more efficient by allowing the application to block for the last IO submission. This prevents an async when we don't need it, as the application will be blocking for the completion event(s) anyway. Typical use cases are using the liburing io_uring_submit_and_wait() API, or just using io_uring_enter() doing both submissions and completions. As a specific example, RocksDB doing MultiGet() is sped up quite a bit with this change. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-09-10Merge tag 'ipc-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic Pull ipc regression fixes from Arnd Bergmann: "Fix ipc regressions from y2038 patches These are two regression fixes for bugs that got introduced during the system call rework that went into linux-5.1 but only bisected and fixed now: - One patch affects semtimedop() on many of the less common 32-bit architectures, this just needs a single-line bugfix. - The other affects only sparc64 and has a slightly more invasive workaround to apply the same change to sparc64 that was done to the generic code used everywhere else" * tag 'ipc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: ipc: fix sparc64 ipc() wrapper ipc: fix semtimedop for generic 32-bit architectures
2019-09-10platform/x86: asus-wmi: Refactor charge threshold to use the battery hooking APIKristian Klausen
At the same time use the official naming for the knobs. Tested on a Zenbook UX430UNR. Signed-off-by: Kristian Klausen <kristian@klausen.dk> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-09-10posix-cpu-timers: Fix permission check regressionThomas Gleixner
The recent consolidation of the three permission checks introduced a subtle regression. For timer_create() with a process wide timer it returns the current task if the lookup through the PID which is encoded into the clockid results in returning current. That's broken because it does not validate whether the current task is the group leader. That was caused by the two different variants of permission checks: - posix_cpu_timer_get() allowed access to the process wide clock when the looked up task is current. That's not an issue because the process wide clock is in the shared sighand. - posix_cpu_timer_create() made sure that the looked up task is the group leader. Restore the previous state. Note, that these permission checks are more than questionable, but that's subject to follow up changes. Fixes: 6ae40e3fdcd3 ("posix-cpu-timers: Provide task validation functions") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1909052314110.1902@nanos.tec.linutronix.de
2019-09-10gpiolib: acpi: make acpi_can_fallback_to_crs() staticDmitry Torokhov
It is not used outside gpiolib-acpi.c module, so there is no need to export it. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20190904172624.GA76617@dtor-ws Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-10gpiolib: of: fix fallback quirks handlingDmitry Torokhov
We should only try to execute fallback quirks handling when previous call returned -ENOENT, and not when we did not get -EPROBE_DEFER. The other errors should be treated as hard errors: we did find the GPIO description, but for some reason we failed to handle it properly. The fallbacks should only be executed when previous handlers returned -ENOENT, which means the mapping/description was not found. Also let's remove the explicit deferral handling when iterating through GPIO suffixes: it is not needed anymore as we will not be calling fallbacks for anything but -ENOENT. Fixes: df451f83e1fc ("gpio: of: fix Freescale SPI CS quirk handling") Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20190903231856.GA165165@dtor-ws Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-09-10spi: bcm2835: Work around DONE bit erratumLukas Wunner
Commit 3bd7f6589f67 ("spi: bcm2835: Overcome sglist entry length limitation") amended the BCM2835 SPI driver with support for DMA transfers whose buffers are not aligned to 4 bytes and require more than one sglist entry. When testing this feature with upcoming commits to speed up TX-only and RX-only transfers, I noticed that SPI transmission sometimes breaks. A function introduced by the commit, bcm2835_spi_transfer_prologue(), performs one or two PIO transmissions as a prologue to the actual DMA transmission. It turns out that the breakage goes away if the DONE bit in the CS register is set when ending such a PIO transmission. The DONE bit signifies emptiness of the TX FIFO. According to the spec, the bit is of type RO, so writing it should never have any effect. Perhaps the spec is wrong and the bit is actually of type RW1C. E.g. the I2C controller on the BCM2835 does have an RW1C DONE bit which needs to be cleared by the driver. Another, possibly more likely explanation is that it's a hardware erratum since the issue does not occur consistently. Either way, amend bcm2835_spi_transfer_prologue() to always write the DONE bit. Usually a transmission is ended by bcm2835_spi_reset_hw(). If the transmission was successful, the TX FIFO is empty and thus the DONE bit is set when bcm2835_spi_reset_hw() reads the CS register. The bit is then written back to the register, so we happen to do the right thing. However if DONE is not set, e.g. because transmission is aborted with a non-empty TX FIFO, the bit won't be written by bcm2835_spi_reset_hw() and it seems possible that transmission might subsequently break. To be on the safe side, likewise amend bcm2835_spi_reset_hw() to always write the bit. Tested-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Martin Sperl <kernel@martin.sperl.org> Link: https://lore.kernel.org/r/edb004dff4af6106f6bfcb89e1a96391e96eb857.1564825752.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-10Merge tag 'gpio-v5.4-fixes-for-linus' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into fixes gpio: fixes for v5.4 - fix a memory leak in gpio-mockup - fix two flag validation bugs in gpiolib's character device ioctl()'s
2019-09-10Merge tag 'intel-gpio-v5.4-1' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel into devel intel-gpio for v5.4-1 The clean up of IRQ chip initialization has been done in few drivers. Stale record in MAINTAINERS database is removed. The following is an automated git shortlog grouped by driver: intel-mid: - Pass irqchip when adding gpiochip - MAINTAINERS: Remove stale record for gpio-intel-mid.c lynxpoint: - Pass irqchip when adding gpiochip merrifield: - Pass irqchip when adding gpiochip pch: - Use dev_get_drvdata
2019-09-10regulator: uniphier: Add Pro5 USB3 VBUS supportKunihiko Hayashi
Pro5 SoC has same scheme of USB3 VBUS as Pro4, so the data for Pro5 is equivalent to Pro4. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1568080304-1572-1-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-13 09:05:07 +0000