Re: [PATCH v3 2/2] ASoC: Intel: Add period size constraint on strago board
On Wed, 12 Aug 2020 08:53:42 +0200, Yu-Hsuan Hsu wrote: > > Takashi Iwai 於 2020年8月12日 週三 下午2:14寫道： > > > > On Wed, 12 Aug 2020 05:09:58 +0200, > > Yu-Hsuan Hsu wrote: > > > > > > Mark Brown 於 2020年8月12日 週三 上午1:22寫道： > > > > > > > > On Tue, Aug 11, 2020 at 11:54:38AM -0500, Pierre-Louis Bossart wrote: > > > > > > > > > > constraint logic needs to know about this DSP limitation - it seems > > > > > > like > > > > > > none of this is going to change without something new going into the > > > > > > mix? We at least need a new question to ask about the DSP firmware > > > > > > I > > > > > > think. > > > > > > > > > I just tested aplay -Dhw: on a Cyan Chromebook with the Ubuntu kernel > > > > > 5.4, > > > > > and I see no issues with the 240 sample period. Same with 432, 960, > > > > > 9600, > > > > > etc. > > > > > > > > > I also tried just for fun what happens with 256 samples, and I don't > > > > > see any > > > > > underflows thrown either, so I am wondering what exactly the problem > > > > > is? > > > > > Something's not adding up. I would definitively favor multiple of 1ms > > > > > periods, since it's the only case that was productized, but there's > > > > > got to > > > > > me something a side effect of how CRAS programs the hw_params. > > > > > > > > Is it something that goes wrong with longer playbacks possibly (eg, > > > > someone watching a feature film or something)? > > > > > > Thanks for testing! > > > > > > After doing some experiments, I think I can identify the problem more > > > precisely. > > > 1. aplay can not reproduce this issue because it writes samples > > > immediately when there are some space in the buffer. However, you can > > > add --test-position to see how the delay grows with period size 256. > > > > aplay -Dhw:1,0 --period-size=256 --buffer-size=480 /dev/zero -d 1 -f > > > > dat --test-position > > > Playing raw data '/dev/zero' : Signed 16 bit Little Endian, Rate 48000 > > > Hz, Stereo > > > Suspicious buffer position (1 total): avail = 0, delay = 2064, buffer = > > > 512 > > > Suspicious buffer position (2 total): avail = 0, delay = 2064, buffer = > > > 512 > > > Suspicious buffer position (3 total): avail = 0, delay = 2096, buffer = > > > 512 > > > ... > > > > Isn't this about the alignment of the buffer size against the period > > size, not the period size itself? i.e. in the example above, the > > buffer size isn't a multiple of period size, and DSP can't handle if > > the position overlaps the buffer size in a half way. > > > > If that's the problem (and it's an oft-seen restriction), the right > > constraint is > > snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); > > > > > > Takashi > Oh sorry for my typo. The issue happens no matter what buffer size is > set. Actually, even if I want to set 480, it will change to 512 > automatically. > Suspicious buffer position (1 total): avail = 0, delay = 2064, buffer > = 512 <-this one is the buffer size OK, then it means that the buffer size alignment is already in place. And this large delay won't happen if you use period size 240? Takashi > > > 2. Since many samples are moved to DSP(delay), the measured rate of > > > the ring-buffer is high. (I measured it by alsa_conformance_test, > > > which only test the sampling rate in the ring buffer of kernel not > > > DSP) > > > > > > 3. Since CRAS writes samples with a fixed frequency, this behavior > > > will take all samples from the ring buffer, which is seen as underrun > > > by CRAS. (It seems that it is not a real underrun because that avail > > > does not larger than buffer size. Maybe CRAS should also take dalay > > > into account.) > > > > > > 4. In spite of it is not a real underrun, the large delay is still a > > > big problem. Can we apply the constraint to fix it? Or any better > > > idea? > > > > > > Thanks, > > > Yu-Hsuan > > > >
Re: [PATCH v11 1/2] usb: dwc3: qcom: Add interconnect support in dwc3 driver
"Sandeep Maheswaram (Temp)" writes: > Hi Felipe, > > On 7/28/2020 12:50 AM, Matthias Kaehlcke wrote: >> On Mon, Jul 27, 2020 at 10:36:36PM +0530, Sandeep Maheswaram wrote: >>> Add interconnect support in dwc3-qcom driver to vote for bus >>> bandwidth. >>> >>> This requires for two different paths - from USB to >>> DDR. The other is from APPS to USB. >>> >>> Signed-off-by: Sandeep Maheswaram >>> Signed-off-by: Chandana Kishori Chiluveru >> Reviewed-by: Matthias Kaehlcke > Please ack if you are ok with this patch. What's the plan to get this upstream? Should I take dwc3-qcom patch and ignore the rest? Is there a hard-dependency on something else? -- balbi signature.asc Description: PGP signature
[Linux-kernel-mentees] [PATCH] hfs, hfsplus: Fix NULL pointer dereference in hfs_find_init()
Prevent hfs_find_init() from dereferencing `tree` as NULL.
Reported-and-tested-by: syzbot+7ca256d0da4af073b...@syzkaller.appspotmail.com
Signed-off-by: Peilin Ye
---
fs/hfs/bfind.c | 3 +++
fs/hfsplus/bfind.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/fs/hfs/bfind.c b/fs/hfs/bfind.c
index 4af318fbda77..880b7ea2c0fc 100644
--- a/fs/hfs/bfind.c
+++ b/fs/hfs/bfind.c
@@ -16,6 +16,9 @@ int hfs_find_init(struct hfs_btree *tree, struct
hfs_find_data *fd)
{
void *ptr;
+ if (!tree)
+ return -EINVAL;
+
fd->tree = tree;
fd->bnode = NULL;
ptr = kmalloc(tree->max_key_len * 2 + 4, GFP_KERNEL);
diff --git a/fs/hfsplus/bfind.c b/fs/hfsplus/bfind.c
index ca2ba8c9f82e..85bef3e44d7a 100644
--- a/fs/hfsplus/bfind.c
+++ b/fs/hfsplus/bfind.c
@@ -16,6 +16,9 @@ int hfs_find_init(struct hfs_btree *tree, struct
hfs_find_data *fd)
{
void *ptr;
+ if (!tree)
+ return -EINVAL;
+
fd->tree = tree;
fd->bnode = NULL;
ptr = kmalloc(tree->max_key_len * 2 + 4, GFP_KERNEL);
--
2.25.1
Re: [PATCH v3 2/2] ASoC: Intel: Add period size constraint on strago board
Takashi Iwai 於 2020年8月12日 週三 下午2:14寫道： > > On Wed, 12 Aug 2020 05:09:58 +0200, > Yu-Hsuan Hsu wrote: > > > > Mark Brown 於 2020年8月12日 週三 上午1:22寫道： > > > > > > On Tue, Aug 11, 2020 at 11:54:38AM -0500, Pierre-Louis Bossart wrote: > > > > > > > > constraint logic needs to know about this DSP limitation - it seems > > > > > like > > > > > none of this is going to change without something new going into the > > > > > mix? We at least need a new question to ask about the DSP firmware I > > > > > think. > > > > > > > I just tested aplay -Dhw: on a Cyan Chromebook with the Ubuntu kernel > > > > 5.4, > > > > and I see no issues with the 240 sample period. Same with 432, 960, > > > > 9600, > > > > etc. > > > > > > > I also tried just for fun what happens with 256 samples, and I don't > > > > see any > > > > underflows thrown either, so I am wondering what exactly the problem is? > > > > Something's not adding up. I would definitively favor multiple of 1ms > > > > periods, since it's the only case that was productized, but there's got > > > > to > > > > me something a side effect of how CRAS programs the hw_params. > > > > > > Is it something that goes wrong with longer playbacks possibly (eg, > > > someone watching a feature film or something)? > > > > Thanks for testing! > > > > After doing some experiments, I think I can identify the problem more > > precisely. > > 1. aplay can not reproduce this issue because it writes samples > > immediately when there are some space in the buffer. However, you can > > add --test-position to see how the delay grows with period size 256. > > > aplay -Dhw:1,0 --period-size=256 --buffer-size=480 /dev/zero -d 1 -f dat > > > --test-position > > Playing raw data '/dev/zero' : Signed 16 bit Little Endian, Rate 48000 > > Hz, Stereo > > Suspicious buffer position (1 total): avail = 0, delay = 2064, buffer = 512 > > Suspicious buffer position (2 total): avail = 0, delay = 2064, buffer = 512 > > Suspicious buffer position (3 total): avail = 0, delay = 2096, buffer = 512 > > ... > > Isn't this about the alignment of the buffer size against the period > size, not the period size itself? i.e. in the example above, the > buffer size isn't a multiple of period size, and DSP can't handle if > the position overlaps the buffer size in a half way. > > If that's the problem (and it's an oft-seen restriction), the right > constraint is > snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); > > > Takashi Oh sorry for my typo. The issue happens no matter what buffer size is set. Actually, even if I want to set 480, it will change to 512 automatically. Suspicious buffer position (1 total): avail = 0, delay = 2064, buffer = 512 <-this one is the buffer size > > > 2. Since many samples are moved to DSP(delay), the measured rate of > > the ring-buffer is high. (I measured it by alsa_conformance_test, > > which only test the sampling rate in the ring buffer of kernel not > > DSP) > > > > 3. Since CRAS writes samples with a fixed frequency, this behavior > > will take all samples from the ring buffer, which is seen as underrun > > by CRAS. (It seems that it is not a real underrun because that avail > > does not larger than buffer size. Maybe CRAS should also take dalay > > into account.) > > > > 4. In spite of it is not a real underrun, the large delay is still a > > big problem. Can we apply the constraint to fix it? Or any better > > idea? > > > > Thanks, > > Yu-Hsuan > >
Re: xfs_reclaim_inodes_ag taking several seconds
On 8/4/20 12:11 AM, Dave Chinner wrote: On Sat, Aug 01, 2020 at 12:25:40PM +0200, Donald Buczek wrote: On 01.08.20 00:32, Dave Chinner wrote: On Fri, Jul 31, 2020 at 01:27:31PM +0200, Donald Buczek wrote: Dear Linux people, we have a backup server with two xfs filesystems on 101.9TB md-raid6 devices (16 * 7.3 T disks) each, Current Linux version is 5.4.54. . root:done:/home/buczek/linux_problems/shrinker_semaphore/# cat /proc/meminfo MemTotal: 263572332 kB 256GB of RAM. MemFree: 2872368 kB MemAvailable: 204193824 kB 200GB "available" Buffers:2568 kB Cached: 164931356 kB 160GB in page cache KReclaimable: 40079660 kB Slab: 49988268 kB SReclaimable: 40079660 kB 40GB in reclaimable slab objects. IOWs, you have no free memory in the machine and so allocation will frequently be dipping into memory reclaim to free up page cache and slab caches to make memory available. xfs_inode 30978282 3119683296041 : tunables 54 278 : slabdata 7799208 7799208434 Yes, 30 million cached inodes. bio_integrity_payload 29644966 30203481192 211 : tunables 120 60 8 : slabdata 1438261 1438261480 Either there is a memory leak in this slab, or it is shared with something like the xfs_ili slab, which would indicate that most of the cached inodes have been dirtied in memory at some point in time. I think you are right here: crash> p $s->name $84 = 0x82259401 "bio_integrity_payload" crash> p $s->refcount $88 = 8 crash> p $s $92 = (struct kmem_cache *) 0x88bff92d2bc0 crash> p sizeof(xfs_inode_log_item_t) $93 = 192 crash> p $s->object_size $94 = 192 So if I understand you correctly, this is expected behavior with this kind of load and conceptual changes are already scheduled for kernel 5.9. I don't understand most of it, but isn't it true that with that planned changes the impact might be better limited to the filesystem, so that the performance of other areas of the system might improve? What the changes in 5.9 will do is remove the direct memory reclaim latency that comes from waiting on IO in the shrinker. Hence you will no longer see this problem from applications doing memory allocation. i.e. they'll get some other memory reclaimed without blocking (e.g. page cache or clean inodes) and so the specific symptom of having large numbers of dirty inodes in memory that you are seeing will go away. Which means that dirty inodes in memory will continue to build up until the next constraint is hit, and then it will go back to having unpredictable large latencies while waiting for inodes to be written back to free up whatever resource the filesystem has run out of. That resource will, most likely, be filesystem journal space. Every fs modification needs to reserve sufficient journal to complete before the modification starts. Hence if the journal fills, any modification to the fs will block waiting on dirty inode writeback to release space in the journal You might be lucky and the backup process is slow enough that the disk subsystem can keep up with the rate of ingest of new data and so you never hit this limitation. However, the reported state of the machine and the amount of RAM it has for caching says to me that the underlying problem is that ingest is far faster than the filesystem and disk subsystem can sink... A solution to this problem might be to spread out the backups being done over a wider timeframe, such that there isn't a sustained heavy load at 3am in the morning when every machine is scheduled to be backed up at the same time... It is already running round the clock. We have two of these servers, doing daily backups for 1374 file spaces (= directory trees below 1 TB) on 392 clients. The servers are doing daily mirrors of these file spaces, creating hard links for existing files and keeping these daily trees for 4 month. The schedule is free from fixed wall clock times. A backup is due when the last iteration is older than 24 hours, and will be done as time, threads and some locking constrains allow. Under normal circumstances the servers keep up, but are nearly continuously busy. The excess capacity is spread all over the day (sometimes there is no work to do for some minutes). I monitor, how long a local mount takes (usually 0.03-0.04 seconds) and the worst time seen so far is over 16 minutes! Because we rely on autofs mounts for logins and some other things, the system kind of appears to be dead during that time. I've limited the inode caches by running the backup jobs in memory control groups, but, as expected, this didn't really bring down the delays. I've also added a cond_resched() to mm/vmscan.c:shrink_slab_memcg(), which seems to be missing after the up_read(), but this didn't help either. From a user perspective it is hard to understand, that a saturated block device delays unrelated functi
[PATCH] perf bench: fix a couple of spelling mistakes in options text
From: Colin Ian King
There are a couple of spelling mistakes in the text. Fix these.
Signed-off-by: Colin Ian King
---
tools/perf/bench/find-bit-bench.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/bench/find-bit-bench.c
b/tools/perf/bench/find-bit-bench.c
index fa90f3e9d368..73b5bcc5946a 100644
--- a/tools/perf/bench/find-bit-bench.c
+++ b/tools/perf/bench/find-bit-bench.c
@@ -17,9 +17,9 @@ static unsigned int inner_iterations = 10;
static const struct option options[] = {
OPT_UINTEGER('i', "outer-iterations", &outer_iterations,
- "Number of outerer iterations used"),
+ "Number of outer iterations used"),
OPT_UINTEGER('j', "inner-iterations", &inner_iterations,
- "Number of outerer iterations used"),
+ "Number of inner iterations used"),
OPT_END()
};
--
2.27.0
RE: [PATCH V2 2/2] scsi: ufs: Improve interrupt handling for shared interrupts
> > For shared interrupts, the interrupt status might be zero, so check that > first. > > Signed-off-by: Adrian Hunter Reviewed-by: Avri Altman
Re: [PATCH v6 1/2] Add DT bindings YAML schema for PWM fan controller of LGM SoC
Hello Rahul, On Wed, Aug 12, 2020 at 11:49:14AM +0800, Tanwar, Rahul wrote: > Our PWM controller is actually a PWM fan controller dedicated for > controlling fan. I am looking for some suggestions from you on how > to handle fan related optional properties in such a scenario. > > Should i create a separate child node for fan with PWM node being > the parent? Is that what you are suggesting? Thanks. What is the problem of just using pwm-fan? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
[GIT PULL] MFD for v5.9
Good morning Linus,
[with added [GIT PULL] subject line label this time]
Enjoy!
The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:
Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git mfd-next-5.9
for you to fetch changes up to ee849ff1fd31f761fc65af04f2649a37e769ceab:
mfd: core: Fix memory leak of 'cell' (2020-08-10 12:27:30 +0100)
- Core Frameworks
- Make better attempt at matching device with the correct OF node
- Allow batch removal of hierarchical sub-devices
- New Drivers
- Add STM32 Clocksource driver
- Add support for Khadas System Control Microcontroller
- Driver Removal
- Remove unused driver for TI's SMSC ECE1099
- New Device Support
- Add support for Intel Emmitsburg PCH to Intel LPSS PCI
- Add support for Intel Tiger Lake PCH-H to Intel LPSS PCI
- Add support for Dialog DA revision to Dialog DA9063
- New Functionality
- Add support for AXP803 to be probed by I2C
- Fix-ups
- Numerous W=1 warning fixes
- Device Tree changes; stm32-lptimer, gateworks-gsc, khadas,mcu, stmfx,
cros-ec, j721e-system-controller
- Enabled Regmap 'fast I/O'; stm32-lptimer
- Change BUG_ON to WARN_ON; arizona-core
- Remove superfluous code/initialisation; madera, max14577
- Trivial formatting/spelling issues; madera-core, madera-i2c, da9055,
max77693-private
- Switch to of_platform_populate(); sprd-sc27xx-spi
- Expand out set/get brightness/pwm macros; lm3533-ctrlbank
- Disable IRQs on suspend; motorola-cpcap
- Clean-up error handling; intel_soc_pmic_mrfld
- Ensure correct removal order of sub-devices; madera
- Many s/HTTP/HTTPS/ link changes
- Ensure name used with Regmap is unique; syscon
- Bug Fixes
- Properly 'put' clock on unbind and error; arizona-core
- Fix revision handling; da9063
- Fix 'assignment of read-only location' error; kempld-core
- Avoid using the Regmap API when atomic; rn5t618
- Redefine volatile register description; rn5t618
- Use locking to protect event handler; dln2
Adam Thomson (2):
mfd: da9063: Fix revision handling to correctly select reg tables
mfd: da9063: Add support for latest DA silicon revision
Alexander A. Klimov (1):
mfd: Replace HTTP links with HTTPS ones
Andreas Kemnade (2):
mfd: rn5t618: Make restart handler atomic safe
mfd: rn5t618: Fix caching of battery related registers
Andy Shevchenko (3):
mfd: intel-lpss: Add Intel Emmitsburg PCH PCI IDs
mfd: intel-lpss: Add Intel Tiger Lake PCH-H PCI IDs
mfd: dln2: Run event handler loop under spinlock
Benjamin Gaignard (5):
dt-bindings: mfd: Document STM32 low power timer bindings
mfd: stm32: Add defines to be used for clkevent purpose
mfd: stm32: Enable regmap fast_io for stm32-lptimer
clocksource: Add Low Power STM32 timers driver
dt-bindings: mfd: Convert stmfx bindings to json-schema
Charles Keepax (6):
mfd: arizona: Remove BUG_ON usage
mfd: arizona: Ensure 32k clock is put on driver unbind and error
mfd: madera: Remove unused forward declaration of madera_codec_pdata
mfd: madera: Fix minor formatting issues
mfd: mfd-core: Add mechanism for removal of a subset of children
mfd: madera: Improve handling of regulator unbinding
Chunyan Zhang (1):
mfd: sprd: Populate sub-devices defined in DT
Colin Ian King (1):
mfd: max14577: Remove redundant initialization of variable current_bits
Fabio Estevam (2):
dt-bindings: mfd: st,stmfx: Remove extra additionalProperties
dt-bindings: mfd: st,stmfx: Remove I2C unit name
Frank Lee (1):
mfd: axp20x: Allow the AXP803 to be probed by I2C
Ikjoon Jang (1):
dt-bindings: mfd: Convert ChromeOS EC bindings to json-schema
Johan Hovold (1):
mfd: lm3533: Expand control-bank accessors
Lee Jones (37):
mfd: twl4030-irq: Fix incorrect type in assignment warning
mfd: twl4030-irq: Fix cast to restricted __le32 warning
mfd: tps6586x: Fix cast to restricted __le32 warning
mfd: altera-sysmgr: Fix physical address storing hacks
mfd: sprd-sc27xx-spi: Fix symbol 'sprd_pmic_detect_charger_type' was not
declared warning
mfd: ab3100-core: Fix incompatible types in comparison expression warning
mfd: ab8500-debugfs: Fix incompatible types in comparison expression issue
mfd: tc3589x: Remove invalid use of kerneldoc syntax
mfd: wm8400-core: Supply description for wm8400_reset_codec_reg_cache's
arg
mfd: wm831x-core: Supply description wm831x_reg_{un}lock args
mfd: wm8350-core: Supply description wm8350_reg_{un}lock args
mfd: mfd-core: Complete kerneldoc header for devm_mfd_add_devices()
mfd: db8500-prcmu: Add description for 'reset_reason' i
[PATCH 10/14] mips: bmips: bcm6328: include and use dt-bindings
Now that there are proper device tree bindings we can start using them.
Signed-off-by: Álvaro Fernández Rojas
---
arch/mips/boot/dts/brcm/bcm6328.dtsi | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/mips/boot/dts/brcm/bcm6328.dtsi
b/arch/mips/boot/dts/brcm/bcm6328.dtsi
index af860d06def6..1f84f6b05f88 100644
--- a/arch/mips/boot/dts/brcm/bcm6328.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm6328.dtsi
@@ -1,4 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
+
+#include "dt-bindings/clock/bcm6328-clock.h"
+#include "dt-bindings/interrupt-controller/bcm6328-interrupt-controller.h"
+
/ {
#address-cells = <1>;
#size-cells = <1>;
@@ -73,7 +77,7 @@ uart0: serial@1100 {
compatible = "brcm,bcm6345-uart";
reg = <0x1100 0x18>;
interrupt-parent = <&periph_intc>;
- interrupts = <28>;
+ interrupts = ;
clocks = <&periph_clk>;
clock-names = "refclk";
status = "disabled";
@@ -83,7 +87,7 @@ uart1: serial@1120 {
compatible = "brcm,bcm6345-uart";
reg = <0x1120 0x18>;
interrupt-parent = <&periph_intc>;
- interrupts = <39>;
+ interrupts = ;
clocks = <&periph_clk>;
clock-names = "refclk";
status = "disabled";
@@ -115,7 +119,7 @@ ehci: usb@10002500 {
reg = <0x10002500 0x100>;
big-endian;
interrupt-parent = <&periph_intc>;
- interrupts = <42>;
+ interrupts = ;
status = "disabled";
};
@@ -125,7 +129,7 @@ ohci: usb@10002600 {
big-endian;
no-big-frame-no;
interrupt-parent = <&periph_intc>;
- interrupts = <41>;
+ interrupts = ;
status = "disabled";
};
};
--
2.28.0
[PATCH 04/14] mips: bmips: add BCM6328 irq definitions
Add header with BCM6328 definitions in order to be able to include it from device tree files. Signed-off-by: Álvaro Fernández Rojas --- .../bcm6328-interrupt-controller.h| 68 +++ 1 file changed, 68 insertions(+) create mode 100644 include/dt-bindings/interrupt-controller/bcm6328-interrupt-controller.h diff --git a/include/dt-bindings/interrupt-controller/bcm6328-interrupt-controller.h b/include/dt-bindings/interrupt-controller/bcm6328-interrupt-controller.h new file mode 100644 index ..def2a21efc77 --- /dev/null +++ b/include/dt-bindings/interrupt-controller/bcm6328-interrupt-controller.h @@ -0,0 +1,68 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ + +#ifndef __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6328_H +#define __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6328_H + +#define BCM6328_IRQ_NAND 0 +#define BCM6328_IRQ_PCM1 +#define BCM6328_IRQ_PCM_DMA0 2 +#define BCM6328_IRQ_PCM_DMA1 3 +#define BCM6328_IRQ_USBS 4 +#define BCM6328_IRQ_USB_CTL_RX_DMA 5 +#define BCM6328_IRQ_USB_CTL_TX_DMA 6 +#define BCM6328_IRQ_USB_BULK_RX_DMA7 +#define BCM6328_IRQ_USB_BULK_TX_DMA8 +#define BCM6328_IRQ_USB_ISO_RX_DMA 9 +#define BCM6328_IRQ_USB_ISO_TX_DMA 10 +#define BCM6328_IRQ_DG 11 +#define BCM6328_IRQ_EPHY 12 +#define BCM6328_IRQ_EPHY_EN0N 13 +#define BCM6328_IRQ_EPHY_EN1N 14 +#define BCM6328_IRQ_EPHY_EN2N 15 +#define BCM6328_IRQ_EPHY_EN3N 16 +#define BCM6328_IRQ_EPHY_EN0 17 +#define BCM6328_IRQ_EPHY_EN1 18 +#define BCM6328_IRQ_EPHY_EN2 19 +#define BCM6328_IRQ_EPHY_EN3 20 +#define BCM6328_IRQ_XDSL 21 +#define BCM6328_IRQ_PCIE_EP22 +#define BCM6328_IRQ_PCIE_RC23 +#define BCM6328_IRQ_EXTO 24 +#define BCM6328_IRQ_EXT1 25 +#define BCM6328_IRQ_EXT2 26 +#define BCM6328_IRQ_EXT3 27 +#define BCM6328_IRQ_UART0 28 +#define BCM6328_IRQ_HSSPI 29 +#define BCM6328_IRQ_WAKE_ON_IRQ30 +#define BCM6328_IRQ_TIMER 31 +#define BCM6328_IRQ_ENETSW_RX_DMA0 32 +#define BCM6328_IRQ_ENETSW_RX_DMA1 33 +#define BCM6328_IRQ_ENETSW_TX_DMA0 34 +#define BCM6328_IRQ_ENETSW_TX_DMA1 35 +#define BCM6328_IRQ_UART1 39 +#define BCM6328_IRQ_ENETSW 40 +#define BCM6328_IRQ_OHCI 41 +#define BCM6328_IRQ_EHCI 42 +#define BCM6328_IRQ_ATM_DMA0 43 +#define BCM6328_IRQ_ATM_DMA1 44 +#define BCM6328_IRQ_ATM_DMA2 45 +#define BCM6328_IRQ_ATM_DMA3 46 +#define BCM6328_IRQ_ATM_DMA4 47 +#define BCM6328_IRQ_ATM_DMA5 48 +#define BCM6328_IRQ_ATM_DMA6 49 +#define BCM6328_IRQ_ATM_DMA7 50 +#define BCM6328_IRQ_ATM_DMA8 51 +#define BCM6328_IRQ_ATM_DMA9 52 +#define BCM6328_IRQ_ATM_DMA10 53 +#define BCM6328_IRQ_ATM_DMA11 54 +#define BCM6328_IRQ_ATM_DMA12 55 +#define BCM6328_IRQ_ATM_DMA13 56 +#define BCM6328_IRQ_ATM_DMA14 57 +#define BCM6328_IRQ_ATM_DMA15 58 +#define BCM6328_IRQ_ATM_DMA16 59 +#define BCM6328_IRQ_ATM_DMA17 60 +#define BCM6328_IRQ_ATM_DMA18 61 +#define BCM6328_IRQ_ATM_DMA19 62 +#define BCM6328_IRQ_SAR63 + +#endif /* __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6328_H */ -- 2.28.0
[PATCH 01/14] mips: dts: brcm: allow including header files
Change /include/ with #include in order to be able to include header files
from dt-bindings.
Signed-off-by: Álvaro Fernández Rojas
---
arch/mips/boot/dts/brcm/bcm3368-netgear-cvg834g.dts| 2 +-
arch/mips/boot/dts/brcm/bcm63268-comtrend-vr-3032u.dts | 2 +-
arch/mips/boot/dts/brcm/bcm6358-neufbox4-sercomm.dts | 2 +-
arch/mips/boot/dts/brcm/bcm6362-neufbox6-sercomm.dts | 2 +-
arch/mips/boot/dts/brcm/bcm93384wvg.dts| 2 +-
arch/mips/boot/dts/brcm/bcm93384wvg_viper.dts | 2 +-
arch/mips/boot/dts/brcm/bcm96368mvwg.dts | 2 +-
arch/mips/boot/dts/brcm/bcm97125cbmb.dts | 2 +-
arch/mips/boot/dts/brcm/bcm97346dbsmb.dts | 4 ++--
arch/mips/boot/dts/brcm/bcm97358svmb.dts | 4 ++--
arch/mips/boot/dts/brcm/bcm97360svmb.dts | 2 +-
arch/mips/boot/dts/brcm/bcm97362svmb.dts | 4 ++--
arch/mips/boot/dts/brcm/bcm97420c.dts | 2 +-
arch/mips/boot/dts/brcm/bcm97425svmb.dts | 4 ++--
arch/mips/boot/dts/brcm/bcm97435svmb.dts | 4 ++--
arch/mips/boot/dts/brcm/bcm9ejtagprb.dts | 2 +-
16 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/mips/boot/dts/brcm/bcm3368-netgear-cvg834g.dts
b/arch/mips/boot/dts/brcm/bcm3368-netgear-cvg834g.dts
index ed6023a91763..d702a843c74a 100644
--- a/arch/mips/boot/dts/brcm/bcm3368-netgear-cvg834g.dts
+++ b/arch/mips/boot/dts/brcm/bcm3368-netgear-cvg834g.dts
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
-/include/ "bcm3368.dtsi"
+#include "bcm3368.dtsi"
/ {
compatible = "netgear,cvg834g", "brcm,bcm3368";
diff --git a/arch/mips/boot/dts/brcm/bcm63268-comtrend-vr-3032u.dts
b/arch/mips/boot/dts/brcm/bcm63268-comtrend-vr-3032u.dts
index 8d010b919de2..b511bc7125d5 100644
--- a/arch/mips/boot/dts/brcm/bcm63268-comtrend-vr-3032u.dts
+++ b/arch/mips/boot/dts/brcm/bcm63268-comtrend-vr-3032u.dts
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
-/include/ "bcm63268.dtsi"
+#include "bcm63268.dtsi"
/ {
compatible = "comtrend,vr-3032u", "brcm,bcm63268";
diff --git a/arch/mips/boot/dts/brcm/bcm6358-neufbox4-sercomm.dts
b/arch/mips/boot/dts/brcm/bcm6358-neufbox4-sercomm.dts
index 53e57cc29291..c646690ee3df 100644
--- a/arch/mips/boot/dts/brcm/bcm6358-neufbox4-sercomm.dts
+++ b/arch/mips/boot/dts/brcm/bcm6358-neufbox4-sercomm.dts
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
-/include/ "bcm6358.dtsi"
+#include "bcm6358.dtsi"
/ {
compatible = "sfr,nb4-ser", "brcm,bcm6358";
diff --git a/arch/mips/boot/dts/brcm/bcm6362-neufbox6-sercomm.dts
b/arch/mips/boot/dts/brcm/bcm6362-neufbox6-sercomm.dts
index 3e83bee5b91e..f83d95ca0514 100644
--- a/arch/mips/boot/dts/brcm/bcm6362-neufbox6-sercomm.dts
+++ b/arch/mips/boot/dts/brcm/bcm6362-neufbox6-sercomm.dts
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
-/include/ "bcm6362.dtsi"
+#include "bcm6362.dtsi"
/ {
compatible = "sfr,nb6-ser", "brcm,bcm6362";
diff --git a/arch/mips/boot/dts/brcm/bcm93384wvg.dts
b/arch/mips/boot/dts/brcm/bcm93384wvg.dts
index 601e4d9293ab..7d3f181b8980 100644
--- a/arch/mips/boot/dts/brcm/bcm93384wvg.dts
+++ b/arch/mips/boot/dts/brcm/bcm93384wvg.dts
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
-/include/ "bcm3384_zephyr.dtsi"
+#include "bcm3384_zephyr.dtsi"
/ {
compatible = "brcm,bcm93384wvg", "brcm,bcm3384";
diff --git a/arch/mips/boot/dts/brcm/bcm93384wvg_viper.dts
b/arch/mips/boot/dts/brcm/bcm93384wvg_viper.dts
index 938a8e66128c..f845faa0d682 100644
--- a/arch/mips/boot/dts/brcm/bcm93384wvg_viper.dts
+++ b/arch/mips/boot/dts/brcm/bcm93384wvg_viper.dts
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
-/include/ "bcm3384_viper.dtsi"
+#include "bcm3384_viper.dtsi"
/ {
compatible = "brcm,bcm93384wvg-viper", "brcm,bcm3384-viper";
diff --git a/arch/mips/boot/dts/brcm/bcm96368mvwg.dts
b/arch/mips/boot/dts/brcm/bcm96368mvwg.dts
index 6d772c394e41..f5e955085308 100644
--- a/arch/mips/boot/dts/brcm/bcm96368mvwg.dts
+++ b/arch/mips/boot/dts/brcm/bcm96368mvwg.dts
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
-/include/ "bcm6368.dtsi"
+#include "bcm6368.dtsi"
/ {
compatible = "brcm,bcm96368mvwg", "brcm,bcm6368";
diff --git a/arch/mips/boot/dts/brcm/bcm97125cbmb.dts
b/arch/mips/boot/dts/brcm/bcm97125cbmb.dts
index 79e9769f7e00..bda5f796251a 100644
--- a/arch/mips/boot/dts/brcm/bcm97125cbmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97125cbmb.dts
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
-/include/ "bcm7125.dtsi"
+#include "bcm7125.dtsi"
/ {
compatible = "brcm,bcm97125cbmb", "brcm,bcm7125";
diff --git a/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
b/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
index 28370ff77eeb..9f73735e815c 100644
--- a/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
@@ -1
[PATCH 03/14] mips: bmips: add BCM6318 irq definitions
Add header with BCM6318 definitions in order to be able to include it from device tree files. Signed-off-by: Álvaro Fernández Rojas --- .../bcm6318-interrupt-controller.h| 84 +++ 1 file changed, 84 insertions(+) create mode 100644 include/dt-bindings/interrupt-controller/bcm6318-interrupt-controller.h diff --git a/include/dt-bindings/interrupt-controller/bcm6318-interrupt-controller.h b/include/dt-bindings/interrupt-controller/bcm6318-interrupt-controller.h new file mode 100644 index ..7882dcb279c4 --- /dev/null +++ b/include/dt-bindings/interrupt-controller/bcm6318-interrupt-controller.h @@ -0,0 +1,84 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ + +#ifndef __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6318_H +#define __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6318_H + +#define BCM6318_IRQ_TIMER0 0 +#define BCM6318_IRQ_TIMER1 1 +#define BCM6318_IRQ_TIMER2 2 +#define BCM6318_IRQ_TIMER3 3 +#define BCM6318_IRQ_USBS 4 +#define BCM6318_IRQ_USB_CTL_RX_DMA 5 +#define BCM6318_IRQ_USB_CTL_TX_DMA 6 +#define BCM6318_IRQ_USB_BULK_RX_DMA7 +#define BCM6318_IRQ_USB_BULK_TX_DMA8 +#define BCM6318_IRQ_USB_ISO_RX_DMA 9 +#define BCM6318_IRQ_USB_ISO_TX_DMA 10 +#define BCM6318_IRQ_DG 11 +#define BCM6318_IRQ_EPHY 12 +#define BCM6318_IRQ_EPHY_EN0N 13 +#define BCM6318_IRQ_EPHY_EN1N 14 +#define BCM6318_IRQ_EPHY_EN2N 15 +#define BCM6318_IRQ_EPHY_EN3N 16 +#define BCM6318_IRQ_EPHY_EN0 17 +#define BCM6318_IRQ_EPHY_EN1 18 +#define BCM6318_IRQ_EPHY_EN2 19 +#define BCM6318_IRQ_EPHY_EN3 20 +#define BCM6318_IRQ_XDSL 21 +#define BCM6318_IRQ_SDR22 +#define BCM6318_IRQ_PCIE_RC23 +#define BCM6318_IRQ_EXT0 24 +#define BCM6318_IRQ_EXT1 25 +#define BCM6318_IRQ_EXT2 26 +#define BCM6318_IRQ_EXT3 27 +#define BCM6318_IRQ_UART0 28 +#define BCM6318_IRQ_HSSPI 29 +#define BCM6318_IRQ_WAKE_ON_IRQ30 +#define BCM6318_IRQ_TIMER 31 +#define BCM6318_IRQ_ENETSW_RX_DMA0 32 +#define BCM6318_IRQ_ENETSW_RX_DMA1 33 +#define BCM6318_IRQ_ENETSW_RX_DMA2 34 +#define BCM6318_IRQ_ENETSW_RX_DMA3 35 +#define BCM6318_IRQ_WDTIMER37 +#define BCM6318_IRQ_ENETSW 40 +#define BCM6318_IRQ_OHCI 41 +#define BCM6318_IRQ_EHCI 42 +#define BCM6318_IRQ_ATM_DMA0 43 +#define BCM6318_IRQ_ATM_DMA1 44 +#define BCM6318_IRQ_ATM_DMA2 45 +#define BCM6318_IRQ_ATM_DMA3 46 +#define BCM6318_IRQ_ATM_DMA4 47 +#define BCM6318_IRQ_ATM_DMA5 48 +#define BCM6318_IRQ_ATM_DMA6 49 +#define BCM6318_IRQ_ATM_DMA7 50 +#define BCM6318_IRQ_ATM_DMA8 51 +#define BCM6318_IRQ_ATM_DMA9 52 +#define BCM6318_IRQ_ATM_DMA10 53 +#define BCM6318_IRQ_ATM_DMA11 54 +#define BCM6318_IRQ_ATM_DMA12 55 +#define BCM6318_IRQ_ATM_DMA13 56 +#define BCM6318_IRQ_ATM_DMA14 57 +#define BCM6318_IRQ_ATM_DMA15 58 +#define BCM6318_IRQ_ATM_DMA16 59 +#define BCM6318_IRQ_ATM_DMA17 60 +#define BCM6318_IRQ_ATM_DMA18 61 +#define BCM6318_IRQ_ATM_DMA19 62 +#define BCM6318_IRQ_SAR63 +#define BCM6318_IRQ_ADSL_ENERGY64 +#define BCM6318_IRQ_ADSL_ENERGY_N 65 +#define BCM6318_IRQ_USB_ENERGY_ON 66 +#define BCM6318_IRQ_USB_ENERGY_OFF 67 +#define BCM6318_IRQ_PVTMON_TEMP68 +#define BCM6318_IRQ_SYSPLL_LOCK69 +#define BCM6318_IRQ_LCPLL_LOCK 70 +#define BCM6318_IRQ_PMU_STABLE 71 +#define BCM6318_IRQ_ENETSW_TX_DMA0 72 +#define BCM6318_IRQ_ENETSW_TX_DMA1 73 +#define BCM6318_IRQ_ENETSW_TX_DMA2 74 +#define BCM6318_IRQ_ENETSW_TX_DMA3 75 +#define BCM6318_IRQ_EPHY0_IDDQ_ENERGY 76 +#define BCM6318_IRQ_EPHY1_IDDQ_ENERGY 77 +#define BCM6318_IRQ_EPHY2_IDDQ_ENERGY 78 +#define BCM6318_IRQ_EPHY3_IDDQ_ENERGY 79 + +#endif /* __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6318_H */ -- 2.28.0
[PATCH 02/14] mips: bmips: add BCM3368 irq definitions
Add header with BCM3368 definitions in order to be able to include it from device tree files. Signed-off-by: Álvaro Fernández Rojas --- .../bcm3368-interrupt-controller.h| 19 +++ 1 file changed, 19 insertions(+) create mode 100644 include/dt-bindings/interrupt-controller/bcm3368-interrupt-controller.h diff --git a/include/dt-bindings/interrupt-controller/bcm3368-interrupt-controller.h b/include/dt-bindings/interrupt-controller/bcm3368-interrupt-controller.h new file mode 100644 index ..e269c1bb93ea --- /dev/null +++ b/include/dt-bindings/interrupt-controller/bcm3368-interrupt-controller.h @@ -0,0 +1,19 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ + +#ifndef __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM3368_H +#define __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM3368_H + +#define BCM3368_IRQ_TIMER 0 +#define BCM3368_IRQ_SPI1 +#define BCM3368_IRQ_UART0 2 +#define BCM3368_IRQ_UART1 3 +#define BCM3368_IRQ_ENET1 6 +#define BCM3368_IRQ_ENET0 8 +#define BCM3368_IRQ_ENET_PHY 9 +#define BCM3368_IRQ_ENET0_RX_DMA 15 +#define BCM3368_IRQ_ENET0_TX_DMA 16 +#define BCM3368_IRQ_ENET1_RX_DMA 17 +#define BCM3368_IRQ_ENET1_TX_DMA 18 +#define BCM3368_IRQ_PCI31 + +#endif /* __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM3368_H */ -- 2.28.0
[PATCH 09/14] mips: bmips: bcm3368: include and use dt-bindings
Now that there are proper device tree bindings we can start using them.
Signed-off-by: Álvaro Fernández Rojas
---
arch/mips/boot/dts/brcm/bcm3368.dtsi | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/mips/boot/dts/brcm/bcm3368.dtsi
b/arch/mips/boot/dts/brcm/bcm3368.dtsi
index 69cbef472377..63d844601718 100644
--- a/arch/mips/boot/dts/brcm/bcm3368.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm3368.dtsi
@@ -1,4 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
+
+#include "dt-bindings/clock/bcm3368-clock.h"
+#include "dt-bindings/interrupt-controller/bcm3368-interrupt-controller.h"
+
/ {
#address-cells = <1>;
#size-cells = <1>;
@@ -86,7 +90,7 @@ uart0: serial@fff8c100 {
reg = <0xfff8c100 0x18>;
interrupt-parent = <&periph_intc>;
- interrupts = <2>;
+ interrupts = ;
clocks = <&periph_clk>;
clock-names = "refclk";
@@ -99,7 +103,7 @@ uart1: serial@fff8c120 {
reg = <0xfff8c120 0x18>;
interrupt-parent = <&periph_intc>;
- interrupts = <3>;
+ interrupts = ;
clocks = <&periph_clk>;
clock-names = "refclk";
--
2.28.0
[PATCH 08/14] mips: bmips: add BCM63268 irq definitions
Add header with BCM63268 definitions in order to be able to include it from device tree files. Signed-off-by: Álvaro Fernández Rojas --- .../bcm63268-interrupt-controller.h | 86 +++ 1 file changed, 86 insertions(+) create mode 100644 include/dt-bindings/interrupt-controller/bcm63268-interrupt-controller.h diff --git a/include/dt-bindings/interrupt-controller/bcm63268-interrupt-controller.h b/include/dt-bindings/interrupt-controller/bcm63268-interrupt-controller.h new file mode 100644 index ..8589e8686d60 --- /dev/null +++ b/include/dt-bindings/interrupt-controller/bcm63268-interrupt-controller.h @@ -0,0 +1,86 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ + +#ifndef __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM63268_H +#define __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM63268_H + +#define BCM63268_IRQ_TIMER 0 +#define BCM63268_IRQ_ENETSW_RX_DMA01 +#define BCM63268_IRQ_ENETSW_RX_DMA12 +#define BCM63268_IRQ_ENETSW_RX_DMA23 +#define BCM63268_IRQ_ENETSW_RX_DMA34 +#define BCM63268_IRQ_UART0 5 +#define BCM63268_IRQ_HSSPI 6 +#define BCM63268_IRQ_WLAN 7 +#define BCM63268_IRQ_IPSEC 8 +#define BCM63268_IRQ_OHCI 9 +#define BCM63268_IRQ_EHCI 10 +#define BCM63268_IRQ_USBS 11 +#define BCM63268_IRQ_PCM 12 +#define BCM63268_IRQ_EPHY 13 +#define BCM63268_IRQ_DG14 +#define BCM63268_IRQ_EPHY0_EN 15 +#define BCM63268_IRQ_EPHY1_EN 16 +#define BCM63268_IRQ_EPHY2_EN 17 +#define BCM63268_IRQ_GPHY_EN 18 +#define BCM63268_IRQ_USB_CTL_RX_DMA19 +#define BCM63268_IRQ_USB_BULK_RX_DMA 20 +#define BCM63268_IRQ_ISO_RX_DMA21 +#define BCM63268_IRQ_IPSEC_DMA022 +#define BCM63268_IRQ_XDSL 23 +#define BCM63268_IRQ_FAP0 24 +#define BCM63268_IRQ_FAP1 25 +#define BCM63268_IRQ_ATM_DMA0 26 +#define BCM63268_IRQ_ATM_DMA1 27 +#define BCM63268_IRQ_ATM_DMA2 28 +#define BCM63268_IRQ_ATM_DMA3 29 +#define BCM63268_IRQ_WAKE_ON_IRQ 30 +#define BCM63268_IRQ_GPHY 31 +#define BCM63268_IRQ_DECT0 32 +#define BCM63268_IRQ_DECT1 33 +#define BCM63268_IRQ_UART1 34 +#define BCM63268_IRQ_WLAN_GPIO 35 +#define BCM63268_IRQ_USB_CTL_TX_DMA36 +#define BCM63268_IRQ_USB_BULK_TX_DMA 37 +#define BCM63268_IRQ_ISO_TX_DMA38 +#define BCM63268_IRQ_IPSEC_DMA139 +#define BCM63268_IRQ_PCIE_RC 40 +#define BCM63268_IRQ_PCIE_EP 41 +#define BCM63268_IRQ_PCM_DMA0 42 +#define BCM63268_IRQ_PCM_DMA1 43 +#define BCM63268_IRQ_EXT0 44 +#define BCM63268_IRQ_EXT1 45 +#define BCM63268_IRQ_EXT2 46 +#define BCM63268_IRQ_EXT3 47 +#define BCM63268_IRQ_ENETSW48 +#define BCM63268_IRQ_SAR 49 +#define BCM63268_IRQ_NAND 50 +#define BCM63268_IRQ_RING_OSC 52 +#define BCM63268_IRQ_USB_CONNECT 53 +#define BCM63268_IRQ_USB_DISCONNECT54 +#define BCM63268_IRQ_PER_MBOX0 55 +#define BCM63268_IRQ_PER_MBOX1 56 +#define BCM63268_IRQ_PER_MBOX2 57 +#define BCM63268_IRQ_PER_MBOX3 58 +#define BCM63268_IRQ_ATM_DMA4 59 +#define BCM63268_IRQ_ATM_DMA5 60 +#define BCM63268_IRQ_ATM_DMA6 61 +#define BCM63268_IRQ_ATM_DMA7 62 +#define BCM63268_IRQ_ENETSW_TX_DMA064 +#define BCM63268_IRQ_ENETSW_TX_DMA165 +#define BCM63268_IRQ_ENETSW_TX_DMA266 +#define BCM63268_IRQ_ENETSW_TX_DMA367 +#define BCM63268_IRQ_ATM_DMA8 68 +#define BCM63268_IRQ_ATM_DMA9 69 +#define BCM63268_IRQ_ATM_DMA10 70 +#define BCM63268_IRQ_ATM_DMA11 71 +#define BCM63268_IRQ_ATM_DMA12 72 +#define BCM63268_IRQ_ATM_DMA13 73 +#define BCM63268_IRQ_ATM_DMA14 74 +#define BCM63268_IRQ_ATM_DMA15 75 +#define BCM63268_IRQ_ATM_DMA16 76 +#define BCM63268_IRQ_ATM_DMA17 77 +#define BCM63268_IRQ_ATM_DMA18 78 +#define BCM63268_IRQ_ATM_DMA19 79 +#define BCM63268_IRQ_LSSPI 80 + +#endif /* __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM63268_H */ -- 2.28.0
[PATCH 06/14] mips: bmips: add BCM6362 irq definitions
Add header with BCM6362 definitions in order to be able to include it from device tree files. Signed-off-by: Álvaro Fernández Rojas --- .../bcm6362-interrupt-controller.h| 71 +++ 1 file changed, 71 insertions(+) create mode 100644 include/dt-bindings/interrupt-controller/bcm6362-interrupt-controller.h diff --git a/include/dt-bindings/interrupt-controller/bcm6362-interrupt-controller.h b/include/dt-bindings/interrupt-controller/bcm6362-interrupt-controller.h new file mode 100644 index ..7a13046f0d81 --- /dev/null +++ b/include/dt-bindings/interrupt-controller/bcm6362-interrupt-controller.h @@ -0,0 +1,71 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ + +#ifndef __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6362_H +#define __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6362_H + +#define BCM6362_IRQ_TIMER 0 +#define BCM6362_IRQ_RING_OSC 1 +#define BCM6362_IRQ_LSSPI 2 +#define BCM6362_IRQ_UART0 3 +#define BCM6362_IRQ_UART1 4 +#define BCM6362_IRQ_HSSPI 5 +#define BCM6362_IRQ_WLAN_GPIO 6 +#define BCM6362_IRQ_WLAN 7 +#define BCM6362_IRQ_IPSEC 8 +#define BCM6362_IRQ_OHCI 9 +#define BCM6362_IRQ_EHCI 10 +#define BCM6362_IRQ_USBS 11 +#define BCM6362_IRQ_NAND 12 +#define BCM6362_IRQ_PCM13 +#define BCM6362_IRQ_EPHY 14 +#define BCM6362_IRQ_DF 15 +#define BCM6362_IRQ_EPHY_EN0 16 +#define BCM6362_IRQ_EPHY_EN1 17 +#define BCM6362_IRQ_EPHY_EN2 18 +#define BCM6362_IRQ_EPHY_EN3 19 +#define BCM6362_IRQ_USB_CTL_RX_DMA 20 +#define BCM6362_IRQ_USB_CTL_TX_DMA 21 +#define BCM6362_IRQ_USB_BULK_RX_DMA22 +#define BCM6362_IRQ_USB_BULK_TX_DMA23 +#define BCM6362_IRQ_USB_ISO_RX_DMA 24 +#define BCM6362_IRQ_USB_ISO_TX_DMA 25 +#define BCM6362_IRQ_IPSEC_DMA0 26 +#define BCM6362_IRQ_IPSEC_DMA1 27 +#define BCM6362_IRQ_XDSL 28 +#define BCM6362_IRQ_FAP29 +#define BCM6362_IRQ_PCIE_RC30 +#define BCM6362_IRQ_PCIE_EP31 +#define BCM6362_IRQ_ENETSW_RX_DMA0 32 +#define BCM6362_IRQ_ENETSW_RX_DMA1 33 +#define BCM6362_IRQ_ENETSW_RX_DMA2 34 +#define BCM6362_IRQ_ENETSW_RX_DMA3 35 +#define BCM6362_IRQ_PCM_DMA0 36 +#define BCM6362_IRQ_PCM_DMA1 37 +#define BCM6362_IRQ_DECT0 38 +#define BCM6362_IRQ_DECT1 39 +#define BCM6362_IRQ_EXT0 40 +#define BCM6362_IRQ_EXT1 41 +#define BCM6362_IRQ_EXT2 42 +#define BCM6362_IRQ_EXT3 43 +#define BCM6362_IRQ_ATM_DMA0 44 +#define BCM6362_IRQ_ATM_DMA1 45 +#define BCM6362_IRQ_ATM_DMA2 46 +#define BCM6362_IRQ_ATM_DMA3 47 +#define BCM6362_IRQ_ATM_DMA4 48 +#define BCM6362_IRQ_ATM_DMA5 49 +#define BCM6362_IRQ_ATM_DMA6 50 +#define BCM6362_IRQ_ATM_DMA7 51 +#define BCM6362_IRQ_ATM_DMA8 52 +#define BCM6362_IRQ_ATM_DMA9 53 +#define BCM6362_IRQ_ATM_DMA10 54 +#define BCM6362_IRQ_ATM_DMA11 55 +#define BCM6362_IRQ_ATM_DMA12 56 +#define BCM6362_IRQ_ATM_DMA13 57 +#define BCM6362_IRQ_ATM_DMA14 58 +#define BCM6362_IRQ_ATM_DMA15 59 +#define BCM6362_IRQ_ATM_DMA16 60 +#define BCM6362_IRQ_ATM_DMA17 61 +#define BCM6362_IRQ_ATM_DMA18 62 +#define BCM6362_IRQ_ATM_DMA19 63 + +#endif /* __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6362_H */ -- 2.28.0
[PATCH 14/14] mips: bmips: bcm63268: include and use dt-bindings
Now that there are proper device tree bindings we can start using them.
Signed-off-by: Álvaro Fernández Rojas
---
arch/mips/boot/dts/brcm/bcm63268.dtsi | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/mips/boot/dts/brcm/bcm63268.dtsi
b/arch/mips/boot/dts/brcm/bcm63268.dtsi
index beec24145af7..17d744db8211 100644
--- a/arch/mips/boot/dts/brcm/bcm63268.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm63268.dtsi
@@ -1,4 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
+
+#include "dt-bindings/clock/bcm63268-clock.h"
+#include "dt-bindings/interrupt-controller/bcm63268-interrupt-controller.h"
+
/ {
#address-cells = <1>;
#size-cells = <1>;
@@ -87,7 +91,7 @@ uart0: serial@1180 {
reg = <0x1180 0x18>;
interrupt-parent = <&periph_intc>;
- interrupts = <5>;
+ interrupts = ;
clocks = <&periph_clk>;
clock-names = "refclk";
@@ -100,7 +104,7 @@ uart1: serial@11a0 {
reg = <0x11a0 0x18>;
interrupt-parent = <&periph_intc>;
- interrupts = <34>;
+ interrupts = ;
clocks = <&periph_clk>;
clock-names = "refclk";
@@ -123,7 +127,7 @@ ehci: usb@10002500 {
big-endian;
interrupt-parent = <&periph_intc>;
- interrupts = <10>;
+ interrupts = ;
status = "disabled";
};
@@ -135,7 +139,7 @@ ohci: usb@10002600 {
no-big-frame-no;
interrupt-parent = <&periph_intc>;
- interrupts = <9>;
+ interrupts = ;
status = "disabled";
};
--
2.28.0
[PATCH 11/14] mips: bmips: bcm6358: include and use dt-bindings
Now that there are proper device tree bindings we can start using them.
Signed-off-by: Álvaro Fernández Rojas
---
arch/mips/boot/dts/brcm/bcm6358.dtsi | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/mips/boot/dts/brcm/bcm6358.dtsi
b/arch/mips/boot/dts/brcm/bcm6358.dtsi
index f21176cac038..d149d062be80 100644
--- a/arch/mips/boot/dts/brcm/bcm6358.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm6358.dtsi
@@ -1,4 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
+
+#include "dt-bindings/clock/bcm6358-clock.h"
+#include "dt-bindings/interrupt-controller/bcm6358-interrupt-controller.h"
+
/ {
#address-cells = <1>;
#size-cells = <1>;
@@ -96,7 +100,7 @@ uart0: serial@fffe0100 {
reg = <0xfffe0100 0x18>;
interrupt-parent = <&periph_intc>;
- interrupts = <2>;
+ interrupts = ;
clocks = <&periph_clk>;
clock-names = "refclk";
@@ -109,7 +113,7 @@ uart1: serial@fffe0120 {
reg = <0xfffe0120 0x18>;
interrupt-parent = <&periph_intc>;
- interrupts = <3>;
+ interrupts = ;
clocks = <&periph_clk>;
clock-names = "refclk";
@@ -122,7 +126,7 @@ ehci: usb@fffe1300 {
reg = <0xfffe1300 0x100>;
big-endian;
interrupt-parent = <&periph_intc>;
- interrupts = <10>;
+ interrupts = ;
status = "disabled";
};
@@ -132,7 +136,7 @@ ohci: usb@fffe1400 {
big-endian;
no-big-frame-no;
interrupt-parent = <&periph_intc>;
- interrupts = <5>;
+ interrupts = ;
status = "disabled";
};
};
--
2.28.0
[PATCH 12/14] mips: bmips: bcm6362: include and use dt-bindings
Now that there are proper device tree bindings we can start using them.
Signed-off-by: Álvaro Fernández Rojas
---
arch/mips/boot/dts/brcm/bcm6362.dtsi | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/mips/boot/dts/brcm/bcm6362.dtsi
b/arch/mips/boot/dts/brcm/bcm6362.dtsi
index 8ae6981735b8..e6ec366818a9 100644
--- a/arch/mips/boot/dts/brcm/bcm6362.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm6362.dtsi
@@ -1,4 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
+
+#include "dt-bindings/clock/bcm6362-clock.h"
+#include "dt-bindings/interrupt-controller/bcm6362-interrupt-controller.h"
+
/ {
#address-cells = <1>;
#size-cells = <1>;
@@ -87,7 +91,7 @@ uart0: serial@1100 {
reg = <0x1100 0x18>;
interrupt-parent = <&periph_intc>;
- interrupts = <3>;
+ interrupts = ;
clocks = <&periph_clk>;
clock-names = "refclk";
@@ -100,7 +104,7 @@ uart1: serial@1120 {
reg = <0x1120 0x18>;
interrupt-parent = <&periph_intc>;
- interrupts = <4>;
+ interrupts = ;
clocks = <&periph_clk>;
clock-names = "refclk";
@@ -123,7 +127,7 @@ ehci: usb@10002500 {
big-endian;
interrupt-parent = <&periph_intc>;
- interrupts = <10>;
+ interrupts = ;
status = "disabled";
};
@@ -135,7 +139,7 @@ ohci: usb@10002600 {
no-big-frame-no;
interrupt-parent = <&periph_intc>;
- interrupts = <9>;
+ interrupts = ;
status = "disabled";
};
--
2.28.0
[PATCH 13/14] mips: bmips: bcm6368: include and use dt-bindings
Now that there are proper device tree bindings we can start using them.
Signed-off-by: Álvaro Fernández Rojas
---
arch/mips/boot/dts/brcm/bcm6368.dtsi | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/mips/boot/dts/brcm/bcm6368.dtsi
b/arch/mips/boot/dts/brcm/bcm6368.dtsi
index 449c167dd892..62599d4e6abe 100644
--- a/arch/mips/boot/dts/brcm/bcm6368.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm6368.dtsi
@@ -1,4 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
+
+#include "dt-bindings/clock/bcm6368-clock.h"
+#include "dt-bindings/interrupt-controller/bcm6368-interrupt-controller.h"
+
/ {
#address-cells = <1>;
#size-cells = <1>;
@@ -94,7 +98,7 @@ uart0: serial@1100 {
compatible = "brcm,bcm6345-uart";
reg = <0x1100 0x18>;
interrupt-parent = <&periph_intc>;
- interrupts = <2>;
+ interrupts = ;
clocks = <&periph_clk>;
clock-names = "refclk";
status = "disabled";
@@ -104,7 +108,7 @@ uart1: serial@1120 {
compatible = "brcm,bcm6345-uart";
reg = <0x1120 0x18>;
interrupt-parent = <&periph_intc>;
- interrupts = <3>;
+ interrupts = ;
clocks = <&periph_clk>;
clock-names = "refclk";
status = "disabled";
@@ -115,7 +119,7 @@ ehci: usb@10001500 {
reg = <0x10001500 0x100>;
big-endian;
interrupt-parent = <&periph_intc>;
- interrupts = <7>;
+ interrupts = ;
status = "disabled";
};
@@ -125,7 +129,7 @@ ohci: usb@10001600 {
big-endian;
no-big-frame-no;
interrupt-parent = <&periph_intc>;
- interrupts = <5>;
+ interrupts = ;
status = "disabled";
};
};
--
2.28.0
[PATCH 05/14] mips: bmips: add BCM6358 irq definitions
Add header with BCM6358 definitions in order to be able to include it from device tree files. Signed-off-by: Álvaro Fernández Rojas --- .../bcm6358-interrupt-controller.h| 38 +++ 1 file changed, 38 insertions(+) create mode 100644 include/dt-bindings/interrupt-controller/bcm6358-interrupt-controller.h diff --git a/include/dt-bindings/interrupt-controller/bcm6358-interrupt-controller.h b/include/dt-bindings/interrupt-controller/bcm6358-interrupt-controller.h new file mode 100644 index ..a098639dbe4e --- /dev/null +++ b/include/dt-bindings/interrupt-controller/bcm6358-interrupt-controller.h @@ -0,0 +1,38 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ + +#ifndef __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6358_H +#define __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6358_H + +#define BCM6358_IRQ_TIMER 0 +#define BCM6358_IRQ_SPI1 +#define BCM6358_IRQ_UART0 2 +#define BCM6358_IRQ_UART1 3 +#define BCM6358_IRQ_OHCI 5 +#define BCM6358_IRQ_EMAC1 6 +#define BCM6358_IRQ_USBS 7 +#define BCM6358_IRQ_EMAC0 8 +#define BCM6358_IRQ_EPHY 9 +#define BCM6358_IRQ_EHCI 10 +#define BCM6358_IRQ_USB_CTL_RX_DMA 11 +#define BCM6358_IRQ_USB_CTL_TX_DMA 12 +#define BCM6358_IRQ_USB_BULK_RX_DMA13 +#define BCM6358_IRQ_USB_BULK_TX_DMA14 +#define BCM6358_IRQ_EMAC0_RX_DMA 15 +#define BCM6358_IRQ_EMAC0_TX_DMA 16 +#define BCM6358_IRQ_EMAC1_RX_DMA 17 +#define BCM6358_IRQ_EMAC1_TX_DMA 18 +#define BCM6358_IRQ_ATM19 +#define BCM6358_IRQ_EXT4 20 +#define BCM6358_IRQ_EXT5 21 +#define BCM6358_IRQ_PCM22 +#define BCM6358_IRQ_PCM_RX_DMA 23 +#define BCM6358_IRQ_PCM_TX_DMA 24 +#define BCM6358_IRQ_EXT0 25 +#define BCM6358_IRQ_EXT1 26 +#define BCM6358_IRQ_EXT2 27 +#define BCM6358_IRQ_EXT3 28 +#define BCM6358_IRQ_ADSL 29 +#define BCM6358_IRQ_DG 30 +#define BCM6358_IRQ_MPI31 + +#endif /* __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6358_H */ -- 2.28.0
[PATCH 07/14] mips: bmips: add BCM6368 irq definitions
Add header with BCM6368 definitions in order to be able to include it from device tree files. Signed-off-by: Álvaro Fernández Rojas --- .../bcm6368-interrupt-controller.h| 71 +++ 1 file changed, 71 insertions(+) create mode 100644 include/dt-bindings/interrupt-controller/bcm6368-interrupt-controller.h diff --git a/include/dt-bindings/interrupt-controller/bcm6368-interrupt-controller.h b/include/dt-bindings/interrupt-controller/bcm6368-interrupt-controller.h new file mode 100644 index ..988e368cc156 --- /dev/null +++ b/include/dt-bindings/interrupt-controller/bcm6368-interrupt-controller.h @@ -0,0 +1,71 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ + +#ifndef __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6368_H +#define __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6368_H + +#define BCM6368_IRQ_TIMER 0 +#define BCM6368_IRQ_SPI1 +#define BCM6368_IRQ_UART0 2 +#define BCM6368_IRQ_UART1 3 +#define BCM6368_IRQ_XDSL 4 +#define BCM6368_IRQ_OHCI 5 +#define BCM6368_IRQ_IPSEC 6 +#define BCM6368_IRQ_EHCI 7 +#define BCM6368_IRQ_USBS 8 +#define BCM6368_IRQ_RING_OSC 9 +#define BCM6368_IRQ_NAND 10 +#define BCM6368_IRQ_ATM11 +#define BCM6368_IRQ_PCM12 +#define BCM6368_IRQ_MPI13 +#define BCM6368_IRQ_DG 14 +#define BCM6368_IRQ_EPHY 15 +#define BCM6368_IRQ_EPHY_EN0 16 +#define BCM6368_IRQ_EPHY_EN1 17 +#define BCM6368_IRQ_EPHY_EN2 18 +#define BCM6368_IRQ_EPHY_EN3 19 +#define BCM6368_IRQ_EXT0 20 +#define BCM6368_IRQ_EXT1 21 +#define BCM6368_IRQ_EXT2 22 +#define BCM6368_IRQ_EXT3 23 +#define BCM6368_IRQ_EXT4 24 +#define BCM6368_IRQ_EXT5 25 +#define BCM6368_IRQ_USB_CTL_RX_DMA 26 +#define BCM6368_IRQ_USB_CTL_TX_DMA 27 +#define BCM6368_IRQ_USB_BULK_RX_DMA28 +#define BCM6368_IRQ_USB_BULK_TX_DMA29 +#define BCM6368_IRQ_USB_ISO_RX_DMA 30 +#define BCM6368_IRQ_USB_ISO_TX_DMA 31 +#define BCM6368_IRQ_ENETSW_RX_DMA0 32 +#define BCM6368_IRQ_ENETSW_RX_DMA1 33 +#define BCM6368_IRQ_ENETSW_RX_DMA2 34 +#define BCM6368_IRQ_ENETSW_RX_DMA3 35 +#define BCM6368_IRQ_ENETSW_TX_DMA0 36 +#define BCM6368_IRQ_ENETSW_TX_DMA1 37 +#define BCM6368_IRQ_ENETSW_TX_DMA2 38 +#define BCM6368_IRQ_ENETSW_TX_DMA3 39 +#define BCM6368_IRQ_ATM_DMA0 40 +#define BCM6368_IRQ_ATM_DMA1 41 +#define BCM6368_IRQ_ATM_DMA2 42 +#define BCM6368_IRQ_ATM_DMA3 43 +#define BCM6368_IRQ_ATM_DMA4 44 +#define BCM6368_IRQ_ATM_DMA5 45 +#define BCM6368_IRQ_ATM_DMA6 46 +#define BCM6368_IRQ_ATM_DMA7 47 +#define BCM6368_IRQ_ATM_DMA8 48 +#define BCM6368_IRQ_ATM_DMA9 49 +#define BCM6368_IRQ_ATM_DMA10 50 +#define BCM6368_IRQ_ATM_DMA11 51 +#define BCM6368_IRQ_ATM_DMA12 52 +#define BCM6368_IRQ_ATM_DMA13 53 +#define BCM6368_IRQ_ATM_DMA14 54 +#define BCM6368_IRQ_ATM_DMA15 55 +#define BCM6368_IRQ_ATM_DMA16 56 +#define BCM6368_IRQ_ATM_DMA17 57 +#define BCM6368_IRQ_ATM_DMA18 58 +#define BCM6368_IRQ_ATM_DMA19 59 +#define BCM6368_IRQ_IPSEC_DMA0 60 +#define BCM6368_IRQ_IPSEC_DMA1 61 +#define BCM6368_IRQ_PCM_DMA0 62 +#define BCM6368_IRQ_PCM_DMA1 63 + +#endif /* __DT_BINDINGS_INTERRUPT_CONTROLLER_BCM6368_H */ -- 2.28.0
[PATCH v2 1/2] KVM: LAPIC: Return 0 when getting the tscdeadline timer if the lapic is hw disabled
From: Wanpeng Li
Return 0 when getting the tscdeadline timer if the lapic is hw disabled.
Suggested-by: Paolo Bonzini
Signed-off-by: Wanpeng Li
---
v1 -> v2:
* fix indentation
arch/x86/kvm/lapic.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 5ccbee7..79599af 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -2183,8 +2183,7 @@ u64 kvm_get_lapic_tscdeadline_msr(struct kvm_vcpu *vcpu)
{
struct kvm_lapic *apic = vcpu->arch.apic;
- if (!lapic_in_kernel(vcpu) ||
- !apic_lvtt_tscdeadline(apic))
+ if (!kvm_apic_present(vcpu) || !apic_lvtt_tscdeadline(apic))
return 0;
return apic->lapic_timer.tscdeadline;
--
2.7.4
[PATCH v2 2/2] KVM: LAPIC: Guarantee the timer is in tsc-deadline mode when setting
From: Wanpeng Li
Check apic_lvtt_tscdeadline() mode directly instead of apic_lvtt_oneshot()
and apic_lvtt_period() to guarantee the timer is in tsc-deadline mode when
wrmsr MSR_IA32_TSCDEADLINE.
Signed-off-by: Wanpeng Li
---
v1 -> v2:
* fix indentation
arch/x86/kvm/lapic.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 79599af..abaf48e 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -2193,8 +2193,7 @@ void kvm_set_lapic_tscdeadline_msr(struct kvm_vcpu *vcpu,
u64 data)
{
struct kvm_lapic *apic = vcpu->arch.apic;
- if (!kvm_apic_present(vcpu) || apic_lvtt_oneshot(apic) ||
- apic_lvtt_period(apic))
+ if (!kvm_apic_present(vcpu) || !apic_lvtt_tscdeadline(apic))
return;
hrtimer_cancel(&apic->lapic_timer.timer);
--
2.7.4
[PATCH 00/14] mips: bmips: include dt-bindings headers
Allow including dt-bindings header files and use them for bcm63xx. Álvaro Fernández Rojas (14): mips: dts: brcm: allow including header files mips: bmips: add BCM3368 irq definitions mips: bmips: add BCM6318 irq definitions mips: bmips: add BCM6328 irq definitions mips: bmips: add BCM6358 irq definitions mips: bmips: add BCM6362 irq definitions mips: bmips: add BCM6368 irq definitions mips: bmips: add BCM63268 irq definitions mips: bmips: bcm3368: include and use dt-bindings mips: bmips: bcm6328: include and use dt-bindings mips: bmips: bcm6358: include and use dt-bindings mips: bmips: bcm6362: include and use dt-bindings mips: bmips: bcm6368: include and use dt-bindings mips: bmips: bcm63268: include and use dt-bindings .../boot/dts/brcm/bcm3368-netgear-cvg834g.dts | 2 +- arch/mips/boot/dts/brcm/bcm3368.dtsi | 8 +- .../dts/brcm/bcm63268-comtrend-vr-3032u.dts | 2 +- arch/mips/boot/dts/brcm/bcm63268.dtsi | 12 ++- arch/mips/boot/dts/brcm/bcm6328.dtsi | 12 ++- .../dts/brcm/bcm6358-neufbox4-sercomm.dts | 2 +- arch/mips/boot/dts/brcm/bcm6358.dtsi | 12 ++- .../dts/brcm/bcm6362-neufbox6-sercomm.dts | 2 +- arch/mips/boot/dts/brcm/bcm6362.dtsi | 12 ++- arch/mips/boot/dts/brcm/bcm6368.dtsi | 12 ++- arch/mips/boot/dts/brcm/bcm93384wvg.dts | 2 +- arch/mips/boot/dts/brcm/bcm93384wvg_viper.dts | 2 +- arch/mips/boot/dts/brcm/bcm96368mvwg.dts | 2 +- arch/mips/boot/dts/brcm/bcm97125cbmb.dts | 2 +- arch/mips/boot/dts/brcm/bcm97346dbsmb.dts | 4 +- arch/mips/boot/dts/brcm/bcm97358svmb.dts | 4 +- arch/mips/boot/dts/brcm/bcm97360svmb.dts | 2 +- arch/mips/boot/dts/brcm/bcm97362svmb.dts | 4 +- arch/mips/boot/dts/brcm/bcm97420c.dts | 2 +- arch/mips/boot/dts/brcm/bcm97425svmb.dts | 4 +- arch/mips/boot/dts/brcm/bcm97435svmb.dts | 4 +- arch/mips/boot/dts/brcm/bcm9ejtagprb.dts | 2 +- .../bcm3368-interrupt-controller.h| 19 .../bcm6318-interrupt-controller.h| 84 ++ .../bcm63268-interrupt-controller.h | 86 +++ .../bcm6328-interrupt-controller.h| 68 +++ .../bcm6358-interrupt-controller.h| 38 .../bcm6362-interrupt-controller.h| 71 +++ .../bcm6368-interrupt-controller.h| 71 +++ 29 files changed, 504 insertions(+), 43 deletions(-) create mode 100644 include/dt-bindings/interrupt-controller/bcm3368-interrupt-controller.h create mode 100644 include/dt-bindings/interrupt-controller/bcm6318-interrupt-controller.h create mode 100644 include/dt-bindings/interrupt-controller/bcm63268-interrupt-controller.h create mode 100644 include/dt-bindings/interrupt-controller/bcm6328-interrupt-controller.h create mode 100644 include/dt-bindings/interrupt-controller/bcm6358-interrupt-controller.h create mode 100644 include/dt-bindings/interrupt-controller/bcm6362-interrupt-controller.h create mode 100644 include/dt-bindings/interrupt-controller/bcm6368-interrupt-controller.h -- 2.28.0
Re: [PATCH v2 5/7] regulator: plug of_node leak in regulator_register()'s error path
Hi Michał,
On 8/12/20 4:31 AM, Michał Mirosław wrote:
> By calling device_initialize() earlier and noting that kfree(NULL) is
> ok, we can save a bit of code in error handling and plug of_node leak.
> Fixed commit already did part of the work.
>
> Cc: sta...@vger.kernel.org
> Fixes: 9177514ce349 ("regulator: fix memory leak on error path of
> regulator_register()")
> Signed-off-by: Michał Mirosław
> Acked-by: Vladimir Zapolskiy
> ---
> drivers/regulator/core.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 71749f48caee..448a267641df 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -5137,6 +5137,7 @@ regulator_register(const struct regulator_desc
> *regulator_desc,
> ret = -ENOMEM;
> goto rinse;
> }
> + device_initialize(&rdev->dev);
>
> /*
>* Duplicate the config so the driver could override it after
> @@ -5144,9 +5145,8 @@ regulator_register(const struct regulator_desc
> *regulator_desc,
>*/
> config = kmemdup(cfg, sizeof(*cfg), GFP_KERNEL);
> if (config == NULL) {
> - kfree(rdev);
> ret = -ENOMEM;
> - goto rinse;
> + goto clean;
Here config == NULL
> }
>
> init_data = regulator_of_get_init_data(dev, regulator_desc, config,
> @@ -5158,10 +5158,8 @@ regulator_register(const struct regulator_desc
> *regulator_desc,
>* from a gpio extender or something else.
>*/
> if (PTR_ERR(init_data) == -EPROBE_DEFER) {
> - kfree(config);
> - kfree(rdev);
> ret = -EPROBE_DEFER;
> - goto rinse;
> + goto clean;
> }
>
> /*
> @@ -5214,7 +5212,6 @@ regulator_register(const struct regulator_desc
> *regulator_desc,
> }
>
> /* register with sysfs */
> - device_initialize(&rdev->dev);
> rdev->dev.class = ®ulator_class;
> rdev->dev.parent = dev;
> dev_set_name(&rdev->dev, "regulator.%lu",
> @@ -5292,13 +5289,11 @@ regulator_register(const struct regulator_desc
> *regulator_desc,
> mutex_lock(®ulator_list_mutex);
> regulator_ena_gpio_free(rdev);
> mutex_unlock(®ulator_list_mutex);
> - put_device(&rdev->dev);
> - rdev = NULL;
> clean:
> if (dangling_of_gpiod)
> gpiod_put(config->ena_gpiod);
And above 'config' NULL pointer could be dereferenced now, right?
> - kfree(rdev);
> kfree(config);
> + put_device(&rdev->dev);
> rinse:
> if (dangling_cfg_gpiod)
> gpiod_put(cfg->ena_gpiod);
>
--
Best wishes,
Vladimir
Re: "mm/vmalloc: Add flag for freeing of special permsissions" broke udev on ia64
Hi Rick! On 8/12/20 6:50 AM, Edgecombe, Rick P wrote: > On non-x86, this patchset shouldn't have changed much, just always > flush the TLB and purge the vmalloc area in cases where previously this > would only happen intermittently. Despite this, it also caused a > problem on sparc. In the end the sparc issue turned out to be an issue > with sparc's kernel range TLB flush implementation that was just now > being hit earlier during boot instead of after the system had been up > for some time. So I'm at first wondering if there might be something > like that uncovered here. Yeah, I am also suspecting a bug in the ia64-specific mm code which got just unconvered by your changes. > Unfortunately, it's unlikely that I can get access to ia64 hardware in > the near term to debug. Would you be able to test some debug patches? I can both test patches for you and arrange access to one of the Itanium servers I manage if you want to test patches yourself. Both works fine. > Also, can you post your config? See attached. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 # # Automatically generated file; DO NOT EDIT. # Linux/ia64 5.1.0-rc7 Kernel Configuration # # # Compiler: ia64-linux-gcc (GCC) 10.1.0 # CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=100100 CONFIG_CLANG_VERSION=0 CONFIG_CC_HAS_ASM_GOTO=y CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y CONFIG_IRQ_WORK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_BUILD_SALT="4.19.0-5-mckinley" CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_LEGACY=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_TIME_VSYSCALL=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # CONFIG_PSI is not set CONFIG_CPU_ISOLATION=y # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TREE_SRCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y # CONFIG_MEMCG_SWAP_ENABLED is not set CONFIG_MEMCG_KMEM=y CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set CONFIG_CGROUP_WRITEBACK=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_CGROUP_PIDS=y CONFIG_CGROUP_RDMA=y CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_HUGETLB is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_BPF=y # CONFIG_CGROUP_DEBUG is not set CONFIG_SOCK_CGROUP_DATA=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_CHECKPOINT_RESTORE=y CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_SYSCTL_ARCH_UNALIGN_NO_WARN=y CONFIG_BPF=y CONFIG_EXPERT=y CONFIG_MULTIUSER=y # CONFIG_SGETMASK_SYSCALL is not set # CONFIG_SYSFS_SYSCALL is not set # CONFIG_SYSCTL_SYSCALL is not set CONFIG_FHANDLE=y CONFIG_POSIX_TIMERS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_FUTEX_PI=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_IO_URING=y CONFIG_ADVISE_SYSCALLS=y CONFIG_MEMBARRIER=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_BPF_SYSCALL=y CONFIG_USERFAULTFD=y # CONFIG_EMBEDDED is not set # CONFIG_PC104 is not set # # Kernel Performance Events And Counters # CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLUB_MEMCG_SYSFS_ON is not set # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_SLAB_MERGE_DEFAULT=y CONFIG_SLAB_FREELIST_RAN
Re: [PATCH 0/3] Modernize tasklet callback API
On Tue, 11 Aug 2020 23:33:13 +0200, Kees Cook wrote: > > On Mon, Aug 03, 2020 at 02:16:15PM +0530, Allen wrote: > > Here's the series re-based on top of 5.8 > > https://github.com/allenpais/tasklets/tree/V3 > > Great! > > > Let me know how you would want these to be reviewed. > > Was a Coccinelle script used for any of these conversions? I wonder if > it'd be easier to do a single treewide patch for the more mechanical > changes. > > And, actually, I still think the "prepare" patches should just be > collapsed into the actual "covert" patches -- there are only a few. > > After those, yeah, I think getting these sent to their respective > maintainers is the next step. > > > Also, I was thinking if removing tasklets completely could be a task > > on KSPP wiki. If yes, I did like to take ownership of that task. I have a > > couple of ideas in mind, which could be discussed in a separate email. > > Sure! I will add it to the tracker. Here's for the refactoring: > https://github.com/KSPP/linux/issues/30 > > and here's for the removal: > https://github.com/KSPP/linux/issues/94 > > if you can added details/examples of how they should be removed, that'd > help other folks too, if they wanted to jump in. :) I have a patch set to convert the remaining tasklet usage in sound drivers to either the threaded IRQ or the work, but it wasn't submitted / merged for 5.8 due to the obvious conflict with your API changes. Each conversion is rather simple, but it's always a question of the nature of each tasklet usage which alternative is the best fit. FWIW, the current version is found in test/kill-tasklet branch of sound git tree git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git thanks, Takashi
Re: [PATCH v3 2/2] ASoC: Intel: Add period size constraint on strago board
On Wed, 12 Aug 2020 05:09:58 +0200, Yu-Hsuan Hsu wrote: > > Mark Brown 於 2020年8月12日 週三 上午1:22寫道： > > > > On Tue, Aug 11, 2020 at 11:54:38AM -0500, Pierre-Louis Bossart wrote: > > > > > > constraint logic needs to know about this DSP limitation - it seems like > > > > none of this is going to change without something new going into the > > > > mix? We at least need a new question to ask about the DSP firmware I > > > > think. > > > > > I just tested aplay -Dhw: on a Cyan Chromebook with the Ubuntu kernel 5.4, > > > and I see no issues with the 240 sample period. Same with 432, 960, 9600, > > > etc. > > > > > I also tried just for fun what happens with 256 samples, and I don't see > > > any > > > underflows thrown either, so I am wondering what exactly the problem is? > > > Something's not adding up. I would definitively favor multiple of 1ms > > > periods, since it's the only case that was productized, but there's got to > > > me something a side effect of how CRAS programs the hw_params. > > > > Is it something that goes wrong with longer playbacks possibly (eg, > > someone watching a feature film or something)? > > Thanks for testing! > > After doing some experiments, I think I can identify the problem more > precisely. > 1. aplay can not reproduce this issue because it writes samples > immediately when there are some space in the buffer. However, you can > add --test-position to see how the delay grows with period size 256. > > aplay -Dhw:1,0 --period-size=256 --buffer-size=480 /dev/zero -d 1 -f dat > > --test-position > Playing raw data '/dev/zero' : Signed 16 bit Little Endian, Rate 48000 > Hz, Stereo > Suspicious buffer position (1 total): avail = 0, delay = 2064, buffer = 512 > Suspicious buffer position (2 total): avail = 0, delay = 2064, buffer = 512 > Suspicious buffer position (3 total): avail = 0, delay = 2096, buffer = 512 > ... Isn't this about the alignment of the buffer size against the period size, not the period size itself? i.e. in the example above, the buffer size isn't a multiple of period size, and DSP can't handle if the position overlaps the buffer size in a half way. If that's the problem (and it's an oft-seen restriction), the right constraint is snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); Takashi > 2. Since many samples are moved to DSP(delay), the measured rate of > the ring-buffer is high. (I measured it by alsa_conformance_test, > which only test the sampling rate in the ring buffer of kernel not > DSP) > > 3. Since CRAS writes samples with a fixed frequency, this behavior > will take all samples from the ring buffer, which is seen as underrun > by CRAS. (It seems that it is not a real underrun because that avail > does not larger than buffer size. Maybe CRAS should also take dalay > into account.) > > 4. In spite of it is not a real underrun, the large delay is still a > big problem. Can we apply the constraint to fix it? Or any better > idea? > > Thanks, > Yu-Hsuan >
Re: [PATCH] OPP: Put opp table in dev_pm_opp_set_rate() all the time
On 8/12/2020 2:58 AM, Stephen Boyd wrote:
We get the opp_table pointer at the top of the function and so we should
put the pointer at the end of the function like all other exit paths
from this function do.
Cc: Rajendra Nayak
Fixes: aca48b61f963 ("opp: Manage empty OPP tables with clk handle")
Signed-off-by: Stephen Boyd
Thanks for the fix.
Reviewed-by: Rajendra Nayak
---
drivers/opp/core.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 9d7fb45b1786..bdb028c7793d 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -893,8 +893,10 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
* have OPP table for the device, while others don't and
* opp_set_rate() just needs to behave like clk_set_rate().
*/
- if (!_get_opp_count(opp_table))
- return 0;
+ if (!_get_opp_count(opp_table)) {
+ ret = 0;
+ goto put_opp_table;
+ }
if (!opp_table->required_opp_tables && !opp_table->regulators &&
!opp_table->paths) {
@@ -905,7 +907,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
ret = _set_opp_bw(opp_table, NULL, dev, true);
if (ret)
- return ret;
+ goto put_opp_table;
if (opp_table->regulator_enabled) {
regulator_disable(opp_table->regulators[0]);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 2/2] exfat: unify name extraction
Thanks for your reply.
On 2020/08/09 2:19, Sungjong Seo wrote:
[snip]
@@ -963,80 +942,38 @@ int exfat_find_dir_entry(struct super_block *sb,
struct exfat_inode_info *ei,
num_empty = 0;
candi_empty.eidx = EXFAT_HINT_NONE;
[snip]
- if (entry_type &
- (TYPE_CRITICAL_SEC |
TYPE_BENIGN_SEC)) {
- if (step == DIRENT_STEP_SECD) {
- if (++order == num_ext)
- goto found;
- continue;
- }
+ exfat_get_uniname_from_name_entries(es, &uni_name);
It is needed to check a return value.
I'll fix it in v2.
+ exfat_free_dentry_set(es, false);
+
+ if (!exfat_uniname_ncmp(sb,
+ p_uniname->name,
+ uni_name.name,
+ name_len)) {
+ /* set the last used position as hint */
+ hint_stat->clu = clu.dir;
+ hint_stat->eidx = dentry;
eidx and clu of hint_stat should have one for the next entry we'll start
looking for.
Did you intentionally change the concept?
Yes, this is intentional.
Essentially, the "Hint" concept is to reduce the next seek cost with minimal
cost.
There is a difference in the position of the hint, but the concept is the same.
As you can see, the patched code strategy doesn't move from current position.
Basically, the original code strategy is advancing only one dentry.(It's the
"minimum cost")
However, when it reaches the cluster boundary, it gets the next cluster and
error handling.
Getting the next cluster The error handling already exists at the end of the
while loop,
so the code is duplicated.
These costs should be paid next time and are no longer the "minimum cost".
Should I add this to the commit-message?
BR
---
Tetsuhiro Kohada
Re: [PATCH v5 3/3] mm/page_alloc: Keep memoryless cpuless node 0 offline
Hi Andrew, Michal, David * Andrew Morton [2020-08-06 21:32:11]: > On Fri, 3 Jul 2020 18:28:23 +0530 Srikar Dronamraju > wrote: > > > > The memory hotplug changes that somehow because you can hotremove numa > > > nodes and therefore make the nodemask sparse but that is not a common > > > case. I am not sure what would happen if a completely new node was added > > > and its corresponding node was already used by the renumbered one > > > though. It would likely conflate the two I am afraid. But I am not sure > > > this is really possible with x86 and a lack of a bug report would > > > suggest that nobody is doing that at least. > > > > > > > JFYI, > > Satheesh copied in this mailchain had opened a bug a year on crash with vcpu > > hotplug on memoryless node. > > > > https://bugzilla.kernel.org/show_bug.cgi?id=202187 > > So... do we merge this patch or not? Seems that the overall view is > "risky but nobody is likely to do anything better any time soon"? Can we decide on this one way or the other? -- Thanks and Regards Srikar Dronamraju
Re: [PATCH] Re: KASAN: use-after-free Read in path_init (2)
On Tue, Aug 11, 2020 at 09:29:47PM -0700, Linus Torvalds wrote: > On Tue, Aug 11, 2020 at 9:15 PM Al Viro wrote: > > > > fix breakage in do_rmdir() > > > > putname() should happen only after we'd *not* branched to > > retry, same as it's done in do_unlinkat(). > > Looks obviously correct. > > Do you want me to apply directly, or do you have other fixes pending > and I'll get a pull request? Not at the moment - I can throw it into #fixes and send a pull request if you wish, but there won't be anything else in it...
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1130 mt7915_mac_sta_stats_work() warn: test_bit() takes a bit number
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: e57b7901469fc0b021930b83a8094baaf3d81b09 mt76: add mac80211 driver for
MT7915 PCIe-based chipsets
date: 3 months ago
config: parisc-randconfig-m031-20200811 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
smatch warnings:
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1130
mt7915_mac_sta_stats_work() warn: test_bit() takes a bit number
vim +1130 drivers/net/wireless/mediatek/mt76/mt7915/mac.c
1107
1108 void mt7915_mac_sta_stats_work(struct work_struct *work)
1109 {
1110 struct ieee80211_sta *sta;
struct ieee80211_vif *vif;
1112 struct mt7915_sta_stats *stats;
1113 struct mt7915_sta *msta;
1114 struct mt7915_dev *dev;
1115
1116 msta = container_of(work, struct mt7915_sta, stats_work);
1117 sta = container_of((void *)msta, struct ieee80211_sta,
drv_priv);
1118 vif = container_of((void *)msta->vif, struct ieee80211_vif,
drv_priv);
1119 dev = msta->vif->dev;
1120 stats = &msta->stats;
1121
1122 /* use MT_TX_FREE_RATE to report Tx rate for further devices */
1123 if (time_after(jiffies, stats->jiffies + HZ)) {
1124 mt7915_mcu_get_rate_info(dev, RATE_CTRL_RU_INFO,
1125 msta->wcid.idx);
1126
1127 stats->jiffies = jiffies;
1128 }
1129
> 1130 if (test_and_clear_bit(IEEE80211_RC_SUPP_RATES_CHANGED |
1131 IEEE80211_RC_NSS_CHANGED |
1132 IEEE80211_RC_BW_CHANGED,
&stats->changed))
1133 mt7915_mcu_add_rate_ctrl(dev, vif, sta);
1134
1135 if (test_and_clear_bit(IEEE80211_RC_SMPS_CHANGED,
&stats->changed))
1136 mt7915_mcu_add_smps(dev, vif, sta);
1137
1138 spin_lock_bh(&dev->sta_poll_lock);
1139 if (list_empty(&msta->poll_list))
1140 list_add_tail(&msta->poll_list, &dev->sta_poll_list);
1141 spin_unlock_bh(&dev->sta_poll_lock);
1142 }
1143
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c:224 dwmac_dma_flush_tx_fifo() warn: this loop depends on readl() succeeding
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: 05933aac7b11911955de307a329dc2a7a14b7bd0 ia64: remove now unused
machvec indirections
date: 12 months ago
config: ia64-randconfig-m031-20200811 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
smatch warnings:
drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c:224 dwmac_dma_flush_tx_fifo()
warn: this loop depends on readl() succeeding
vim +224 drivers/net/ethernet/stmicro/stmmac/dwmac_lib.c
aec7ff27814528 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-01-06
218
ad01b7d480a4a1 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-08-23
219 void dwmac_dma_flush_tx_fifo(void __iomem *ioaddr)
688911c2f5e5e4 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-04-13
220 {
688911c2f5e5e4 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-04-13
221u32 csr6 = readl(ioaddr + DMA_CONTROL);
688911c2f5e5e4 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-04-13
222writel((csr6 | DMA_CONTROL_FTF), ioaddr + DMA_CONTROL);
688911c2f5e5e4 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-04-13
223
688911c2f5e5e4 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-04-13
@224do {} while ((readl(ioaddr + DMA_CONTROL) & DMA_CONTROL_FTF));
688911c2f5e5e4 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-04-13
225 }
aec7ff27814528 drivers/net/stmmac/dwmac_lib.c Giuseppe CAVALLARO 2010-01-06
226
:: The code at line 224 was first introduced by commit
:: 688911c2f5e5e4f33b5a1c32839184f1fdf814ee stmmac: fix Transmit FIFO flush
operation
:: TO: Giuseppe CAVALLARO
:: CC: David S. Miller
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [RFC 0/5] Introduce NMI aware serial drivers
On Tue, 11 Aug 2020 at 20:28, Greg Kroah-Hartman wrote: > > On Tue, Aug 11, 2020 at 07:59:24PM +0530, Sumit Garg wrote: > > Hi Greg, > > > > Thanks for your comments. > > > > On Tue, 11 Aug 2020 at 19:27, Greg Kroah-Hartman > > wrote: > > > > > > On Tue, Aug 11, 2020 at 07:20:26PM +0530, Sumit Garg wrote: > > > > On Tue, 21 Jul 2020 at 17:40, Sumit Garg wrote: > > > > > > > > > > Make it possible for UARTs to trigger magic sysrq from an NMI. With > > > > > the > > > > > advent of pseudo NMIs on arm64 it became quite generic to request > > > > > serial > > > > > device interrupt as an NMI rather than IRQ. And having NMI driven > > > > > serial > > > > > RX will allow us to trigger magic sysrq as an NMI and hence drop into > > > > > kernel debugger in NMI context. > > > > > > > > > > The major use-case is to add NMI debugging capabilities to the kernel > > > > > in order to debug scenarios such as: > > > > > - Primary CPU is stuck in deadlock with interrupts disabled and hence > > > > > doesn't honor serial device interrupt. So having magic sysrq > > > > > triggered > > > > > as an NMI is helpful for debugging. > > > > > - Always enabled NMI based magic sysrq irrespective of whether the > > > > > serial > > > > > TTY port is active or not. > > > > > > > > > > Currently there is an existing kgdb NMI serial driver which provides > > > > > partial implementation in upstream to have a separate ttyNMI0 port but > > > > > that remained in silos with the serial core/drivers which made it a > > > > > bit > > > > > odd to enable using serial device interrupt and hence remained > > > > > unused. It > > > > > seems to be clearly intended to avoid almost all custom NMI changes to > > > > > the UART driver. > > > > > > > > > > But this patch-set allows the serial core/drivers to be NMI aware > > > > > which > > > > > in turn provides NMI debugging capabilities via magic sysrq and hence > > > > > there is no specific reason to keep this special driver. So remove it > > > > > instead. > > > > > > > > > > Approach: > > > > > - > > > > > > > > > > The overall idea is to intercept serial RX characters in NMI context, > > > > > if > > > > > those are specific to magic sysrq then allow corresponding handler to > > > > > run > > > > > in NMI context. Otherwise, defer all other RX and TX operations onto > > > > > IRQ > > > > > work queue in order to run those in normal interrupt context. > > > > > > > > > > This approach is demonstrated using amba-pl011 driver. > > > > > > > > > > Patch-wise description: > > > > > --- > > > > > > > > > > Patch #1 prepares magic sysrq handler to be NMI aware. > > > > > Patch #2 adds NMI framework to serial core. > > > > > Patch #3 and #4 demonstrates NMI aware uart port using amba-pl011 > > > > > driver. > > > > > Patch #5 removes kgdb NMI serial driver. > > > > > > > > > > Goal of this RFC: > > > > > - > > > > > > > > > > My main reason for sharing this as an RFC is to help decide whether or > > > > > not to continue with this approach. The next step for me would to port > > > > > the work to a system with an 8250 UART. > > > > > > > > > > > > > A gentle reminder to seek feedback on this series. > > > > > > It's the middle of the merge window, and I can't do anything. > > > > > > Also, I almost never review RFC patches as I have have way too many > > > patches that people think are "right" to review first... > > > > > > > Okay, I understand and I can definitely wait for your feedback. > > My feedback here is this: > > > > I suggest you work to flesh this out first and submit something that you > > > feels works properly. > > :) > > > IIUC, in order to make this approach substantial I need to make it > > work with 8250 UART (major serial driver), correct? As currently it > > works properly for amba-pl011 driver. > > Yes, try to do that, or better yet, make it work with all serial drivers > automatically. I would like to make serial drivers work automatically but unfortunately the interrupt request/ handling code is pretty specific to the corresponding serial driver. BTW, I will look for ways how we can make it much easier for serial drivers to adapt. -Sumit > > thanks, > > greg k-h
Re: [RFC v2 03/11] tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state
On 8/12/2020 7:03 AM, John Stultz wrote: On Tue, Aug 11, 2020 at 4:11 PM John Stultz wrote: On Wed, Mar 20, 2019 at 2:49 AM Rajendra Nayak wrote: geni serial needs to express a perforamnce state requirement on CX depending on the frequency of the clock rates. Use OPP table from DT to register with OPP framework and use dev_pm_opp_set_rate() to set the clk/perf state. Signed-off-by: Rajendra Nayak Signed-off-by: Stephen Boyd --- drivers/tty/serial/qcom_geni_serial.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) Hey, I just wanted to follow up on this patch, as I've bisected it (a5819b548af0) down as having broken qca bluetooth on the Dragonboard 845c. I haven't yet had time to debug it yet, but wanted to raise the issue in case anyone else has seen similar trouble. So I dug in a bit further, and this chunk seems to be causing the issue: @@ -961,7 +963,7 @@ static void qcom_geni_serial_set_termios(struct uart_port *uport, goto out_restart_rx; uport->uartclk = clk_rate; - clk_set_rate(port->se.clk, clk_rate); + dev_pm_opp_set_rate(port->dev, clk_rate); ser_clk_cfg = SER_CLK_EN; ser_clk_cfg |= clk_div << CLK_DIV_SHFT; With that applied, I see the following errors in dmesg and bluetooth fails to function: [4.763467] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: failed to find OPP for freq 10240 (-34) [4.773493] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: failed to find OPP for freq 10240 (-34) With just that chunk reverted on linus/HEAD, bluetooth seems to work ok. This seems like the same issue that was also reported on venus [1] because the clock frequency tables apparently don;t exactly match the achievable clock frequencies (which we also used to construct the OPP tables) Can you try updating the OPP table for QUP to have 10240 instead of the current 1 and see if that fixes it? [1] https://lkml.org/lkml/2020/7/27/507 thanks -john -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 10/10] mm/hugetlb: not necessary to abuse temporary page to workaround the nasty free_huge_page
On 08/11/20 at 02:43pm, Mike Kravetz wrote:
> Here is a patch to do that. However, we are optimizing a return path in
> a race condition that we are unlikely to ever hit. I 'tested' it by
> allocating
> an 'extra' page and freeing it via this method in alloc_surplus_huge_page.
>
> From 864c5f8ef4900c95ca3f6f2363a85f3cb25e793e Mon Sep 17 00:00:00 2001
> From: Mike Kravetz
> Date: Tue, 11 Aug 2020 12:45:41 -0700
> Subject: [PATCH] hugetlb: optimize race error return in
> alloc_surplus_huge_page
>
> The routine alloc_surplus_huge_page() could race with with a pool
> size change. If this happens, the allocated page may not be needed.
> To free the page, the current code will 'Abuse temporary page to
> workaround the nasty free_huge_page codeflow'. Instead, directly
> call the low level routine that free_huge_page uses. This works
> out well because the page is new, we hold the only reference and
> already hold the hugetlb_lock.
>
> Signed-off-by: Mike Kravetz
> ---
> mm/hugetlb.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 590111ea6975..ac89b91fba86 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1923,14 +1923,17 @@ static struct page *alloc_surplus_huge_page(struct
> hstate *h, gfp_t gfp_mask,
> /*
>* We could have raced with the pool size change.
>* Double check that and simply deallocate the new page
> - * if we would end up overcommiting the surpluses. Abuse
> - * temporary page to workaround the nasty free_huge_page
> - * codeflow
> + * if we would end up overcommiting the surpluses.
>*/
> if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
> - SetPageHugeTemporary(page);
> + /*
> + * Since this page is new, we hold the only reference, and
> + * we already hold the hugetlb_lock call the low level free
> + * page routine. This saves at least a lock roundtrip.
> + */
> + (void)put_page_testzero(page); /* don't call destructor */
> + update_and_free_page(h, page);
Yeah, taking this code change, or keeping the temporary page way as is,
both looks good.
> spin_unlock(&hugetlb_lock);
> - put_page(page);
> return NULL;
> } else {
> h->surplus_huge_pages++;
Re: [PATCH] i2c: imx: Use dev_err_probe() to simplify error handling
On Wed, Aug 12, 2020 at 11:45:54AM +0800, Anson Huang wrote:
> dev_err_probe() can reduce code size, uniform error handling and record the
> defer probe reason etc., use it to simplify the code.
>
> Signed-off-by: Anson Huang
> ---
> drivers/i2c/busses/i2c-imx.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 0ab5381..63f4367 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1159,11 +1159,9 @@ static int i2c_imx_probe(struct platform_device *pdev)
>
> /* Get I2C clock */
> i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
> - if (IS_ERR(i2c_imx->clk)) {
> - if (PTR_ERR(i2c_imx->clk) != -EPROBE_DEFER)
> - dev_err(&pdev->dev, "can't get I2C clock\n");
> - return PTR_ERR(i2c_imx->clk);
> - }
> + if (IS_ERR(i2c_imx->clk))
> + return dev_err_probe(&pdev->dev, PTR_ERR(i2c_imx->clk),
> + "can't get I2C clock\n");
>
> ret = clk_prepare_enable(i2c_imx->clk);
> if (ret) {
> --
Acked-by: Oleksij Rempel
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: PGP signature
Re: [PATCH v5 06/10] powerpc/smp: Optimize start_secondary
Hi Srikar,
On Mon, Aug 10, 2020 at 12:48:30PM +0530, Srikar Dronamraju wrote:
> In start_secondary, even if shared_cache was already set, system does a
> redundant match for cpumask. This redundant check can be removed by
> checking if shared_cache is already set.
>
> While here, localize the sibling_mask variable to within the if
> condition.
>
> Cc: linuxppc-dev
> Cc: LKML
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Anton Blanchard
> Cc: Oliver O'Halloran
> Cc: Nathan Lynch
> Cc: Michael Neuling
> Cc: Gautham R Shenoy
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Valentin Schneider
> Cc: Jordan Niethe
> Cc: Vaidyanathan Srinivasan
> Signed-off-by: Srikar Dronamraju
The change looks good to me.
Reviewed-by: Gautham R. Shenoy
> ---
> Changelog v4 ->v5:
> Retain cache domain, no need for generalization
>(Michael Ellerman, Peter Zijlstra,
>Valentin Schneider, Gautham R. Shenoy)
>
> Changelog v1 -> v2:
> Moved shared_cache topology fixup to fixup_topology (Gautham)
>
> arch/powerpc/kernel/smp.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 0c960ce3be42..91cf5d05e7ec 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -851,7 +851,7 @@ static int powerpc_shared_cache_flags(void)
> */
> static const struct cpumask *shared_cache_mask(int cpu)
> {
> - return cpu_l2_cache_mask(cpu);
> + return per_cpu(cpu_l2_cache_map, cpu);
> }
>
> #ifdef CONFIG_SCHED_SMT
> @@ -1305,7 +1305,6 @@ static void add_cpu_to_masks(int cpu)
> void start_secondary(void *unused)
> {
> unsigned int cpu = smp_processor_id();
> - struct cpumask *(*sibling_mask)(int) = cpu_sibling_mask;
>
> mmgrab(&init_mm);
> current->active_mm = &init_mm;
> @@ -1331,14 +1330,20 @@ void start_secondary(void *unused)
> /* Update topology CPU masks */
> add_cpu_to_masks(cpu);
>
> - if (has_big_cores)
> - sibling_mask = cpu_smallcore_mask;
> /*
>* Check for any shared caches. Note that this must be done on a
>* per-core basis because one core in the pair might be disabled.
>*/
> - if (!cpumask_equal(cpu_l2_cache_mask(cpu), sibling_mask(cpu)))
> - shared_caches = true;
> + if (!shared_caches) {
> + struct cpumask *(*sibling_mask)(int) = cpu_sibling_mask;
> + struct cpumask *mask = cpu_l2_cache_mask(cpu);
> +
> + if (has_big_cores)
> + sibling_mask = cpu_smallcore_mask;
> +
> + if (cpumask_weight(mask) > cpumask_weight(sibling_mask(cpu)))
> + shared_caches = true;
> + }
>
> set_numa_node(numa_cpu_lookup_table[cpu]);
> set_numa_mem(local_memory_node(numa_cpu_lookup_table[cpu]));
> --
> 2.18.2
>
drivers/edac/amd64_edac.c:3065:47: sparse: sparse: incorrect type in argument 3 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb893de323e2d39f7a1f6df425703a2edbdf56ea commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 8 weeks ago config: i386-randconfig-s001-20200812 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-168-g9554805c-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/edac/amd64_edac.c:3065:47: sparse: sparse: incorrect type in >> argument 3 (different address spaces) @@ expected struct msr *msrs @@ >> got struct msr [noderef] __percpu *static [toplevel] msrs @@ drivers/edac/amd64_edac.c:3065:47: sparse: expected struct msr *msrs >> drivers/edac/amd64_edac.c:3065:47: sparse: got struct msr [noderef] >> __percpu *static [toplevel] msrs drivers/edac/amd64_edac.c:3097:48: sparse: sparse: incorrect type in argument 3 (different address spaces) @@ expected struct msr *msrs @@ got struct msr [noderef] __percpu *static [toplevel] msrs @@ drivers/edac/amd64_edac.c:3097:48: sparse: expected struct msr *msrs drivers/edac/amd64_edac.c:3097:48: sparse: got struct msr [noderef] __percpu *static [toplevel] msrs drivers/edac/amd64_edac.c:3116:48: sparse: sparse: incorrect type in argument 3 (different address spaces) @@ expected struct msr *msrs @@ got struct msr [noderef] __percpu *static [toplevel] msrs @@ drivers/edac/amd64_edac.c:3116:48: sparse: expected struct msr *msrs drivers/edac/amd64_edac.c:3116:48: sparse: got struct msr [noderef] __percpu *static [toplevel] msrs >> drivers/edac/amd64_edac.c:3674:14: sparse: sparse: incorrect type in >> assignment (different address spaces) @@ expected struct msr [noderef] >> __percpu *static [toplevel] msrs @@ got struct msr * @@ >> drivers/edac/amd64_edac.c:3674:14: sparse: expected struct msr [noderef] >> __percpu *static [toplevel] msrs drivers/edac/amd64_edac.c:3674:14: sparse: got struct msr * drivers/edac/amd64_edac.c:3711:19: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected struct msr *msrs @@ got struct msr [noderef] __percpu *static [toplevel] msrs @@ drivers/edac/amd64_edac.c:3711:19: sparse: expected struct msr *msrs drivers/edac/amd64_edac.c:3711:19: sparse: got struct msr [noderef] __percpu *static [toplevel] msrs >> drivers/edac/amd64_edac.c:3740:19: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected struct msr *msrs @@ >> got struct msr [noderef] __percpu *static [assigned] [toplevel] msrs @@ drivers/edac/amd64_edac.c:3740:19: sparse: expected struct msr *msrs >> drivers/edac/amd64_edac.c:3740:19: sparse: got struct msr [noderef] >> __percpu *static [assigned] [toplevel] msrs -- >> drivers/video/fbdev/geode/suspend_gx.c:32:28: sparse: sparse: incorrect type >> in argument 2 (different address spaces) @@ expected void const *q @@ >> got void [noderef] __iomem *gp_regs @@ drivers/video/fbdev/geode/suspend_gx.c:32:28: sparse: expected void const *q drivers/video/fbdev/geode/suspend_gx.c:32:28: sparse: got void [noderef] __iomem *gp_regs >> drivers/video/fbdev/geode/suspend_gx.c:33:28: sparse: sparse: incorrect type >> in argument 2 (different address spaces) @@ expected void const *q @@ >> got void [noderef] __iomem *dc_regs @@ drivers/video/fbdev/geode/suspend_gx.c:33:28: sparse: expected void const *q drivers/video/fbdev/geode/suspend_gx.c:33:28: sparse: got void [noderef] __iomem *dc_regs >> drivers/video/fbdev/geode/suspend_gx.c:34:28: sparse: sparse: incorrect type >> in argument 2 (different address spaces) @@ expected void const *q @@ >> got void [noderef] __iomem *vid_regs @@ drivers/video/fbdev/geode/suspend_gx.c:34:28: sparse: expected void const *q drivers/video/fbdev/geode/suspend_gx.c:34:28: sparse: got void [noderef] __iomem *vid_regs >> drivers/video/fbdev/geode/suspend_gx.c:35:39: sparse: sparse: incorrect type >> in argument 2 (different address spaces) @@ expected void const *q @@ >> got void [noderef] __iomem * @@ drivers/video/fbdev/geode/suspend_gx.c:35:39: sparse: expected void const *q drivers/video/fbdev/geode/suspend_gx.c:35:39: sparse: got void [noderef] __iomem * -- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c: note: in included file (through drivers/net/wireless/intel/iwlwifi/mvm/..//fw/img.h, drivers/net/wireless/intel/iwlwifi/mvm/..//iwl-trans.h, ...): drivers/net/wireless/intel/iwlwifi/
drivers/gpu/drm/i915/i915_sw_fence.c:84:20: error: unused function 'debug_fence_init_onstack'
Hi Masahiro,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: 6863f5643dd717376c2fdc85a47a00f9d738a834 kbuild: allow Clang to find
unused static inline functions for W=1 build
date: 11 months ago
config: x86_64-randconfig-a005-20200812 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
4f2ad15db535873dda9bfe248a2771023b64a43c)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout 6863f5643dd717376c2fdc85a47a00f9d738a834
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/i915_sw_fence.c:84:20: error: unused function
>> 'debug_fence_init_onstack' [-Werror,-Wunused-function]
static inline void debug_fence_init_onstack(struct i915_sw_fence *fence)
^
>> drivers/gpu/drm/i915/i915_sw_fence.c:105:20: error: unused function
>> 'debug_fence_free' [-Werror,-Wunused-function]
static inline void debug_fence_free(struct i915_sw_fence *fence)
^
2 errors generated.
--
>> drivers/gpu/drm/i915/display/intel_hdmi.c:1696:26: error: unused function
>> 'intel_hdmi_hdcp2_protocol' [-Werror,-Wunused-function]
enum hdcp_wired_protocol intel_hdmi_hdcp2_protocol(void)
^
1 error generated.
--
>> drivers/gpu/drm/i915/gvt/gtt.c:263:19: error: unused function 'get_pt_type'
>> [-Werror,-Wunused-function]
static inline int get_pt_type(int type)
^
>> drivers/gpu/drm/i915/gvt/gtt.c:587:20: error: unused function
>> 'ppgtt_set_guest_root_entry' [-Werror,-Wunused-function]
static inline void ppgtt_set_guest_root_entry(struct intel_vgpu_mm *mm,
^
2 errors generated.
vim +/debug_fence_init_onstack +84 drivers/gpu/drm/i915/i915_sw_fence.c
fc1584059d6c43 Chris Wilson 2016-11-25 83
214707fc2ce08d Chris Wilson 2017-10-12 @84 static inline void
debug_fence_init_onstack(struct i915_sw_fence *fence)
214707fc2ce08d Chris Wilson 2017-10-12 85 {
214707fc2ce08d Chris Wilson 2017-10-12 86 }
214707fc2ce08d Chris Wilson 2017-10-12 87
fc1584059d6c43 Chris Wilson 2016-11-25 88 static inline void
debug_fence_activate(struct i915_sw_fence *fence)
fc1584059d6c43 Chris Wilson 2016-11-25 89 {
fc1584059d6c43 Chris Wilson 2016-11-25 90 }
fc1584059d6c43 Chris Wilson 2016-11-25 91
fc1584059d6c43 Chris Wilson 2016-11-25 92 static inline void
debug_fence_set_state(struct i915_sw_fence *fence,
fc1584059d6c43 Chris Wilson 2016-11-25 93
int old, int new)
fc1584059d6c43 Chris Wilson 2016-11-25 94 {
fc1584059d6c43 Chris Wilson 2016-11-25 95 }
fc1584059d6c43 Chris Wilson 2016-11-25 96
fc1584059d6c43 Chris Wilson 2016-11-25 97 static inline void
debug_fence_deactivate(struct i915_sw_fence *fence)
fc1584059d6c43 Chris Wilson 2016-11-25 98 {
fc1584059d6c43 Chris Wilson 2016-11-25 99 }
fc1584059d6c43 Chris Wilson 2016-11-25 100
fc1584059d6c43 Chris Wilson 2016-11-25 101 static inline void
debug_fence_destroy(struct i915_sw_fence *fence)
fc1584059d6c43 Chris Wilson 2016-11-25 102 {
fc1584059d6c43 Chris Wilson 2016-11-25 103 }
fc1584059d6c43 Chris Wilson 2016-11-25 104
fc1584059d6c43 Chris Wilson 2016-11-25 @105 static inline void
debug_fence_free(struct i915_sw_fence *fence)
fc1584059d6c43 Chris Wilson 2016-11-25 106 {
fc1584059d6c43 Chris Wilson 2016-11-25 107 }
fc1584059d6c43 Chris Wilson 2016-11-25 108
:: The code at line 84 was first introduced by commit
:: 214707fc2ce08d09982bc4fe4b7a1c1f010e82be drm/i915/selftests: Wrap a
timer into a i915_sw_fence
:: TO: Chris Wilson
:: CC: Chris Wilson
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v3 06/18] gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL
On Sun, Aug 09, 2020 at 09:25:17PM +0800, Kent Gibson wrote: > Add support for GPIO_V2_GET_LINEINFO_IOCTL and > GPIO_V2_GET_LINEINFO_WATCH_IOCTL. > > Signed-off-by: Kent Gibson > --- > [snip] > > if (copy_from_user(&lineinfo, ip, sizeof(lineinfo))) > return -EFAULT; > @@ -1251,7 +1353,9 @@ static long gpio_ioctl(struct file *file, unsigned int > cmd, unsigned long arg) > if (IS_ERR(desc)) > return PTR_ERR(desc); > > - gpio_desc_to_lineinfo(desc, &lineinfo); > + gpio_desc_to_lineinfo(desc, &lineinfo_v2); > + lineinfo_v2.offset = lineinfo.line_offset; > + gpio_v2_line_info_to_v1(&lineinfo_v2, &lineinfo); > This is broken as gpio_desc_to_lineinfo() requires the offset to be already set in the info. I could move the setting of offset before the call, but would rather change gpio_desc_to_lineinfo() to treat info strictly as output (it can determine the offset from the desc) so as not to trap anyone else in the future. I also intend to replace the use of strncpy, from this patch and elsewhere, to placate the build-bot. Cheers, Kent.
drivers/soc/qcom/smd-rpm.c:177:47: sparse: sparse: incorrect type in argument 2 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb893de323e2d39f7a1f6df425703a2edbdf56ea commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 8 weeks ago config: powerpc64-randconfig-s032-20200812 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-168-g9554805c-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/soc/qcom/smd-rpm.c:177:47: sparse: sparse: incorrect type in >> argument 2 (different address spaces) @@ expected void const volatile >> [noderef] __iomem *s @@ got unsigned char const * @@ >> drivers/soc/qcom/smd-rpm.c:177:47: sparse: expected void const volatile >> [noderef] __iomem *s drivers/soc/qcom/smd-rpm.c:177:47: sparse: got unsigned char const * -- >> drivers/spi/spi-fsl-cpm.c:58:39: sparse: sparse: incorrect type in argument >> 1 (different base types) @@ expected unsigned int volatile [noderef] >> [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ >> drivers/spi/spi-fsl-cpm.c:58:39: sparse: expected unsigned int volatile >> [noderef] [usertype] __iomem *addr >> drivers/spi/spi-fsl-cpm.c:58:39: sparse: got restricted __be32 [noderef] >> __iomem * >> drivers/spi/spi-fsl-cpm.c:59:39: sparse: sparse: incorrect type in argument >> 1 (different base types) @@ expected unsigned short volatile [noderef] >> [usertype] __iomem *addr @@ got restricted __be16 [noderef] __iomem * @@ >> drivers/spi/spi-fsl-cpm.c:59:39: sparse: expected unsigned short >> volatile [noderef] [usertype] __iomem *addr >> drivers/spi/spi-fsl-cpm.c:59:39: sparse: got restricted __be16 [noderef] >> __iomem * >> drivers/spi/spi-fsl-cpm.c:60:47: sparse: sparse: incorrect type in argument >> 1 (different base types) @@ expected unsigned short const volatile >> [noderef] [usertype] __iomem *addr @@ got restricted __be16 [noderef] >> __iomem * @@ >> drivers/spi/spi-fsl-cpm.c:60:47: sparse: expected unsigned short const >> volatile [noderef] [usertype] __iomem *addr drivers/spi/spi-fsl-cpm.c:60:47: sparse: got restricted __be16 [noderef] __iomem * drivers/spi/spi-fsl-cpm.c:61:39: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ drivers/spi/spi-fsl-cpm.c:61:39: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr drivers/spi/spi-fsl-cpm.c:61:39: sparse: got restricted __be32 [noderef] __iomem * drivers/spi/spi-fsl-cpm.c:62:39: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short volatile [noderef] [usertype] __iomem *addr @@ got restricted __be16 [noderef] __iomem * @@ drivers/spi/spi-fsl-cpm.c:62:39: sparse: expected unsigned short volatile [noderef] [usertype] __iomem *addr drivers/spi/spi-fsl-cpm.c:62:39: sparse: got restricted __be16 [noderef] __iomem * drivers/spi/spi-fsl-cpm.c:63:47: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned short const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be16 [noderef] __iomem * @@ drivers/spi/spi-fsl-cpm.c:63:47: sparse: expected unsigned short const volatile [noderef] [usertype] __iomem *addr drivers/spi/spi-fsl-cpm.c:63:47: sparse: got restricted __be16 [noderef] __iomem * >> drivers/spi/spi-fsl-cpm.c:77:44: sparse: sparse: incorrect type in >> initializer (different address spaces) @@ expected struct fsl_spi_reg >> *reg_base @@ got void [noderef] __iomem *reg_base @@ drivers/spi/spi-fsl-cpm.c:77:44: sparse: expected struct fsl_spi_reg *reg_base >> drivers/spi/spi-fsl-cpm.c:77:44: sparse: got void [noderef] __iomem >> *reg_base >> drivers/spi/spi-fsl-cpm.c:97:32: sparse: sparse: incorrect type in argument >> 1 (different address spaces) @@ expected restricted __be32 [noderef] >> [usertype] __iomem *reg @@ got restricted __be32 * @@ >> drivers/spi/spi-fsl-cpm.c:97:32: sparse: expected restricted __be32 >> [noderef] [usertype] __iomem *reg drivers/spi/spi-fsl-cpm.c:97:32: sparse: got restricted __be32 * drivers/spi/spi-fsl-cpm.c:104:44: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected
drivers/tty/serial/8250/serial_cs.c:148:17: sparse: sparse: cast removes address space '__iomem' of expression
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb893de323e2d39f7a1f6df425703a2edbdf56ea commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 8 weeks ago config: riscv-randconfig-s031-20200812 (attached as .config) compiler: riscv64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-168-g9554805c-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/tty/serial/8250/serial_cs.c:148:17: sparse: sparse: cast removes >> address space '__iomem' of expression >> drivers/tty/serial/8250/serial_cs.c:148:17: sparse: sparse: incorrect type >> in argument 2 (different address spaces) @@ expected void volatile >> [noderef] __iomem *addr @@ got void * @@ >> drivers/tty/serial/8250/serial_cs.c:148:17: sparse: expected void >> volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:148:17: sparse: got void * drivers/tty/serial/8250/serial_cs.c:162:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:162:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:162:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:162:9: sparse: got void * drivers/tty/serial/8250/serial_cs.c:164:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:164:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:164:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:164:9: sparse: got void * drivers/tty/serial/8250/serial_cs.c:166:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:166:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:166:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:166:9: sparse: got void * drivers/tty/serial/8250/serial_cs.c:168:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:168:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:168:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:168:9: sparse: got void * drivers/tty/serial/8250/serial_cs.c:170:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:170:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:170:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:170:9: sparse: got void * drivers/tty/serial/8250/serial_cs.c:172:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:172:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:172:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:172:9: sparse: got void * drivers/tty/serial/8250/serial_cs.c:174:9: sparse: sparse: cast removes address space '__iomem' of expression drivers/tty/serial/8250/serial_cs.c:174:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/tty/serial/8250/serial_cs.c:174:9: sparse: expected void volatile [noderef] __iomem *addr drivers/tty/serial/8250/serial_cs.c:174:9: sparse: got void * -- >> drivers/video/fbdev/arcfb.c:119:9: sparse: sparse: cast removes address >> space '__iomem' of expression >> drivers/video/
[PATCH v3] f2fs: change virtual mapping way for compression pages
From: Daeho Jeong
By profiling f2fs compression works, I've found vmap() callings have
unexpected hikes in the execution time in our test environment and
those are bottlenecks of f2fs decompression path. Changing these with
vm_map_ram(), we can enhance f2fs decompression speed pretty much.
[Verification]
Android Pixel 3(ARM64, 6GB RAM, 128GB UFS)
Turned on only 0-3 little cores(at 1.785GHz)
dd if=/dev/zero of=dummy bs=1m count=1000
echo 3 > /proc/sys/vm/drop_caches
dd if=dummy of=/dev/zero bs=512k
- w/o compression -
1048576000 bytes (0.9 G) copied, 2.082554 s, 480 M/s
1048576000 bytes (0.9 G) copied, 2.081634 s, 480 M/s
1048576000 bytes (0.9 G) copied, 2.090861 s, 478 M/s
- before patch -
1048576000 bytes (0.9 G) copied, 7.407527 s, 135 M/s
1048576000 bytes (0.9 G) copied, 7.283734 s, 137 M/s
1048576000 bytes (0.9 G) copied, 7.291508 s, 137 M/s
- after patch -
1048576000 bytes (0.9 G) copied, 1.998959 s, 500 M/s
1048576000 bytes (0.9 G) copied, 1.987554 s, 503 M/s
1048576000 bytes (0.9 G) copied, 1.986380 s, 503 M/s
Signed-off-by: Daeho Jeong
---
Changes in v2:
- Added test environment description.
Changes in v3:
- Re-tested using only ARM little cores and maximzing cpu clock.
---
fs/f2fs/compress.c | 42 --
1 file changed, 32 insertions(+), 10 deletions(-)
diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
index 6e7db450006c..46b7e359f313 100644
--- a/fs/f2fs/compress.c
+++ b/fs/f2fs/compress.c
@@ -554,6 +554,8 @@ static void f2fs_compress_free_page(struct page *page)
mempool_free(page, compress_page_pool);
}
+#define MAX_VMAP_RETRIES 3
+
static int f2fs_compress_pages(struct compress_ctx *cc)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(cc->inode);
@@ -590,13 +592,23 @@ static int f2fs_compress_pages(struct compress_ctx *cc)
}
}
- cc->rbuf = vmap(cc->rpages, cc->cluster_size, VM_MAP, PAGE_KERNEL_RO);
+ for (i = 0; i < MAX_VMAP_RETRIES; i++) {
+ cc->rbuf = vm_map_ram(cc->rpages, cc->cluster_size, -1);
+ if (cc->rbuf)
+ break;
+ vm_unmap_aliases();
+ }
if (!cc->rbuf) {
ret = -ENOMEM;
goto out_free_cpages;
}
- cc->cbuf = vmap(cc->cpages, cc->nr_cpages, VM_MAP, PAGE_KERNEL);
+ for (i = 0; i < MAX_VMAP_RETRIES; i++) {
+ cc->cbuf = vm_map_ram(cc->cpages, cc->nr_cpages, -1);
+ if (cc->cbuf)
+ break;
+ vm_unmap_aliases();
+ }
if (!cc->cbuf) {
ret = -ENOMEM;
goto out_vunmap_rbuf;
@@ -624,8 +636,8 @@ static int f2fs_compress_pages(struct compress_ctx *cc)
memset(&cc->cbuf->cdata[cc->clen], 0,
(nr_cpages * PAGE_SIZE) - (cc->clen + COMPRESS_HEADER_SIZE));
- vunmap(cc->cbuf);
- vunmap(cc->rbuf);
+ vm_unmap_ram(cc->cbuf, cc->nr_cpages);
+ vm_unmap_ram(cc->rbuf, cc->cluster_size);
for (i = nr_cpages; i < cc->nr_cpages; i++) {
f2fs_compress_free_page(cc->cpages[i]);
@@ -642,9 +654,9 @@ static int f2fs_compress_pages(struct compress_ctx *cc)
return 0;
out_vunmap_cbuf:
- vunmap(cc->cbuf);
+ vm_unmap_ram(cc->cbuf, cc->nr_cpages);
out_vunmap_rbuf:
- vunmap(cc->rbuf);
+ vm_unmap_ram(cc->rbuf, cc->cluster_size);
out_free_cpages:
for (i = 0; i < cc->nr_cpages; i++) {
if (cc->cpages[i])
@@ -715,13 +727,23 @@ void f2fs_decompress_pages(struct bio *bio, struct page
*page, bool verity)
goto out_free_dic;
}
- dic->rbuf = vmap(dic->tpages, dic->cluster_size, VM_MAP, PAGE_KERNEL);
+ for (i = 0; i < MAX_VMAP_RETRIES; i++) {
+ dic->rbuf = vm_map_ram(dic->tpages, dic->cluster_size, -1);
+ if (dic->rbuf)
+ break;
+ vm_unmap_aliases();
+ }
if (!dic->rbuf) {
ret = -ENOMEM;
goto destroy_decompress_ctx;
}
- dic->cbuf = vmap(dic->cpages, dic->nr_cpages, VM_MAP, PAGE_KERNEL_RO);
+ for (i = 0; i < MAX_VMAP_RETRIES; i++) {
+ dic->cbuf = vm_map_ram(dic->cpages, dic->nr_cpages, -1);
+ if (dic->cbuf)
+ break;
+ vm_unmap_aliases();
+ }
if (!dic->cbuf) {
ret = -ENOMEM;
goto out_vunmap_rbuf;
@@ -738,9 +760,9 @@ void f2fs_decompress_pages(struct bio *bio, struct page
*page, bool verity)
ret = cops->decompress_pages(dic);
out_vunmap_cbuf:
- vunmap(dic->cbuf);
+ vm_unmap_ram(dic->cbuf, dic->nr_cpages);
out_vunmap_rbuf:
- vunmap(dic->rbuf);
+ vm_unmap_ram(dic->rbuf, dic->cluster_size);
destroy_decompress_ctx:
if (cops->destroy_decompress_ctx)
cops->destroy_decompress_ctx(dic);
--
2.28.0.236.gb10cc79966-goog
[RFC V2] kthread: add object debug support
From: Qianli Zhao
Add debugobject support to track the life time of kthread_work
which is used to detect reinitialization/free active object problems
Add kthread_init_work_onstack/kthread_init_delayed_work_onstack for
kthread onstack support
Signed-off-by: Qianli Zhao
---
I got an crash issue since kthread_delayed_work reinitialization,crash log show
us that is a timer NULL pointer exception
[16238.089921] Unable to handle kernel paging request at virtual address
dead0208
[16238.090298] Call trace:
[16238.090307] run_timer_softirq+0x2d0/0xa30
[16238.090318] __do_softirq+0x1dc/0x384
[16238.090328] irq_exit+0xb4/0xb8
[16238.090338] __handle_domain_irq+0x84/0xc0
[16238.090345] gic_handle_irq+0x138/0x1bc
[16238.090353] el1_irq+0xb0/0x128
[16238.090362] queue_work_on+0x54/0x60
[16238.090374] _process_event_group+0x190/0x230
[16238.090382] kgsl_process_event_groups+0x44/0x70
[16238.090391] adreno_dispatcher_work+0x1e4/0xae8
[16238.090400] kthread_worker_fn+0xec/0x180
[16238.090407] kthread+0x118/0x128
[16238.090415] ret_from_fork+0x10/0x18
It turns out that the problem is caused by the timer reinitialization,after
enable CONFIG_DEBUG_OBJECTS_TIMERS,the reason for the problem is obvious.
This timer belongs to kthread_delayed_work,from kernel log we also see list
corruption WARNING:
[30858.395766] list_del corruption. next->prev should be ffe388ebbf88, but
was ffe388ebb588
[30858.395788] WARNING: CPU: 2 PID: 387 at
/home/work/data/miui_codes/build_home/kernel/msm-4.19/lib/list_debug.c:56
__list_del_entry_valid+0xc8/0xd0
...
[30858.405951] list_add corruption. next->prev should be prev
(ffe389392620), but was ffe388ebbf88. (next=ffe388ebbf88).
[30858.405977] WARNING: CPU: 0 PID: 7721 at
/home/work/data/miui_codes/build_home/kernel/msm-4.19/lib/list_debug.c:25
__list_add_valid+0x7c/0xc8
crash> struct kthread_worker.delayed_work_list 0xffe3893925f0
[ffe389392620] delayed_work_list = {
next = 0xffe388ebbf88,
prev = 0xffe388ebb588
}
crash> list 0xffe388ebbf88
ffe388ebbf88
delayed_work_list is corruption,this work is reinitialized.if kthread_work
reinitialized after move to work_list,this work will be carried out forever in
kthread_worker_fn.
Timer and workqueue both provide debugobject support，kthread_work similar with
workqueue,so i think it is necessary to support objectdebug in kthread_work.
---
include/linux/kthread.h | 29 ++-
include/linux/poison.h | 3 ++
kernel/kthread.c| 95 -
lib/Kconfig.debug | 10 ++
4 files changed, 135 insertions(+), 2 deletions(-)
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 65b81e0..1530953 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -108,6 +108,16 @@ struct kthread_delayed_work {
struct timer_list timer;
};
+#ifdef CONFIG_DEBUG_OBJECTS_KTHREAD
+extern void __init_kwork(struct kthread_work *kwork, int onstack);
+extern void destroy_kwork_on_stack(struct kthread_work *kwork);
+extern void destroy_delayed_kwork_on_stack(struct kthread_delayed_work
*kdwork);
+#else
+static inline void __init_kwork(struct kthread_work *kwork, int onstack) { }
+static inline void destroy_kwork_on_stack(struct kthread_work *kwork) { }
+static inline void destroy_delayed_kwork_on_stack(struct kthread_delayed_work
*kdwork) { }
+#endif
+
#define KTHREAD_WORKER_INIT(worker){ \
.lock = __RAW_SPIN_LOCK_UNLOCKED((worker).lock),\
.work_list = LIST_HEAD_INIT((worker).work_list),\
@@ -115,7 +125,7 @@ struct kthread_delayed_work {
}
#define KTHREAD_WORK_INIT(work, fn){ \
- .node = LIST_HEAD_INIT((work).node),\
+ .node = { .next = KWORK_ENTRY_STATIC }, \
.func = (fn), \
}
@@ -160,6 +170,15 @@ extern void __kthread_init_worker(struct kthread_worker
*worker,
#define kthread_init_work(work, fn)\
do {\
memset((work), 0, sizeof(struct kthread_work)); \
+ __init_kwork(work, 0);
\
+ INIT_LIST_HEAD(&(work)->node); \
+ (work)->func = (fn);\
+ } while (0)
+
+#define kthread_init_work_onstack(work, fn)
\
+ do {\
+ memset((work), 0, sizeof(struct kthread_work)); \
+ __init_kwork(work, 1);
\
INIT_LIST_HEAD(&(work)->node); \
(work)
[PATCH] KVM: x86/pmu: Add '.exclude_hv = 1' for guest perf_event
To emulate PMC counter for guest, KVM would create an event on the host with 'exclude_guest=0, exclude_hv=0' which simply makes no sense and is utterly broken. To keep perf semantics consistent, any event created by pmc_reprogram_counter() should both set exclude_hv and exclude_host in the KVM context. Message-ID: <20200811084548.gw3...@worktop.programming.kicks-ass.net> Signed-off-by: Like Xu --- arch/x86/kvm/pmu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c index 67741d2a0308..6a30763a10d7 100644 --- a/arch/x86/kvm/pmu.c +++ b/arch/x86/kvm/pmu.c @@ -108,6 +108,7 @@ static void pmc_reprogram_counter(struct kvm_pmc *pmc, u32 type, .exclude_host = 1, .exclude_user = exclude_user, .exclude_kernel = exclude_kernel, + .exclude_hv = 1, .config = config, }; -- 2.21.3
[git pull] drm fixes for 5.9-rc1
Hi Linus, This is the fixes pull for 5.9-rc1. I had some fixes from the misc fixes tree come on a later base than drm-next was on, so I had to backmerge 5.8 into this to make things work for me and CI. However it totally messed up the diffstat so I didn't bother including it. The changelog looks fine. This has a few vmwgfx regression fixes we hit from the merge window (one in TTM), it also has a bunch of amdgpu fixes along with a scattering everywhere else. I'm not working for next few days, but I'll be around and have some time if anything comes up, but hopefully this is good enough for rc1, and any pulls after this can wait for rc2. Dave. drm-next-2020-08-12: drm fixes for 5.9-rc1 core: - Fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi - Remove null check for kfree in drm_dev_release. - Fix DRM_FORMAT_MOD_AMLOGIC_FBC definition. - re-added docs for drm_gem_flink_ioctl() - add orientation quirk for ASUS T103HAF ttm: - ttm: fix page-offset calculation within TTM - revert patch causing vmwgfx regressions fbcon: - Fix a fbcon OOB read in fbdev, found by syzbot. vga: - Mark vga_tryget static as it's not used elsewhere. amdgpu: - Re-add spelling typo fix - Sienna Cichlid fixes - Navy Flounder fixes - DC fixes - SMU i2c fix - Power fixes vmwgfx: - regression fixes for modesetting crashes - misc fixes xlnx: - Small fixes to xlnx. omap: - Fix mode initialization in omap_connector_mode_valid(). - force runtime PM suspend on system suspend tidss: - fix modeset init for DPI panels The following changes since commit dc100bc8fae59aafd2ea2e1a1a43ef1f65f8a8bc: Merge tag 'drm-msm-next-2020-07-30' of https://gitlab.freedesktop.org/drm/msm into drm-next (2020-08-05 08:05:31 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-08-12 for you to fetch changes up to 62975d27d647a40c58d3b96c29b911fc4f33c310: drm/ttm: revert "drm/ttm: make TT creation purely optional v3" (2020-08-12 13:26:28 +1000) drm fixes for 5.9-rc1 core: - Fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi - Remove null check for kfree in drm_dev_release. - Fix DRM_FORMAT_MOD_AMLOGIC_FBC definition. - re-added docs for drm_gem_flink_ioctl() - add orientation quirk for ASUS T103HAF ttm: - ttm: fix page-offset calculation within TTM - revert patch causing vmwgfx regressions fbcon: - Fix a fbcon OOB read in fbdev, found by syzbot. vga: - Mark vga_tryget static as it's not used elsewhere. amdgpu: - Re-add spelling typo fix - Sienna Cichlid fixes - Navy Flounder fixes - DC fixes - SMU i2c fix - Power fixes vmwgfx: - regression fixes for modesetting crashes - misc fixes xlnx: - Small fixes to xlnx. omap: - Fix mode initialization in omap_connector_mode_valid(). - force runtime PM suspend on system suspend tidss: - fix modeset init for DPI panels Alex Deucher (1): drm/amdgpu/smu: rework i2c adpater registration Alvin Lee (1): drm/amd/display: Don't compare dppclk before updating DTO Aric Cyr (2): drm/amd/display: Fix DP Compliance tests 4.3.2.1 and 4.3.2.2 drm/amd/display: AMD OUI (DPCD 0x00300) skipped on some sink Bhawanpreet Lakha (2): drm/amd/display: Use seperate dmcub firmware for navy_flounder drm/amd/display: Use proper abm/backlight functions for DCN3 Boyuan Zhang (1): drm/amdgpu: update dec ring test for VCN 3.0 Changfeng (2): Revert "drm/amd/powerplay: drop unnecessary message support check" drm/amd/powerplay: drop unnecessary message support check(v2) Christian König (1): drm/ttm: revert "drm/ttm: make TT creation purely optional v3" Christoph Hellwig (1): vgaarb: mark vga_tryget static Colin Ian King (4): drm: xlnx: fix spelling mistake "failes" -> "failed" drm/amdgpu: fix spelling mistake "Falied" -> "Failed" drm/vmwgfx: fix spelling mistake "Cound" -> "Could" drm/vmwgfx: fix spelling mistake "Cant" -> "Can't" Dan Carpenter (3): drm/amd/powerplay: off by one bugs in smu_cmn_to_asic_specific_index() drm/vmwgfx: Use correct vmw_legacy_display_unit pointer drm/vmwgfx: Fix two list_for_each loop exit tests Daniel Vetter (1): drm/vmwgfx/stdu: Use drm_mode_config_reset Dave Airlie (5): Merge tag 'drm-misc-next-fixes-2020-08-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge tag 'v5.8' into drm-next Merge tag 'drm-misc-fixes-2020-08-04' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge tag 'amd-drm-fixes-5.9-2020-08-07' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge branch 'vmwgfx-next-5.9' of git://people.freedesktop.org/~sroland/linux into drm-next Dmytro Laktyushkin (2): drm/amd/display: Clean up global sync param retrieval drm/amd/display: populate new dml variable Eric Bernstein (1): drm/a
Re: [PATCH 1/2] exfat: add NameLength check when extracting name
Thanks for your reply.
On 2020/08/09 1:54, Sungjong Seo wrote:
The current implementation doesn't care NameLength when extracting the
name from Name dir-entries, so the name may be incorrect.
(Without null-termination, Insufficient Name dir-entry, etc) Add a
NameLength check when extracting the name from Name dir-entries to extract
correct name.
And, change to get the information of file/stream-ext dir-entries via the
member variable of exfat_entry_set_cache.
** This patch depends on:
'[PATCH v3] exfat: integrates dir-entry getting and validation'.
Signed-off-by: Tetsuhiro Kohada
---
fs/exfat/dir.c | 81 --
1 file changed, 39 insertions(+), 42 deletions(-)
diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index
91cdbede0fd1..545bb73b95e9 100644
--- a/fs/exfat/dir.c
+++ b/fs/exfat/dir.c
@@ -28,16 +28,15 @@ static int exfat_extract_uni_name(struct exfat_dentry
*ep,
}
-static void exfat_get_uniname_from_ext_entry(struct super_block *sb,
- struct exfat_chain *p_dir, int entry, unsigned short
*uniname)
+static int exfat_get_uniname_from_name_entries(struct
exfat_entry_set_cache *es,
+ struct exfat_uni_name *uniname)
{
- int i;
- struct exfat_entry_set_cache *es;
+ int n, l, i;
struct exfat_dentry *ep;
- es = exfat_get_dentry_set(sb, p_dir, entry, ES_ALL_ENTRIES);
- if (!es)
- return;
+ uniname->name_len = es->de_stream->name_len;
+ if (uniname->name_len == 0)
+ return -EIO;
-EINVAL looks better.
OK.
I'll change in v2.
/*
* First entry : file entry
@@ -45,14 +44,15 @@ static void exfat_get_uniname_from_ext_entry(struct
super_block *sb,
* Third entry : first file-name entry
* So, the index of first file-name dentry should start from 2.
*/
-
- i = 2;
- while ((ep = exfat_get_validated_dentry(es, i++, TYPE_NAME))) {
- exfat_extract_uni_name(ep, uniname);
- uniname += EXFAT_FILE_NAME_LEN;
+ for (l = 0, n = 2; l < uniname->name_len; n++) {
+ ep = exfat_get_validated_dentry(es, n, TYPE_NAME);
+ if (!ep)
+ return -EIO;
+ for (i = 0; l < uniname->name_len && i <
EXFAT_FILE_NAME_LEN;
i++, l++)
+ uniname->name[l] = le16_to_cpu(ep-
dentry.name.unicode_0_14[i]);
Looks good.
}
-
- exfat_free_dentry_set(es, false);
+ uniname->name[l] = 0;
+ return 0;
}
/* read a directory entry from the opened directory */ @@ -63,6 +63,7 @@
static int exfat_readdir(struct inode *inode, struct exfat_dir_entry
*dir_entry)
[snip]
- *uni_name.name = 0x0;
- exfat_get_uniname_from_ext_entry(sb, &dir, dentry,
- uni_name.name);
+ dir_entry->size = le64_to_cpu(es->de_stream-
valid_size);
+
+ exfat_get_uniname_from_name_entries(es, &uni_name);
Modified function has a return value.
It would be better to check the return value.
Oops!
I'll fix it in v2.
exfat_utf16_to_nls(sb, &uni_name,
dir_entry->namebuf.lfn,
dir_entry->namebuf.lfnbuf_len);
- brelse(bh);
- ep = exfat_get_dentry(sb, &clu, i + 1, &bh, NULL);
- if (!ep)
- return -EIO;
- dir_entry->size =
- le64_to_cpu(ep->dentry.stream.valid_size);
- brelse(bh);
+ exfat_free_dentry_set(es, false);
ei->hint_bmap.off = dentry >> dentries_per_clu_bits;
ei->hint_bmap.clu = clu.dir;
--
2.25.1
Re: "mm/vmalloc: Add flag for freeing of special permsissions" broke udev on ia64
On Tue, 2020-08-11 at 23:54 +0200, John Paul Adrian Glaubitz wrote: > Hi Rick! > > I have been bisecting some regressions on ia64 and one problem I ran > into is that > udev is causing the kernel to crash after the following change from > 2019: > > commit 868b104d7379e28013e9d48bdd2db25e0bdcf751 > Author: Rick Edgecombe > Date: Thu Apr 25 17:11:36 2019 -0700 > > mm/vmalloc: Add flag for freeing of special permsissions > > With your patch applied, udev crashes on ia64 when trying to load > modules, I'm pasting > the whole boot message sequence below. > > Any idea what could cause this problem on ia64? > > Thanks, > Adrian > Hi, On non-x86, this patchset shouldn't have changed much, just always flush the TLB and purge the vmalloc area in cases where previously this would only happen intermittently. Despite this, it also caused a problem on sparc. In the end the sparc issue turned out to be an issue with sparc's kernel range TLB flush implementation that was just now being hit earlier during boot instead of after the system had been up for some time. So I'm at first wondering if there might be something like that uncovered here. Unfortunately, it's unlikely that I can get access to ia64 hardware in the near term to debug. Would you be able to test some debug patches? Also, can you post your config? Thanks, Rick
[PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver
From: Chandan Uddaraju
Add the needed DP PLL specific files to support
display port interface on msm targets.
The DP driver calls the DP PLL driver registration.
The DP driver sets the link and pixel clock sources.
Changes in v2:
-- Update copyright markings on all relevant files.
-- Use DRM_DEBUG_DP for debug msgs.
Changes in v4:
-- Update the DP link clock provider names
Changes in V5:
-- Addressed comments from Stephen Boyd, Rob clark.
Changes in V6:
-- Remove PLL as separate driver and include PLL as DP module
-- Remove redundant clock parsing from PLL module and make DP as
clock provider
-- Map USB3 DPCOM and PHY IO using hardcoded register address and
move mapping form parser to PLL module
-- Access DP PHY modules from same base address using offsets instead of
deriving base address of individual module from device tree.
-- Remove dp_pll_10nm_util.c and include its functionality in
dp_pll_10nm.c
-- Introduce new data structures private to PLL module
Changes in v7:
-- Remove DRM_MSM_DP_PLL config from Makefile and Kconfig
-- Remove set_parent from determin_rate API
-- Remove phy_pll_vco_div_clk from parent list
-- Remove flag CLK_DIVIDER_ONE_BASED
-- Remove redundant cell-index property parsing
Changes in v8:
-- Unregister hardware clocks during driver cleanup
Changes in v9:
-- Remove redundant Kconfig option DRM_MSM_DP_10NM_PLL
Signed-off-by: Chandan Uddaraju
Signed-off-by: Vara Reddy
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/Makefile| 4 +-
drivers/gpu/drm/msm/dp/dp_catalog.c | 31 +-
drivers/gpu/drm/msm/dp/dp_display.c | 18 +-
drivers/gpu/drm/msm/dp/dp_display.h | 3 +
drivers/gpu/drm/msm/dp/dp_parser.c | 2 +
drivers/gpu/drm/msm/dp/dp_parser.h | 7 +-
drivers/gpu/drm/msm/dp/dp_pll.c | 99 +++
drivers/gpu/drm/msm/dp/dp_pll.h | 61 ++
drivers/gpu/drm/msm/dp/dp_pll_10nm.c| 917
drivers/gpu/drm/msm/dp/dp_pll_private.h | 98 +++
drivers/gpu/drm/msm/dp/dp_power.c | 10 +
drivers/gpu/drm/msm/dp/dp_power.h | 40 +-
drivers/gpu/drm/msm/dp/dp_reg.h | 16 +
14 files changed, 1290 insertions(+), 17 deletions(-)
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll.c
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll.h
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll_10nm.c
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll_private.h
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 0b59e4f184fb..8e6ca119ea94 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -60,6 +60,7 @@ config DRM_MSM_HDMI_HDCP
config DRM_MSM_DP
bool "Enable DisplayPort support in MSM DRM driver"
depends on DRM_MSM
+ default y
help
Compile in support for DP driver in MSM DRM driver. DP external
display support is enabled through this config option. It can
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index af868e791210..6d31188cc776 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -109,7 +109,9 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
dp/dp_link.o \
dp/dp_panel.o \
dp/dp_parser.o \
- dp/dp_power.o
+ dp/dp_power.o \
+ dp/dp_pll.o \
+ dp/dp_pll_10nm.o
msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
msm-$(CONFIG_COMMON_CLK) += disp/mdp4/mdp4_lvds_pll.o
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 497f97f86c82..e506e0756e92 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -5,6 +5,7 @@
#define pr_fmt(fmt)"[drm-dp] %s: " fmt, __func__
+#include
#include
#include
#include
@@ -131,51 +132,58 @@ static inline void dp_write_ahb(struct dp_catalog_private
*catalog,
static inline void dp_write_phy(struct dp_catalog_private *catalog,
u32 offset, u32 data)
{
+ offset += DP_PHY_REG_OFFSET;
/*
* To make sure phy reg writes happens before any other operation,
* this function uses writel() instread of writel_relaxed()
*/
- writel(data, catalog->io->phy_io.base + offset);
+ writel(data, catalog->io->phy_reg.base + offset);
}
static inline u32 dp_read_phy(struct dp_catalog_private *catalog,
u32 offset)
{
+ offset += DP_PHY_REG_OFFSET;
/*
* To make sure phy reg writes happens before any other operation,
* this function uses writel() instread of writel_relaxed()
*/
- return readl_relaxed(catalog->io->phy_io.base + offset);
+ return readl_relaxed(catalog->io->phy_reg.base + offset);
}
static inline void dp_write_pll(struct dp_catalog_private *catalog,
u32 offset, u32 data)
{
- writel_relaxed(data, catalog->io->dp_pll_io.base + off
[PATCH v10 5/5] drm/msm/dp: Add Display Port HPD feature
Configure HPD registers in DP controller and
enable HPD interrupt.
Add interrupt to handle HPD connect and disconnect events.
Changes in v8: None
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 18
drivers/gpu/drm/msm/dp/dp_catalog.c | 63 --
drivers/gpu/drm/msm/dp/dp_catalog.h | 5 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 1 -
drivers/gpu/drm/msm/dp/dp_display.c | 108 ++--
drivers/gpu/drm/msm/dp/dp_reg.h | 12 +++
drivers/gpu/drm/msm/msm_drv.h | 6 ++
7 files changed, 180 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index fe86d760ed01..99a83d75ce23 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -765,6 +765,23 @@ static void dpu_irq_preinstall(struct msm_kms *kms)
dpu_core_irq_preinstall(dpu_kms);
}
+static int dpu_irq_postinstall(struct msm_kms *kms)
+{
+ struct msm_drm_private *priv;
+ struct dpu_kms *dpu_kms = to_dpu_kms(kms);
+
+ if (!dpu_kms || !dpu_kms->dev)
+ return -EINVAL;
+
+ priv = dpu_kms->dev->dev_private;
+ if (!priv)
+ return -EINVAL;
+
+ msm_dp_irq_postinstall(priv->dp);
+
+ return 0;
+}
+
static void dpu_irq_uninstall(struct msm_kms *kms)
{
struct dpu_kms *dpu_kms = to_dpu_kms(kms);
@@ -775,6 +792,7 @@ static void dpu_irq_uninstall(struct msm_kms *kms)
static const struct msm_kms_funcs kms_funcs = {
.hw_init = dpu_kms_hw_init,
.irq_preinstall = dpu_irq_preinstall,
+ .irq_postinstall = dpu_irq_postinstall,
.irq_uninstall = dpu_irq_uninstall,
.irq = dpu_irq,
.enable_commit = dpu_kms_enable_commit,
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index e506e0756e92..d186424044b1 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -17,7 +17,6 @@
#define POLLING_SLEEP_US 1000
#define POLLING_TIMEOUT_US 1
-#define REFTIMER_DEFAULT_VALUE 0x2
#define SCRAMBLER_RESET_COUNT_VALUE0xFC
#define DP_INTERRUPT_STATUS_ACK_SHIFT 1
@@ -731,35 +730,51 @@ void dp_catalog_ctrl_enable_irq(struct dp_catalog
*dp_catalog,
}
}
-void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog, bool en)
+void dp_catalog_hpd_config_intr(struct dp_catalog *dp_catalog,
+ u32 intr_mask, bool en)
{
struct dp_catalog_private *catalog = container_of(dp_catalog,
struct dp_catalog_private, dp_catalog);
- if (en) {
- u32 reftimer = dp_read_aux(catalog, REG_DP_DP_HPD_REFTIMER);
+ u32 config = dp_read_aux(catalog, REG_DP_DP_HPD_INT_MASK);
- dp_write_aux(catalog, REG_DP_DP_HPD_INT_ACK,
- DP_DP_HPD_PLUG_INT_ACK |
- DP_DP_IRQ_HPD_INT_ACK |
- DP_DP_HPD_REPLUG_INT_ACK |
- DP_DP_HPD_UNPLUG_INT_ACK);
- dp_write_aux(catalog, REG_DP_DP_HPD_INT_MASK,
- DP_DP_HPD_PLUG_INT_MASK |
- DP_DP_IRQ_HPD_INT_MASK |
- DP_DP_HPD_REPLUG_INT_MASK |
- DP_DP_HPD_UNPLUG_INT_MASK);
+ config = (en ? config | intr_mask : config & ~intr_mask);
- /* Configure REFTIMER */
- reftimer |= REFTIMER_DEFAULT_VALUE;
- dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer);
- /* Enable HPD */
- dp_write_aux(catalog, REG_DP_DP_HPD_CTRL,
- DP_DP_HPD_CTRL_HPD_EN);
- } else {
- /* Disable HPD */
- dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, 0x0);
- }
+ dp_write_aux(catalog, REG_DP_DP_HPD_INT_MASK,
+ config & DP_DP_HPD_INT_MASK);
+}
+
+void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog)
+{
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+
+ u32 reftimer = dp_read_aux(catalog, REG_DP_DP_HPD_REFTIMER);
+
+ /* enable HPD interrupts */
+ dp_catalog_hpd_config_intr(dp_catalog,
+ DP_DP_HPD_PLUG_INT_MASK | DP_DP_IRQ_HPD_INT_MASK
+ | DP_DP_HPD_UNPLUG_INT_MASK, true);
+
+ /* Configure REFTIMER and enable it */
+ reftimer |= DP_DP_HPD_REFTIMER_ENABLE;
+ dp_write_aux(catalog, REG_DP_DP_HPD_REFTIMER, reftimer);
+
+ /* Enable HPD */
+ dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, DP_DP_HPD_CTRL_HPD_EN);
+}
+
+u32 dp_catalog_hpd_get_intr_status(struct dp_catalog *dp_catalog)
+{
+ struct dp_catalog_p
[PATCH v10 4/5] drm/msm/dpu: add display port support in DPU
From: Jeykumar Sankaran
Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.
changes in v2:
- rebase on [2] (Sean Paul)
- remove unwanted error checks and
switch cases (Jordan Crouse)
[1] https://lwn.net/Articles/768265/
[2] https://lkml.org/lkml/2018/11/17/87
changes in V3:
-- Moved this change as part of the DP driver changes.
-- Addressed compilation issues on the latest code base.
Changes in v6:
-- Fix checkpatch.pl warning
Changes in v7: Remove depends-on tag from commit message.
Changes in v8: None
Changes in v9: None
Signed-off-by: Jeykumar Sankaran
Signed-off-by: Chandan Uddaraju
Signed-off-by: Vara Reddy
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 65 +
2 files changed, 58 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0a5ad6a9e609..fe0d538099f9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1992,7 +1992,7 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
{
int ret = 0;
int i = 0;
- enum dpu_intf_type intf_type;
+ enum dpu_intf_type intf_type = INTF_NONE;
struct dpu_enc_phys_init_params phys_params;
if (!dpu_enc) {
@@ -2014,9 +2014,9 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
case DRM_MODE_ENCODER_DSI:
intf_type = INTF_DSI;
break;
- default:
- DPU_ERROR_ENC(dpu_enc, "unsupported display interface type\n");
- return -EINVAL;
+ case DRM_MODE_ENCODER_TMDS:
+ intf_type = INTF_DP;
+ break;
}
WARN_ON(disp_info->num_of_h_tiles < 1);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 680527e28d09..fe86d760ed01 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -492,6 +492,33 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
return rc;
}
+static int _dpu_kms_initialize_displayport(struct drm_device *dev,
+ struct msm_drm_private *priv,
+ struct dpu_kms *dpu_kms)
+{
+ struct drm_encoder *encoder = NULL;
+ int rc = 0;
+
+ if (!priv->dp)
+ return rc;
+
+ encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_TMDS);
+ if (IS_ERR(encoder)) {
+ DPU_ERROR("encoder init failed for dsi display\n");
+ return PTR_ERR(encoder);
+ }
+
+ rc = msm_dp_modeset_init(priv->dp, dev, encoder);
+ if (rc) {
+ DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
+ drm_encoder_cleanup(encoder);
+ return rc;
+ }
+
+ priv->encoders[priv->num_encoders++] = encoder;
+ return rc;
+}
+
/**
* _dpu_kms_setup_displays - create encoders, bridges and connectors
* for underlying displays
@@ -504,12 +531,21 @@ static int _dpu_kms_setup_displays(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
{
- /**
-* Extend this function to initialize other
-* types of displays
-*/
+ int rc = 0;
+
+ rc = _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ if (rc) {
+ DPU_ERROR("initialize_dsi failed, rc = %d\n", rc);
+ return rc;
+ }
- return _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ rc = _dpu_kms_initialize_displayport(dev, priv, dpu_kms);
+ if (rc) {
+ DPU_ERROR("initialize_DP failed, rc = %d\n", rc);
+ return rc;
+ }
+
+ return rc;
}
static void _dpu_kms_drm_obj_destroy(struct dpu_kms *dpu_kms)
@@ -694,13 +730,20 @@ static void _dpu_kms_set_encoder_mode(struct msm_kms *kms,
info.capabilities = cmd_mode ? MSM_DISPLAY_CAP_CMD_MODE :
MSM_DISPLAY_CAP_VID_MODE;
- /* TODO: No support for DSI swap */
- for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
- if (priv->dsi[i]) {
- info.h_tile_instance[info.num_of_h_tiles] = i;
- info.num_of_h_tiles++;
+ switch (info.intf_type) {
+ case DRM_MODE_ENCODER_DSI:
+ /* TODO: No support for DSI swap */
+ for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
+ if (priv->dsi[i]) {
+ info.h_tile_instance[info.num_of_h_tiles] = i;
+ info.num_of_h_tiles++;
+ }
}
- }
+
Re: [PATCH v5 0/4] Allow bigger 64bit window by removing default DMA window
Hello Michael, Do you suggest any change for this patchset? Any chance it can get in this merge window? Best regards, Leonardo Bras On Wed, 2020-08-05 at 00:04 -0300, Leonardo Bras wrote: > There are some devices in which a hypervisor may only allow 1 DMA window > to exist at a time, and in those cases, a DDW is never created to them, > since the default DMA window keeps using this resource. > > LoPAR recommends this procedure: > 1. Remove the default DMA window, > 2. Query for which configs the DDW can be created, > 3. Create a DDW. > > Patch #1: > Create defines for outputs of ibm,ddw-applicable, so it's easier to > identify them. > > Patch #2: > - After LoPAR level 2.8, there is an extension that can make > ibm,query-pe-dma-windows to have 6 outputs instead of 5. This changes the > order of the outputs, and that can cause some trouble. > - query_ddw() was updated to check how many outputs the > ibm,query-pe-dma-windows is supposed to have, update the rtas_call() and > deal correctly with the outputs in both cases. > - This patch looks somehow unrelated to the series, but it can avoid future > problems on DDW creation. > > Patch #3 moves the window-removing code from remove_ddw() to > remove_dma_window(), creating a way to delete any DMA window, so it can be > used to delete the default DMA window. > > Patch #4 makes use of the remove_dma_window() from patch #3 to remove the > default DMA window before query_ddw(). It also implements a new rtas call > to recover the default DMA window, in case anything fails after it was > removed, and a DDW couldn't be created. > > --- > Changes since v4: > - Removed patches 5+ in order to deal with a feature at a time > - Remove unnecessary parentesis in patch #4 > - Changed patch #4 title from > "Remove default DMA window before creating DDW" > - Included David Dai tested-by > - v4 link: > http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=190051&state=%2A&archive=both > > Changes since v3: > - Introduces new patch #5, to prepare for an important change in #6 > - struct iommu_table was not being updated, so include a way to do this > in patch #6. > - Improved patch #4 based in a suggestion from Alexey, to make code > more easily understandable > - v3 link: > http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=187348&state=%2A&archive=both > > Changes since v2: > - Change the way ibm,ddw-extensions is accessed, using a proper function > instead of doing this inline everytime it's used. > - Remove previous patch #6, as it doesn't look like it would be useful. > - Add new patch, for changing names from direct* to dma*, as indirect > mapping can be used from now on. > - Fix some typos, corrects some define usage. > - v2 link: > http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=185433&state=%2A&archive=both > > Changes since v1: > - Add defines for ibm,ddw-applicable and ibm,ddw-extensions outputs > - Merge aux function query_ddw_out_sz() into query_ddw() > - Merge reset_dma_window() patch (prev. #2) into remove default DMA > window patch (#4). > - Keep device_node *np name instead of using pdn in remove_*() > - Rename 'device_node *pdn' into 'parent' in new functions > - Rename dfl_win to default_win > - Only remove the default DMA window if there is no window available > in first query. > - Check if default DMA window can be restored before removing it. > - Fix 'unitialized use' (found by travis mpe:ci-test) > - New patches #5 and #6 > - v1 link: > http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=184420&state=%2A&archive=both > > Special thanks for Alexey Kardashevskiy, Brian King and > Oliver O'Halloran for the feedback provided! > > > Leonardo Bras (4): > powerpc/pseries/iommu: Create defines for operations in > ibm,ddw-applicable > powerpc/pseries/iommu: Update call to ibm,query-pe-dma-windows > powerpc/pseries/iommu: Move window-removing part of remove_ddw into > remove_dma_window > powerpc/pseries/iommu: Allow bigger 64bit window by removing default > DMA window > > arch/powerpc/platforms/pseries/iommu.c | 242 - > 1 file changed, 195 insertions(+), 47 deletions(-) >
[PATCH v10 1/5] drm: add constant N value in helper file
From: Chandan Uddaraju The constant N value (0x8000) is used by i915 DP driver. Define this value in dp helper header file to use in multiple Display Port drivers. Change i915 driver accordingly. Change in v6: Change commit message Signed-off-by: Chandan Uddaraju Signed-off-by: Vara Reddy Signed-off-by: Tanmay Shah Reviewed-by: Stephen Boyd Acked-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- include/drm/drm_dp_helper.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 729ec6e0d43a..10b8310f290b 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -8114,7 +8114,7 @@ static void compute_m_n(unsigned int m, unsigned int n, * which the devices expect also in synchronous clock mode. */ if (constant_n) - *ret_n = 0x8000; + *ret_n = DP_LINK_CONSTANT_N_VALUE; else *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX); diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index e47dc22ebf50..a31d7aebb8b8 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -1134,6 +1134,7 @@ #define DP_MST_PHYSICAL_PORT_0 0 #define DP_MST_LOGICAL_PORT_0 8 +#define DP_LINK_CONSTANT_N_VALUE 0x8000 #define DP_LINK_STATUS_SIZE 6 bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE], int lane_count); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v10 0/5] Add support for DisplayPort driver on SnapDragon
These patches add Display-Port driver on SnapDragon/msm hardware. This series also contains device-tree bindings for msm DP driver. It also contains Makefile and Kconfig changes to compile msm DP driver. The block diagram of DP driver is shown below: +-+ |DRM FRAMEWORK| +--+--+ | +v+ | DP DRM | +++ | +v+ ++| DP+--++--+ ++---+| DISPLAY |+---+ | | |++-+-+-+| | | || | | | | | || | | | | | || | | | | | vv v v v v v +--+ +--+ +---+ ++ ++ +---+ +-+ | DP | | DP | |DP | | DP | | DP | |DP | | DP | |PARSER| | HPD | |AUX| |LINK| |CTRL| |PHY| |POWER| +--+---+ +---+--+ +---+ ++ +--+-+ +-+-+ +-+ | | | +--v---+ +v-v+ |DEVICE| | DP | | TREE | |CATALOG| +--+ +---+---+ | +---v+ |CTRL/PHY| | HW | ++ Changes in v7: - Modify cover letter description and fix title. - Introduce dp-controller.yaml for common bindings across SOC - Rename dp-sc7180.yaml to dp-controller-sc7180.yaml for SC7180 bindings - Rename compatible string to qcom,sc7180-dp - Add assigned-clocks and assigned-clock-parents properties in bindings - Remove redundant code from driver - Extend series to include HPD detection logic Changes in v8: - Add MDSS AHB clock in bindings - Replace mode->vrefresh use with drm_mode_vrefresh API - Remove redundant aux config code from parser and aux module - Assign default max lanes if data-lanes property is not available - Fix use-after-free during DP driver remove - Unregister hardware clocks during driver cleanup Changes in v9: - Drop YAML bindings change from the series - Use assigne-clock-parents property and remove clk_set_parent use from code - Access register address space without name - Fix DP register dump utility - Disable DP clocks after vsync generated - Avoid 64-bit modulo operation - Drop any unused code and fix function proptotyes to avoid W=1 warnings - Drop DRM_MSM_DP_10NM_PLL config as only 10nm PLL is available Changes in v10: - Fix help description of Kconfig entry Chandan Uddaraju (4): dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon drm: add constant N value in helper file drm/msm/dp: add displayPort driver support drm/msm/dp: add support for DP PLL driver Jeykumar Sankaran (1): drm/msm/dpu: add display port support in DPU Tanmay Shah (1): drm/msm/dp: Add Display Port HPD feature drivers/gpu/drm/i915/display/intel_display.c |2 +- drivers/gpu/drm/msm/Kconfig |9 + drivers/gpu/drm/msm/Makefile | 14 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 27 +- .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c |8 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 83 +- drivers/gpu/drm/msm/dp/dp_aux.c | 510 + drivers/gpu/drm/msm/dp/dp_aux.h | 29 + drivers/gpu/drm/msm/dp/dp_catalog.c | 1030 ++ drivers/gpu/drm/msm/dp/dp_catalog.h | 104 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 1693 + drivers/gpu/drm/msm/dp/dp_ctrl.h | 35 + drivers/gpu/drm/msm/dp/dp_display.c | 1017 ++ drivers/gpu/drm/msm/dp/dp_display.h | 31 + drivers/gpu/drm/msm/dp/dp_drm.c | 168 ++ drivers/gpu/drm/msm/dp/dp_drm.h | 18 + drivers/gpu/drm/msm/dp/dp_hpd.c | 69 + drivers/gpu/drm/msm/dp/dp_hpd.h | 79 + drivers/gpu/drm/msm/dp/dp_link.c | 1214 drivers/gpu/drm/msm/dp/dp_link.h | 132 ++ drivers/gpu/drm/msm/dp/dp_panel.c | 486 + drivers/gpu/drm/msm/dp/dp_panel.h | 95 + drivers/gpu/drm/msm/dp/dp_parser.c| 269 +++ drivers/gpu/drm/msm/dp/dp_parser.h| 138 ++ drivers/gpu/drm/msm/dp/dp_pll.c | 99 + drivers/gpu/drm/msm/dp/dp_pll.h | 61 + drivers/gpu/drm/msm/dp/dp_pll_10nm.c | 917 + drivers/gpu/drm/msm/dp/dp_pll_private.h | 98 + drivers/gpu/drm/msm/dp/dp_power.c | 373 drivers/gpu/drm/msm/dp/dp_power.h | 103 + drivers/gpu/drm/msm/dp/dp_reg.h | 517 + drivers/gpu/drm/msm/msm_drv.c |2 + drivers/gpu/drm/msm/msm_d
Re: [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early
On 8/11/2020 10:42 PM, Matthias Kaehlcke wrote:
On Mon, Aug 10, 2020 at 12:36:19PM +0530, Rajendra Nayak wrote:
dev_pm_opp_set_rate() can now be called with freq = 0 inorder
to either drop performance or bandwidth votes or to disable
regulators on platforms which support them.
In such cases, a subsequent call to dev_pm_opp_set_rate() with
the same frequency ends up returning early because 'old_freq == freq'
Instead make it fall through and put back the dropped performance
and bandwidth votes and/or enable back the regulators.
Fixes: cd7ea582 ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to drop
performance votes")
Reported-by: Sajida Bhanu
Signed-off-by: Rajendra Nayak
Tested-by: Matthias Kaehlcke
Originally-reported-by: Matthias Kaehlcke
https://patchwork.kernel.org/patch/11675369/#23514895 :P
Sorry to have missed that :/
Thanks for testing.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
On Wed, Aug 12, 2020 at 02:13:25AM +0200, Thomas Gleixner wrote: > "Paul E. McKenney" writes: > > Hence Ulad's work on kfree_rcu(). The approach is to allocate a > > page-sized array to hold all the pointers, then fill in the rest of these > > pointers on each subsequent kfree_rcu() call. These arrays of pointers > > also allows use of kfree_bulk() instead of kfree(), which can improve > > performance yet more. It is no big deal if kfree_rcu()'s allocation > > attempts fail occasionally because it can simply fall back to the old > > linked-list approach. And given that the various lockless caches in > > the memory allocator are almost never empty, in theory life is good. > > Of course, it's always the damned reality which ruins the fun. Classic!!! And yes, it always is! > > But in practice, mainline now has CONFIG_PROVE_RAW_LOCK_NESTING, > > and for good reason -- this Kconfig option makes it at least a > > little bit harder for mainline developers to mess up RT. But with > > CONFIG_PROVE_RAW_LOCK_NESTING=y and lockdep enabled, mainline will now > > sometimes complain if you invoke kfree_rcu() while holding a raw spinlock. > > This happens when kfree_rcu() needs to invoke the memory allocator and > > the memory allocator's caches are empty, thus resulting in the memory > > allocator attempting to acquire a non-raw spinlock. > > Right. > > > Because kfree_rcu() has a fallback available (just using the old linked > > list), kfree_rcu() would work well given a way to tell the memory > > allocator to return NULL instead of acquiring a non-raw spinlock. > > Which is exactly what Ulad's recent patches are intended to do. > > That much I understood, but I somehow failed to figure the why out > despite the elaborate changelog. 2 weeks of 30+C seem to have cooked my > brain :) Ouch!!! And what on earth is Germany doing being that warm??? I hate it when that happens... > > Since then, this thread has discussed various other approaches, > > including using existing combinations of GFP_ flags, converting > > the allocator's zone lock to a raw spinlock, and so on. > > > > Does that help, or am I missing the point of your question? > > Yes, that helps so far that I understand what the actual problem is. It > does not really help to make me more happy. :) I must confess that I was not expecting to find anything resembling happiness anywhere down this road, whether for myself or anyone else... > That said, we can support atomic allocations on RT up to the point where > zone->lock comes into play. We don't know yet exactly where the > zone->lock induced damage happens. Presumably it's inside > free_pcppages_bulk() - at least that's where I have faint bad memories > from 15+ years ago. Aside of that I seriously doubt that it can be made > work within a reasonable time frame. I was not considering any approach other than return NULL just before the code would otherwise have acquired zone->lock. > But what makes me really unhappy is that my defense line against > allocations from truly atomic contexts (from RT POV) which was enforced > on RT gets a real big gap shot into it. Understood, and agreed: We do need to keep the RT degradation in check. > It becomes pretty hard to argue why atomic allocations via kmalloc() or > kmem_cache_alloc() should be treated any different. Technically they can > work similar to the page allocations up to the point where regular > spinlocks come into play or the slab cache is exhausted. Where to draw > the line? > > It's also unclear for the page allocator case whether we can and should > stick a limit on the number of pages and/or the pageorder. > > Myself and others spent a considerable amount of time to kill off these > kind of allocations from various interesting places including the guts > of send IPI, the affinity setting path and others where people just > slapped allocations into them because the stack checker warned or > because they happened to copy the code from some other place. > > RT was pretty much a quick crap detector whenever new incarnations of > this got added and to some extent continuous education about these > issues made them less prominent over the years. Using atomic allocations > should always have a real good rationale, not only in the cases where > they collide with RT. > > I can understand your rationale and what you are trying to solve. So, if > we can actually have a distinct GFP variant: > > GFP_I_ABSOLUTELY_HAVE_TO_DO_THAT_AND_I_KNOW_IT_CAN_FAIL_EARLY > > which is easy to grep for then having the page allocator go down to the > point where zone lock gets involved is not the end of the world for > RT in theory - unless that damned reality tells otherwise. :) I have no objection to an otherwise objectionable name in this particular case. After all, we now have 100 characters per line, right? ;-) > The page allocator allocations should also have a limit on the number of > pages and eventually also page order (need to stare at th
Re: [PATCH] Re: KASAN: use-after-free Read in path_init (2)
On Tue, Aug 11, 2020 at 9:15 PM Al Viro wrote: > > fix breakage in do_rmdir() > > putname() should happen only after we'd *not* branched to > retry, same as it's done in do_unlinkat(). Looks obviously correct. Do you want me to apply directly, or do you have other fixes pending and I'll get a pull request? Linus
linux-next: Tree for Aug 12
Hi all,
News: The merge window has opened, so please do not add any v5.10
related material to your linux-next included branches until after the
merge window closes again.
Changes since 20200811:
Dropped tree: set_fs at maintainer's request
My fixes tree contains:
73c7adb54169 ("device_cgroup: Fix RCU list debugging warning")
The tip tree gained a conflict against Linus' tree.
Non-merge commits (relative to Linus' tree): 1382
1597 files changed, 41786 insertions(+), 15627 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 327 trees (counting Linus' and 85 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (bb5baaa9238e Merge tag 'arm64-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux)
Merging fixes/master (73c7adb54169 device_cgroup: Fix RCU list debugging
warning)
Merging kbuild-current/fixes (06a81c1c7db9 Merge tag 'arm64-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux)
Merging arc-current/for-curr (11ba468877bb Linux 5.8-rc5)
Merging arm-current/fixes (5c6360ee4a0e ARM: 8988/1: mmu: fix crash in EFI
calls due to p4d typo in create_mapping_late())
Merging arm64-fixes/for-next/fixes (6a7389f0312f MAINTAINERS: Include drivers
subdirs for ARM PMU PROFILING AND DEBUGGING entry)
Merging arm-soc-fixes/arm/fixes (fe1d899f4212 ARM: dts: keystone-k2g-evm: fix
rgmii phy-mode for ksz9031 phy)
Merging uniphier-fixes/fixes (48778464bb7d Linux 5.8-rc2)
Merging drivers-memory-fixes/fixes (b3a9e3b9622a Linux 5.8-rc1)
Merging m68k-current/for-linus (382f429bb559 m68k: defconfig: Update defconfigs
for v5.8-rc3)
Merging powerpc-fixes/fixes (6553fb799f60 powerpc/pkeys: Fix boot failures with
Nemo board (A-EON AmigaOne X1000))
Merging s390-fixes/fixes (00e4db51259a Merge tag 'perf-tools-2020-08-10' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty
inodes after removing key)
Merging net/master (1b8ef1423dbf net: phy: marvell10g: fix null pointer
dereference)
Merging bpf/master (da7bdfdd23b8 selftests/bpf: Fix v4_to_v6 in sk_lookup)
Merging ipsec/master (61ee4137b574 ip_vti: Fix unused variable warning)
Merging netfilter/master (2f941622fd88 netfilter: nft_compat: remove flush
counter optimization)
Merging ipvs/master (7c7ab580db49 net: Convert to use the fallthrough macro)
Merging wireless-drivers/master (1cfd3426ef98 ath10k: Fix NULL pointer
dereference in AHB device probe)
Merging mac80211/master (ac3a0c847296 Merge
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging rdma-fixes/for-rc (bcf876870b95 Linux 5.8)
Merging sound-current/for-linus (404690649e6a ALSA: hda - reverse the setting
value in the micmute_led_set)
Merging sound-asoc-fixes/for-linus (b6448e0359f1 Merge remote-tracking branch
'asoc/for-5.9' into asoc-linus)
Merging regmap-fixes/for-linus (2b0f61e27f75 Merge remote-tracking branch
'regmap/for-5.8' into regmap-linus)
Merging regulator-fixes/for-linus (75f4d068cb0d Merge remote-tracking branch
'regulator/for-5.9' into regulator-linus)
Mergi
Re: drivers/dma/xilinx/xilinx_dpdma.c:1172 xilinx_dpdma_synchronize() error: double unlocked 'chan->vchan.lock' (orig line 1170)
HI Laurent,
On 12-08-20, 01:50, Laurent Pinchart wrote:
> On Wed, Aug 12, 2020 at 06:37:59AM +0800, kernel test robot wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> > head: c636eef2ee3696f261a35f34989842701a107895
> > commit: 7cbb0c63de3fc218fd06ecfedb42a4d12f76 dmaengine: xilinx: dpdma:
> > Add the Xilinx DisplayPort DMA engine driver
> > date: 4 weeks ago
> > config: h8300-randconfig-m031-20200811 (attached as .config)
> > compiler: h8300-linux-gcc (GCC) 9.3.0
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot
> >
> > smatch warnings:
> > drivers/dma/xilinx/xilinx_dpdma.c:1172 xilinx_dpdma_synchronize() error:
> > double unlocked 'chan->vchan.lock' (orig line 1170)
>
> Unless I'm mistaken, this is a false positive. I'd appreciate if someone
> could check if I'm missing something obvious.
>
> > vim +1172 drivers/dma/xilinx/xilinx_dpdma.c
> >
> > 1140
> > 1141 /**
> > 1142 * xilinx_dpdma_synchronize - Synchronize callback execution
> > 1143 * @dchan: DMA channel
> > 1144 *
> > 1145 * Synchronizing callback execution ensures that all previously
> > issued
> > 1146 * transfers have completed and all associated callbacks have
> > been called and
> > 1147 * have returned.
> > 1148 *
> > 1149 * This function waits for the DMA channel to stop. It assumes
> > it has been
> > 1150 * paused by a previous call to dmaengine_terminate_async(),
> > and that no new
> > 1151 * pending descriptors have been issued with
> > dma_async_issue_pending(). The
> > 1152 * behaviour is undefined otherwise.
> > 1153 */
> > 1154 static void xilinx_dpdma_synchronize(struct dma_chan *dchan)
> > 1155 {
> > 1156 struct xilinx_dpdma_chan *chan = to_xilinx_chan(dchan);
> > 1157 unsigned long flags;
> > 1158
> > 1159 xilinx_dpdma_chan_stop(chan);
> > 1160
> > 1161 spin_lock_irqsave(&chan->vchan.lock, flags);
Lock is held here
> > 1162 if (chan->desc.pending) {
> > 1163
> > vchan_terminate_vdesc(&chan->desc.pending->vdesc);
This should be called with lock held
> > 1164 chan->desc.pending = NULL;
> > 1165 }
> > 1166 if (chan->desc.active) {
> > 1167
> > vchan_terminate_vdesc(&chan->desc.active->vdesc);
same here
> > 1168 chan->desc.active = NULL;
> > 1169 }
> > > 1170 spin_unlock_irqrestore(&chan->vchan.lock, flags);
Dropped
> > 1171
> > > 1172 vchan_synchronize(&chan->vchan);
This should be called without lock
So I agree with you, looks like a false positive to me as well
--
~Vinod
[PATCH] Re: KASAN: use-after-free Read in path_init (2)
On Tue, Aug 11, 2020 at 08:17:16PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:5631c5e0 Merge tag 'xfs-5.9-merge-7' of git://git.kernel.o..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1707698490
> kernel config: https://syzkaller.appspot.com/x/.config?x=afba7c06f91e56eb
> dashboard link: https://syzkaller.appspot.com/bug?extid=bbeb1c88016c7db4aa24
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1502ce0290
fix breakage in do_rmdir()
putname() should happen only after we'd *not* branched to
retry, same as it's done in do_unlinkat().
Fixes: e24ab0ef689d "fs: push the getname from do_rmdir into the callers"
Signed-off-by: Al Viro
---
diff --git a/fs/namei.c b/fs/namei.c
index fde8fe086c09..9fa10c614de7 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3770,11 +3770,11 @@ long do_rmdir(int dfd, struct filename *name)
mnt_drop_write(path.mnt);
exit1:
path_put(&path);
- putname(name);
if (retry_estale(error, lookup_flags)) {
lookup_flags |= LOOKUP_REVAL;
goto retry;
}
+ putname(name);
return error;
}
Re: [External] Re: [PATCH] x86/MCE/AMD, EDAC/mce_amd
Ok, as more AMD servers are used in bytedance, we hope to issue a patch to the community as soon as possible. Thank you very much. 在 2020/8/11 上午3:10, Yazen Ghannam 写道: On Sun, Aug 09, 2020 at 12:35:59PM +0800, Feng zhou wrote: From: zhoufeng The edac_mce_amd module calls decode_dram_ecc() on AMD Family17h and later systems. This function is used in amd64_edac_mod to do system-specific decoding for DRAM ECC errors. The function takes a "NodeId" as a parameter. In AMD documentation, NodeId is used to identify a physical die in a system. This can be used to identify a node in the AMD_NB code and also it is used with umc_normaddr_to_sysaddr(). However, the input used for decode_dram_ecc() is currently the NUMA node of a logical CPU. so this will cause the address translation function to fail or report incorrect results. Signed-off-by: zhoufeng --- drivers/edac/mce_amd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c index 325aedf46ff2..73c805113322 100644 --- a/drivers/edac/mce_amd.c +++ b/drivers/edac/mce_amd.c @@ -996,7 +996,7 @@ static void decode_smca_error(struct mce *m) } if (bank_type == SMCA_UMC && xec == 0 && decode_dram_ecc) - decode_dram_ecc(cpu_to_node(m->extcpu), m); + decode_dram_ecc(topology_physical_package_id(m->extcpu), m); This will break on Naples systems, because the NodeId and the physical package ID will not match. I can send a patch soon that will work for Naples, Rome, and later systems. Thanks, Yazen
[PATCH 3/3] mm: remove superfluous __ClearPageWaiters()
Presumably __ClearPageWaiters() was added to follow the previously
removed __ClearPageActive() pattern.
Only flags that are in PAGE_FLAGS_CHECK_AT_FREE needs to be properly
cleared because otherwise we think there may be some kind of leak.
PG_waiters is not one of those flags and leaving the clearing to
PAGE_FLAGS_CHECK_AT_PREP is more appropriate.
Signed-off-by: Yu Zhao
---
include/linux/page-flags.h | 2 +-
mm/filemap.c | 2 ++
mm/memremap.c | 2 --
mm/swap.c | 3 ---
4 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 6be1aa559b1e..dba80a2bdfba 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -318,7 +318,7 @@ static inline int TestClearPage##uname(struct page *page) {
return 0; }
TESTSETFLAG_FALSE(uname) TESTCLEARFLAG_FALSE(uname)
__PAGEFLAG(Locked, locked, PF_NO_TAIL)
-PAGEFLAG(Waiters, waiters, PF_ONLY_HEAD) __CLEARPAGEFLAG(Waiters, waiters,
PF_ONLY_HEAD)
+PAGEFLAG(Waiters, waiters, PF_ONLY_HEAD)
PAGEFLAG(Error, error, PF_NO_TAIL) TESTCLEARFLAG(Error, error, PF_NO_TAIL)
PAGEFLAG(Referenced, referenced, PF_HEAD)
TESTCLEARFLAG(Referenced, referenced, PF_HEAD)
diff --git a/mm/filemap.c b/mm/filemap.c
index f2bb5ff0293d..8a096844ddad 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1079,6 +1079,8 @@ static void wake_up_page_bit(struct page *page, int
bit_nr)
* other pages on it.
*
* That's okay, it's a rare case. The next waker will clear it.
+* Otherwise the bit will be cleared by PAGE_FLAGS_CHECK_AT_PREP
+* when the page is being freed.
*/
}
spin_unlock_irqrestore(&q->lock, flags);
diff --git a/mm/memremap.c b/mm/memremap.c
index 3a06eb91cb59..a9d02ffaf9e3 100644
--- a/mm/memremap.c
+++ b/mm/memremap.c
@@ -451,8 +451,6 @@ void free_devmap_managed_page(struct page *page)
return;
}
- __ClearPageWaiters(page);
-
mem_cgroup_uncharge(page);
/*
diff --git a/mm/swap.c b/mm/swap.c
index 1f223a02549d..6129692752a5 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -90,7 +90,6 @@ static void __page_cache_release(struct page *page)
del_page_from_lru_list(page, lruvec, page_off_lru(page));
spin_unlock_irqrestore(&pgdat->lru_lock, flags);
}
- __ClearPageWaiters(page);
}
static void __put_single_page(struct page *page)
@@ -898,8 +897,6 @@ void release_pages(struct page **pages, int nr)
del_page_from_lru_list(page, lruvec,
page_off_lru(page));
}
- __ClearPageWaiters(page);
-
list_add(&page->lru, &pages_to_free);
}
if (locked_pgdat)
--
2.28.0.236.gb10cc79966-goog
[PATCH 2/3] mm: remove superfluous __ClearPageActive()
To activate a page, mark_page_accessed() always holds a reference on it. It either gets a new reference when adding a page to lru_pvecs.activate_page or reuses an existing one it previously got when it added a page to lru_pvecs.lru_add. So it can't call SetPageActive() on a page that doesn't have any reference left. Therefore, the race is impossible, not these days (I didn't brother to dig into its history). For other paths, namely reclaim and migration, a reference count is always held while calling SetPageActive() on a page. SetPageSlabPfmemalloc() also uses SetPageActive(), but it's irrelevant to LRU pages. Signed-off-by: Yu Zhao --- mm/memremap.c | 2 -- mm/swap.c | 2 -- 2 files changed, 4 deletions(-) diff --git a/mm/memremap.c b/mm/memremap.c index 03e38b7a38f1..3a06eb91cb59 100644 --- a/mm/memremap.c +++ b/mm/memremap.c @@ -451,8 +451,6 @@ void free_devmap_managed_page(struct page *page) return; } - /* Clear Active bit in case of parallel mark_page_accessed */ - __ClearPageActive(page); __ClearPageWaiters(page); mem_cgroup_uncharge(page); diff --git a/mm/swap.c b/mm/swap.c index de257c0a89b1..1f223a02549d 100644 --- a/mm/swap.c +++ b/mm/swap.c @@ -898,8 +898,6 @@ void release_pages(struct page **pages, int nr) del_page_from_lru_list(page, lruvec, page_off_lru(page)); } - /* Clear Active bit in case of parallel mark_page_accessed */ - __ClearPageActive(page); __ClearPageWaiters(page); list_add(&page->lru, &pages_to_free); -- 2.28.0.236.gb10cc79966-goog
RE: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver
> From: Jason Wang > Sent: Wednesday, August 12, 2020 11:28 AM > > > On 2020/8/10 下午3:32, Tian, Kevin wrote: > >> From: Jason Gunthorpe > >> Sent: Friday, August 7, 2020 8:20 PM > >> > >> On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote: > >> > >>> If you see this as an abuse of the framework, then let's identify those > >>> specific issues and come up with a better approach. As we've discussed > >>> before, things like basic PCI config space emulation are acceptable > >>> overhead and low risk (imo) and some degree of register emulation is > >>> well within the territory of an mdev driver. > >> What troubles me is that idxd already has a direct userspace interface > >> to its HW, and does userspace DMA. The purpose of this mdev is to > >> provide a second direct userspace interface that is a little different > >> and trivially plugs into the virtualization stack. > > No. Userspace DMA and subdevice passthrough (what mdev provides) > > are two distinct usages IMO (at least in idxd context). and this might > > be the main divergence between us, thus let me put more words here. > > If we could reach consensus in this matter, which direction to go > > would be clearer. > > > > First, a passthrough interface requires some unique requirements > > which are not commonly observed in an userspace DMA interface, e.g.: > > > > - Tracking DMA dirty pages for live migration; > > - A set of interfaces for using SVA inside guest; > > * PASID allocation/free (on some platforms); > > * bind/unbind guest mm/page table (nested translation); > > * invalidate IOMMU cache/iotlb for guest page table changes; > > * report page request from device to guest; > > * forward page response from guest to device; > > - Configuring irqbypass for posted interrupt; > > - ... > > > > Second, a passthrough interface requires delegating raw controllability > > of subdevice to guest driver, while the same delegation might not be > > required for implementing an userspace DMA interface (especially for > > modern devices which support SVA). For example, idxd allows following > > setting per wq (guest driver may configure them in any combination): > > - put in dedicated or shared mode; > > - enable/disable SVA; > > - Associate guest-provided PASID to MSI/IMS entry; > > - set threshold; > > - allow/deny privileged access; > > - allocate/free interrupt handle (enlightened for guest); > > - collect error status; > > - ... > > > > We plan to support idxd userspace DMA with SVA. The driver just needs > > to prepare a wq with a predefined configuration (e.g. shared, SVA, > > etc.), bind the process mm to IOMMU (non-nested) and then map > > the portal to userspace. The goal that userspace can do DMA to > > associated wq doesn't change the fact that the wq is still *owned* > > and *controlled* by kernel driver. However as far as passthrough > > is concerned, the wq is considered 'owned' by the guest driver thus > > we need an interface which can support low-level *controllability* > > from guest driver. It is sort of a mess in uAPI when mixing the > > two together. > > > So for userspace drivers like DPDK, it can use both of the two uAPIs? yes. > > > > > > Based on above two reasons, we see distinct requirements between > > userspace DMA and passthrough interfaces, at least in idxd context > > (though other devices may have less distinction in-between). Therefore, > > we didn't see the value/necessity of reinventing the wheel that mdev > > already handles well to evolve an simple application-oriented usespace > > DMA interface to a complex guest-driver-oriented passthrough interface. > > The complexity of doing so would incur far more kernel-side changes > > than the portion of emulation code that you've been concerned about... > > > >> I don't think VFIO should be the only entry point to > >> virtualization. If we say the universe of devices doing user space DMA > >> must also implement a VFIO mdev to plug into virtualization then it > >> will be alot of mdevs. > > Certainly VFIO will not be the only entry point. and This has to be a > > case-by-case decision. > > > The problem is that if we tie all controls via VFIO uAPI, the other > subsystem like vDPA is likely to duplicate them. I wonder if there is a > way to decouple the vSVA out of VFIO uAPI? vSVA is a per-device (either pdev or mdev) feature thus naturally should be managed by its device driver (VFIO or vDPA). From this angle some duplication is inevitable given VFIO and vDPA are orthogonal passthrough frameworks. Within the kernel the majority of vSVA handling is done by IOMMU and IOASID modules thus most logic are shared. > > > > If an userspace DMA interface can be easily > > adapted to be a passthrough one, it might be the choice. > > > It's not that easy even for VFIO which requires a lot of new uAPIs and > infrastructures(e.g mdev) to be invented. > > > > But for idxd, > > we see mdev a much better f
[PATCH 1/3] mm: don't call activate_page() on new ksm pages
lru_cache_add_active_or_unevictable() already adds new ksm pages to
active lru. Calling activate_page() isn't really necessary in this
case.
Signed-off-by: Yu Zhao
---
mm/swapfile.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 6c26916e95fd..cf115ea26a20 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1913,16 +1913,16 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t
*pmd,
pte_mkold(mk_pte(page, vma->vm_page_prot)));
if (page == swapcache) {
page_add_anon_rmap(page, vma, addr, false);
+ /*
+* Move the page to the active list so it is not
+* immediately swapped out again after swapon.
+*/
+ activate_page(page);
} else { /* ksm created a completely new copy */
page_add_new_anon_rmap(page, vma, addr, false);
lru_cache_add_active_or_unevictable(page, vma);
}
swap_free(entry);
- /*
-* Move the page to the active list so it is not
-* immediately swapped out again after swapon.
-*/
- activate_page(page);
out:
pte_unmap_unlock(pte, ptl);
if (page != swapcache) {
--
2.28.0.236.gb10cc79966-goog
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:3223:63: sparse: expected unsigned char const
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: 4f58121dc40a1d5dd2f630a5ec4dac5afa1ce3f4 iwlwifi: mvm: Block 26-tone RU
OFDMA transmissions
date: 11 months ago
config: i386-randconfig-s001-20200812 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
git checkout 4f58121dc40a1d5dd2f630a5ec4dac5afa1ce3f4
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c: note: in included file
(through drivers/net/wireless/intel/iwlwifi/mvm/..//fw/img.h,
drivers/net/wireless/intel/iwlwifi/mvm/..//iwl-trans.h, ...):
drivers/net/wireless/intel/iwlwifi/mvm/..//fw/file.h:330:19: sparse: sparse:
mixed bitwiseness
drivers/net/wireless/intel/iwlwifi/mvm/..//fw/file.h:475:19: sparse: sparse:
mixed bitwiseness
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:3223:63: sparse: sparse:
incorrect type in argument 2 (different address spaces) @@ expected
unsigned char const [usertype] *ies @@ got unsigned char const [noderef]
* @@
>> drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:3223:63: sparse:
>> expected unsigned char const [usertype] *ies
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:3223:63: sparse: got
unsigned char const [noderef] *
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c: note: in included file
(through include/linux/bitops.h, include/linux/kernel.h):
arch/x86/include/asm/bitops.h:78:37: sparse: sparse: cast truncates bits
from constant value (ff7f becomes 7f)
arch/x86/include/asm/bitops.h:78:37: sparse: sparse: cast truncates bits
from constant value (ff7f becomes 7f)
arch/x86/include/asm/bitops.h:78:37: sparse: sparse: cast truncates bits
from constant value (ff7f becomes 7f)
>> drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:3224:38: sparse: sparse:
>> dereference of noderef expression
>> drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:3224:38: sparse: sparse:
>> dereference of noderef expression
vim +3223 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
3215
3216 static void iwl_mvm_check_he_obss_narrow_bw_ru_iter(struct wiphy *wiphy,
3217 struct cfg80211_bss
*bss,
3218 void *_data)
3219 {
3220 struct iwl_mvm_he_obss_narrow_bw_ru_data *data = _data;
3221 const struct element *elem;
3222
> 3223 elem = cfg80211_find_elem(WLAN_EID_EXT_CAPABILITY,
> bss->ies->data,
> 3224bss->ies->len);
3225
3226 if (!elem || elem->datalen < 10 ||
3227 !(elem->data[10] &
3228WLAN_EXT_CAPA10_OBSS_NARROW_BW_RU_TOLERANCE_SUPPORT)) {
3229 data->tolerated = false;
3230 }
3231 }
3232
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v4 1/4] fpga: dfl: change data type of feature id to u16
On Mon, Aug 10, 2020 at 10:41:10AM +0800, Xu Yilun wrote:
> The feature id is stored in a 12 bit field in DFH. So a u16 variable is
> enough for feature id.
>
> This patch changes all feature id related places to fit u16.
>
> Signed-off-by: Xu Yilun
> Reviewed-by: Tom Rix
> Acked-by: Wu Hao
> ---
> v3: no change.
> v4: no change.
> ---
> drivers/fpga/dfl-fme-perf.c | 2 +-
> drivers/fpga/dfl.c | 29 +++--
> drivers/fpga/dfl.h | 10 +-
> 3 files changed, 21 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
> index 6ce1ed2..5312662 100644
> --- a/drivers/fpga/dfl-fme-perf.c
> +++ b/drivers/fpga/dfl-fme-perf.c
> @@ -148,7 +148,7 @@ struct fme_perf_priv {
> struct device *dev;
> void __iomem *ioaddr;
> struct pmu pmu;
> - u64 id;
> + u16 id;
>
> u32 fab_users;
> u32 fab_port_id;
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index 649958a..18575d9 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -58,7 +58,7 @@ static const char *dfl_pdata_key_strings[DFL_ID_MAX] = {
> */
> struct dfl_dev_info {
> const char *name;
> - u32 dfh_id;
> + u16 dfh_id;
> struct idr id;
> enum dfl_fpga_devt_type devt_type;
> };
> @@ -134,7 +134,7 @@ static enum dfl_id_type feature_dev_id_type(struct
> platform_device *pdev)
> return DFL_ID_MAX;
> }
>
> -static enum dfl_id_type dfh_id_to_type(u32 id)
> +static enum dfl_id_type dfh_id_to_type(u16 id)
> {
> int i;
>
> @@ -454,7 +454,7 @@ struct build_feature_devs_info {
> * @nr_irqs: number of irqs of this sub feature.
> */
> struct dfl_feature_info {
> - u64 fid;
> + u16 fid;
> struct resource mmio_res;
> void __iomem *ioaddr;
> struct list_head node;
> @@ -649,7 +649,7 @@ static inline u32 feature_size(void __iomem *start)
> return ofst ? ofst : 4096;
> }
>
> -static u64 feature_id(void __iomem *start)
> +static u16 feature_id(void __iomem *start)
> {
> u64 v = readq(start + DFH);
> u16 id = FIELD_GET(DFH_ID, v);
> @@ -667,7 +667,7 @@ static u64 feature_id(void __iomem *start)
> }
>
> static int parse_feature_irqs(struct build_feature_devs_info *binfo,
> - resource_size_t ofst, u64 fid,
> + resource_size_t ofst, u16 fid,
> unsigned int *irq_base, unsigned int *nr_irqs)
> {
> void __iomem *base = binfo->ioaddr + ofst;
> @@ -713,12 +713,12 @@ static int parse_feature_irqs(struct
> build_feature_devs_info *binfo,
> return 0;
> }
>
> - dev_dbg(binfo->dev, "feature: 0x%llx, irq_base: %u, nr_irqs: %u\n",
> + dev_dbg(binfo->dev, "feature: 0x%x, irq_base: %u, nr_irqs: %u\n",
> fid, ibase, inr);
>
> if (ibase + inr > binfo->nr_irqs) {
> dev_err(binfo->dev,
> - "Invalid interrupt number in feature 0x%llx\n", fid);
> + "Invalid interrupt number in feature 0x%x\n", fid);
> return -EINVAL;
> }
>
> @@ -726,7 +726,7 @@ static int parse_feature_irqs(struct
> build_feature_devs_info *binfo,
> virq = binfo->irq_table[ibase + i];
> if (virq < 0 || virq > NR_IRQS) {
> dev_err(binfo->dev,
> - "Invalid irq table entry for feature 0x%llx\n",
> + "Invalid irq table entry for feature 0x%x\n",
> fid);
> return -EINVAL;
> }
> @@ -748,7 +748,7 @@ static int parse_feature_irqs(struct
> build_feature_devs_info *binfo,
> static int
> create_feature_instance(struct build_feature_devs_info *binfo,
> struct dfl_fpga_enum_dfl *dfl, resource_size_t ofst,
> - resource_size_t size, u64 fid)
> + resource_size_t size, u16 fid)
> {
> unsigned int irq_base, nr_irqs;
> struct dfl_feature_info *finfo;
> @@ -819,9 +819,10 @@ static int parse_feature_fiu(struct
> build_feature_devs_info *binfo,
>struct dfl_fpga_enum_dfl *dfl,
>resource_size_t ofst)
> {
> - u32 id, offset;
> - u64 v;
> int ret = 0;
> + u32 offset;
> + u16 id;
> + u64 v;
>
> v = readq(dfl->ioaddr + ofst + DFH);
> id = FIELD_GET(DFH_ID, v);
> @@ -855,8 +856,8 @@ static int parse_feature_private(struct
> build_feature_devs_info *binfo,
>resource_size_t ofst)
> {
> if (!binfo->feature_dev) {
> - dev_err(binfo->dev, "the private feature %llx does not belong
> to any AFU.\n",
> - (unsigned long long)feature_id(dfl->ioaddr + ofst));
> + dev_err(binfo->dev, "the private feature 0x%x does not belong
> to any AFU.\n",
> + feature_id(df
drivers/video/fbdev/arcfb.c:119:9: sparse: got void COPYING CREDITS Documentation Kbuild Kconfig LICENSES MAINTAINERS Makefile README arch block certs crypto drivers fs include init ipc kernel lib mm
Hi Bartlomiej,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: 3d3287e609877aa549b1cbb41eafaf73c3742a0b video: fbdev: arcfb: add
COMPILE_TEST support
date: 5 months ago
config: riscv-randconfig-s031-20200812 (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
git checkout 3d3287e609877aa549b1cbb41eafaf73c3742a0b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/video/fbdev/arcfb.c:119:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:119:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:119:9: sparse: expected void volatile
[noderef] *addr
>> drivers/video/fbdev/arcfb.c:119:9: sparse: got void *
drivers/video/fbdev/arcfb.c:120:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:120:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:120:9: sparse: expected void volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:120:9: sparse: got void *
drivers/video/fbdev/arcfb.c:122:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:122:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:122:9: sparse: expected void volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:122:9: sparse: got void *
drivers/video/fbdev/arcfb.c:128:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:128:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:128:9: sparse: expected void volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:128:9: sparse: got void *
drivers/video/fbdev/arcfb.c:134:16: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:134:16: sparse: sparse: incorrect type in
argument 1 (different address spaces) @@ expected void const volatile
[noderef] *addr @@ got void * @@
drivers/video/fbdev/arcfb.c:134:16: sparse: expected void const volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:134:16: sparse: got void *
drivers/video/fbdev/arcfb.c:142:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:142:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:142:9: sparse: expected void volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:142:9: sparse: got void *
drivers/video/fbdev/arcfb.c:143:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:143:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:143:9: sparse: expected void volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:143:9: sparse: got void *
drivers/video/fbdev/arcfb.c:145:9: sparse: sparse: cast removes address
space '' of expression
drivers/video/fbdev/arcfb.c:145:9: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void volatile [noderef]
*addr @@ got void * @@
drivers/video/fbdev/arcfb.c:145:9: sparse: expected void volatile
[noderef] *addr
drivers/video/fbdev/arcfb.c:145:9: sparse: got void *
vim +119 drivers/video/fbdev/arcfb.c
1154ea7dcd8eed drivers/video/arcfb.c Jaya Kumar 2005-06-21 113
1154ea7dcd8eed drivers/video/arcfb.c Jaya Kumar 2005-06-21 114 static void
ks108_writeb_ctl(struct arcfb_par *par,
1154ea7dcd8eed drivers/video/arcfb.c Jaya Kumar 2005-06-21 115
unsigned int chipindex, unsigned char value)
1154ea7dcd8eed drivers/video/arcfb.c Jaya Kumar 2005-06-21 116 {
1154ea7dcd8eed drivers/video/arcfb.c Jaya Kumar 2005-06-21 117
Re: [PATCH v1 2/2] perf/core: Fake regs for leaked kernel samples
Hi Peter, On 8/11/2020 4:45 PM, Peter Zijlstra wrote: On Tue, Aug 11, 2020 at 04:31:10PM +0800, Jin, Yao wrote: Hi Peter, On 8/11/2020 3:59 PM, Peter Zijlstra wrote: On Tue, Aug 11, 2020 at 03:50:43PM +0800, Jin, Yao wrote: Could I post v2 which basically refers to your patch but removes some conditions since I see some issues in test if we use these conditions. 1. Remove '!event->attr.exclude_hv || !event->attr.exclude_host || !event->attr.exclude_guest' at the entry of sanitize_sample_regs(). 2. Remove '!attr.exclude_hv || !attr.exclude_host || !attr.exclude_guest' at the perf_event_open syscall entry. exclude_host, maybe -- due to the dodgy semantics of it, but the others should definitely be there. exclude_guest and exclude_hv are tricky too. If we do 'perf record -e cycles:u' in both host and guest, we can see: event->attr.exclude_guest = 0 thus sanitize_sample_regs() returns regs directly even if exclude_kernel = 1. And in guest, exclude_hv = 0, it's out of my expectation too. I'm confused, how can 'perf record -e cycles:u' _ever_ have exclude_guest=0, exclude_hv=0 ? That simply makes no sense and is utterly broken. You explicitly ask for userspace-only, reporting hypervisor or guest events is a straight up bug. If we run 'perf record -e cycles:u', 1. On host, exclude_guest = 0 and exclude_hv = 1 perf tool doesn't specially set 'exclude_guest' when it parses the 'u' modifier. I agree that can be improved. I will post a perf tool patch to fix that. 2. On guest, exclude_guest = 0 and exclude_hv = 0. For exclude_hv = 0, it looks like a bug but x86 doesn't use exclude_hv. But yes, we should fix that. CC Like Xu . Thanks Jin Yao
RE: [RFC PATCH] sched/numa: fix bug in update_task_scan_period
OK. Thanks for your advice and I'll use label instead. In the case of migration failures, if there are still new failures after clearing (meaning the node is still overloaded), the scanning period would be doubled, just like not using this patch. However, if the failures do not increase again, then the scanning period should be adjusted according to the following rules (i.e., ps and lr ratio). I believe this is the original design idea, right? > -Original Message- > From: Mel Gorman > Sent: Tuesday, August 11, 2020 7:02 PM > To: Tianchen Ding > Cc: Ingo Molnar ; Peter Zijlstra > ; Juri Lelli ; Vincent Guittot > ; Dietmar Eggemann > ; Steven Rostedt ; > Ben Segall ; linux-kernel ker...@vger.kernel.org>; ?? > Subject: Re: [RFC PATCH] sched/numa: fix bug in update_task_scan_period > > On Tue, Aug 11, 2020 at 04:30:31PM +0800, ? wrote: > > When p->numa_faults_locality[2] > 0, numa_scan_period is doubled, but > > this array will never be cleared, which causes scanning period always > > reaching its max value. This patch clears numa_faults_locality after > > numa_scan_period being doubled to fix this bug. > > > > An out label at the end of the function to clears numa_faults_locality would > also work with a comment explaining why. That aside, what is the user- > visible impact of the patch? If there are no useful faults or migration failures, > it makes sense that scanning is very slow until the situation changes. The > corner case is that a migration failure might keep the scan rate slower than it > should be but the flip side is that fixing it might increase the scan rate and still > incur migration failures which introduces overhead with no gain. > > -- > Mel Gorman > SUSE Labs
Re: [PATCH v2 2/3] perf/x86/rapl: Support multiple rapl unit quirks
On Wed, 2020-08-12 at 11:29 +0800, Zhang Rui wrote: > Hi, > > Thanks for reviewing. > > On Tue, 2020-08-11 at 11:19 -0700, Joe Perches wrote: > > On Tue, 2020-08-11 at 23:31 +0800, Zhang Rui wrote: > > > There will be more platforms with different fixed energy units. > > > Enhance the code to support different rapl unit quirks for > > > different > > > platforms. > > > > This seems like one quirk per platform. > > > > Should multiple quirks on individual platforms be supported? > > > enum rapl_unit_quirk is just used as a flag. > multiple quirks can be deployed with the same flag, just like what I > did in patch 3/3. > Also different platforms can either have different flags or share the > same flag. Sure, but it does lead to possible code duplication in the quirks as enums can not be combined like bit flags. No worries, your code, your choice...
[PATCH] i2c: imx: Use dev_err_probe() to simplify error handling
dev_err_probe() can reduce code size, uniform error handling and record the
defer probe reason etc., use it to simplify the code.
Signed-off-by: Anson Huang
---
drivers/i2c/busses/i2c-imx.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 0ab5381..63f4367 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1159,11 +1159,9 @@ static int i2c_imx_probe(struct platform_device *pdev)
/* Get I2C clock */
i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
- if (IS_ERR(i2c_imx->clk)) {
- if (PTR_ERR(i2c_imx->clk) != -EPROBE_DEFER)
- dev_err(&pdev->dev, "can't get I2C clock\n");
- return PTR_ERR(i2c_imx->clk);
- }
+ if (IS_ERR(i2c_imx->clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(i2c_imx->clk),
+"can't get I2C clock\n");
ret = clk_prepare_enable(i2c_imx->clk);
if (ret) {
--
2.7.4
[PATCH] brcm: Add 4356 based AP6356S NVRAM for the khadas VIM2
Add a NVRAM file for the wireless module used in khadas VIM2. This
source comes from khadas fenix project's commit 022fdc3a1333 ("hwpacks:
wlan-firmware: add AP6356S firmware for mainline linux"). [1]
[1]:
https://github.com/khadas/fenix/commit/022fdc3a1333d2d16f84c2e59e4507c92a668a3d
Suggested-by: Nick Xie
Signed-off-by: Jian-Hong Pan
---
brcm/brcmfmac4356-sdio.khadas,vim2.txt | 128 +
1 file changed, 128 insertions(+)
create mode 100644 brcm/brcmfmac4356-sdio.khadas,vim2.txt
diff --git a/brcm/brcmfmac4356-sdio.khadas,vim2.txt
b/brcm/brcmfmac4356-sdio.khadas,vim2.txt
new file mode 100644
index 000..4c286cc
--- /dev/null
+++ b/brcm/brcmfmac4356-sdio.khadas,vim2.txt
@@ -0,0 +1,128 @@
+#AP6356SL_V1.1_NVRAM_20150805
+#Modified from AP6356SDP_V1.0_NVRAM_20150216
+NVRAMRev=$Rev: 373428 $
+sromrev=11
+boardrev=0x1121
+boardtype=0x073e
+boardflags=0x02400201
+boardflags2=0x00802000
+boardflags3=0x010a
+macaddr=00:90:4c:1a:10:01
+ccode=0x5855
+regrev=1
+antswitch=0
+pdgain5g=4
+pdgain2g=4
+tworangetssi2g=0
+tworangetssi5g=0
+paprdis=0
+femctrl=10
+vendid=0x14e4
+devid=0x43a3
+manfid=0x2d0
+nocrc=1
+otpimagesize=502
+xtalfreq=37400
+rxgains2gelnagaina0=0
+rxgains2gtrisoa0=7
+rxgains2gtrelnabypa0=0
+rxgains5gelnagaina0=0
+rxgains5gtrisoa0=11
+rxgains5gtrelnabypa0=0
+rxgains5gmelnagaina0=0
+rxgains5gmtrisoa0=13
+rxgains5gmtrelnabypa0=0
+rxgains5ghelnagaina0=0
+rxgains5ghtrisoa0=12
+rxgains5ghtrelnabypa0=0
+rxgains2gelnagaina1=0
+rxgains2gtrisoa1=7
+rxgains2gtrelnabypa1=0
+rxgains5gelnagaina1=0
+rxgains5gtrisoa1=10
+rxgains5gtrelnabypa1=0
+rxgains5gmelnagaina1=0
+rxgains5gmtrisoa1=11
+rxgains5gmtrelnabypa1=0
+rxgains5ghelnagaina1=0
+rxgains5ghtrisoa1=11
+rxgains5ghtrelnabypa1=0
+rxchain=3
+txchain=3
+aa2g=3
+aa5g=3
+agbg0=2
+agbg1=2
+aga0=2
+aga1=2
+tssipos2g=1
+extpagain2g=2
+tssipos5g=1
+extpagain5g=2
+tempthresh=255
+tempoffset=255
+rawtempsense=0x1ff
+pa2ga0=-135,5769,-647
+pa2ga1=-143,6023,-677
+pa5ga0=-183,5746,-697,-172,5801,-685,-176,5707,-680,-180,5445,-659
+pa5ga1=-186,5543,-669,-193,5506,-675,-210,5282,-661,-199,5367,-665
+subband5gver=0x4
+pdoffsetcckma0=0x4
+pdoffsetcckma1=0x4
+pdoffset40ma0=0x
+pdoffset80ma0=0x
+pdoffset40ma1=0x
+pdoffset80ma1=0x
+maxp2ga0=72
+maxp5ga0=69,70,69,68
+maxp2ga1=71
+maxp5ga1=67,67,67,67
+cckbw202gpo=0x1222
+cckbw20ul2gpo=0x
+mcsbw202gpo=0x99E644422
+mcsbw402gpo=0xE9744424
+dot11agofdmhrbw202gpo=0x
+ofdmlrbw202gpo=0x0022
+mcsbw205glpo=0xEEA86661
+mcsbw405glpo=0xEEB86663
+mcsbw805glpo=0xEEB86663
+mcsbw205gmpo=0xAAA86663
+mcsbw405gmpo=0xECB86663
+mcsbw805gmpo=0xEEA86663
+mcsbw205ghpo=0xCC986663
+mcsbw405ghpo=0xEEA86663
+mcsbw805ghpo=0xEEA86663
+mcslr5glpo=0x
+mcslr5gmpo=0x
+mcslr5ghpo=0x
+sb20in40hrpo=0x0
+sb20in80and160hr5glpo=0x0
+sb40and80hr5glpo=0x0
+sb20in80and160hr5gmpo=0x0
+sb40and80hr5gmpo=0x0
+sb20in80and160hr5ghpo=0x0
+sb40and80hr5ghpo=0x0
+sb20in40lrpo=0x0
+sb20in80and160lr5glpo=0x0
+sb40and80lr5glpo=0x0
+sb20in80and160lr5gmpo=0x0
+sb40and80lr5gmpo=0x0
+sb20in80and160lr5ghpo=0x0
+sb40and80lr5ghpo=0x0
+dot11agduphrpo=0x0
+dot11agduplrpo=0x0
+phycal_tempdelta=255
+temps_period=15
+temps_hysteresis=15
+rssicorrnorm_c0=4,4
+rssicorrnorm_c1=4,4
+rssicorrnorm5g_c0=1,2,3,1,2,3,6,6,8,6,6,8
+rssicorrnorm5g_c1=1,2,3,2,2,2,7,7,8,7,7,8
+
+swctrlmap_2g=0x1040,0x4010,0x4010,0x200010,0xff
+swctrlmap_5g=0x0202,0x0101,0x0101,0x00,0x47
+swctrlmapext_5g=0x,0x,0x,0x00,0x000
+swctrlmapext_2g=0x,0x,0x,0x00,0x000
+
+muxenab=0x10
+
--
2.28.0
Re: [PATCH v6 1/2] Add DT bindings YAML schema for PWM fan controller of LGM SoC
Hi Rob, On 1/8/2020 2:19 am, Rob Herring wrote: > On Tue, Jul 28, 2020 at 04:52:12PM +0800, Rahul Tanwar wrote: >> Intel's LGM(Lightning Mountain) SoC contains a PWM fan controller >> which is only used to control the fan attached to the system. This >> PWM controller does not have any other consumer other than fan. >> Add DT bindings documentation for this PWM fan controller. >> >> Signed-off-by: Rahul Tanwar >> --- >> .../devicetree/bindings/pwm/intel,lgm-pwm.yaml | 54 >> ++ >> 1 file changed, 54 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml >> >> diff --git a/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml >> b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml >> new file mode 100644 >> index ..9879972470dc >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml >> @@ -0,0 +1,54 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/pwm/intel,lgm-pwm.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: LGM SoC PWM fan controller >> + >> +maintainers: >> + - Rahul Tanwar >> + >> +properties: >> + compatible: >> +const: intel,lgm-pwm >> + >> + reg: >> +maxItems: 1 >> + >> + "#pwm-cells": >> +const: 2 >> + >> + clocks: >> +maxItems: 1 >> + >> + resets: >> +maxItems: 1 >> + >> + intel,fan-wire: >> +$ref: '/schemas/types.yaml#/definitions/uint32' >> +description: Specifies fan mode. Default when unspecified is 2. >> + >> + intel,max-rpm: >> +$ref: '/schemas/types.yaml#/definitions/uint32' >> +description: >> + Specifies maximum RPM of fan attached to the system. >> + Default when unspecified is 4000. > Again, these are properties of a fan, not the pwm controller. They > belong in a fan node. Our PWM controller is actually a PWM fan controller dedicated for controlling fan. I am looking for some suggestions from you on how to handle fan related optional properties in such a scenario. Should i create a separate child node for fan with PWM node being the parent? Is that what you are suggesting? Thanks. Regards, Rahul
drivers/hwspinlock/u8500_hsem.c:52:39: sparse: got void
Hi Baolin,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: ffd0bbfb378ecd56eac22bf932ccdbf89ac7f725 hwspinlock: Allow drivers to
be built with COMPILE_TEST
date: 5 months ago
config: powerpc64-randconfig-s032-20200812 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
git checkout ffd0bbfb378ecd56eac22bf932ccdbf89ac7f725
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/hwspinlock/u8500_hsem.c:52:39: sparse: sparse: incorrect type in
initializer (different address spaces) @@ expected void [noderef]
*lock_addr @@ got void *priv @@
drivers/hwspinlock/u8500_hsem.c:52:39: sparse: expected void [noderef]
*lock_addr
>> drivers/hwspinlock/u8500_hsem.c:52:39: sparse: got void *priv
drivers/hwspinlock/u8500_hsem.c:65:39: sparse: sparse: incorrect type in
initializer (different address spaces) @@ expected void [noderef]
*lock_addr @@ got void *priv @@
drivers/hwspinlock/u8500_hsem.c:65:39: sparse: expected void [noderef]
*lock_addr
drivers/hwspinlock/u8500_hsem.c:65:39: sparse: got void *priv
drivers/hwspinlock/u8500_hsem.c:116:30: sparse: sparse: incorrect type in
assignment (different address spaces) @@ expected void *priv @@ got
void [noderef] * @@
>> drivers/hwspinlock/u8500_hsem.c:116:30: sparse: expected void *priv
drivers/hwspinlock/u8500_hsem.c:116:30: sparse: got void [noderef]
*
drivers/hwspinlock/u8500_hsem.c:126:52: sparse: sparse: incorrect type in
initializer (different address spaces) @@ expected void [noderef]
*io_base @@ got void * @@
drivers/hwspinlock/u8500_hsem.c:126:52: sparse: expected void [noderef]
*io_base
>> drivers/hwspinlock/u8500_hsem.c:126:52: sparse: got void *
vim +52 drivers/hwspinlock/u8500_hsem.c
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 49
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 50 static int
u8500_hsem_trylock(struct hwspinlock *lock)
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 51 {
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 @52 void __iomem *lock_addr
= lock->priv;
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 53
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 54 writel(HSEM_MASTER_ID,
lock_addr);
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 55
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 56 /* get only first 4 bit
and compare to masterID.
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 57* if equal, we have
the semaphore, otherwise
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 58* someone else has it.
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 59*/
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 60 return (HSEM_MASTER_ID
== (0x0F & readl(lock_addr)));
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 61 }
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 62
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 63 static void
u8500_hsem_unlock(struct hwspinlock *lock)
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 64 {
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 65 void __iomem *lock_addr
= lock->priv;
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 66
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 67 /* release the lock by
writing 0 to it */
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 68 writel(RESET_SEMAPHORE,
lock_addr);
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 69 }
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 70
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 71 /*
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 72 * u8500: what value is
recommended here ?
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 73 */
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 74 static void
u8500_hsem_relax(struct hwspinlock *lock)
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 75 {
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 76 ndelay(50);
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 77 }
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 78
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 79 static const struct
hwspinlock_ops u8500_hwspinlock_ops = {
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 80 .trylock=
u8500_hsem_trylock,
f84a8ecfca9229 Mathieu J. Poirier 2011-09-08 81 .unlock =
u8500_hsem_unlock,
f84a8ecfca9229 Mathieu J. Poirier 2011-09-
RE: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver
> From: Alex Williamson > Sent: Wednesday, August 12, 2020 10:36 AM > On Wed, 12 Aug 2020 01:58:00 + > "Tian, Kevin" wrote: > > > > > > > I'll also remind folks that LPC is coming up in just a couple short > > > weeks and this might be something we should discuss (virtually) > > > in-person. uconf CfPs are currently open.Thanks, > > > > > > > Yes, LPC is a good place to reach consensus. btw I saw there is > > already one VFIO topic called "device assignment/sub-assignment". > > Do you think whether this can be covered under that topic, or > > makes more sense to be a new one? > > All the things listed in the CFP are only potential topics to get ideas > flowing, there is currently no proposal to talk about sub-assignment. > I'd suggest submitting separate topics for each and if we run into time > constraints we can ask that they might be combined together. Thanks, > Done. -- title: Criteria of using VFIO mdev (vs. userspace DMA) Content: VFIO mdev provides a framework for subdevice assignment and reuses existing VFIO uAPI to handle common passthrough-related requirements. However, subdevice (e.g. ADI defined in Intel Scalable IOV) might not be a PCI endpoint (e.g. just a work queue), thus requires some degree of emulation/mediation in kernel to fit into VFIO device API. Then there is a concern on putting emulation in kernel and how to judge abuse of mdev framework by simply using it as an easy path to hook into virtualization stack. An associated open is about differentiating mdev from userspace DMA framework (such as uacce), and whether building passthrough features on top of userspace DMA framework is a better choice than using mdev. Thanks Kevin
Re: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver
On 2020/8/10 下午3:32, Tian, Kevin wrote: From: Jason Gunthorpe Sent: Friday, August 7, 2020 8:20 PM On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote: If you see this as an abuse of the framework, then let's identify those specific issues and come up with a better approach. As we've discussed before, things like basic PCI config space emulation are acceptable overhead and low risk (imo) and some degree of register emulation is well within the territory of an mdev driver. What troubles me is that idxd already has a direct userspace interface to its HW, and does userspace DMA. The purpose of this mdev is to provide a second direct userspace interface that is a little different and trivially plugs into the virtualization stack. No. Userspace DMA and subdevice passthrough (what mdev provides) are two distinct usages IMO (at least in idxd context). and this might be the main divergence between us, thus let me put more words here. If we could reach consensus in this matter, which direction to go would be clearer. First, a passthrough interface requires some unique requirements which are not commonly observed in an userspace DMA interface, e.g.: - Tracking DMA dirty pages for live migration; - A set of interfaces for using SVA inside guest; * PASID allocation/free (on some platforms); * bind/unbind guest mm/page table (nested translation); * invalidate IOMMU cache/iotlb for guest page table changes; * report page request from device to guest; * forward page response from guest to device; - Configuring irqbypass for posted interrupt; - ... Second, a passthrough interface requires delegating raw controllability of subdevice to guest driver, while the same delegation might not be required for implementing an userspace DMA interface (especially for modern devices which support SVA). For example, idxd allows following setting per wq (guest driver may configure them in any combination): - put in dedicated or shared mode; - enable/disable SVA; - Associate guest-provided PASID to MSI/IMS entry; - set threshold; - allow/deny privileged access; - allocate/free interrupt handle (enlightened for guest); - collect error status; - ... We plan to support idxd userspace DMA with SVA. The driver just needs to prepare a wq with a predefined configuration (e.g. shared, SVA, etc.), bind the process mm to IOMMU (non-nested) and then map the portal to userspace. The goal that userspace can do DMA to associated wq doesn't change the fact that the wq is still *owned* and *controlled* by kernel driver. However as far as passthrough is concerned, the wq is considered 'owned' by the guest driver thus we need an interface which can support low-level *controllability* from guest driver. It is sort of a mess in uAPI when mixing the two together. So for userspace drivers like DPDK, it can use both of the two uAPIs? Based on above two reasons, we see distinct requirements between userspace DMA and passthrough interfaces, at least in idxd context (though other devices may have less distinction in-between). Therefore, we didn't see the value/necessity of reinventing the wheel that mdev already handles well to evolve an simple application-oriented usespace DMA interface to a complex guest-driver-oriented passthrough interface. The complexity of doing so would incur far more kernel-side changes than the portion of emulation code that you've been concerned about... I don't think VFIO should be the only entry point to virtualization. If we say the universe of devices doing user space DMA must also implement a VFIO mdev to plug into virtualization then it will be alot of mdevs. Certainly VFIO will not be the only entry point. and This has to be a case-by-case decision. The problem is that if we tie all controls via VFIO uAPI, the other subsystem like vDPA is likely to duplicate them. I wonder if there is a way to decouple the vSVA out of VFIO uAPI? If an userspace DMA interface can be easily adapted to be a passthrough one, it might be the choice. It's not that easy even for VFIO which requires a lot of new uAPIs and infrastructures(e.g mdev) to be invented. But for idxd, we see mdev a much better fit here, given the big difference between what userspace DMA requires and what guest driver requires in this hw. A weak point for mdev is that it can't serve kernel subsystem other than VFIO. In this case, you need some other infrastructures (like [1]) to do this. (For idxd, you probably don't need this, but it's pretty common in the case of networking or storage device.) Thanks [1] https://patchwork.kernel.org/patch/11280547/ I would prefer to see that the existing userspace interface have the extra needed bits for virtualization (eg by having appropriate internal kernel APIs to make this easy) and all the emulation to build the synthetic PCI device be done in userspace. In the e
Re: [PATCH v2 2/3] perf/x86/rapl: Support multiple rapl unit quirks
Hi,
Thanks for reviewing.
On Tue, 2020-08-11 at 11:19 -0700, Joe Perches wrote:
> On Tue, 2020-08-11 at 23:31 +0800, Zhang Rui wrote:
> > There will be more platforms with different fixed energy units.
> > Enhance the code to support different rapl unit quirks for
> > different
> > platforms.
>
> This seems like one quirk per platform.
>
> Should multiple quirks on individual platforms be supported?
>
enum rapl_unit_quirk is just used as a flag.
multiple quirks can be deployed with the same flag, just like what I
did in patch 3/3.
Also different platforms can either have different flags or share the
same flag.
thanks,
rui
> > diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c
>
> []
> > @@ -130,11 +130,16 @@ struct rapl_pmus {
> > struct rapl_pmu *pmus[];
> > };
> >
> > +enum rapl_unit_quirk {
> > + RAPL_UNIT_QUIRK_NONE,
> > + RAPL_UNIT_QUIRK_INTEL_HSW,
> > +};
> > +
> > struct rapl_model {
> > struct perf_msr *rapl_msrs;
> > unsigned long events;
> > unsigned intmsr_power_unit;
> > - boolapply_quirk;
> > + enum rapl_unit_quirkunit_quirk;
> > };
>
>
Re: [Resend PATCH 2/6] mm/memcg: remove useless check on page->mem_cgroup
在 2020/8/11 下午9:56, Michal Hocko 写道: > On Tue 11-08-20 20:54:18, Alex Shi wrote: >> >From beeac61119ab39b1869c520c0f272fb8bab93765 Mon Sep 17 00:00:00 2001 >> From: Alex Shi >> Date: Wed, 5 Aug 2020 21:02:30 +0800 >> Subject: [PATCH 2/6] memcg: bail out early from swap accounting when memcg is >> disabled>> >> If we disabled memcg by cgroup_disable=memory, the swap charges are >> still called. Let's return from the funcs earlier. > They are not, are they? page->memcg will be NULL and so the charge is > skipped and that will trigger a warning with your current ordering. Hi Michal, Thanks for comment! Looks like we both agree the memcg wasn't charged, but funcs just are called. :) > > Let me repeat again. Either you put it first in the series and argue > that we can bail out early or keep the ordering then this makes sure the > warning doesn't trigger. > Is the following commit log fine? Thanks! Alex >From 999b0fe5fc65865c3b59ff28500d45572a4a9570 Mon Sep 17 00:00:00 2001 From: Alex Shi Date: Wed, 5 Aug 2020 21:02:30 +0800 Subject: [PATCH 2/6] mm/memcg: bail out early from swap accounting when memcg is disabled If we disabled memcg by cgroup_disable=memory, page->memcg will be NULL and so the charge is skipped and that will trigger a warning like below. Let's return from the funcs earlier. ---[ end trace f1f34bfc3b32ed2f ]--- anon flags:0x5005b48008000d(locked|uptodate|dirty|swapbacked) raw: 005005b48008000d dead0100 dead0122 8897c7c76ad1 raw: 0022 0002 page dumped because: VM_WARN_ON_ONCE_PAGE(!memcg) Signed-off-by: Alex Shi Reviewed-by: Roman Gushchin Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: Andrew Morton Cc: cgro...@vger.kernel.org Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org --- mm/memcontrol.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 299382fc55a9..419cf565f40b 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -7098,6 +7098,9 @@ void mem_cgroup_swapout(struct page *page, swp_entry_t entry) VM_BUG_ON_PAGE(PageLRU(page), page); VM_BUG_ON_PAGE(page_count(page), page); + if (mem_cgroup_disabled()) + return; + if (cgroup_subsys_on_dfl(memory_cgrp_subsys)) return; @@ -7163,6 +7166,9 @@ int mem_cgroup_try_charge_swap(struct page *page, swp_entry_t entry) struct mem_cgroup *memcg; unsigned short oldid; + if (mem_cgroup_disabled()) + return 0; + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) return 0; -- 1.8.3.1
Re: [kbuild-all] Re: arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates bits from constant value (ffffffffe0f510cc becomes cc)
On 8/12/20 11:09 AM, Gao Xiang wrote:
Hi,
On Wed, Aug 12, 2020 at 09:49:38AM +0800, kernel test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
commit: 47e4937a4a7ca4184fd282791dfee76c6799966a erofs: move erofs out of
staging
date: 12 months ago
config: sparc64-randconfig-s032-20200812 (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-168-g9554805c-dirty
git checkout 47e4937a4a7ca4184fd282791dfee76c6799966a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sparc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
fs/erofs/utils.c: note: in included file (through
arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_64.h,
arch/sparc/include/asm/atomic.h, ...):
arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates bits
from constant value (e0f510cc becomes cc)
--
fs/erofs/zdata.c: note: in included file (through
arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_64.h,
arch/sparc/include/asm/atomic.h, ...):
arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates bits
from constant value (e0f510cc becomes cc)
arch/sparc/include/asm/cmpxchg_64.h:161:50: sparse: sparse: cast truncates
bits from constant value (5f0ecafe becomes fe)
arch/sparc/include/asm/cmpxchg_64.h:161:50: sparse: sparse: cast truncates
bits from constant value (5f0ecafe becomes fe)
arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates
bits from constant value (5f0edead becomes ad)
vim +161 arch/sparc/include/asm/cmpxchg_64.h
d550bbd40c0e10 David Howells 2012-03-28 155
d550bbd40c0e10 David Howells 2012-03-28 156 static inline unsigned long
d550bbd40c0e10 David Howells 2012-03-28 157 __cmpxchg(volatile void *ptr,
unsigned long old, unsigned long new, int size)
d550bbd40c0e10 David Howells 2012-03-28 158 {
d550bbd40c0e10 David Howells 2012-03-28 159switch (size) {
a12ee2349312d7 Babu Moger2017-05-24 160case 1:
a12ee2349312d7 Babu Moger2017-05-24 @161return
__cmpxchg_u8(ptr, old, new);
d550bbd40c0e10 David Howells 2012-03-28 162case 4:
d550bbd40c0e10 David Howells 2012-03-28 163return
__cmpxchg_u32(ptr, old, new);
d550bbd40c0e10 David Howells 2012-03-28 164case 8:
d550bbd40c0e10 David Howells 2012-03-28 165return
__cmpxchg_u64(ptr, old, new);
d550bbd40c0e10 David Howells 2012-03-28 166}
d550bbd40c0e10 David Howells 2012-03-28 167
__cmpxchg_called_with_bad_pointer();
d550bbd40c0e10 David Howells 2012-03-28 168return old;
d550bbd40c0e10 David Howells 2012-03-28 169 }
d550bbd40c0e10 David Howells 2012-03-28 170
Again, I have no idea how to deal with that in my current
gatekeeping code.
I got these reports, but I cannot help to resolve that.
Even I don't know if that's another sparse issue (since I
only got such reports on sparc and alpha arch, but no x86
or arm64.)
https://lore.kernel.org/r/202007251532.y5a10zoo%25...@intel.com
https://lore.kernel.org/r/202007272132.1agbbo3u%25...@intel.com
https://lore.kernel.org/r/202008100408.wc6wgrac%25...@intel.com
https://lore.kernel.org/r/202008120933.yrvhhyoa%25...@intel.com
If no one can help that, could you please silence such reports.
It really makes me confusing.
Hi Gao Xiang,
Sorry for the inconvenience, we'll silence the reports on this commit.
Best Regards,
Rong Chen
Thanks,
Gao Xiang
:: The code at line 161 was first introduced by commit
:: a12ee2349312d7112b9b7c6ac2e70c5ec2ca334e arch/sparc: Introduce
cmpxchg_u8 SPARC
:: TO: Babu Moger
:: CC: David S. Miller
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
kbuild-all mailing list -- kbuild-...@lists.01.org
To unsubscribe send an email to kbuild-all-le...@lists.01.org
Re: [PATCH] sched/fair: reduce preemption with IDLE tasks runable(Internet mail)
Hi, > On Aug 11, 2020, at 11:54 PM, Dietmar Eggemann > wrote: > > On 11/08/2020 02:41, benbjiang(蒋彪) wrote: >> Hi, >> >>> On Aug 10, 2020, at 9:24 PM, Dietmar Eggemann >>> wrote: >>> >>> On 06/08/2020 17:52, benbjiang(蒋彪) wrote: Hi, > On Aug 6, 2020, at 9:29 PM, Dietmar Eggemann > wrote: > > On 03/08/2020 13:26, benbjiang(蒋彪) wrote: >> >> >>> On Aug 3, 2020, at 4:16 PM, Dietmar Eggemann >>> wrote: >>> >>> On 01/08/2020 04:32, Jiang Biao wrote: From: Jiang Biao > > [...] > >>> Because of this very small weight (weight=3), compared to a SCHED_NORMAL >>> nice 0 task (weight=1024), a SCHED_IDLE task is penalized by a huge >>> se->vruntime value (1024/3 higher than for a SCHED_NORMAL nice 0 task). >>> This should make sure it doesn't tick preempt a SCHED_NORMAL nice 0 task. >> Could you please explain how the huge penalization of vruntime(1024/3) could >> make sure SCHED_IDLE not tick preempting SCHED_NORMAL nice 0 task? >> >> Thanks a lot. > > Trace a run of 2 SCHED_OTHER (nice 0) tasks and 1 SCHED_IDLE task on a > single CPU and trace_printk the conditions 'if (delta < 0)' and ' if > (delta > ideal_runtime)' in check_preempt_tick(). > > Then do the same with 3 SCHED_OTHER (nice 0) tasks. You can also change > the niceness of the 2 SCHED_OTHER task to 19 to see some differences in > the kernelshark's task layout. > > rt-app (https://github.com/scheduler-tools/rt-app) is a nice tool to > craft those artificial use cases. With rt-app tool, sched_switch traced by ftrace, the result is as what I expected, ** 1normal+1idle: idle preempt normal every 200ms ** <...>-92016 [002] d... 2398066.902477: sched_switch: prev_comm=normal0-0 prev_pid=92016 prev_prio=120 prev_state=S ==> next_comm=idle0-0 next_pid=91814 next_prio=120 <...>-91814 [002] d... 2398066.902527: sched_switch: prev_comm=idle0-0 prev_pid=91814 prev_prio=120 prev_state=R ==> next_comm=normal0-0 next_pid=92016 next_prio=120 <...>-92016 [002] d... 2398066.922472: sched_switch: prev_comm=normal0-0 prev_pid=92016 prev_prio=120 prev_state=S ==> next_comm=idle0-0 next_pid=91814 next_prio=120 <...>-91814 [002] d... 2398066.922522: sched_switch: prev_comm=idle0-0 prev_pid=91814 prev_prio=120 prev_state=R ==> next_comm=normal0-0 next_pid=92016 next_prio=120 <...>-92016 [002] d... 2398066.942292: sched_switch: prev_comm=normal0-0 prev_pid=92016 prev_prio=120 prev_state=S ==> next_comm=idle0-0 next_pid=91814 next_prio=120 <...>-91814 [002] d... 2398066.942343: sched_switch: prev_comm=idle0-0 prev_pid=91814 prev_prio=120 prev_state=R ==> next_comm=normal0-0 next_pid=92016 next_prio=120 <...>-92016 [002] d... 2398066.962331: sched_switch: prev_comm=normal0-0 prev_pid=92016 prev_prio=120 prev_state=S ==> next_comm=idle0-0 next_pid=91814 next_prio=120 ** 2normal+1idle: idle preempt normal every 600+ms ** <...>-49009 [002] d... 2400562.746640: sched_switch: prev_comm=normal0-0 prev_pid=49009 prev_prio=120 prev_state=R ==> next_comm=idle0-0 next_pid=187466 next_prio=120 <...>-187466 [002] d... 2400562.747502: sched_switch: prev_comm=idle0-0 prev_pid=187466 prev_prio=120 prev_state=S ==> next_comm=normal1-0 next_pid=198658 next_prio=120 <...>-198658 [002] d... 2400563.335262: sched_switch: prev_comm=normal1-0 prev_pid=198658 prev_prio=120 prev_state=R ==> next_comm=idle0-0 next_pid=187466 next_prio=120 <...>-187466 [002] d... 2400563.336258: sched_switch: prev_comm=idle0-0 prev_pid=187466 prev_prio=120 prev_state=R ==> next_comm=normal0-0 next_pid=49009 next_prio=120 <...>-198658 [002] d... 2400564.017663: sched_switch: prev_comm=normal1-0 prev_pid=198658 prev_prio=120 prev_state=R ==> next_comm=idle0-0 next_pid=187466 next_prio=120 <...>-187466 [002] d... 2400564.018661: sched_switch: prev_comm=idle0-0 prev_pid=187466 prev_prio=120 prev_state=R ==> next_comm=normal0-0 next_pid=49009 next_prio=120 <...>-198658 [002] d... 2400564.701063: sched_switch: prev_comm=normal1-0 prev_pid=198658 prev_prio=120 prev_state=R ==> next_comm=idle0-0 next_pid=187466 next_prio=120 ** 3normal+idle: idle preempt normal every 1000+ms ** <...>-198658 [002] d... 2400415.780701: sched_switch: prev_comm=normal1-0 prev_pid=198658 prev_prio=120 prev_state=R ==> next_comm=idle0-0 next_pid=187466 next_prio=120 <...>-187466 [002] d... 2400415.781699: sched_switch: prev_comm=idle0-0 prev_pid=187466 prev_prio=120 prev_state=R ==> next_comm=normal2-0 next_pid=46478 next_prio=120 <...>-49009 [002] d... 2400416.806298: sched_switch: prev_comm=normal0-0 prev_pid=49009 prev_prio=120 prev_state=R ==> next_comm=idle0-0 next_pid=187466 next_prio=120 <...>-187466 [002] d... 2400416.807297: sched_switch: prev_comm=idle0-0 prev_pid=187466 prev_prio=120 prev_state=R ==> next_comm=normal2-0 next_pi
KASAN: use-after-free Read in path_init (2)
Hello,
syzbot found the following issue on:
HEAD commit:5631c5e0 Merge tag 'xfs-5.9-merge-7' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1707698490
kernel config: https://syzkaller.appspot.com/x/.config?x=afba7c06f91e56eb
dashboard link: https://syzkaller.appspot.com/bug?extid=bbeb1c88016c7db4aa24
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1502ce0290
The issue was bisected to:
commit e24ab0ef689de43649327f54cd1088f3dad25bb3
Author: Christoph Hellwig
Date: Tue Jul 21 08:48:15 2020 +
fs: push the getname from do_rmdir into the callers
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=155f36c290
final oops: https://syzkaller.appspot.com/x/report.txt?x=175f36c290
console output: https://syzkaller.appspot.com/x/log.txt?x=135f36c290
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+bbeb1c88016c7db4a...@syzkaller.appspotmail.com
Fixes: e24ab0ef689d ("fs: push the getname from do_rmdir into the callers")
==
BUG: KASAN: use-after-free in path_init+0x116b/0x13c0 fs/namei.c:2207
Read of size 8 at addr 88807853c940 by task syz-executor.2/8233
CPU: 0 PID: 8233 Comm: syz-executor.2 Not tainted 5.8.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x18f/0x20d lib/dump_stack.c:118
print_address_description.constprop.0.cold+0xae/0x436 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
path_init+0x116b/0x13c0 fs/namei.c:2207
path_parentat+0x22/0x1b0 fs/namei.c:2384
filename_parentat+0x188/0x560 fs/namei.c:2407
do_rmdir+0xa8/0x440 fs/namei.c:3732
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45ce79
Code: 2d b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
fb b5 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f756fb2bc78 EFLAGS: 0246 ORIG_RAX: 0054
RAX: ffda RBX: 000260c0 RCX: 0045ce79
RDX: RSI: RDI: 20c0
RBP: 0118bff0 R08: R09:
R10: R11: 0246 R12: 0118bfcc
R13: 7ffedeb9931f R14: 7f756fb2c9c0 R15: 0118bfcc
Allocated by task 8233:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494
slab_post_alloc_hook mm/slab.h:586 [inline]
slab_alloc mm/slab.c:3320 [inline]
kmem_cache_alloc+0x12c/0x3b0 mm/slab.c:3484
getname_flags.part.0+0x50/0x4f0 fs/namei.c:138
getname_flags include/linux/audit.h:320 [inline]
getname fs/namei.c:209 [inline]
__do_sys_rmdir fs/namei.c:3783 [inline]
__se_sys_rmdir fs/namei.c:3781 [inline]
__x64_sys_rmdir+0xb1/0x100 fs/namei.c:3781
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 8233:
save_stack+0x1b/0x40 mm/kasan/common.c:48
set_track mm/kasan/common.c:56 [inline]
kasan_set_free_info mm/kasan/common.c:316 [inline]
__kasan_slab_free+0xf5/0x140 mm/kasan/common.c:455
__cache_free mm/slab.c:3426 [inline]
kmem_cache_free+0x7f/0x310 mm/slab.c:3694
putname+0xe1/0x120 fs/namei.c:259
do_rmdir+0x145/0x440 fs/namei.c:3773
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at 88807853c940
which belongs to the cache names_cache of size 4096
The buggy address is located 0 bytes inside of
4096-byte region [88807853c940, 88807853d940)
The buggy address belongs to the page:
page:ea0001e14f00 refcount:1 mapcount:0 mapping: index:0x0
head:ea0001e14f00 order:1 compound_mapcount:0
flags: 0xfffe010200(slab|head)
raw: 00fffe010200 ea0001e14e88 ea0001e14f88 8880aa246380
raw: 88807853c940 00010001
page dumped because: kasan: bad access detected
Memory state around the buggy address:
88807853c800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
88807853c880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>88807853c900: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
88807853c980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
88807853ca00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syz
Re: [PATCH 2/2] perf sched timehist: Fix use of CPU list with summary option
On 8/11/20 12:42 AM, Namhyung Kim wrote:
>> @@ -2575,7 +2575,8 @@ static int timehist_sched_change_event(struct
>> perf_tool *tool,
>> }
>>
>> if (!sched->idle_hist || thread->tid == 0) {
>> - timehist_update_runtime_stats(tr, t, tprev);
>> + if (!cpu_list || test_bit(sample->cpu, cpu_bitmap))
>> + timehist_update_runtime_stats(tr, t, tprev);
>>
>> if (sched->idle_hist) {
>> struct idle_thread_runtime *itr = (void *)tr;
>> @@ -2848,6 +2849,9 @@ static void timehist_print_summary(struct perf_sched
>> *sched,
>>
>> printf("\nIdle stats:\n");
>> for (i = 0; i < idle_max_cpu; ++i) {
>> + if (!test_bit(i, cpu_bitmap))
>
> Shouldn't it check cpu_list as well?
>
oh, right. will fix.
Re: [PATCH v3 2/2] ASoC: Intel: Add period size constraint on strago board
Mark Brown 於 2020年8月12日 週三 上午1:22寫道： > > On Tue, Aug 11, 2020 at 11:54:38AM -0500, Pierre-Louis Bossart wrote: > > > > constraint logic needs to know about this DSP limitation - it seems like > > > none of this is going to change without something new going into the > > > mix? We at least need a new question to ask about the DSP firmware I > > > think. > > > I just tested aplay -Dhw: on a Cyan Chromebook with the Ubuntu kernel 5.4, > > and I see no issues with the 240 sample period. Same with 432, 960, 9600, > > etc. > > > I also tried just for fun what happens with 256 samples, and I don't see any > > underflows thrown either, so I am wondering what exactly the problem is? > > Something's not adding up. I would definitively favor multiple of 1ms > > periods, since it's the only case that was productized, but there's got to > > me something a side effect of how CRAS programs the hw_params. > > Is it something that goes wrong with longer playbacks possibly (eg, > someone watching a feature film or something)? Thanks for testing! After doing some experiments, I think I can identify the problem more precisely. 1. aplay can not reproduce this issue because it writes samples immediately when there are some space in the buffer. However, you can add --test-position to see how the delay grows with period size 256. > aplay -Dhw:1,0 --period-size=256 --buffer-size=480 /dev/zero -d 1 -f dat > --test-position Playing raw data '/dev/zero' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Suspicious buffer position (1 total): avail = 0, delay = 2064, buffer = 512 Suspicious buffer position (2 total): avail = 0, delay = 2064, buffer = 512 Suspicious buffer position (3 total): avail = 0, delay = 2096, buffer = 512 ... 2. Since many samples are moved to DSP(delay), the measured rate of the ring-buffer is high. (I measured it by alsa_conformance_test, which only test the sampling rate in the ring buffer of kernel not DSP) 3. Since CRAS writes samples with a fixed frequency, this behavior will take all samples from the ring buffer, which is seen as underrun by CRAS. (It seems that it is not a real underrun because that avail does not larger than buffer size. Maybe CRAS should also take dalay into account.) 4. In spite of it is not a real underrun, the large delay is still a big problem. Can we apply the constraint to fix it? Or any better idea? Thanks, Yu-Hsuan
drivers/net/ethernet/realtek/r8169_main.c:1872 rtl_coalesce_choose_scale() warn: passing a valid pointer to 'PTR_ERR'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: bb5baaa9238ecf8f13b112232c7bbe0d3d598ee8
commit: 2815b30535a0613ee07d477d0c628100f40b6059 r8169: merge scale for tx and
rx irq coalescing
date: 3 months ago
config: parisc-randconfig-m031-20200811 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
New smatch warnings:
drivers/net/ethernet/realtek/r8169_main.c:1872 rtl_coalesce_choose_scale()
warn: passing a valid pointer to 'PTR_ERR'
Old smatch warnings:
drivers/net/ethernet/realtek/r8169_main.c:1837 rtl_get_coalesce() warn: passing
a valid pointer to 'PTR_ERR'
vim +/PTR_ERR +1872 drivers/net/ethernet/realtek/r8169_main.c
1862
1863 /* choose appropriate scale factor and CPlusCmd[0:1] for (speed, nsec)
*/
1864 static int rtl_coalesce_choose_scale(struct rtl8169_private *tp, u32
nsec,
1865 u16 *cp01)
1866 {
1867 const struct rtl_coalesce_info *ci;
1868 u16 i;
1869
1870 ci = rtl_coalesce_info(tp);
1871 if (IS_ERR(ci))
> 1872 return PTR_ERR(ci);
1873
1874 for (i = 0; i < 4; i++) {
1875 if (nsec <= ci->scale_nsecs[i] * RTL_COALESCE_T_MAX) {
1876 *cp01 = i;
1877 return ci->scale_nsecs[i];
1878 }
1879 }
1880
1881 return -EINVAL;
1882 }
1883
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates bits from constant value (ffffffffe0f510cc becomes cc)
Hi,
On Wed, Aug 12, 2020 at 09:49:38AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: fb893de323e2d39f7a1f6df425703a2edbdf56ea
> commit: 47e4937a4a7ca4184fd282791dfee76c6799966a erofs: move erofs out of
> staging
> date: 12 months ago
> config: sparc64-randconfig-s032-20200812 (attached as .config)
> compiler: sparc64-linux-gcc (GCC) 9.3.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # apt-get install sparse
> # sparse version: v0.6.2-168-g9554805c-dirty
> git checkout 47e4937a4a7ca4184fd282791dfee76c6799966a
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
> CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sparc64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
>
> sparse warnings: (new ones prefixed by >>)
>
>fs/erofs/utils.c: note: in included file (through
> arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_64.h,
> arch/sparc/include/asm/atomic.h, ...):
> >> arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates
> >> bits from constant value (e0f510cc becomes cc)
> --
>fs/erofs/zdata.c: note: in included file (through
> arch/sparc/include/asm/cmpxchg.h, arch/sparc/include/asm/atomic_64.h,
> arch/sparc/include/asm/atomic.h, ...):
> >> arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates
> >> bits from constant value (e0f510cc becomes cc)
>arch/sparc/include/asm/cmpxchg_64.h:161:50: sparse: sparse: cast truncates
> bits from constant value (5f0ecafe becomes fe)
>arch/sparc/include/asm/cmpxchg_64.h:161:50: sparse: sparse: cast truncates
> bits from constant value (5f0ecafe becomes fe)
>arch/sparc/include/asm/cmpxchg_64.h:161:55: sparse: sparse: cast truncates
> bits from constant value (5f0edead becomes ad)
>
> vim +161 arch/sparc/include/asm/cmpxchg_64.h
>
> d550bbd40c0e10 David Howells 2012-03-28 155
> d550bbd40c0e10 David Howells 2012-03-28 156 static inline unsigned long
> d550bbd40c0e10 David Howells 2012-03-28 157 __cmpxchg(volatile void *ptr,
> unsigned long old, unsigned long new, int size)
> d550bbd40c0e10 David Howells 2012-03-28 158 {
> d550bbd40c0e10 David Howells 2012-03-28 159 switch (size) {
> a12ee2349312d7 Babu Moger2017-05-24 160 case 1:
> a12ee2349312d7 Babu Moger2017-05-24 @161 return
> __cmpxchg_u8(ptr, old, new);
> d550bbd40c0e10 David Howells 2012-03-28 162 case 4:
> d550bbd40c0e10 David Howells 2012-03-28 163 return
> __cmpxchg_u32(ptr, old, new);
> d550bbd40c0e10 David Howells 2012-03-28 164 case 8:
> d550bbd40c0e10 David Howells 2012-03-28 165 return
> __cmpxchg_u64(ptr, old, new);
> d550bbd40c0e10 David Howells 2012-03-28 166 }
> d550bbd40c0e10 David Howells 2012-03-28 167
> __cmpxchg_called_with_bad_pointer();
> d550bbd40c0e10 David Howells 2012-03-28 168 return old;
> d550bbd40c0e10 David Howells 2012-03-28 169 }
> d550bbd40c0e10 David Howells 2012-03-28 170
Again, I have no idea how to deal with that in my current
gatekeeping code.
I got these reports, but I cannot help to resolve that.
Even I don't know if that's another sparse issue (since I
only got such reports on sparc and alpha arch, but no x86
or arm64.)
https://lore.kernel.org/r/202007251532.y5a10zoo%25...@intel.com
https://lore.kernel.org/r/202007272132.1agbbo3u%25...@intel.com
https://lore.kernel.org/r/202008100408.wc6wgrac%25...@intel.com
https://lore.kernel.org/r/202008120933.yrvhhyoa%25...@intel.com
If no one can help that, could you please silence such reports.
It really makes me confusing.
Thanks,
Gao Xiang
>
> :: The code at line 161 was first introduced by commit
> :: a12ee2349312d7112b9b7c6ac2e70c5ec2ca334e arch/sparc: Introduce
> cmpxchg_u8 SPARC
>
> :: TO: Babu Moger
> :: CC: David S. Miller
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH] lib/cmdline: prevent unintented access to address
When args = "\"\0", "i" will be 0 and args[i-1] is used (line:238)
Because of "i" is an unsigned int type,
the function will access at args[0x]
It can make a crash
Signed-off-by: Seungil Kang
---
lib/cmdline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/cmdline.c b/lib/cmdline.c
index fbb9981a04a4..2fd29d7723b2 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -200,7 +200,7 @@ bool parse_option_str(const char *str, const char *option)
*/
char *next_arg(char *args, char **param, char **val)
{
- unsigned int i, equals = 0;
+ int i, equals = 0;
int in_quote = 0, quoted = 0;
char *next;
--
2.17.1
[PATCH v3] usb: typec: tcpm: Fix TDA 2.2.1.1 and TDA 2.2.1.2 failures
>From the spec: "7.1.5 Response to Hard Resets Hard Reset Signaling indicates a communication failure has occurred and the Source Shall stop driving VCONN, Shall remove Rp from the VCONN pin and Shall drive VBUS to vSafe0V as shown in Figure 7-9. The USB connection May reset during a Hard Reset since the VBUS voltage will be less than vSafe5V for an extended period of time. After establishing the vSafe0V voltage condition on VBUS, the Source Shall wait tSrcRecover before re-applying VCONN and restoring VBUS to vSafe5V. A Source Shall conform to the VCONN timing as specified in [USB Type-C 1.3]." Signed-off-by: Badhri Jagan Sridharan Reviewed-by: Guenter Roeck --- Changes since V1 (Guenter's suggestion): - Bound SRC_HARD_RESET_VBUS_ON to accommodate tcpc drivers which doesn't update the vbus status. Changes since V2: - Reviewed-by: Guenter Roeck --- drivers/usb/typec/tcpm/tcpm.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 3ef37202ee37..a48e3f90d196 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -3372,13 +3372,31 @@ static void run_state_machine(struct tcpm_port *port) tcpm_set_state(port, SNK_HARD_RESET_SINK_OFF, 0); break; case SRC_HARD_RESET_VBUS_OFF: - tcpm_set_vconn(port, true); + /* +* 7.1.5 Response to Hard Resets +* Hard Reset Signaling indicates a communication failure has occurred and the +* Source Shall stop driving VCONN, Shall remove Rp from the VCONN pin and Shall +* drive VBUS to vSafe0V as shown in Figure 7-9. +*/ + tcpm_set_vconn(port, false); tcpm_set_vbus(port, false); tcpm_set_roles(port, port->self_powered, TYPEC_SOURCE, tcpm_data_role_for_source(port)); - tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, PD_T_SRC_RECOVER); + /* +* If tcpc fails to notify vbus off, TCPM will wait for PD_T_SAFE_0V + +* PD_T_SRC_RECOVER before turning vbus back on. +* From Table 7-12 Sequence Description for a Source Initiated Hard Reset: +* 4. Policy Engine waits tPSHardReset after sending Hard Reset Signaling and then +* tells the Device Policy Manager to instruct the power supply to perform a +* Hard Reset. The transition to vSafe0V Shall occur within tSafe0V (t2). +* 5. After tSrcRecover the Source applies power to VBUS in an attempt to +* re-establish communication with the Sink and resume USB Default Operation. +* The transition to vSafe5V Shall occur within tSrcTurnOn(t4). +*/ + tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, PD_T_SAFE_0V + PD_T_SRC_RECOVER); break; case SRC_HARD_RESET_VBUS_ON: + tcpm_set_vconn(port, true); tcpm_set_vbus(port, true); port->tcpc->set_pd_rx(port->tcpc, true); tcpm_set_attached_state(port, true); @@ -3944,7 +3962,11 @@ static void _tcpm_pd_vbus_off(struct tcpm_port *port) tcpm_set_state(port, SNK_HARD_RESET_WAIT_VBUS, 0); break; case SRC_HARD_RESET_VBUS_OFF: - tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, 0); + /* +* After establishing the vSafe0V voltage condition on VBUS, the Source Shall wait +* tSrcRecover before re-applying VCONN and restoring VBUS to vSafe5V. +*/ + tcpm_set_state(port, SRC_HARD_RESET_VBUS_ON, PD_T_SRC_RECOVER); break; case HARD_RESET_SEND: break; -- 2.28.0.236.gb10cc79966-goog
drivers/i2c/busses/i2c-mlxcpld.c:97:17: sparse: got void COPYING CREDITS Documentation Kbuild Kconfig LICENSES MAINTAINERS Makefile README arch block certs crypto drivers fs include init ipc kernel li
Hi Krzysztof, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: bb5baaa9238ecf8f13b112232c7bbe0d3d598ee8 commit: 4a2d5f663dab6614772d8e28ca190b127ba46d9d i2c: Enable compile testing for more drivers date: 7 months ago config: riscv-randconfig-s031-20200812 (attached as .config) compiler: riscv64-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-168-g9554805c-dirty git checkout 4a2d5f663dab6614772d8e28ca190b127ba46d9d # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) drivers/i2c/busses/i2c-mlxcpld.c:97:17: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:97:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:97:17: sparse: expected void volatile [noderef] *addr >> drivers/i2c/busses/i2c-mlxcpld.c:97:17: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:99:17: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:99:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:99:17: sparse: expected void volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:99:17: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:107:38: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:107:38: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:107:38: sparse: expected void const volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:107:38: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:109:31: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:109:31: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:109:31: sparse: expected void const volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:109:31: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:119:27: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:119:27: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:119:27: sparse: expected void const volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:119:27: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:122:34: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:122:34: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:122:34: sparse: expected void const volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:122:34: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:125:34: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:125:34: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:125:34: sparse: expected void const volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:125:34: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:126:31: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:126:31: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] *addr @@ got void * @@ drivers/i2c/busses/i2c-mlxcpld.c:126:31: sparse: expected void const volatile [noderef] *addr drivers/i2c/busses/i2c-mlxcpld.c:126:31: sparse: got void * drivers/i2c/busses/i2c-mlxcpld.c:129:34: sparse: sparse: cast removes address space '' of expression drivers/i2c/busses/i2c-mlxcpld.c:129:34: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [
Re: KASAN: use-after-free Read in __io_req_task_submit
#syz dup: KASAN: use-after-free Read in io_async_task_func -- Jens Axboe
Re: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver
On Wed, 12 Aug 2020 01:58:00 + "Tian, Kevin" wrote: > > From: Alex Williamson > > Sent: Wednesday, August 12, 2020 1:01 AM > > > > On Mon, 10 Aug 2020 07:32:24 + > > "Tian, Kevin" wrote: > > > > > > From: Jason Gunthorpe > > > > Sent: Friday, August 7, 2020 8:20 PM > > > > > > > > On Wed, Aug 05, 2020 at 07:22:58PM -0600, Alex Williamson wrote: > > > > > > > > > If you see this as an abuse of the framework, then let's identify > > > > > those > > > > > specific issues and come up with a better approach. As we've > > > > > discussed > > > > > before, things like basic PCI config space emulation are acceptable > > > > > overhead and low risk (imo) and some degree of register emulation is > > > > > well within the territory of an mdev driver. > > > > > > > > What troubles me is that idxd already has a direct userspace interface > > > > to its HW, and does userspace DMA. The purpose of this mdev is to > > > > provide a second direct userspace interface that is a little different > > > > and trivially plugs into the virtualization stack. > > > > > > No. Userspace DMA and subdevice passthrough (what mdev provides) > > > are two distinct usages IMO (at least in idxd context). and this might > > > be the main divergence between us, thus let me put more words here. > > > If we could reach consensus in this matter, which direction to go > > > would be clearer. > > > > > > First, a passthrough interface requires some unique requirements > > > which are not commonly observed in an userspace DMA interface, e.g.: > > > > > > - Tracking DMA dirty pages for live migration; > > > - A set of interfaces for using SVA inside guest; > > > * PASID allocation/free (on some platforms); > > > * bind/unbind guest mm/page table (nested translation); > > > * invalidate IOMMU cache/iotlb for guest page table changes; > > > * report page request from device to guest; > > > * forward page response from guest to device; > > > - Configuring irqbypass for posted interrupt; > > > - ... > > > > > > Second, a passthrough interface requires delegating raw controllability > > > of subdevice to guest driver, while the same delegation might not be > > > required for implementing an userspace DMA interface (especially for > > > modern devices which support SVA). For example, idxd allows following > > > setting per wq (guest driver may configure them in any combination): > > > - put in dedicated or shared mode; > > > - enable/disable SVA; > > > - Associate guest-provided PASID to MSI/IMS entry; > > > - set threshold; > > > - allow/deny privileged access; > > > - allocate/free interrupt handle (enlightened for guest); > > > - collect error status; > > > - ... > > > > > > We plan to support idxd userspace DMA with SVA. The driver just needs > > > to prepare a wq with a predefined configuration (e.g. shared, SVA, > > > etc.), bind the process mm to IOMMU (non-nested) and then map > > > the portal to userspace. The goal that userspace can do DMA to > > > associated wq doesn't change the fact that the wq is still *owned* > > > and *controlled* by kernel driver. However as far as passthrough > > > is concerned, the wq is considered 'owned' by the guest driver thus > > > we need an interface which can support low-level *controllability* > > > from guest driver. It is sort of a mess in uAPI when mixing the > > > two together. > > > > > > Based on above two reasons, we see distinct requirements between > > > userspace DMA and passthrough interfaces, at least in idxd context > > > (though other devices may have less distinction in-between). Therefore, > > > we didn't see the value/necessity of reinventing the wheel that mdev > > > already handles well to evolve an simple application-oriented usespace > > > DMA interface to a complex guest-driver-oriented passthrough interface. > > > The complexity of doing so would incur far more kernel-side changes > > > than the portion of emulation code that you've been concerned about... > > > > > > > > > > > I don't think VFIO should be the only entry point to > > > > virtualization. If we say the universe of devices doing user space DMA > > > > must also implement a VFIO mdev to plug into virtualization then it > > > > will be alot of mdevs. > > > > > > Certainly VFIO will not be the only entry point. and This has to be a > > > case-by-case decision. If an userspace DMA interface can be easily > > > adapted to be a passthrough one, it might be the choice. But for idxd, > > > we see mdev a much better fit here, given the big difference between > > > what userspace DMA requires and what guest driver requires in this hw. > > > > > > > > > > > I would prefer to see that the existing userspace interface have the > > > > extra needed bits for virtualization (eg by having appropriate > > > > internal kernel APIs to make this easy) and all the emulation to build > > > > the synthetic PCI device be done in userspace. > > > > > > In the end what decides the direction i
[GIT PULL] VFIO updates for v5.9-rc1
Hi Linus, The following changes since commit 92ed301919932f13b9172e525674157e983d: Linux 5.8-rc7 (2020-07-26 14:14:06 -0700) are available in the Git repository at: git://github.com/awilliam/linux-vfio.git tags/vfio-v5.9-rc1 for you to fetch changes up to ccd59dce1a21f473518bf273bdf5b182bab955b3: vfio/type1: Refactor vfio_iommu_type1_ioctl() (2020-07-27 13:46:13 -0600) VFIO updates for v5.9-rc1 - Inclusive naming updates (Alex Williamson) - Intel X550 INTx quirk (Alex Williamson) - Error path resched between unmaps (Xiang Zheng) - SPAPR IOMMU pin_user_pages() conversion (John Hubbard) - Trivial mutex simplification (Alex Williamson) - QAT device denylist (Giovanni Cabiddu) - type1 IOMMU ioctl refactor (Liu Yi L) Alex Williamson (3): vfio: Cleanup allowed driver naming vfio/pci: Add Intel X550 to hidden INTx devices vfio/pci: Hold igate across releasing eventfd contexts Giovanni Cabiddu (3): PCI: Add Intel QuickAssist device IDs vfio/pci: Add device denylist vfio/pci: Add QAT devices to denylist John Hubbard (1): vfio/spapr_tce: convert get_user_pages() --> pin_user_pages() Liu Yi L (1): vfio/type1: Refactor vfio_iommu_type1_ioctl() Xiang Zheng (1): vfio/type1: Add conditional rescheduling after iommu map failed drivers/vfio/pci/vfio_pci.c | 54 - drivers/vfio/vfio.c | 13 +- drivers/vfio/vfio_iommu_spapr_tce.c | 4 +- drivers/vfio/vfio_iommu_type1.c | 398 +++- include/linux/pci_ids.h | 6 + 5 files changed, 282 insertions(+), 193 deletions(-)
Re: [PATCH net] drivers/net/wan/x25_asy: Added needed_headroom and a skb->len check
On Tue, Aug 11, 2020 at 10:32 AM David Miller wrote: > > Applied, thank you. Thank you!
[PATCH 1/2 v3] tcpm: During PR_SWAP, source caps should be sent only after tSwapSourceStart
>From the spec: "6.6.8.1 SwapSourceStartTimer The SwapSourceStartTimer Shall be used by the new Source, after a Power Role Swap or Fast Role Swap, to ensure that it does not send Source_Capabilities Message before the new Sink is ready to receive the Source_Capabilities Message. The new Source Shall Not send the Source_Capabilities Message earlier than tSwapSourceStart after the last bit of the EOP of GoodCRC Message sent in response to the PS_RDY Message sent by the new Source indicating that its power supply is ready." This fixes TD.PD.CP.E3, TD.PD.CP.E4, TD.PD.CP.E5 failures Signed-off-by: Badhri Jagan Sridharan Reviewed-by: Guenter Roeck --- Changes since V1: - Comment on the permissible values of tSwapSourceStart Changes since V2: - Fixing alignment issue pointed out by Guenter. - Added Reviewed-by: Guenter Roeck --- drivers/usb/typec/tcpm/tcpm.c | 2 +- include/linux/usb/pd.h| 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 3ef37202ee37..d38347bd3335 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -3555,7 +3555,7 @@ static void run_state_machine(struct tcpm_port *port) */ tcpm_set_pwr_role(port, TYPEC_SOURCE); tcpm_pd_send_control(port, PD_CTRL_PS_RDY); - tcpm_set_state(port, SRC_STARTUP, 0); + tcpm_set_state(port, SRC_STARTUP, PD_T_SWAP_SRC_START); break; case VCONN_SWAP_ACCEPT: diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h index b6c233e79bd4..1df895e4680b 100644 --- a/include/linux/usb/pd.h +++ b/include/linux/usb/pd.h @@ -473,6 +473,7 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_T_ERROR_RECOVERY100 /* minimum 25 is insufficient */ #define PD_T_SRCSWAPSTDBY 625 /* Maximum of 650ms */ #define PD_T_NEWSRC250 /* Maximum of 275ms */ +#define PD_T_SWAP_SRC_START20 /* Minimum of 20ms */ #define PD_T_DRP_TRY 100 /* 75 - 150 ms */ #define PD_T_DRP_TRYWAIT 600 /* 400 - 800 ms */ -- 2.28.0.236.gb10cc79966-goog
[PATCH 2/2 v3] usb: typec: pd: Fix formatting in pd.h header
Replacing spaces with tabs for PD_T_* constants. Signed-off-by: Badhri Jagan Sridharan --- Change history: First version. Keeping the version number same as the parent. --- include/linux/usb/pd.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h index 1df895e4680b..f842e4589bd2 100644 --- a/include/linux/usb/pd.h +++ b/include/linux/usb/pd.h @@ -471,9 +471,10 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_T_VCONN_SOURCE_ON 100 #define PD_T_SINK_REQUEST 100 /* 100 ms minimum */ #define PD_T_ERROR_RECOVERY100 /* minimum 25 is insufficient */ -#define PD_T_SRCSWAPSTDBY 625 /* Maximum of 650ms */ -#define PD_T_NEWSRC250 /* Maximum of 275ms */ +#define PD_T_SRCSWAPSTDBY 625 /* Maximum of 650ms */ +#define PD_T_NEWSRC250 /* Maximum of 275ms */ #define PD_T_SWAP_SRC_START20 /* Minimum of 20ms */ +#define PD_T_BIST_CONT_MODE50 /* 30 - 60 ms */ #define PD_T_DRP_TRY 100 /* 75 - 150 ms */ #define PD_T_DRP_TRYWAIT 600 /* 400 - 800 ms */ @@ -484,5 +485,4 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_N_CAPS_COUNT(PD_T_NO_RESPONSE / PD_T_SEND_SOURCE_CAP) #define PD_N_HARD_RESET_COUNT 2 -#define PD_T_BIST_CONT_MODE50 /* 30 - 60 ms */ #endif /* __LINUX_USB_PD_H */ -- 2.28.0.236.gb10cc79966-goog
Re: [PATCH net] drivers/net/wan/x25_asy: Added needed_headroom and a skb->len check
On Tue, Aug 11, 2020 at 3:50 AM Willem de Bruijn wrote: > > > I became interested in X.25 when I was trying different address > > families that Linux supported. I tried AF_X25 sockets. And then I > > tried to use the X.25 link layer directly through AF_PACKET. I believe > > both AF_X25 sockets and AF_PACKET sockets need to work without > > problems with X.25 drivers - lapbether and x25_asy. There is another > > X.25 driver (hdlc_x25) in the kernel. I haven't been able to run that > > driver. But that driver seems to be the real driver which is really > > used, and I know Martin Schiller is an active user and > > developer of that driver. > > Great, sounds like we might have additional LAPB and X25 maintainers soon? :) :) I just want to fix any problems I see. I'll do this whenever I have time. > MAINTAINERS lists Andrew Hendry as maintainer for X.25. Please do CC them. OK. I'll surely do that. Thanks!
