Re: [PATCH 1/5] gpio: tps65910: use regmap accessors
On Sun, Sep 27, 2020 at 1:59 AM Michał Mirosław wrote: > Use regmap accessors directly for register manipulation - removing one > layer of abstraction. > > Signed-off-by: Michał Mirosław Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v2 0/4] media: meson: Add support for the Amlogic GE2D Accelerator Unit
Hi Neil, this is just a drive-by question and I'm looping in Todd in the hopes for a discussion or clarification. On Fri, Oct 30, 2020 at 3:37 PM Neil Armstrong wrote: > The GE2D is a 2D accelerator with various features like configurable blitter > with alpha blending, frame rotation, scaling, format conversion and colorspace > conversion. > > The driver implements a Memory2Memory VB2 V4L2 streaming device permitting: > - 0, 90, 180, 270deg rotation > - horizontal/vertical flipping > - source cropping > - destination compositing > - 32bit/24bit/16bit format conversion > > This adds the support for the GE2D version found in the AXG SoCs Family. We are starting to see a bunch of these really nicely abstracted blitters and other 2D-accelerators now. Is stuff like Android going to pick up and use this to blit and blend generic buffers? Or is this in essence a camera and/or video out accelerator thing? The placement of this driver in drivers/media makes me think that it is for cameras or video output, but the functionality is actually quite generic. I've been half-guessing that userspace like Android actually mostly use GPUs to composit their graphics, but IIUC this can sometimes be used for 2D compositing, and when used will often be quicker and/or more energy efficient than using a GPU for the same task. Yours, Linus Walleij
Re: [PATCH] clk: fsl-sai: fix memory leak
Am 2020-11-05 01:29, schrieb Stephen Boyd:
Quoting Michael Walle (2020-11-01 10:48:18)
diff --git a/drivers/clk/clk-fsl-sai.c b/drivers/clk/clk-fsl-sai.c
index 0221180a4dd7..1e81c8d8a6fd 100644
--- a/drivers/clk/clk-fsl-sai.c
+++ b/drivers/clk/clk-fsl-sai.c
@@ -68,9 +68,20 @@ static int fsl_sai_clk_probe(struct platform_device
*pdev)
if (IS_ERR(hw))
return PTR_ERR(hw);
+ platform_set_drvdata(pdev, hw);
+
return devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get,
hw);
}
+static int fsl_sai_clk_remove(struct platform_device *pdev)
+{
+ struct clk_hw *hw = platform_get_drvdata(pdev);
+
+ clk_hw_unregister_composite(hw);
Should we add a devm_clk_hw_register_composite() API and use it here?
That way we don't need a remove function and devm can be used
throughout.
Can do. But does adding a devm_ function qualify for the -stable branch?
Or should I expect to have exactly this patch as a backport there then?
-michael
[PATCH] sched/deadline: Fix priority inheritance with multiple scheduling classes
Glenn reported that "an application [he developed produces] a BUG in
deadline.c when a SCHED_DEADLINE task contends with CFS tasks on nested
PTHREAD_PRIO_INHERIT mutexes. I believe the bug is triggered when a CFS
task that was boosted by a SCHED_DEADLINE task boosts another CFS task
(nested priority inheritance).
[ cut here ]
kernel BUG at kernel/sched/deadline.c:1462!
invalid opcode: [#1] PREEMPT SMP
CPU: 12 PID: 19171 Comm: dl_boost_bug Tainted: ...
Hardware name: ...
RIP: 0010:enqueue_task_dl+0x335/0x910
Code: ...
RSP: 0018:c9000c2bbc68 EFLAGS: 00010002
RAX: 0009 RBX: 888c0af94c00 RCX: 81e12500
RDX: 002e RSI: 888c0af94c00 RDI: 888c10b22600
RBP: c9000c2bbd08 R08: 0009 R09: 0078
R10: 81e12440 R11: 81e1236c R12: 888bc8932600
R13: 888c0af94eb8 R14: 888c10b22600 R15: 888bc8932600
FS: 7fa58ac55700() GS:888c10b0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7fa58b523230 CR3: 000bf44ab003 CR4: 007606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
PKRU: 5554
Call Trace:
? intel_pstate_update_util_hwp+0x13/0x170
rt_mutex_setprio+0x1cc/0x4b0
task_blocks_on_rt_mutex+0x225/0x260
rt_spin_lock_slowlock_locked+0xab/0x2d0
rt_spin_lock_slowlock+0x50/0x80
hrtimer_grab_expiry_lock+0x20/0x30
hrtimer_cancel+0x13/0x30
do_nanosleep+0xa0/0x150
hrtimer_nanosleep+0xe1/0x230
? __hrtimer_init_sleeper+0x60/0x60
__x64_sys_nanosleep+0x8d/0xa0
do_syscall_64+0x4a/0x100
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7fa58b52330d
...
---[ end trace 0002 ]—
He also provided a simple reproducer creating the situation below:
So the execution order of locking steps are the following
(N1 and N2 are non-deadline tasks. D1 is a deadline task. M1 and M2
are mutexes that are enabled * with priority inheritance.)
Time moves forward as this timeline goes down:
N1 N2 D1
| ||
| ||
Lock(M1)||
| ||
| Lock(M2) |
| ||
| | Lock(M2)
| ||
| Lock(M1) |
| (!!bug triggered!) |
Daniel reported a similar situation as well, by just letting ksoftirqd
run with DEADLINE (and eventually block on a mutex).
Problem is that boosted entities (Priority Inheritance) use static
DEADLINE parameters of the top priority waiter. However, there might be
cases where top waiter could be a non-DEADLINE entity that is currently
boosted by a DEADLINE entity from a different lock chain (i.e., nested
priority chains involving entities of non-DEADLINE classes). In this
case, top waiter static DEADLINE parameters could be null (initialized
to 0 at fork()) and replenish_dl_entity() would hit a BUG().
Fix this by keeping track of the original donor and using its parameters
when a task is boosted.
Reported-by: Glenn Elliott
Reported-by: Daniel Bristot de Oliveira
Signed-off-by: Juri Lelli
---
This is actually a v2 attempt (didn't keep $SUBJECT since it's quite
different than v1 [1]) to fix this problem.
v1 was admittedly pretty ugly. Hope this looks slightly better (even
though there is of course overhead associated to the additional
pointer).
Again, the proper way to fix this is by proxy execution. But, I don't
think we are yet there and this problem needs a quick band-aid.
One could probably also think to complicate the present approach and
actually perform accounting using donor's dynamic parameters, but I fear
it would be of little benefit since it would still bring all the
problems associated to affinities. So, I'd propose let's try to fix all
this properly with proxy and just avoid crashes in the meantime.
1 - 20191112075056.19971-1-juri.le...@redhat.com
---
include/linux/sched.h | 9 +
kernel/sched/core.c | 13 ++--
kernel/sched/deadline.c | 74 -
3 files changed, 56 insertions(+), 40 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 063cd120b459..db29ab492181 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -571,6 +571,15 @@ struct sched_dl_entity {
* time.
*/
struct hrtimer inactive_timer;
+
+#ifdef CONFIG_RT_MUTEXES
+ /*
+* Priority Inheritance. When a DEADLINE scheduling entity is boosted
+* pi_se points to the donor, otherwise points to the dl_se it belongs
+* to (the original one/itself).
+*/
+ struct sched_dl_entity *pi_se;
+#endif
};
#ifdef CONFIG_UCLAMP_TASK
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index
Re: Kernel 5.10-rc1 not mounting NAND flash (Bisected to d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits"))
Hi Christophe,
Christophe Leroy wrote on Wed, 4 Nov 2020
19:37:57 +0100:
> Hi Miquel,
>
> Le 04/11/2020 à 18:38, Miquel Raynal a écrit :
> > Hi Christophe,
> >
> > Christophe Leroy wrote on Wed, 04 Nov
> > 2020 18:33:53 +0100:
> >
> >> Hi Miquel,
> >>
> >> I'm unable to boot 5.10-rc1 on my boards. I get the following error:
> >>
> >> [4.125811] nand: device found, Manufacturer ID: 0xad, Chip ID: 0x76
> >> [4.131992] nand: Hynix NAND 64MiB 3,3V 8-bit
> >> [4.136173] nand: 64 MiB, SLC, erase size: 16 KiB, page size: 512, OOB
> >> size: 16
> >> [4.143534] [ cut here ]
> >> [4.147934] Unsupported ECC algorithm!
> >> [4.152142] WARNING: CPU: 0 PID: 1 at
> >> drivers/mtd/nand/raw/nand_base.c:5244 nand_scan_with_ids+0x1260/0x1640
> >> ...
> >> [4.332052] ---[ end trace e3a36f62cae4ac56 ]---
> >> [4.336882] gpio-nand: probe of c000.nand failed with error -22
> >>
> >> Bisected to commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework user
> >> input parsing bits")
> >>
> >> My first impression is that with that change, the value set in
> >> chip->ecc.algo
> >> by gpio_nand_probe() in drivers/mtd/nand/raw/gpio.c gets overwritten in
> >> rawnand_dt_init()
> >>
> >> The following change fixes the problem, though I'm not sure it is the
> >> right fix. Can you have a look ?
> >>
> >> diff --git a/drivers/mtd/nand/raw/nand_base.c
> >> b/drivers/mtd/nand/raw/nand_base.c
> >> index 1f0d542d5923..aa74797cf2da 100644
> >> --- a/drivers/mtd/nand/raw/nand_base.c
> >> +++ b/drivers/mtd/nand/raw/nand_base.c
> >> @@ -5032,7 +5032,8 @@ static int rawnand_dt_init(struct nand_chip *chip)
> >>chip->ecc.engine_type = nand->ecc.defaults.engine_type;
> >>
> >>chip->ecc.placement = nand->ecc.user_conf.placement;
> >> - chip->ecc.algo = nand->ecc.user_conf.algo;
> >> + if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN)
> >> + chip->ecc.algo = nand->ecc.user_conf.algo;
> >> chip->ecc.strength = nand->ecc.user_conf.strength;
> >>chip->ecc.size = nand->ecc.user_conf.step_size;
> >>
> >> ---
> >>
> >> Thanks
> >> Christophe
> >
> > Sorry for introducing this issue, I didn't had the time to send the
> > Fixes PR yet but I think this issue has been solved already. Could
> > you please try with a recent linux-next?
> >
>
> Sorry, same problem with "Linux version 5.10.0-rc2-next-20201104"
Can you please give this patch a try, please?
---8<---
Author: Miquel Raynal
Date: Thu Nov 5 08:44:48 2020 +0100
mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()
While forcing a Hamming software ECC looks clearly wrong, let's just
fix the situation for now and move these lines to the ->attach_chip()
hook which gets executed after the user input parsing and NAND chip
discovery.
Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input
parsing bits")
Signed-off-by: Miquel Raynal
diff --git a/drivers/mtd/nand/raw/gpio.c b/drivers/mtd/nand/raw/gpio.c
index 3bd847ccc3f3..6feab847f5e0 100644
--- a/drivers/mtd/nand/raw/gpio.c
+++ b/drivers/mtd/nand/raw/gpio.c
@@ -161,8 +161,15 @@ static int gpio_nand_exec_op(struct nand_chip *chip,
return ret;
}
+static int gpio_nand_attach_chip(struct nand_chip *chip)
+{
+ chip->ecc.mode = NAND_ECC_SOFT;
+ chip->ecc.algo = NAND_ECC_HAMMING;
+}
+
static const struct nand_controller_ops gpio_nand_ops = {
.exec_op = gpio_nand_exec_op,
+ .attach_chip = gpio_nand_attach_chip,
};
#ifdef CONFIG_OF
@@ -342,8 +349,6 @@ static int gpio_nand_probe(struct platform_device *pdev)
gpiomtd->base.ops = _nand_ops;
nand_set_flash_node(chip, pdev->dev.of_node);
- chip->ecc.mode = NAND_ECC_SOFT;
- chip->ecc.algo = NAND_ECC_HAMMING;
chip->options = gpiomtd->plat.options;
chip->controller= >base;
Re: [PATCH mlx5-next v1 06/11] vdpa/mlx5: Connect mlx5_vdpa to auxiliary bus
On Wed, Nov 4, 2020 at 11:32 PM gregkh wrote:
>
> On Wed, Nov 04, 2020 at 03:21:23PM -0800, Dan Williams wrote:
> > On Tue, Nov 3, 2020 at 7:45 AM Jason Gunthorpe wrote:
> > [..]
> > > > +MODULE_DEVICE_TABLE(auxiliary, mlx5v_id_table);
> > > > +
> > > > +static struct auxiliary_driver mlx5v_driver = {
> > > > + .name = "vnet",
> > > > + .probe = mlx5v_probe,
> > > > + .remove = mlx5v_remove,
> > > > + .id_table = mlx5v_id_table,
> > > > +};
> > >
> > > It is hard to see from the diff, but when this patch is applied the
> > > vdpa module looks like I imagined things would look with the auxiliary
> > > bus. It is very similar in structure to a PCI driver with the probe()
> > > function cleanly registering with its subsystem. This is what I'd like
> > > to see from the new Intel RDMA driver.
> > >
> > > Greg, I think this patch is the best clean usage example.
> > >
> > > I've looked over this series and it has the right idea and
> > > parts. There is definitely more that can be done to improve mlx5 in
> > > this area, but this series is well scoped and cleans a good part of
> > > it.
> >
> > Greg?
> >
> > I know you alluded to going your own way if the auxiliary bus patches
> > did not shape up soon, but it seems they have and the stakeholders
> > have reached this consensus point.
> >
> > Were there any additional changes you wanted to see happen? I'll go
> > give the final set another once over, but David has been diligently
> > fixing up all the declared major issues so I expect to find at most
> > minor incremental fixups.
>
> This is in my to-review pile, along with a load of other stuff at the
> moment:
> $ ~/bin/mdfrm -c ~/mail/todo/
> 1709 messages in /home/gregkh/mail/todo/
>
> So give me a chance. There is no rush on my side for this given the
> huge delays that have happened here on the authorship side many times in
> the past :)
Sure, I was more looking to confirm that it's worth continuing to
polish this set given your mention of possibly going a different
direction.
> If you can review it, or anyone else, that is always most appreciated.
Thanks, will do.
Re: [PATCH v3 5/6] i2c: iproc: handle master read request
On Wed, 4 Nov 2020 10:01:06 -0800, Ray Jui wrote: +#define MAX_SLAVE_RX_PER_INT 10 >>> In patch [3/6], you've enabled IS_S_RX_THLD_SHIFT in slave ISR bitmask, however it's not actually used in processing rx events. Instead of hardcoding this threshold here, it's better to add a device-tree knob for rx threshold, program it in controller and handle that RX_THLD interrupt. This will give more flexibility to drain the rx fifo earlier than - (1) waiting for FIFO_FULL interrupt for transactions > 64B. (2) waiting for start of read transaction in case of master write-read. >> >> Yes this is one way to implement. >> But do you see any issue in batching 64 bytes at a time in case of >> transaction > 64 Bytes. >> I feel batching will be more efficient as it avoids more number of >> interrupts and hence context switch. >> >>> >>> The Device Tree is really intended to describe the hardware FIFO size, >>> not watermarks, as those tend to be more of a policy/work load decision. >>> Maybe this is something that can be added as a module parameter, or >>> configurable via ioctl() at some point. >> > >Yes, DT can have properties to describe the FIFO size, if there happens >to be some variants in the HW blocks in different versions. But that is >not the case here. DT should not be used to control SW/use case specific >behavior. So the suggestion was to set HW threshold for rx fifo interrupt, not really a SW property. By setting it in DT, makes it easier to customize for target system, module param needs or ioctl makes it dependent on userpsace to configure it. The need for tasklet seems to arise from the fact that many bytes are left in the fifo. If there's a common problem here, such tasklet would be needed in i2c subsys rather than controller specific tweak, akin to how networking uses NAPI or adding block transactions to the interface? For master write-read event, it seems both IS_S_RD_EVENT_SHIFT and IS_S_RX_EVENT_SHIFT are detected, which implies that core is late to drain rx fifo i.e. write is complete and the read has started on the bus? Thanks, Dhananjay
Re: linux-next: build warning after merge of the akpm-current tree
SNIPPED > > > > Looks like left column became too wide, so rather than shift the right > > column to the right, I'd suggest to drop underscores in Speculation*. > > Hm. That makes it inconsistent with Speculation_Store_Bypass. I guess > it's the lesser of two evils. Oh, do you mean renaming the existing Speculation_Store_Bypass? I thought that was a big no-no for the kernel?
Re: linux-next: build warning after merge of the akpm-current tree
On Thu, 5 Nov 2020 at 18:03, Mike Rapoport wrote:
>
> On Thu, Nov 05, 2020 at 05:45:49PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (htmldocs)
> > produced this warning:
> >
> > Documentation/filesystems/proc.rst:296: WARNING: Malformed table.
> > Text in column margin in table line 61.
> >
> > ==
> > ===
> > Field Content
> > ==
> > ===
> ...
> > Speculation_Store_Bypassspeculative store bypass mitigation status
> > Speculation_Indirect_Branch indirect branch speculation mode
> ...
> > ==
> > ===
> > Documentation/filesystems/proc.rst:234: WARNING: Error parsing content
> > block for the "table" directive: exactly one table expected.
>
> Looks like left column became too wide, so rather than shift the right
> column to the right, I'd suggest to drop underscores in Speculation*.
Hm. That makes it inconsistent with Speculation_Store_Bypass. I guess
it's the lesser of two evils.
How would I go about fixing this? Send a new (v2), fixed patch to the
mailing list? I'm not that familiar with how patches get merged
through the branches.
>
> >
> > .. table:: Table 1-2: Contents of the status files (as of 4.19)
> >
> > ==
> > ===
> > Field Content
> > ==
> > ===
>...
> > Speculation_Store_Bypassspeculative store bypass mitigation status
> > Speculation_Indirect_Branch indirect branch speculation mode
> > Cpus_allowedmask of CPUs on which this process may run
> > Cpus_allowed_list Same as previous, but in "list format"
> > Mems_allowedmask of memory nodes allowed to this process
> > Mems_allowed_list Same as previous, but in "list format"
> > voluntary_ctxt_switches number of voluntary context switches
> > nonvoluntary_ctxt_switches number of non voluntary context switches
> > ==
> > ===
>
> Same here.
>
> > Introduced by commit
> >
> > 60b492d745d5 ("proc: provide details on indirect branch speculation")
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
>
>
> --
> Sincerely yours,
> Mike.
--
Anand K. Mistry
Software Engineer
Google Australia
Re: Very slow realtek 8169 ethernet performance, but only one interface, on ThinkPad T14.
On 2020/11/5 下午3:01, Heiner Kallweit wrote: > On 05.11.2020 03:48, Qu Wenruo wrote: >> Hi, >> >> Not sure if this is a regression or not, but just find out that after >> upgrading to v5.9 kernel, one of my ethernet port on my ThinkPad T14 (ryzen >> version) becomes very slow. >> >> Only *2~3* Mbps. >> >> The laptop has two ethernet interfaces, one needs a passive adapter, the >> other one is a standard RJ45. >> >> The offending one is the one which needs the adapter (eth0). >> While the RJ45 one is completely fine. >> >> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. >> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0e) >> 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. >> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) >> >> The 02:00.0 one is the affected one. >> >> The related dmesgs are: >> [ 38.110293] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM >> control >> [ 38.126069] libphy: r8169: probed >> [ 38.126250] r8169 :02:00.0 eth0: RTL8168ep/8111ep, 00:2b:67:b3:d9:20, >> XID 502, IRQ 105 >> [ 38.126252] r8169 :02:00.0 eth0: jumbo features [frames: 9194 bytes, >> tx checksumming: ko] >> [ 38.126294] r8169 :05:00.0: can't disable ASPM; OS doesn't have ASPM >> control >> [ 38.126300] r8169 :05:00.0: enabling device ( -> 0003) >> [ 38.139355] libphy: r8169: probed >> [ 38.139523] r8169 :05:00.0 eth1: RTL8168h/8111h, 00:2b:67:b3:d9:1f, >> XID 541, IRQ 107 >> [ 38.139525] r8169 :05:00.0 eth1: jumbo features [frames: 9194 bytes, >> tx checksumming: ko] >> [ 42.120935] Generic FE-GE Realtek PHY r8169-200:00: attached PHY driver >> [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-200:00, irq=IGNORE) >> [ 42.247646] r8169 :02:00.0 eth0: Link is Down >> [ 42.280799] Generic FE-GE Realtek PHY r8169-500:00: attached PHY driver >> [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-500:00, irq=IGNORE) >> [ 42.477616] r8169 :05:00.0 eth1: Link is Down >> [ 76.479569] r8169 :02:00.0 eth0: Link is Up - 1Gbps/Full - flow >> control rx/tx >> [ 91.271894] r8169 :02:00.0 eth0: Link is Down >> [ 99.873390] r8169 :02:00.0 eth0: Link is Up - 1Gbps/Full - flow >> control rx/tx >> [ 99.878938] r8169 :02:00.0 eth0: Link is Down >> [ 102.579290] r8169 :02:00.0 eth0: Link is Up - 1Gbps/Full - flow >> control rx/tx >> [ 185.086002] r8169 :02:00.0 eth0: Link is Down >> [ 392.884584] r8169 :02:00.0 eth0: Link is Up - 1Gbps/Full - flow >> control rx/tx >> [ 392.891208] r8169 :02:00.0 eth0: Link is Down >> [ 395.889047] r8169 :02:00.0 eth0: Link is Up - 1Gbps/Full - flow >> control rx/tx >> [ 406.670738] r8169 :02:00.0 eth0: Link is Down >> >> Really nothing strange, even it negotiates to 1Gbps. >> >> But during iperf3, it only goes up to miserable 3Mbps. >> >> Is this some known bug or something special related to the passive adapter? >> >> Since the adapter is passive, and hasn't experience anything wrong for a >> long time, I really doubt that. >> >> Thanks, >> Qu >> >> > Thanks for the report. From which kernel version did you upgrade? Tested back to v5.7, which still shows the miserable performance. So I guess it could be a faulty adapter? > Please test > with the prior kernel version and report behavior (link stability and speed). > Under 5.9, does ethtool -S eth0 report packet errors? > Nope, no tx/rx_errors, no missed/aborted/underrun. Adding that the adapter is completely passive (no chip, just converting RJ45 pins to the I shaped pins), I'm not sure that the adapter itself can fail. THanks, Qu signature.asc Description: OpenPGP digital signature
[no subject]
Do you get my last mail
Re: [PATCH v4 2/4] mfd: Support ROHM BD9576MUF and BD9573MUF
On Thu, 2020-11-05 at 08:46 +0200, Matti Vaittinen wrote:
> Morning Lee,
>
> Thanks for taking a look at this :) I see most of the comments being
> valid. There's two I would like to clarify though...
>
> On Wed, 2020-11-04 at 15:51 +, Lee Jones wrote:
> > On Wed, 28 Oct 2020, Matti Vaittinen wrote:
> >
> > > Add core support for ROHM BD9576MUF and BD9573MUF PMICs which are
> > > mainly used to power the R-Car series processors.
> > >
> > > Signed-off-by: Matti Vaittinen > > >
> > > ---
> > > + unsigned int chip_type;
> > > +
> > > + chip_type = (unsigned int)(uintptr_t)
> > > + of_device_get_match_data(>dev);
> >
> > Not overly keen on this casting.
> >
> > Why not just leave it as (uintptr_t)?
>
> I didn't do so because on x86_64 the address width is probably 64
> bits
> whereas the unsigned int is likely to be 32 bits. So the assignment
> will crop half of the value. It does not really matter as values are
> small - but I would be surprized if no compilers/analyzers emitted a
> warning.
>
> I must admit I am not 100% sure though. I sure can change this if you
> know it better?
>
> > What happens when you don't cast to (uintptr_t) first?
>
> On some systems at least the gcc will warn:
> > warning: cast from pointer to integer of different size [-Wpointer-
> to-int-cast]
>
> I am pretty sure I did end up this double casting via trial and error
> :)
> +
> > > +static const struct of_device_id bd957x_of_match[] = {
> > > + {
> > > + .compatible = "rohm,bd9576",
> > > + .data = (void *)ROHM_CHIP_TYPE_BD9576,
> > > + },
> > > + {
> >
> > You could put the 2 lines above on a single line.
>
> Braces? I put braces on separate lines on purpose. Been doing this
> after we had this discussion:
>
> https://lore.kernel.org/lkml/20180705055226.GJ496@dell/
> https://lore.kernel.org/lkml/20180706070559.GW496@dell/
>
> ;)
>
> I can change it if you wishfeel it is important - not a point I feel
> like fighting over ;)
>
Ah. I guess you meant:
static const struct of_device_id bd957x_of_match[] = {
{ .compatible = "rohm,bd9576", .data = (void *)ROHM_CHIP_TYPE_BD9576, },
{ .compatible = "rohm,bd9573", .data = (void *)ROHM_CHIP_TYPE_BD9573, },
{},
};
Feeling "little bit" stupid... :rolleyes:
> > > + .compatible = "rohm,bd9573",
> > > + .data = (void *)ROHM_CHIP_TYPE_BD9573,
> > > + },
> > > + { },
> > > +};
> > > +MODULE_DEVICE_TABLE(of, bd957x_of_match);
>
> Best Regards
> Matti
>
> --
> Matti Vaittinen, Linux device drivers
> ROHM Semiconductors, Finland
> SWDC
> Kiviharjunlenkki 1E
> 90220 OULU
> FINLAND
>
> ~~~ "I don't think so," said Rene Descartes. Just then he vanished
> ~~~
>
> Simon says - in Latin please.
> "non cogito me" dixit Rene Descarte, deinde evanescavit
>
> (Thanks for the translation Simon)
>
Re: [PATCH 34/36] tty: serial: pmac_zilog: Make disposable variable __always_unused
On 05. 11. 20, 8:04, Christophe Leroy wrote:
Le 04/11/2020 à 20:35, Lee Jones a écrit :
Fixes the following W=1 kernel build warning(s):
drivers/tty/serial/pmac_zilog.h:365:58: warning: variable ‘garbage’
set but not used [-Wunused-but-set-variable]
Explain how you are fixing this warning.
Setting __always_unused is usually not the good solution for fixing
this warning, but here I guess this is likely the good solution. But it
should be explained why.
Or, why is the "garbage =" needed in the first place? read_zsdata is not
defined with __warn_unused_result__. And even if it was, would
(void)!read_zsdata(port) fix it?
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linux-ser...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: Lee Jones
---
drivers/tty/serial/pmac_zilog.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/pmac_zilog.h
b/drivers/tty/serial/pmac_zilog.h
index bb874e76810e0..968aec7c1cf82 100644
--- a/drivers/tty/serial/pmac_zilog.h
+++ b/drivers/tty/serial/pmac_zilog.h
@@ -362,7 +362,7 @@ static inline void zssync(struct uart_pmac_port
*port)
/* Misc macros */
#define ZS_CLEARERR(port) (write_zsreg(port, 0, ERR_RES))
-#define ZS_CLEARFIFO(port) do { volatile unsigned char garbage; \
+#define ZS_CLEARFIFO(port) do { volatile unsigned char
__always_unused garbage; \
garbage = read_zsdata(port); \
garbage = read_zsdata(port); \
garbage = read_zsdata(port); \
thanks,
--
js
[PATCH] pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback
When GPIOs that are routed to PDC are used as output they can still latch
the IRQ pending at GIC. As a result the spurious IRQ was handled when the
client driver change the direction to input to starts using it as IRQ.
Currently such erroneous latched IRQ are cleared with .irq_enable callback
however if the driver continue to use GPIO as interrupt and invokes
disable_irq() followed by enable_irq() then everytime during enable_irq()
previously latched interrupt gets cleared.
This can make edge IRQs not seen after enable_irq() if they had arrived
after the driver has invoked disable_irq() and were pending at GIC.
Move clearing erroneous IRQ to .irq_request_resources callback as this is
the place where GPIO direction is changed as input and its locked as IRQ.
While at this add a missing check to invoke msm_gpio_irq_clear_unmask()
from .irq_enable callback only when GPIO is not routed to PDC.
Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy")
Signed-off-by: Maulik Shah
---
drivers/pinctrl/qcom/pinctrl-msm.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
b/drivers/pinctrl/qcom/pinctrl-msm.c
index c4bcda9..77a25bd 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -815,21 +815,14 @@ static void msm_gpio_irq_clear_unmask(struct irq_data *d,
bool status_clear)
static void msm_gpio_irq_enable(struct irq_data *d)
{
- /*
-* Clear the interrupt that may be pending before we enable
-* the line.
-* This is especially a problem with the GPIOs routed to the
-* PDC. These GPIOs are direct-connect interrupts to the GIC.
-* Disabling the interrupt line at the PDC does not prevent
-* the interrupt from being latched at the GIC. The state at
-* GIC needs to be cleared before enabling.
-*/
- if (d->parent_data) {
- irq_chip_set_parent_state(d, IRQCHIP_STATE_PENDING, 0);
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct msm_pinctrl *pctrl = gpiochip_get_data(gc);
+
+ if (d->parent_data)
irq_chip_enable_parent(d);
- }
- msm_gpio_irq_clear_unmask(d, true);
+ if (!test_bit(d->hwirq, pctrl->skip_wake_irqs))
+ msm_gpio_irq_clear_unmask(d, true);
}
static void msm_gpio_irq_disable(struct irq_data *d)
@@ -1104,6 +1097,19 @@ static int msm_gpio_irq_reqres(struct irq_data *d)
ret = -EINVAL;
goto out;
}
+
+ /*
+* Clear the interrupt that may be pending before we enable
+* the line.
+* This is especially a problem with the GPIOs routed to the
+* PDC. These GPIOs are direct-connect interrupts to the GIC.
+* Disabling the interrupt line at the PDC does not prevent
+* the interrupt from being latched at the GIC. The state at
+* GIC needs to be cleared before enabling.
+*/
+ if (d->parent_data && test_bit(d->hwirq, pctrl->skip_wake_irqs))
+ irq_chip_set_parent_state(d, IRQCHIP_STATE_PENDING, 0);
+
return 0;
out:
module_put(gc->owner);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v5 06/17] virt: acrn: Introduce VM management interfaces
On Thu 5.Nov'20 at 7:29:07 +0100, Greg Kroah-Hartman wrote:
On Thu, Nov 05, 2020 at 11:10:29AM +0800, Shuo A Liu wrote:
On Wed 4.Nov'20 at 20:02:35 +0100, Greg Kroah-Hartman wrote:
> On Mon, Oct 19, 2020 at 02:17:52PM +0800, shuo.a@intel.com wrote:
> > --- /dev/null
> > +++ b/include/uapi/linux/acrn.h
> > @@ -0,0 +1,56 @@
> > +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > +/*
> > + * Userspace interface for /dev/acrn_hsm - ACRN Hypervisor Service Module
> > + *
> > + * This file can be used by applications that need to communicate with the
HSM
> > + * via the ioctl interface.
> > + */
> > +
> > +#ifndef _UAPI_ACRN_H
> > +#define _UAPI_ACRN_H
> > +
> > +#include
> > +
> > +/**
> > + * struct acrn_vm_creation - Info to create a User VM
> > + * @vmid:User VM ID returned from the hypervisor
> > + * @reserved0: Reserved
> > + * @vcpu_num:Number of vCPU in the VM. Return from
hypervisor.
> > + * @reserved1: Reserved
> > + * @uuid:UUID of the VM. Pass to hypervisor directly.
> > + * @vm_flag: Flag of the VM creating. Pass to hypervisor directly.
> > + * @ioreq_buf: Service VM GPA of I/O request buffer. Pass to
> > + * hypervisor directly.
> > + * @cpu_affinity:CPU affinity of the VM. Pass to hypervisor directly.
> > + * @reserved2: Reserved
>
> Reserved and must be 0?
Not a must.
That's guaranteed to come back and bite you in the end.
OK. I can fill them with zero before passing them to hypervisor.
You all have read the "how to write a good api" document, right?
Is it Documentation/driver-api/ioctl.rst? Or i missed..
> What are they reserved for?
>
> Same for all of the reserved fields, why?
Some reserved fields are to map layout in the hypervisor side, others
are for future use.
ioctls should not have these, again, please read the documentation. If
you need something new in the future, just make a new ioctl.
OK. I will remove some reserved fields for scalability. Though i can
keep some reserved fields for alignment (and to keep same data structure
layout with the hypervisor), right?
Documentation/driver-api/ioctl.rst says that explicit reserved fields
could be used.
> > + */
> > +struct acrn_vm_creation {
> > + __u16 vmid;
> > + __u16 reserved0;
> > + __u16 vcpu_num;
> > + __u16 reserved1;
> > + __u8uuid[16];
>
> We have a userspace-visable uid structure in include/uapi/uuid.h, why
> not use that?
we just pass the uuid data from user space to hypervisor. So, we can
remove a header dependeny with using raw data format.
I do not understand this, please use the built-in kernel types we have.
OK. I will use that.
Thanks
shuo
[PATCH net-next] net: x25_asy: Delete the x25_asy driver
This driver transports LAPB (X.25 link layer) frames over TTY links.
I can safely say that this driver has no actual user because it was
not working at all until:
commit 8fdcabeac398 ("drivers/net/wan/x25_asy: Fix to make it work")
The code in its current state still has problems:
1.
The uses of "struct x25_asy" in x25_asy_unesc (when receiving) and in
x25_asy_write_wakeup (when sending) are not protected by locks against
x25_asy_change_mtu's changing of the transmitting/receiving buffers.
Also, all "netif_running" checks in this driver are not protected by
locks against the ndo_stop function.
2.
The driver stops all TTY read/write when the netif is down.
I think this is not right because this may cause the last outgoing frame
before the netif goes down to be incompletely transmitted, and the first
incoming frame after the netif goes up to be incompletely received.
And there may also be other problems.
I was planning to fix these problems but after recent discussions about
deleting other old networking code, I think we may just delete this
driver, too.
Signed-off-by: Xie He
---
Documentation/process/magic-number.rst| 1 -
.../it_IT/process/magic-number.rst| 1 -
.../zh_CN/process/magic-number.rst| 1 -
arch/mips/configs/gpr_defconfig | 1 -
arch/mips/configs/mtx1_defconfig | 1 -
drivers/net/wan/Kconfig | 15 -
drivers/net/wan/Makefile | 1 -
drivers/net/wan/x25_asy.c | 836 --
drivers/net/wan/x25_asy.h | 46 -
9 files changed, 903 deletions(-)
delete mode 100644 drivers/net/wan/x25_asy.c
delete mode 100644 drivers/net/wan/x25_asy.h
diff --git a/Documentation/process/magic-number.rst
b/Documentation/process/magic-number.rst
index eee9b44553b3..e02ff5ffb653 100644
--- a/Documentation/process/magic-number.rst
+++ b/Documentation/process/magic-number.rst
@@ -84,7 +84,6 @@ PPP_MAGIC 0x5002 ppp
``include/linux/
SSTATE_MAGIC 0x5302 serial_state
``include/linux/serial.h``
SLIP_MAGIC0x5302 slip
``drivers/net/slip.h``
STRIP_MAGIC 0x5303 strip
``drivers/net/strip.c``
-X25_ASY_MAGIC 0x5303 x25_asy
``drivers/net/x25_asy.h``
SIXPACK_MAGIC 0x5304 sixpack
``drivers/net/hamradio/6pack.h``
AX25_MAGIC0x5316 ax_disp
``drivers/net/mkiss.h``
TTY_MAGIC 0x5401 tty_struct
``include/linux/tty.h``
diff --git a/Documentation/translations/it_IT/process/magic-number.rst
b/Documentation/translations/it_IT/process/magic-number.rst
index 783e0de314a0..0243d32a0b59 100644
--- a/Documentation/translations/it_IT/process/magic-number.rst
+++ b/Documentation/translations/it_IT/process/magic-number.rst
@@ -90,7 +90,6 @@ PPP_MAGIC 0x5002 ppp
``include/linux/
SSTATE_MAGIC 0x5302 serial_state
``include/linux/serial.h``
SLIP_MAGIC0x5302 slip
``drivers/net/slip.h``
STRIP_MAGIC 0x5303 strip
``drivers/net/strip.c``
-X25_ASY_MAGIC 0x5303 x25_asy
``drivers/net/x25_asy.h``
SIXPACK_MAGIC 0x5304 sixpack
``drivers/net/hamradio/6pack.h``
AX25_MAGIC0x5316 ax_disp
``drivers/net/mkiss.h``
TTY_MAGIC 0x5401 tty_struct
``include/linux/tty.h``
diff --git a/Documentation/translations/zh_CN/process/magic-number.rst
b/Documentation/translations/zh_CN/process/magic-number.rst
index e4c225996af0..de182bf4191c 100644
--- a/Documentation/translations/zh_CN/process/magic-number.rst
+++ b/Documentation/translations/zh_CN/process/magic-number.rst
@@ -73,7 +73,6 @@ PPP_MAGIC 0x5002 ppp
``include/linux/
SSTATE_MAGIC 0x5302 serial_state
``include/linux/serial.h``
SLIP_MAGIC0x5302 slip
``drivers/net/slip.h``
STRIP_MAGIC 0x5303 strip
``drivers/net/strip.c``
-X25_ASY_MAGIC 0x5303 x25_asy
``drivers/net/x25_asy.h``
SIXPACK_MAGIC 0x5304 sixpack
``drivers/net/hamradio/6pack.h``
AX25_MAGIC0x5316 ax_disp
``drivers/net/mkiss.h``
TTY_MAGIC 0x5401 tty_struct
``include/linux/tty.h``
diff --git a/arch/mips/configs/gpr_defconfig b/arch/mips/configs/gpr_defconfig
index 9085f4d6c698..599d5604aabe 100644
--- a/arch/mips/configs/gpr_defconfig
+++ b/arch/mips/configs/gpr_defconfig
@@
Re: [PATCH mlx5-next v1 06/11] vdpa/mlx5: Connect mlx5_vdpa to auxiliary bus
On Wed, Nov 04, 2020 at 03:21:23PM -0800, Dan Williams wrote:
> On Tue, Nov 3, 2020 at 7:45 AM Jason Gunthorpe wrote:
> [..]
> > > +MODULE_DEVICE_TABLE(auxiliary, mlx5v_id_table);
> > > +
> > > +static struct auxiliary_driver mlx5v_driver = {
> > > + .name = "vnet",
> > > + .probe = mlx5v_probe,
> > > + .remove = mlx5v_remove,
> > > + .id_table = mlx5v_id_table,
> > > +};
> >
> > It is hard to see from the diff, but when this patch is applied the
> > vdpa module looks like I imagined things would look with the auxiliary
> > bus. It is very similar in structure to a PCI driver with the probe()
> > function cleanly registering with its subsystem. This is what I'd like
> > to see from the new Intel RDMA driver.
> >
> > Greg, I think this patch is the best clean usage example.
> >
> > I've looked over this series and it has the right idea and
> > parts. There is definitely more that can be done to improve mlx5 in
> > this area, but this series is well scoped and cleans a good part of
> > it.
>
> Greg?
>
> I know you alluded to going your own way if the auxiliary bus patches
> did not shape up soon, but it seems they have and the stakeholders
> have reached this consensus point.
>
> Were there any additional changes you wanted to see happen? I'll go
> give the final set another once over, but David has been diligently
> fixing up all the declared major issues so I expect to find at most
> minor incremental fixups.
This is in my to-review pile, along with a load of other stuff at the
moment:
$ ~/bin/mdfrm -c ~/mail/todo/
1709 messages in /home/gregkh/mail/todo/
So give me a chance. There is no rush on my side for this given the
huge delays that have happened here on the authorship side many times in
the past :)
If you can review it, or anyone else, that is always most appreciated.
thanks,
greg k-h
Re: [PATCH 2/4] arm64: dts: ti: k3-j721e*: Cleanup disabled nodes at SoC dtsi level
Nishanth,
On 05/11/2020 0.43, Nishanth Menon wrote:
> The device tree standard sets the default node behavior when status
> property as enabled.
It should be:
When the status property is not present under a node, the "okay' value
is assumed.
Note: the device tree specification does not document default value as
such, see v0.3 (2.3.4, page 14).
Yes, the "okay" is used in case the status property is missing (by Linux
at least).
> There are many reasons for doing the same, number
> of strings in device tree,
with expense of loc and readability.
> default power management functionality etc
Right, so how does that helps with devices present in the SoC, but no
node at all? First thing which comes to mind is AASRC, we don't have
Linux driver for it (and no DT binding document), but that does not mean
that it is not present. How PM would take that into account?
> are few of the reasons.
>
> In general, after a few rounds of discussions [1] there are few
> options one could take when dealing with SoC dtsi and board dts
>
> a. SoC dtsi provide nodes as a super-set default (aka enabled) state and
>to prevent messy board files, when more boards are added per SoC, we
>optimize and disable commonly un-used nodes in board-common.dtsi
> b. SoC dtsi disables all hardware dependent nodes by default and board
>dts files enable nodes based on a need basis.
> c. Subjectively pick and choose which nodes we will disable by default
>in SoC dtsi and over the years we can optimize things and change
>default state depending on the need.
For the record: c was not really an option. There were no subjectivity,
the reason was pragmatic.
We are all familiar with the Devicetree specification, but let me quote
from chapter 2.3.4:
"okay"
Indicates the device is operational.
"disabled"
Indicates that the device is not presently operational, but it might
become operational in the future (for example, something is not plugged
in, or switched off).
Refer to the device binding for details on what disabled means for a
given device.
The reason why we kept McASP nodes (and dss) disabled in the soc dtsi
file is that they are not operation in the form they present in there.
They _need_ additional properties to be operational and those properties
can only be added in the board dts file.
This is not remotely a subjective view, this is the opposite of
subjectivity.
As for things not owned by the OS we have the "reserved" status.
> While there are pros and cons on each of these approaches, the right
> thing to do will be to stick with device tree default standards and
> work within those established rules. So, we choose to go with option
> (a).
>
> Lets cleanup defaults of j721e SoC dtsi before this gets more harder
> to cleanup later on and new SoCs are added.
>
> The only functional difference between the dtb generated is
> status='okay' is no longer necessary for mcasp10 and depends on the
> default state.
>
> [1]
> https://lore.kernel.org/linux-arm-kernel/20201027130701.ge5...@atomide.com/
>
> Fixes: 1c4d35265fb2 ("arm64: dts: ti: k3-j721e-main: Add McASP nodes")
> Fixes: 76921f15acc0 ("arm64: dts: ti: k3-j721e-main: Add DSS node")
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: Peter Ujfalusi
> Cc: Tony Lindgren
> Signed-off-by: Nishanth Menon
> ---
> .../dts/ti/k3-j721e-common-proc-board.dts | 48 ++-
> arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 26 --
> 2 files changed, 47 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
> b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
> index 52e121155563..9416528caa8a 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
> @@ -540,6 +540,46 @@ {
><_clks 152 18>; /* PLL23_HSDIV0 */
> };
>
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> {
> #sound-dai-cells = <0>;
>
> @@ -556,8 +596,10 @@ {
> >;
> tx-num-evt = <0>;
> rx-num-evt = <0>;
> +};
>
> - status = "okay";
> + {
> + status = "disabled";
> };
Looks much better in this way.
?
I always wondered what is _not_ used by the board...
But it is not really about that, we need to disable these nodes as they
are incomplete in dtsi, they are not operational...
> {
> @@ -639,3 +681,7 @@ _rc {
> _ep {
> status = "disabled";
> };
> +
> + {
> + status = "disabled";
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
>
Re: [PATCH v4 1/2] kunit: Support for Parameterized Testing
On 28/10/20 12:51 am, Marco Elver wrote:
> On Tue, 27 Oct 2020 at 18:47, Arpitha Raghunandan <98.a...@gmail.com> wrote:
>>
>> Implementation of support for parameterized testing in KUnit.
>> This approach requires the creation of a test case using the
>> KUNIT_CASE_PARAM macro that accepts a generator function as input.
>> This generator function should return the next parameter given the
>> previous parameter in parameterized tests. It also provides
>> a macro to generate common-case generators.
>>
>> Signed-off-by: Arpitha Raghunandan <98.a...@gmail.com>
>> Co-developed-by: Marco Elver
>> Signed-off-by: Marco Elver
>> ---
>> Changes v3->v4:
>> - Rename kunit variables
>> - Rename generator function helper macro
>> - Add documentation for generator approach
>> - Display test case name in case of failure along with param index
>> Changes v2->v3:
>> - Modifictaion of generator macro and method
>> Changes v1->v2:
>> - Use of a generator method to access test case parameters
>>
>> include/kunit/test.h | 34 ++
>> lib/kunit/test.c | 21 -
>> 2 files changed, 54 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/kunit/test.h b/include/kunit/test.h
>> index 9197da792336..ec2307ee9bb0 100644
>> --- a/include/kunit/test.h
>> +++ b/include/kunit/test.h
>> @@ -107,6 +107,13 @@ struct kunit;
>> *
>> * @run_case: the function representing the actual test case.
>> * @name: the name of the test case.
>> + * @generate_params: the generator function for parameterized tests.
>> + *
>> + * The generator function is used to lazily generate a series of
>> + * arbitrarily typed values that fit into a void*. The argument @prev
>> + * is the previously returned value, which should be used to derive the
>> + * next value; @prev is set to NULL on the initial generator call.
>> + * When no more values are available, the generator must return NULL.
>> *
>
> Hmm, should this really be the first paragraph? I think it should be
> the paragraph before "Example:" maybe. But then that paragraph should
> refer to generate_params e.g. "The generator function @generate_params
> is used to ".
>
> The other option you have is to move this paragraph to the kernel-doc
> comment for KUNIT_CASE_PARAM, which seems to be missing a kernel-doc
> comment.
>
>> * A test case is a function with the signature,
>> * ``void (*)(struct kunit *)``
>> @@ -141,6 +148,7 @@ struct kunit;
>> struct kunit_case {
>> void (*run_case)(struct kunit *test);
>> const char *name;
>> + void* (*generate_params)(void *prev);
>>
>> /* private: internal use only. */
>> bool success;
>> @@ -162,6 +170,9 @@ static inline char *kunit_status_to_string(bool status)
>> * kunit_case for an example on how to use it.
>> */
>> #define KUNIT_CASE(test_name) { .run_case = test_name, .name = #test_name }
>
> I.e. create a new kernel-doc comment for KUNIT_CASE_PARAM here, and
> simply move the paragraph describing the generator protocol into that
> comment.
>
>> +#define KUNIT_CASE_PARAM(test_name, gen_params)\
>> + { .run_case = test_name, .name = #test_name,\
>> + .generate_params = gen_params }
>>
>> /**
>> * struct kunit_suite - describes a related collection of kunit_case
>> @@ -208,6 +219,15 @@ struct kunit {
>> const char *name; /* Read only after initialization! */
>> char *log; /* Points at case log after initialization */
>> struct kunit_try_catch try_catch;
>> + /* param_value points to test case parameters in parameterized tests
>> */
>
> Hmm, not quite: param_value is the current parameter value for a test
> case. Most likely it's a pointer, but it doesn't need to be.
>
>> + void *param_value;
>> + /*
>> +* param_index stores the index of the parameter in
>> +* parameterized tests. param_index + 1 is printed
>> +* to indicate the parameter that causes the test
>> +* to fail in case of test failure.
>> +*/
>
> I think this comment needs to be reformatted, because you can use at
> the very least use 80 cols per line. (If you use vim, visual select
> and do 'gq'.)
>
>> + int param_index;
>> /*
>> * success starts as true, and may only be set to false during a
>> * test case; thus, it is safe to update this across multiple
>> @@ -1742,4 +1762,18 @@ do {
>> \
>> fmt,
>> \
>> ##__VA_ARGS__)
>>
>> +/**
>> + * KUNIT_ARRAY_PARAM() - Helper method for test parameter generators
>> + * required in parameterized tests.
>> + * @name: prefix of the name for the test parameter generator function.
>> + *It will be suffixed by "_gen_params".
>> + * @array:
[PATCH v2 1/4] dt-bindings: soc: imx8m: add DT Binding doc for soc unique ID
Add DT Binding doc for the Unique ID of i.MX 8M series. Signed-off-by: Alice Guo --- .../devicetree/bindings/arm/fsl.yaml | 33 +++ 1 file changed, 33 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index e4db0f9ed664..0419f078502b 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -901,6 +901,39 @@ properties: - fsl,s32v234-evb # S32V234-EVB2 Customer Evaluation Board - const: fsl,s32v234 + soc: +description: + i.MX8M Family SoC must provide a soc node in the root of the device tree, + representing the System-on-Chip since these test chips are rather complex. +type: object +properties: + compatible: +oneOf: + - items: + - const: fsl,imx8mm-soc + - const: simple-bus + - items: + - const: fsl,imx8mn-soc + - const: simple-bus + - items: + - const: fsl,imx8mp-soc + - const: simple-bus + - items: + - const: fsl,imx8mq-soc + - const: simple-bus + + nvmem-cells: +maxItems: 1 +description: Phandle to the SOC Unique ID provided by a nvmem node + + nvmem-cells-names: +const: soc_unique_id + +required: + - compatible + - nvmem-cells + - nvmem-cell-names + additionalProperties: true ... -- 2.17.1
Re: [PATCH v2 2/4] Kbuild: do not emit debug info for assembly with LLVM_IAS=1
On 2020-11-04, Nathan Chancellor wrote: On Tue, Nov 03, 2020 at 04:53:41PM -0800, Nick Desaulniers wrote: Clang's integrated assembler produces the warning for assembly files: warning: DWARF2 only supports one section per compilation unit If -Wa,-gdwarf-* is unspecified, then debug info is not emitted. This Is this something that should be called out somewhere? If I understand this correctly, LLVM_IAS=1 + CONFIG_DEBUG_INFO=y won't work? Maybe this should be handled in Kconfig? will be re-enabled for new DWARF versions in a follow up patch. Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with LLVM=1 LLVM_IAS=1 for x86_64 and arm64. Cc: Link: https://github.com/ClangBuiltLinux/linux/issues/716 Reported-by: Nathan Chancellor Suggested-by: Dmitry Golovin If you happen to respin, Dmitry deserves a Reported-by tag too :) Suggested-by: Sedat Dilek Signed-off-by: Nick Desaulniers Regardless of the other two comments, this is fine as is as a fix for stable to unblock Android + CrOS since we have been running something similar to it in CI: Reviewed-by: Nathan Chancellor --- Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index f353886dbf44..75b1a3dcbf30 100644 --- a/Makefile +++ b/Makefile @@ -826,7 +826,9 @@ else DEBUG_CFLAGS += -g endif +ifndef LLVM_IAS Nit: this should probably match the existing LLVM_IAS check ifneq ($(LLVM_IAS),1) KBUILD_AFLAGS += -Wa,-gdwarf-2 +endif ifdef CONFIG_DEBUG_INFO_DWARF4 DEBUG_CFLAGS += -gdwarf-4 -- 2.29.1.341.ge80a0c044ae-goog The root cause is that DWARF v2 has no DW_AT_ranges, so it cannot represent non-contiguous address ranges. It seems that GNU as -gdwarf-3 emits DW_AT_ranges as well and emits an entry for a non-executable section. In any case, the option is of very low value, at least for LLVM. Reviewed-by: Fangrui Song
[PATCH v2 2/4] arm64: dts: imx8m: add compatible string to .dtsi file
Add compatible string to .dtsi file for binding of imx8_soc_init_driver
and device.
Signed-off-by: Alice Guo
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 +-
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 033fee525982..cd9a77d763eb 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -257,7 +257,7 @@
};
soc@0 {
- compatible = "simple-bus";
+ compatible = "fsl,imx8mm-soc", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x0 0x3e00>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index a06d2a6268e6..6d3a809a00fd 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -241,7 +241,7 @@
};
soc@0 {
- compatible = "simple-bus";
+ compatible = "fsl,imx8mn-soc", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x0 0x3e00>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 479312293036..9cd218f5f004 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -218,7 +218,7 @@
};
soc@0 {
- compatible = "simple-bus";
+ compatible = "fsl,imx8mp-soc", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x0 0x3e00>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index a841a023e8e0..9b6d9307e5d7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -286,7 +286,7 @@
};
soc@0 {
- compatible = "simple-bus";
+ compatible = "fsl,imx8mq-soc", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x0 0x3e00>;
--
2.17.1
[PATCH v2 3/4] arm64: dts: imx8m: add nvmem-cell related stuff
Add nvmem-cell related stuff for the soc unique ID.
Signed-off-by: Alice Guo
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 6 ++
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 6 ++
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 6 ++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 6 ++
4 files changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index cd9a77d763eb..d4aec3eae147 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -261,6 +261,8 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x0 0x3e00>;
+ nvmem-cells = <_uid>;
+ nvmem-cell-names = "soc_unique_id";
aips1: bus@3000 {
compatible = "fsl,aips-bus", "simple-bus";
@@ -518,6 +520,10 @@
#address-cells = <1>;
#size-cells = <1>;
+ imx8mm_uid: unique_id@410 {
+ reg = <0x4 0x8>;
+ };
+
cpu_speed_grade: speed-grade@10 {
reg = <0x10 4>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 6d3a809a00fd..ff12194b60a1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -245,6 +245,8 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x0 0x3e00>;
+ nvmem-cells = <_uid>;
+ nvmem-cell-names = "soc_unique_id";
aips1: bus@3000 {
compatible = "fsl,aips-bus", "simple-bus";
@@ -388,6 +390,10 @@
#address-cells = <1>;
#size-cells = <1>;
+ imx8mn_uid: unique_id@410 {
+ reg = <0x4 0x8>;
+ };
+
cpu_speed_grade: speed-grade@10 {
reg = <0x10 4>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 9cd218f5f004..3db59f61e871 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -222,6 +222,8 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x0 0x3e00>;
+ nvmem-cells = <_uid>;
+ nvmem-cell-names = "soc_unique_id";
aips1: bus@3000 {
compatible = "fsl,aips-bus", "simple-bus";
@@ -328,6 +330,10 @@
#address-cells = <1>;
#size-cells = <1>;
+ imx8mp_uid: unique_id@420 {
+ reg = <0x8 0x8>;
+ };
+
cpu_speed_grade: speed-grade@10 {
reg = <0x10 4>;
};
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 9b6d9307e5d7..6db5cba9c07d 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -291,6 +291,8 @@
#size-cells = <1>;
ranges = <0x0 0x0 0x0 0x3e00>;
dma-ranges = <0x4000 0x0 0x4000 0xc000>;
+ nvmem-cells = <_uid>;
+ nvmem-cell-names = "soc_unique_id";
bus@3000 { /* AIPS1 */
compatible = "fsl,aips-bus", "simple-bus";
@@ -555,6 +557,10 @@
#address-cells = <1>;
#size-cells = <1>;
+ imx8mq_uid: soc_uid@410 {
+ reg = <0x4 0x8>;
+ };
+
cpu_speed_grade: speed-grade@10 {
reg = <0x10 4>;
};
--
2.17.1
[PATCH] applesmc: Re-work SMC comms v2
Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()") introduced
an issue whereby communication with the SMC became unreliable with write
errors like :
[ 120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[ 120.378621] applesmc: LKSB: write data fail
[ 120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[ 120.512787] applesmc: LKSB: write data fail
The original code appeared to be timing sensitive and was not reliable with
the timing changes in the aforementioned commit.
This patch re-factors the SMC communication to remove the timing
dependencies and restore function with the changes previously committed.
v2 : Address logic and coding style
Reported-by: Andreas Kemnade
Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
Signed-off-by: Brad Campbell
---
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index a18887990f4a..de890f3ec12f 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -42,6 +42,11 @@
#define APPLESMC_MAX_DATA_LENGTH 32
+/* Apple SMC status bits */
+#define SMC_STATUS_AWAITING_DATA BIT(0) /* SMC has data waiting */
+#define SMC_STATUS_IB_CLOSED BIT(1) /* Will ignore any input */
+#define SMC_STATUS_BUSY BIT(2) /* Command in progress */
+
/* wait up to 128 ms for a status change. */
#define APPLESMC_MIN_WAIT 0x0010
#define APPLESMC_RETRY_WAIT0x0100
@@ -151,65 +156,69 @@ static unsigned int key_at_index;
static struct workqueue_struct *applesmc_led_wq;
/*
- * wait_read - Wait for a byte to appear on SMC port. Callers must
- * hold applesmc_lock.
+ * Wait for specific status bits with a mask on the SMC
+ * Used before and after writes, and before reads
*/
-static int wait_read(void)
+
+static int wait_status(u8 val, u8 mask)
{
unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int us;
for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
- usleep_range(us, us * 16);
status = inb(APPLESMC_CMD_PORT);
- /* read: wait for smc to settle */
- if (status & 0x01)
+ if ((status & mask) == val)
return 0;
/* timeout: give up */
if (time_after(jiffies, end))
break;
- }
-
- pr_warn("wait_read() fail: 0x%02x\n", status);
+ usleep_range(us, us * 16);
+ }
return -EIO;
}
/*
- * send_byte - Write to SMC port, retrying when necessary. Callers
+ * send_byte_data - Write to SMC data port. Callers
* must hold applesmc_lock.
+ * Parameter skip must be true on the last write of any
+ * command or it'll time out.
*/
-static int send_byte(u8 cmd, u16 port)
+
+static int send_byte_data(u8 cmd, u16 port, bool skip)
{
- u8 status;
- int us;
- unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
+ int ret;
+ ret = wait_status(SMC_STATUS_BUSY, SMC_STATUS_BUSY |
SMC_STATUS_IB_CLOSED);
+ if (ret)
+ return ret;
outb(cmd, port);
- for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
- usleep_range(us, us * 16);
- status = inb(APPLESMC_CMD_PORT);
- /* write: wait for smc to settle */
- if (status & 0x02)
- continue;
- /* ready: cmd accepted, return */
- if (status & 0x04)
- return 0;
- /* timeout: give up */
- if (time_after(jiffies, end))
- break;
- /* busy: long wait and resend */
- udelay(APPLESMC_RETRY_WAIT);
- outb(cmd, port);
- }
+ return wait_status(skip ? 0 : SMC_STATUS_BUSY, SMC_STATUS_BUSY);
+}
- pr_warn("send_byte(0x%02x, 0x%04x) fail: 0x%02x\n", cmd, port, status);
- return -EIO;
+static int send_byte(u8 cmd, u16 port)
+{
+ return send_byte_data(cmd, port, false);
}
+/*
+ * send_command - Write a command to the SMC. Callers must hold applesmc_lock.
+ * If SMC is in undefined state, any new command write resets the state
machine.
+ */
+
static int send_command(u8 cmd)
{
- return send_byte(cmd, APPLESMC_CMD_PORT);
+ u8 status;
+ int ret;
+
+ ret = wait_status(0, SMC_STATUS_IB_CLOSED);
+ if (ret)
+ return ret;
+
+ status = inb(APPLESMC_CMD_PORT);
+
+ outb(cmd, APPLESMC_CMD_PORT);
+ return wait_status(SMC_STATUS_BUSY, SMC_STATUS_BUSY);
}
static int send_argument(const char *key)
@@ -239,7 +248,9 @@ static int read_smc(u8 cmd, const char *key, u8 *buffer, u8
len)
}
for (i = 0; i < len; i++) {
- if (wait_read()) {
+ if (wait_status(SMC_STATUS_AWAITING_DATA | SMC_STATUS_BUSY,
+ SMC_STATUS_AWAITING_DATA | SMC_STATUS_BUSY |
+
Re: [PATCH] mm/memcontrol:rewrite mem_cgroup_page_lruvec()
On Wed 04-11-20 14:38:00, Roman Gushchin wrote: > On Wed, Nov 04, 2020 at 10:25:16PM +0800, Hui Su wrote: > > mem_cgroup_page_lruvec() in memcontrol.c and > > mem_cgroup_lruvec() in memcontrol.h is very similar > > except for the param(page and memcg) which also can be > > convert to each other. > > > > So rewrite mem_cgroup_page_lruvec() with mem_cgroup_lruvec(). > > > > Signed-off-by: Hui Su > > --- > > include/linux/memcontrol.h | 18 +++-- > > mm/memcontrol.c| 40 -- > > 2 files changed, 16 insertions(+), 42 deletions(-) > > > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > > index e391e3c56de5..a586363fb766 100644 > > --- a/include/linux/memcontrol.h > > +++ b/include/linux/memcontrol.h > > @@ -457,9 +457,10 @@ mem_cgroup_nodeinfo(struct mem_cgroup *memcg, int nid) > > /** > > * mem_cgroup_lruvec - get the lru list vector for a memcg & node > > * @memcg: memcg of the wanted lruvec > > + * @pgdat: pglist_data > > * > > * Returns the lru list vector holding pages for a given @memcg & > > - * @node combination. This can be the node lruvec, if the memory > > + * @pgdat combination. This can be the node lruvec, if the memory > > * controller is disabled. > > */ > > static inline struct lruvec *mem_cgroup_lruvec(struct mem_cgroup *memcg, > > @@ -489,7 +490,20 @@ static inline struct lruvec *mem_cgroup_lruvec(struct > > mem_cgroup *memcg, > > return lruvec; > > } > > Hi Hui, > > > > > -struct lruvec *mem_cgroup_page_lruvec(struct page *, struct pglist_data *); > > +/** > > + * mem_cgroup_page_lruvec - return lruvec for isolating/putting an LRU page > > + * @page: the page > > + * @pgdat: pgdat of the page > > + * > > + * This function relies on page->mem_cgroup being stable. > > + */ > > +static inline struct lruvec *mem_cgroup_page_lruvec(struct page *page, > > + struct pglist_data *pgdat) > > Hm, do we need to pass page and pgdat? Not really because page already knows its node so pgdat can be easily taken from there. I suspect the only reason for having pgdat here is that many callers already know it and we optimize for memcg disable case. Hard to tell whether this actually matters because most of those paths are not really hot but something that would require a deeper investigation. Hint hint... Anyway, this looks like a nice simplification already. There were some attempts to do similar thing recently but they were adding nodeid as an additional argument and I really disliked those. Acked-by: Michal Hocko Thanks! -- Michal Hocko SUSE Labs
[PATCH v2 4/4] soc: imx8m: change to use platform driver
Directly reading ocotp register depends on that bootloader enables ocotp
clk, which is not always effective, so change to use nvmem API. Using
nvmem API requires to support driver defer probe and thus change
soc-imx8m.c to use platform driver.
The other reason is that directly reading ocotp register causes kexec
kernel hang because the 1st kernel running will disable unused clks
after kernel boots up, and then ocotp clk will be disabled even if
bootloader enables it. When kexec kernel, ocotp clk needs to be enabled
before reading ocotp registers, and nvmem API with platform driver
supported can accomplish this.
Signed-off-by: Alice Guo
---
drivers/soc/imx/soc-imx8m.c | 75 +
1 file changed, 42 insertions(+), 33 deletions(-)
diff --git a/drivers/soc/imx/soc-imx8m.c b/drivers/soc/imx/soc-imx8m.c
index cc57a384d74d..83f3297509be 100644
--- a/drivers/soc/imx/soc-imx8m.c
+++ b/drivers/soc/imx/soc-imx8m.c
@@ -5,6 +5,8 @@
#include
#include
+#include
+#include
#include
#include
#include
@@ -29,7 +31,7 @@
struct imx8_soc_data {
char *name;
- u32 (*soc_revision)(void);
+ u32 (*soc_revision)(struct device *dev);
};
static u64 soc_uid;
@@ -50,12 +52,15 @@ static u32 imx8mq_soc_revision_from_atf(void)
static inline u32 imx8mq_soc_revision_from_atf(void) { return 0; };
#endif
-static u32 __init imx8mq_soc_revision(void)
+static u32 __init imx8mm_soc_uid(struct device *dev);
+
+static u32 __init imx8mq_soc_revision(struct device *dev)
{
struct device_node *np;
void __iomem *ocotp_base;
u32 magic;
u32 rev;
+ int ret = 0;
np = of_find_compatible_node(NULL, NULL, "fsl,imx8mq-ocotp");
if (!np)
@@ -75,9 +80,9 @@ static u32 __init imx8mq_soc_revision(void)
rev = REV_B1;
}
- soc_uid = readl_relaxed(ocotp_base + OCOTP_UID_HIGH);
- soc_uid <<= 32;
- soc_uid |= readl_relaxed(ocotp_base + OCOTP_UID_LOW);
+ ret = imx8mm_soc_uid(dev);
+ if (ret)
+ return ret;
iounmap(ocotp_base);
of_node_put(np);
@@ -85,33 +90,20 @@ static u32 __init imx8mq_soc_revision(void)
return rev;
}
-static void __init imx8mm_soc_uid(void)
+static u32 __init imx8mm_soc_uid(struct device *dev)
{
- void __iomem *ocotp_base;
- struct device_node *np;
- u32 offset = of_machine_is_compatible("fsl,imx8mp") ?
-IMX8MP_OCOTP_UID_OFFSET : 0;
-
- np = of_find_compatible_node(NULL, NULL, "fsl,imx8mm-ocotp");
- if (!np)
- return;
-
- ocotp_base = of_iomap(np, 0);
- WARN_ON(!ocotp_base);
-
- soc_uid = readl_relaxed(ocotp_base + OCOTP_UID_HIGH + offset);
- soc_uid <<= 32;
- soc_uid |= readl_relaxed(ocotp_base + OCOTP_UID_LOW + offset);
+ int ret = 0;
- iounmap(ocotp_base);
- of_node_put(np);
+ ret = nvmem_cell_read_u64(dev, "soc_unique_id", _uid);
+ return ret;
}
-static u32 __init imx8mm_soc_revision(void)
+static u32 __init imx8mm_soc_revision(struct device *dev)
{
struct device_node *np;
void __iomem *anatop_base;
u32 rev;
+ int ret;
np = of_find_compatible_node(NULL, NULL, "fsl,imx8mm-anatop");
if (!np)
@@ -125,7 +117,9 @@ static u32 __init imx8mm_soc_revision(void)
iounmap(anatop_base);
of_node_put(np);
- imx8mm_soc_uid();
+ ret = imx8mm_soc_uid(dev);
+ if (ret)
+ return ret;
return rev;
}
@@ -151,19 +145,20 @@ static const struct imx8_soc_data imx8mp_soc_data = {
};
static __maybe_unused const struct of_device_id imx8_soc_match[] = {
- { .compatible = "fsl,imx8mq", .data = _soc_data, },
- { .compatible = "fsl,imx8mm", .data = _soc_data, },
- { .compatible = "fsl,imx8mn", .data = _soc_data, },
- { .compatible = "fsl,imx8mp", .data = _soc_data, },
+ { .compatible = "fsl,imx8mq-soc", .data = _soc_data, },
+ { .compatible = "fsl,imx8mm-soc", .data = _soc_data, },
+ { .compatible = "fsl,imx8mn-soc", .data = _soc_data, },
+ { .compatible = "fsl,imx8mp-soc", .data = _soc_data, },
{ }
};
+MODULE_DEVICE_TABLE(of, imx8_soc_match);
#define imx8_revision(soc_rev) \
soc_rev ? \
kasprintf(GFP_KERNEL, "%d.%d", (soc_rev >> 4) & 0xf, soc_rev & 0xf) : \
"unknown"
-static int __init imx8_soc_init(void)
+static int imx8_soc_init_probe(struct platform_device *pdev)
{
struct soc_device_attribute *soc_dev_attr;
struct soc_device *soc_dev;
@@ -182,7 +177,7 @@ static int __init imx8_soc_init(void)
if (ret)
goto free_soc;
- id = of_match_node(imx8_soc_match, of_root);
+ id = of_match_node(imx8_soc_match, pdev->dev.of_node);
if (!id) {
ret = -ENODEV;
goto free_soc;
@@ -192,7 +187,11 @@ static int __init imx8_soc_init(void)
if (data) {
Re: [PATCH 2/4] arm64: dts: ti: k3-j721e*: Cleanup disabled nodes at SoC dtsi level
On 05/11/2020 00:43, Nishanth Menon wrote:
> The device tree standard sets the default node behavior when status
> property as enabled. There are many reasons for doing the same, number
> of strings in device tree, default power management functionality etc
> are few of the reasons.
>
> In general, after a few rounds of discussions [1] there are few
> options one could take when dealing with SoC dtsi and board dts
>
> a. SoC dtsi provide nodes as a super-set default (aka enabled) state and
>to prevent messy board files, when more boards are added per SoC, we
>optimize and disable commonly un-used nodes in board-common.dtsi
> b. SoC dtsi disables all hardware dependent nodes by default and board
>dts files enable nodes based on a need basis.
> c. Subjectively pick and choose which nodes we will disable by default
>in SoC dtsi and over the years we can optimize things and change
>default state depending on the need.
>
> While there are pros and cons on each of these approaches, the right
> thing to do will be to stick with device tree default standards and
> work within those established rules. So, we choose to go with option
> (a).
>
> Lets cleanup defaults of j721e SoC dtsi before this gets more harder
> to cleanup later on and new SoCs are added.
>
> The only functional difference between the dtb generated is
> status='okay' is no longer necessary for mcasp10 and depends on the
> default state.
>
> [1]
> https://lore.kernel.org/linux-arm-kernel/20201027130701.ge5...@atomide.com/
>
> Fixes: 1c4d35265fb2 ("arm64: dts: ti: k3-j721e-main: Add McASP nodes")
> Fixes: 76921f15acc0 ("arm64: dts: ti: k3-j721e-main: Add DSS node")
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: Peter Ujfalusi
> Cc: Tony Lindgren
> Signed-off-by: Nishanth Menon
> ---
> .../dts/ti/k3-j721e-common-proc-board.dts | 48 ++-
> arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 26 --
> 2 files changed, 47 insertions(+), 27 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[RESEND,PATCH v1] mtd: spinand: macronix: Add support for MX35LFxGE4AD
The Macronix MX35LF2GE4AD / MX35LF4GE4AD are 3V, 2G / 4Gbit serial
SLC NAND flash device (with on-die ECC).
Validated by read, erase, read back, write, read back and nandtest
on Xilinx Zynq PicoZed FPGA board which included Macronix SPI Host
(drivers/spi/spi-mxic.c).
Signed-off-by: YouChing Lin
---
v2: Removed the unnecessary "/*SPINAND_HAS_QE_BIT*/" as per the comments.
v1: Add support for MX35LFxGE4AD
drivers/mtd/nand/spi/macronix.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/mtd/nand/spi/macronix.c b/drivers/mtd/nand/spi/macronix.c
index 8e801e4..3786b1b 100644
--- a/drivers/mtd/nand/spi/macronix.c
+++ b/drivers/mtd/nand/spi/macronix.c
@@ -119,6 +119,26 @@ static int mx35lf1ge4ab_ecc_get_status(struct
spinand_device *spinand,
_cache_variants),
SPINAND_HAS_QE_BIT,
SPINAND_ECCINFO(_ooblayout, NULL)),
+ SPINAND_INFO("MX35LF2GE4AD",
+SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x26),
+NAND_MEMORG(1, 2048, 64, 64, 2048, 40, 1, 1, 1),
+NAND_ECCREQ(8, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+0,
+SPINAND_ECCINFO(_ooblayout,
+mx35lf1ge4ab_ecc_get_status)),
+ SPINAND_INFO("MX35LF4GE4AD",
+SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x37),
+NAND_MEMORG(1, 4096, 128, 64, 2048, 40, 1, 1, 1),
+NAND_ECCREQ(8, 512),
+SPINAND_INFO_OP_VARIANTS(_cache_variants,
+ _cache_variants,
+ _cache_variants),
+0,
+SPINAND_ECCINFO(_ooblayout,
+mx35lf1ge4ab_ecc_get_status)),
SPINAND_INFO("MX31LF1GE4BC",
SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x1e),
NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1),
--
1.9.1
Re: [PATCH 1/4] arm64: dts: ti: k3-am65*: Cleanup disabled nodes at SoC dtsi level
On 05/11/2020 00:43, Nishanth Menon wrote:
> The device tree standard sets the default node behavior when status
> property as enabled. There are many reasons for doing the same, number
> of strings in device tree, default power management functionality etc
> are few of the reasons.
>
> In general, after a few rounds of discussions [1] there are few
> options one could take when dealing with SoC dtsi and board dts
>
> a. SoC dtsi provide nodes as a super-set default (aka enabled) state and
>to prevent messy board files, when more boards are added per SoC, we
>optimize and disable commonly un-used nodes in board-common.dtsi
> b. SoC dtsi disables all hardware dependent nodes by default and board
>dts files enable nodes based on a need basis.
> c. Subjectively pick and choose which nodes we will disable by default
>in SoC dtsi and over the years we can optimize things and change
>default state depending on the need.
>
> While there are pros and cons on each of these approaches, the right
> thing to do will be to stick with device tree default standards and
> work within those established rules. So, we choose to go with option
> (a).
>
> Lets cleanup defaults of am654 SoC dtsi before this gets more harder
> to cleanup later on and new SoCs are added.
>
> The dtb generated is identical with the patch and it is just cleanup to
> ensure we have a clean usage model
>
> [1]
> https://lore.kernel.org/linux-arm-kernel/20201027130701.ge5...@atomide.com/
>
> Fixes: 9bcb631e9953 ("arm64: dts: ti: k3-am654-main: Add McASP nodes")
> Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node")
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: Peter Ujfalusi
> Cc: Tony Lindgren
> Signed-off-by: Nishanth Menon
> ---
> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 8
> arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 16
> 2 files changed, 16 insertions(+), 8 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] mmc: block: Prevent new req entering queue while freeing up the queue
On 3/11/20 5:25 pm, Ulf Hansson wrote:
> On Wed, 28 Oct 2020 at 12:20, Veerabhadrarao Badiganti
> wrote:
>>
>> The commit bbdc74dc19e0 ("mmc: block: Prevent new req entering queue
>> after its cleanup") has introduced this change but it got moved after
>> del_gendisk() with commit 57678e5a3d51 ("mmc: block: Delete gendisk
>> before cleaning up the request queue").
>
> This isn't the first time we have spotted errors in this path. Seems
> like a difficult path to get correct. :-)
>
>>
>> It is blocking reboot with below Call stack().
>>
>> INFO: task reboot:3086 blocked for more than 122 seconds.
>> __schedule
>> schedule
>> schedule_timeout
>> io_schedule_timeout
>> do_wait_for_common
>> wait_for_completion_io
>> submit_bio_wait
>> blkdev_issue_flush
>> ext4_sync_fs
>> __sync_filesystem
>> sync_filesystem
>> fsync_bdev
>> invalidate_partition
>> del_gendisk
>> mmc_blk_remove_req
>> mmc_blk_remove
>> mmc_bus_remove
>> device_release_driver_internal
>> device_release_driver
>> bus_remove_device
>> device_del
>> mmc_remove_card
>> mmc_remove
>> mmc_stop_host
>> mmc_remove_host
>> sdhci_remove_host
>> sdhci_msm_remove
>
> Why do you call sdhci_msm_remove() from the shutdown callback? What
> specific operations do you need to run in the shutdown path for sdhci
> msm?
Yes, the problem is that upper layers, like the mmc block driver, have
already shut down, so doing operations like remove will get into deadlocks.
>
> The important part should be to do a graceful shutdown of the card
> (and the block device) - is there anything else?
>
> Or you are just using the shutdown callback as a simple way to trigger
> this problem? Could unbinding the driver trigger the same issue?
>
>> sdhci_msm_shutdown
>> platform_drv_shutdown
>> device_shutdown
>> kernel_restart_prepare
>> kernel_restart
>>
>> So bringing this change back.
>>
>> Signed-off-by: Veerabhadrarao Badiganti
>> ---
>>
>> I'm observing this issue 100% of the time with shutdown callback added to
>> sdhci-msm driver.
>> I'm trying on 5.4 kernel with ChromeOS.
>>
>> Please let me know if this can be fixed in a better way.
>
> I don't know yet, but I will have a closer look. Let's also see if
> Adrian has some thoughts.
>
> Kind regards
> Uffe
>
>> ---
>>
>> drivers/mmc/core/block.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
>> index 8d3df0be0355..76dbb2b8a13b 100644
>> --- a/drivers/mmc/core/block.c
>> +++ b/drivers/mmc/core/block.c
>> @@ -2627,6 +2627,7 @@ static void mmc_blk_remove_req(struct mmc_blk_data *md)
>> * from being accepted.
>> */
>> card = md->queue.card;
>> + blk_set_queue_dying(md->queue.queue);
>> if (md->disk->flags & GENHD_FL_UP) {
>> device_remove_file(disk_to_dev(md->disk),
>> >force_ro);
>> if ((md->area_type & MMC_BLK_DATA_AREA_BOOT) &&
>> --
>> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
>> Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative
>> Project
>>
Re: [PATCH 1/4] clk: sifive: Extract prci core to common base
On Thu, Nov 5, 2020 at 10:45 AM Stephen Boyd wrote: > > Quoting Zong Li (2020-10-16 02:18:23) > > Extract common core of prci driver to an independent file, it could > > allow other chips to reuse it. Separate SoCs-dependent code 'fu540' > > from prci core, then we can easily add 'fu740' later. > > Please indicate if there are any functional changes or this is just code > movement. There are some changes for common use, not just code movement or copies, I would figure out the changes in the commit message in the next version. > > > > > Signed-off-by: Zong Li > > --- > > drivers/clk/sifive/Makefile | 2 + > > drivers/clk/sifive/fu540-prci.c | 586 +-- > > drivers/clk/sifive/fu540-prci.h | 21 ++ > > drivers/clk/sifive/sifive-prci.c | 409 + > > drivers/clk/sifive/sifive-prci.h | 201 +++ > > How much of this is a copy/pastes? Can you generate patches with > format-patch -M -C to try to find copies and renames? I tried to add -M and -C option to find renames and copies, but it doesn't detect anything here. > > > 5 files changed, 652 insertions(+), 567 deletions(-) > > create mode 100644 drivers/clk/sifive/fu540-prci.h > > create mode 100644 drivers/clk/sifive/sifive-prci.c > > create mode 100644 drivers/clk/sifive/sifive-prci.h > >
Re: [PATCH] arm64: dts: ti: k3-am65*/j721e*: Fix unit address format error for dss node
On 05/11/2020 00:25, Nishanth Menon wrote:
> Fix the node address to follow the device tree convention.
>
> This fixes the dtc warning:
> : Warning (simple_bus_reg): /bus@10/dss@04a0: simple-bus
> unit address format error, expected "4a0"
>
> Fixes: 76921f15acc0 ("arm64: dts: ti: k3-j721e-main: Add DSS node")
> Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node")
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Signed-off-by: Nishanth Menon
> ---
> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 2 +-
> arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> index 533525229a8d..27f6fd9eaa0a 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> @@ -834,7 +834,7 @@ csi2_0: port@0 {
> };
> };
>
> - dss: dss@04a0 {
> + dss: dss@4a0 {
> compatible = "ti,am65x-dss";
> reg = <0x0 0x04a0 0x0 0x1000>, /* common */
> <0x0 0x04a02000 0x0 0x1000>, /* vidl1 */
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> index e2a96b2c423c..c66ded9079be 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> @@ -1278,7 +1278,7 @@ ufs@4e84000 {
> };
> };
>
> - dss: dss@04a0 {
> + dss: dss@4a0 {
> compatible = "ti,j721e-dss";
> reg =
> <0x00 0x04a0 0x00 0x1>, /* common_m */
>
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 4/4] clk: sifive: Refactor __prci_clock array by using macro
On Thu, Nov 5, 2020 at 10:50 AM Stephen Boyd wrote:
>
> Quoting Zong Li (2020-10-16 02:18:26)
> > Refactor code by using DEFINE_PRCI_CLOCK to define each clock
> > and reduce duplicate code.
>
> What is duplicate?
Sorry for unclear description, actually, I want to say that we can
remove the repeating code about initializing the data member of
structure.
>
> >
> > Signed-off-by: Zong Li
> > ---
> > drivers/clk/sifive/fu540-prci.c | 38 ++--
> > drivers/clk/sifive/fu540-prci.h | 2 +-
> > drivers/clk/sifive/fu740-prci.c | 74
> > drivers/clk/sifive/fu740-prci.h | 2 +-
> > drivers/clk/sifive/sifive-prci.c | 2 +-
> > drivers/clk/sifive/sifive-prci.h | 10 -
> > 6 files changed, 53 insertions(+), 75 deletions(-)
> >
> > diff --git a/drivers/clk/sifive/fu540-prci.c
> > b/drivers/clk/sifive/fu540-prci.c
> > index 840b97bfff85..d43b9a9984f6 100644
> > --- a/drivers/clk/sifive/fu540-prci.c
> > +++ b/drivers/clk/sifive/fu540-prci.c
> > @@ -54,29 +54,19 @@ static const struct clk_ops
> > sifive_fu540_prci_tlclksel_clk_ops = {
> > .recalc_rate = sifive_prci_tlclksel_recalc_rate,
> > };
> >
> > +DEFINE_PRCI_CLOCK(fu540, corepll, hfclk,
> > + _fu540_prci_wrpll_clk_ops, &__prci_corepll_data);
> > +DEFINE_PRCI_CLOCK(fu540, ddrpll, hfclk,
> > + _fu540_prci_wrpll_ro_clk_ops, &__prci_ddrpll_data);
> > +DEFINE_PRCI_CLOCK(fu540, gemgxlpll, hfclk,
> > + _fu540_prci_wrpll_clk_ops, &__prci_gemgxlpll_data);
> > +DEFINE_PRCI_CLOCK(fu540, tlclk, corepll,
> > + _fu540_prci_tlclksel_clk_ops, NULL);
>
> Readability looks to decrease with this change. Why should all us code
> reviewers suffer because the code author wants to type a few less
> characters? Named initializers are useful so we don't have to hold each
> macro argument in our head and map it to the struct member that is being
> initialized.
Ok, as you mentioned, macro reduce the readability, let me remove this
change in the next version.
>
> > +
> > /* List of clock controls provided by the PRCI */
> > -struct __prci_clock __prci_init_clocks_fu540[] = {
> > - [PRCI_CLK_COREPLL] = {
> > - .name = "corepll",
> > - .parent_name = "hfclk",
> > - .ops = _fu540_prci_wrpll_clk_ops,
> > - .pwd = &__prci_corepll_data,
> > - },
> > - [PRCI_CLK_DDRPLL] = {
> > - .name = "ddrpll",
> > - .parent_name = "hfclk",
> > - .ops = _fu540_prci_wrpll_ro_clk_ops,
> > - .pwd = &__prci_ddrpll_data,
> > - },
> > - [PRCI_CLK_GEMGXLPLL] = {
> > - .name = "gemgxlpll",
> > - .parent_name = "hfclk",
> > - .ops = _fu540_prci_wrpll_clk_ops,
> > - .pwd = &__prci_gemgxlpll_data,
> > - },
> > - [PRCI_CLK_TLCLK] = {
> > - .name = "tlclk",
> > - .parent_name = "corepll",
> > - .ops = _fu540_prci_tlclksel_clk_ops,
> > - },
> > +struct __prci_clock *__prci_init_clocks_fu540[] = {
> > + [PRCI_CLK_COREPLL] = _corepll,
> > + [PRCI_CLK_DDRPLL] = _ddrpll,
> > + [PRCI_CLK_GEMGXLPLL]= _gemgxlpll,
> > + [PRCI_CLK_TLCLK]= _tlclk,
> > };
> > diff --git a/drivers/clk/sifive/fu540-prci.h
> > b/drivers/clk/sifive/fu540-prci.h
> > index c8271efa7bdc..281200cd8848 100644
> > --- a/drivers/clk/sifive/fu540-prci.h
> > +++ b/drivers/clk/sifive/fu540-prci.h
> > @@ -11,7 +11,7 @@
> >
> > #define NUM_CLOCK_FU5404
> >
> > -extern struct __prci_clock __prci_init_clocks_fu540[NUM_CLOCK_FU540];
> > +extern struct __prci_clock *__prci_init_clocks_fu540[NUM_CLOCK_FU540];
> >
> > static const struct prci_clk_desc prci_clk_fu540 = {
> > .clks = __prci_init_clocks_fu540,
> > diff --git a/drivers/clk/sifive/fu740-prci.c
> > b/drivers/clk/sifive/fu740-prci.c
> > index 3b87e273c3eb..676cad2c3886 100644
> > --- a/drivers/clk/sifive/fu740-prci.c
> > +++ b/drivers/clk/sifive/fu740-prci.c
> > @@ -71,52 +71,32 @@ static const struct clk_ops
> > sifive_fu740_prci_hfpclkplldiv_clk_ops = {
> > .recalc_rate = sifive_prci_hfpclkplldiv_recalc_rate,
> > };
> >
> > +
> > +DEFINE_PRCI_CLOCK(fu740, corepll, hfclk,
> > + _fu740_prci_wrpll_clk_ops, &__prci_corepll_data);
> > +DEFINE_PRCI_CLOCK(fu740, ddrpll, hfclk,
> > + _fu740_prci_wrpll_ro_clk_ops, &__prci_ddrpll_data);
> > +DEFINE_PRCI_CLOCK(fu740, gemgxlpll, hfclk,
> > + _fu740_prci_wrpll_clk_ops, &__prci_gemgxlpll_data);
> > +DEFINE_PRCI_CLOCK(fu740, dvfscorepll, hfclk,
> > + _fu740_prci_wrpll_clk_ops,
> > &__prci_dvfscorepll_data);
> > +DEFINE_PRCI_CLOCK(fu740, hfpclkpll, hfclk,
> > + _fu740_prci_wrpll_clk_ops, &__prci_hfpclkpll_data);
> > +DEFINE_PRCI_CLOCK(fu740, cltxpll, hfclk,
> > + _fu740_prci_wrpll_clk_ops, &__prci_cltxpll_data);
> >
[PATCH net-next] net: udp: introduce UDP_MIB_MEMERRORS for udp_mem
From: Menglong Dong
When udp_memory_allocated is at the limit, __udp_enqueue_schedule_skb
will return a -ENOBUFS, and skb will be dropped in __udp_queue_rcv_skb
without any counters being done. It's hard to find out what happened
once this happen.
So we introduce a UDP_MIB_MEMERRORS to do this job. Well, this change
looks friendly to the existing users, such as netstat:
$ netstat -u -s
Udp:
0 packets received
639 packets to unknown port received.
158689 packet receive errors
180022 packets sent
RcvbufErrors: 20930
MemErrors: 137759
UdpLite:
IpExt:
InOctets: 257426235
OutOctets: 257460598
InNoECTPkts: 181177
Signed-off-by: Menglong Dong
---
include/uapi/linux/snmp.h | 1 +
net/ipv4/proc.c | 1 +
net/ipv4/udp.c| 3 +++
net/ipv6/proc.c | 2 ++
net/ipv6/udp.c| 3 +++
5 files changed, 10 insertions(+)
diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
index f84e7bcad6de..26fc60ce9298 100644
--- a/include/uapi/linux/snmp.h
+++ b/include/uapi/linux/snmp.h
@@ -159,6 +159,7 @@ enum
UDP_MIB_SNDBUFERRORS, /* SndbufErrors */
UDP_MIB_CSUMERRORS, /* InCsumErrors */
UDP_MIB_IGNOREDMULTI, /* IgnoredMulti */
+ UDP_MIB_MEMERRORS, /* MemErrors */
__UDP_MIB_MAX
};
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 8d5e1695b9aa..63cd370ea29d 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -167,6 +167,7 @@ static const struct snmp_mib snmp4_udp_list[] = {
SNMP_MIB_ITEM("SndbufErrors", UDP_MIB_SNDBUFERRORS),
SNMP_MIB_ITEM("InCsumErrors", UDP_MIB_CSUMERRORS),
SNMP_MIB_ITEM("IgnoredMulti", UDP_MIB_IGNOREDMULTI),
+ SNMP_MIB_ITEM("MemErrors", UDP_MIB_MEMERRORS),
SNMP_MIB_SENTINEL
};
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 09f0a23d1a01..aa1bd53dd9f9 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2038,6 +2038,9 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct
sk_buff *skb)
if (rc == -ENOMEM)
UDP_INC_STATS(sock_net(sk), UDP_MIB_RCVBUFERRORS,
is_udplite);
+ else
+ UDP_INC_STATS(sock_net(sk), UDP_MIB_MEMERRORS,
+ is_udplite);
UDP_INC_STATS(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
kfree_skb(skb);
trace_udp_fail_queue_rcv_skb(rc, sk);
diff --git a/net/ipv6/proc.c b/net/ipv6/proc.c
index bbff3e02e302..d6306aa46bb1 100644
--- a/net/ipv6/proc.c
+++ b/net/ipv6/proc.c
@@ -126,6 +126,7 @@ static const struct snmp_mib snmp6_udp6_list[] = {
SNMP_MIB_ITEM("Udp6SndbufErrors", UDP_MIB_SNDBUFERRORS),
SNMP_MIB_ITEM("Udp6InCsumErrors", UDP_MIB_CSUMERRORS),
SNMP_MIB_ITEM("Udp6IgnoredMulti", UDP_MIB_IGNOREDMULTI),
+ SNMP_MIB_ITEM("Udp6MemErrors", UDP_MIB_MEMERRORS),
SNMP_MIB_SENTINEL
};
@@ -137,6 +138,7 @@ static const struct snmp_mib snmp6_udplite6_list[] = {
SNMP_MIB_ITEM("UdpLite6RcvbufErrors", UDP_MIB_RCVBUFERRORS),
SNMP_MIB_ITEM("UdpLite6SndbufErrors", UDP_MIB_SNDBUFERRORS),
SNMP_MIB_ITEM("UdpLite6InCsumErrors", UDP_MIB_CSUMERRORS),
+ SNMP_MIB_ITEM("UdpLite6MemErrors", UDP_MIB_MEMERRORS),
SNMP_MIB_SENTINEL
};
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 29d9691359b9..e6158e04e15c 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -637,6 +637,9 @@ static int __udpv6_queue_rcv_skb(struct sock *sk, struct
sk_buff *skb)
if (rc == -ENOMEM)
UDP6_INC_STATS(sock_net(sk),
UDP_MIB_RCVBUFERRORS, is_udplite);
+ else
+ UDP6_INC_STATS(sock_net(sk),
+UDP_MIB_MEMERRORS, is_udplite);
UDP6_INC_STATS(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
kfree_skb(skb);
return -1;
--
2.25.1
Re: [PATCH v5 5/6] dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml
On Thu, Oct 29, 2020 at 8:39 AM Ramuthevar,Vadivel MuruganX wrote: > From: Ramuthevar Vadivel Murugan > > Convert the cadence-quadspi.txt documentation to cadence-quadspi.yaml > remove the cadence-quadspi.txt from Documentation/devicetree/bindings/spi/ > > Signed-off-by: Ramuthevar Vadivel Murugan > > + cdns,is-decoded-cs: > +type: boolean > +description: > + Flag to indicate whether decoder is used or not. Please elaborate a bit on what kind of decoder this is. I am curious! :) Yours, Linus Walleij
Re: [PATCH v6 3/6] spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoC
On Fri, Oct 30, 2020 at 6:32 AM Ramuthevar,Vadivel MuruganX
wrote:
> + ddata = of_device_get_match_data(dev);
> + if (ddata->hwcaps_mask & CQSPI_SUPPORTS_MULTI_CHIPSELECT) {
> + if (of_property_read_u32(np, "num-chipselect",
The standard SPI bindings in spi-controller.yaml already has a binding
for this "num-cs" so please use that. It is also what your device tree
binding is referencing, so if you were using "num-chipselect" the
YAML check should give a warning?
Yours,
Linus Walleij
Re: [PATCH 31/36] powerpc: asm: hvconsole: Move 'hvc_vio_init_early's prototype to shared location
Le 04/11/2020 à 20:35, Lee Jones a écrit : Fixes the following W=1 kernel build warning(s): drivers/tty/hvc/hvc_vio.c:385:13: warning: no previous prototype for ‘hvc_vio_init_early’ [-Wmissing-prototypes] 385 | void __init hvc_vio_init_early(void) | ^~ Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-...@lists.ozlabs.org Signed-off-by: Lee Jones --- arch/powerpc/include/asm/hvconsole.h | 3 +++ arch/powerpc/platforms/pseries/pseries.h | 3 --- arch/powerpc/platforms/pseries/setup.c | 1 + 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/include/asm/hvconsole.h b/arch/powerpc/include/asm/hvconsole.h index 999ed5ac90531..936a1ee1ac786 100644 --- a/arch/powerpc/include/asm/hvconsole.h +++ b/arch/powerpc/include/asm/hvconsole.h @@ -24,5 +24,8 @@ extern int hvc_get_chars(uint32_t vtermno, char *buf, int count); extern int hvc_put_chars(uint32_t vtermno, const char *buf, int count); +/* Provided by HVC VIO */ +extern void hvc_vio_init_early(void); + Declaring a prototype 'extern' is pointless. Don't add new misuse of 'extern' keyword. #endif /* __KERNEL__ */ #endif /* _PPC64_HVCONSOLE_H */ diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h index 13fa370a87e4e..7be5b054dfc36 100644 --- a/arch/powerpc/platforms/pseries/pseries.h +++ b/arch/powerpc/platforms/pseries/pseries.h @@ -43,9 +43,6 @@ extern void pSeries_final_fixup(void); /* Poweron flag used for enabling auto ups restart */ extern unsigned long rtas_poweron_auto; -/* Provided by HVC VIO */ -extern void hvc_vio_init_early(void); - /* Dynamic logical Partitioning/Mobility */ extern void dlpar_free_cc_nodes(struct device_node *); extern void dlpar_free_cc_property(struct property *); diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c index 633c45ec406da..6999b83f06612 100644 --- a/arch/powerpc/platforms/pseries/setup.c +++ b/arch/powerpc/platforms/pseries/setup.c @@ -71,6 +71,7 @@ #include #include #include +#include #include "pseries.h" #include "../../../../drivers/pci/pci.h" Christophe
Re: [RFC PATCH] .clang-format: Remove conditional comments
On Thu, 2020-11-05 at 07:44 +0100, Miguel Ojeda wrote: > There are a few important new features: https://clang.llvm.org/docs/ClangFormatStyleOptions.html > - AlignConsecutiveMacros is probably one of the biggest one for the > kernel that we were missing so far. There's no control as to effective column nor sensible mechanism to avoid extremely long indents with a single exceptional entry. > - IndentPPDirectives and Some yes, mostly no. AlignEscapedNewlines: Generally the kernel uses column 72 but there's not real consistency. clang-format doesn't have that option as far as I can tell. > Then there are a few others that pertain to us too: > - SpaceBeforeSquareBrackets no > - SpacesInConditionalStatement no > - SpaceAfterLogicalNot no > - SpaceInEmptyBlock no > - IndentGotoLabels no > > Others are also worth checking to see if we can take advantage of them: > - IncludeBlocks (and configuring IncludeCategories etc.) Might be worthwhile. It's different by maintainer preference though. Reverse Xmas tree is somewhat common in networking, (which I think is silly, but DaveM likes it). Some like alphabetic ordering, others by order of include. > - StatementMacros Kernel is not c++ so this is irrelevant for gcc macro statement expressions. > Then there are others that are not related to us, but to be consistent > we would explicitly set them in the file. Finally, for extra points, > we could already document the new ones in LLVM 11 if any, for the > future, but that is optional. > > If no one is up for the task, I will eventually do it... :-) Enjoy...
Re: [RFC, v0 1/3] vfio/platform: add support for msi
On Thu, 5 Nov 2020 11:32:55 +0530
Vikas Gupta wrote:
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 2f313a238a8f..aab051e8338d 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -203,6 +203,7 @@ struct vfio_device_info {
> #define VFIO_DEVICE_FLAGS_AP (1 << 5)/* vfio-ap device */
> #define VFIO_DEVICE_FLAGS_FSL_MC (1 << 6)/* vfio-fsl-mc device */
> #define VFIO_DEVICE_FLAGS_CAPS (1 << 7)/* Info supports caps */
> +#define VFIO_DEVICE_FLAGS_MSI(1 << 8)/* Device supports msi
> */
> __u32 num_regions;/* Max region index + 1 */
> __u32 num_irqs; /* Max IRQ index + 1 */
> __u32 cap_offset; /* Offset within info struct of first cap */
This doesn't make any sense to me, MSIs are just edge triggered
interrupts to userspace, so why isn't this fully described via
VFIO_DEVICE_GET_IRQ_INFO? If we do need something new to describe it,
this seems incomplete, which indexes are MSI (IRQ_INFO can describe
that)? We also already support MSI with vfio-pci, so a global flag for
the device advertising this still seems wrong. Thanks,
Alex
Request to Update WCN3991 FW file
Hello Team, Please include updated firmware bins for WCN3991. Change includes updated TLV file to fix BT SSR. Snapshot of pull request is as below, let me know if anything is missing. The following changes since commit dae4b4cd084102cd49c37aa8b579b208028ab025: Merge branch 'v1.1.5' of https://github.com/irui-wang/linux_fw_vpu_v1.1.5 into main (2020-10-23 08:10:37 -0400) are available in the git repository at: https://github.com/shahasit/bt-linux-firmware.git master for you to fetch changes up to d7793e53b156126f6ea09c8d6e17cc9a8fe0ca77: QCA : Fixed BT SSR due to command timeout / IO fatal error (2020-11-05 12:26:32 +0530) Asit Shah (1): QCA : Fixed BT SSR due to command timeout / IO fatal error qca/crbtfw32.tlv | Bin 126832 -> 126892 bytes 1 file changed, 0 insertions(+), 0 deletions(-) < Regards, Asit
Re: [PATCH 34/36] tty: serial: pmac_zilog: Make disposable variable __always_unused
Le 04/11/2020 à 20:35, Lee Jones a écrit :
Fixes the following W=1 kernel build warning(s):
drivers/tty/serial/pmac_zilog.h:365:58: warning: variable ‘garbage’ set but
not used [-Wunused-but-set-variable]
Explain how you are fixing this warning.
Setting __always_unused is usually not the good solution for fixing this warning, but here I guess
this is likely the good solution. But it should be explained why.
Christophe
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linux-ser...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: Lee Jones
---
drivers/tty/serial/pmac_zilog.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/pmac_zilog.h b/drivers/tty/serial/pmac_zilog.h
index bb874e76810e0..968aec7c1cf82 100644
--- a/drivers/tty/serial/pmac_zilog.h
+++ b/drivers/tty/serial/pmac_zilog.h
@@ -362,7 +362,7 @@ static inline void zssync(struct uart_pmac_port *port)
/* Misc macros */
#define ZS_CLEARERR(port)(write_zsreg(port, 0, ERR_RES))
-#define ZS_CLEARFIFO(port) do { volatile unsigned char garbage; \
+#define ZS_CLEARFIFO(port) do { volatile unsigned char __always_unused
garbage; \
garbage = read_zsdata(port); \
garbage = read_zsdata(port); \
garbage = read_zsdata(port); \
linux-next: build warning after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (htmldocs) produced
this warning:
Documentation/admin-guide/hw-vuln/l1d_flush.rst:25: WARNING: undefined label:
documentation/userspace-api/spec_ctrl.rst (if the link has no caption the label
must precede a section header)
Introduced by commit
767d46ab566d ("Documentation: Add L1D flushing Documentation")
--
Cheers,
Stephen Rothwell
pgpWnHKt09cd9.pgp
Description: OpenPGP digital signature
RE: [PATCH RFC v2 4/4] 9p: fix race issue in fid contention.
Hi Dominique,
Good News!
I'm happy to see that you have time to pick this up again. All the changes are
OK for me.
Thanks
Jianyong
> -Original Message-
> From: Dominique Martinet
> Sent: Tuesday, November 3, 2020 6:41 PM
> To: Jianyong Wu
> Cc: eri...@gmail.com; lu...@ionkov.net; qemu_...@crudebyte.com;
> gr...@kaod.org; v9fs-develo...@lists.sourceforge.net; linux-
> ker...@vger.kernel.org; Justin He
> Subject: Re: [PATCH RFC v2 4/4] 9p: fix race issue in fid contention.
>
> Jianyong,
>
> Jianyong Wu wrote on Wed, Sep 23, 2020:
> > Eric's and Greg's patch offer a mechanism to fix open-unlink-f*syscall
> > bug in 9p. But there is race issue in fid comtention.
> > As Greg's patch stores all of fids from opened files into according
> > inode, so all the lookup fid ops can retrieve fid from inode
> > preferentially. But there is no mechanism to handle the fid comtention
> > issue. For example, there are two threads get the same fid in the same
> > time and one of them clunk the fid before the other thread ready to
> > discard the fid. In this scenario, it will lead to some fatal problems, even
> kernel core dump.
> >
> > I introduce a mechanism to fix this race issue. A counter field
> > introduced into p9_fid struct to store the reference counter to the
> > fid. When a fid is allocated from the inode or dentry, the counter
> > will increase, and will decrease at the end of its occupation. It is
> > guaranteed that the fid won't be clunked before the reference counter
> > go down to 0, then we can avoid the clunked fid to be used.
> >
> > tests:
> > race issue test from the old test case:
> > for file in {01..50}; do touch f.${file}; done seq 1 1000 | xargs -n 1
> > -P 50 -I{} cat f.* > /dev/null
> >
> > open-unlink-f*syscall test:
> > I have tested for f*syscall include: ftruncate fstat fchown fchmod
> > faccessat.
> >
> > Signed-off-by: Jianyong Wu
>
> Ok so I've finally taken some time to test -- sorry for the delay.
> I didn't bother with qemu but the use-after-close f* calls work with nfs-
> ganesha and it doesn't introduce any obvious regression with the current
> qemu either, so this is good for me.
>
> Greg, Christian - from what I understood (in private, hopefully I'm allowed to
> repeat!), he won't be able to contribute to qemu because of company
> policies and I'm unlikely to take the time either right now.
> I don't think it's a problem to continue as is though, we can land linux
> kernel
> support (it's still useful for non-qemu servers) and if someone is interested
> later on they'll just need to finish that bit.
>
>
> I'm not seeing any obvious problem now so I'll take these patches in -next
> within the next few days, with this extra patch on top that basically applies
> the requests I had:
> - removing the extra atomic_set in fs/9p/fid.c
> - convert from atomic to refcount API (overflow checks)
> - rename a no-composant walk to clone_fid()
>
> I'll just run some more instrumented tests first to check we're not leaking
> anything but so far I haven't found any problem.
>
> If you noticed anything else please speak up.
> Thanks for taking the time to finish this! :)
> ---
> fs/9p/fid.c | 10 --
> fs/9p/fid.h | 2 +-
> include/net/9p/client.h | 2 +-
> net/9p/client.c | 4 ++--
> 4 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/fs/9p/fid.c b/fs/9p/fid.c
> index 89643dabcdae..50118ec72a92 100644
> --- a/fs/9p/fid.c
> +++ b/fs/9p/fid.c
> @@ -28,7 +28,6 @@
>
> static inline void __add_fid(struct dentry *dentry, struct p9_fid *fid) {
> -atomic_set(>count, 1);
> hlist_add_head(>dlist, (struct hlist_head *)
> >d_fsdata); }
>
> @@ -62,7 +61,7 @@ static struct p9_fid *v9fs_fid_find_inode(struct inode
> *inode, kuid_t uid)
> }
> }
> if (ret && !IS_ERR(ret))
> -atomic_inc(>count);
> +refcount_inc(>count);
> spin_unlock(>i_lock);
> return ret;
> }
> @@ -77,7 +76,6 @@ static struct p9_fid *v9fs_fid_find_inode(struct inode
> *inode, kuid_t uid) void v9fs_open_fid_add(struct inode *inode, struct
> p9_fid *fid) {
> spin_lock(>i_lock);
> -atomic_set(>count, 1);
> hlist_add_head(>ilist, (struct hlist_head *)>i_private);
> spin_unlock(>i_lock);
> }
> @@ -110,7 +108,7 @@ static struct p9_fid *v9fs_fid_find(struct dentry
> *dentry, kuid_t uid, int any)
> hlist_for_each_entry(fid, h, dlist) {
> if (any || uid_eq(fid->uid, uid)) {
> ret = fid;
> -atomic_inc(>count);
> +refcount_inc(>count);
> break;
> }
> }
> @@ -201,7 +199,7 @@ static struct p9_fid *v9fs_fid_lookup_with_uid(struct
> dentry *dentry,
> }
> /* If we are root ourself just return that */
> if (dentry->d_sb->s_root == dentry) {
> -atomic_inc(>count);
> +refcount_inc(>count);
> return fid;
> }
> /*
> @@ -250,7 +248,7 @@ static struct p9_fid *v9fs_fid_lookup_with_uid(struct
> dentry *dentry,
> fid = ERR_PTR(-ENOENT);
> } else {
> __add_fid(dentry, fid);
> -atomic_inc(>count);
> +refcount_inc(>count);
> spin_unlock(>d_lock);
> }
> }
> diff
linux-next: build warning after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (htmldocs) produced
this warning:
Documentation/gpu/drm-kms:466: drivers/gpu/drm/drm_crtc.c:236: WARNING:
Unexpected indentation.
Documentation/gpu/drm-kms:466: drivers/gpu/drm/drm_crtc.c:237: WARNING: Block
quote ends without a blank line; unexpected unindent.
Documentation/gpu/drm-kms:472: drivers/gpu/drm/drm_blend.c:203: WARNING:
Unexpected indentation.
Documentation/gpu/drm-kms:472: drivers/gpu/drm/drm_blend.c:204: WARNING: Block
quote ends without a blank line; unexpected unindent.
Introduced by commit
5c759eda9b04 ("drm: Introduce plane and CRTC scaling filter properties")
--
Cheers,
Stephen Rothwell
pgpeA1z_emEhA.pgp
Description: OpenPGP digital signature
Re: linux-next: build warning after merge of the akpm-current tree
On Thu, Nov 05, 2020 at 05:45:49PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/filesystems/proc.rst:296: WARNING: Malformed table.
> Text in column margin in table line 61.
>
> ==
> ===
> Field Content
> ==
> ===
...
> Speculation_Store_Bypassspeculative store bypass mitigation status
> Speculation_Indirect_Branch indirect branch speculation mode
...
> ==
> ===
> Documentation/filesystems/proc.rst:234: WARNING: Error parsing content block
> for the "table" directive: exactly one table expected.
Looks like left column became too wide, so rather than shift the right
column to the right, I'd suggest to drop underscores in Speculation*.
>
> .. table:: Table 1-2: Contents of the status files (as of 4.19)
>
> ==
> ===
> Field Content
> ==
> ===
...
> Speculation_Store_Bypassspeculative store bypass mitigation status
> Speculation_Indirect_Branch indirect branch speculation mode
> Cpus_allowedmask of CPUs on which this process may run
> Cpus_allowed_list Same as previous, but in "list format"
> Mems_allowedmask of memory nodes allowed to this process
> Mems_allowed_list Same as previous, but in "list format"
> voluntary_ctxt_switches number of voluntary context switches
> nonvoluntary_ctxt_switches number of non voluntary context switches
> ==
> ===
Same here.
> Introduced by commit
>
> 60b492d745d5 ("proc: provide details on indirect branch speculation")
>
> --
> Cheers,
> Stephen Rothwell
--
Sincerely yours,
Mike.
Re: Very slow realtek 8169 ethernet performance, but only one interface, on ThinkPad T14.
On 05.11.2020 03:48, Qu Wenruo wrote: > Hi, > > Not sure if this is a regression or not, but just find out that after > upgrading to v5.9 kernel, one of my ethernet port on my ThinkPad T14 (ryzen > version) becomes very slow. > > Only *2~3* Mbps. > > The laptop has two ethernet interfaces, one needs a passive adapter, the > other one is a standard RJ45. > > The offending one is the one which needs the adapter (eth0). > While the RJ45 one is completely fine. > > 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0e) > 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) > > The 02:00.0 one is the affected one. > > The related dmesgs are: > [ 38.110293] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM > control > [ 38.126069] libphy: r8169: probed > [ 38.126250] r8169 :02:00.0 eth0: RTL8168ep/8111ep, 00:2b:67:b3:d9:20, > XID 502, IRQ 105 > [ 38.126252] r8169 :02:00.0 eth0: jumbo features [frames: 9194 bytes, > tx checksumming: ko] > [ 38.126294] r8169 :05:00.0: can't disable ASPM; OS doesn't have ASPM > control > [ 38.126300] r8169 :05:00.0: enabling device ( -> 0003) > [ 38.139355] libphy: r8169: probed > [ 38.139523] r8169 :05:00.0 eth1: RTL8168h/8111h, 00:2b:67:b3:d9:1f, > XID 541, IRQ 107 > [ 38.139525] r8169 :05:00.0 eth1: jumbo features [frames: 9194 bytes, > tx checksumming: ko] > [ 42.120935] Generic FE-GE Realtek PHY r8169-200:00: attached PHY driver > [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-200:00, irq=IGNORE) > [ 42.247646] r8169 :02:00.0 eth0: Link is Down > [ 42.280799] Generic FE-GE Realtek PHY r8169-500:00: attached PHY driver > [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-500:00, irq=IGNORE) > [ 42.477616] r8169 :05:00.0 eth1: Link is Down > [ 76.479569] r8169 :02:00.0 eth0: Link is Up - 1Gbps/Full - flow > control rx/tx > [ 91.271894] r8169 :02:00.0 eth0: Link is Down > [ 99.873390] r8169 :02:00.0 eth0: Link is Up - 1Gbps/Full - flow > control rx/tx > [ 99.878938] r8169 :02:00.0 eth0: Link is Down > [ 102.579290] r8169 :02:00.0 eth0: Link is Up - 1Gbps/Full - flow > control rx/tx > [ 185.086002] r8169 :02:00.0 eth0: Link is Down > [ 392.884584] r8169 :02:00.0 eth0: Link is Up - 1Gbps/Full - flow > control rx/tx > [ 392.891208] r8169 :02:00.0 eth0: Link is Down > [ 395.889047] r8169 :02:00.0 eth0: Link is Up - 1Gbps/Full - flow > control rx/tx > [ 406.670738] r8169 :02:00.0 eth0: Link is Down > > Really nothing strange, even it negotiates to 1Gbps. > > But during iperf3, it only goes up to miserable 3Mbps. > > Is this some known bug or something special related to the passive adapter? > > Since the adapter is passive, and hasn't experience anything wrong for a long > time, I really doubt that. > > Thanks, > Qu > > Thanks for the report. From which kernel version did you upgrade? Please test with the prior kernel version and report behavior (link stability and speed). Under 5.9, does ethtool -S eth0 report packet errors?
Re: [PATCH] drm/virtio: use kvmalloc for large allocations
Hi, On (20/11/05 07:52), Gerd Hoffmann wrote: > > - *ents = kmalloc_array(*nents, sizeof(struct virtio_gpu_mem_entry), > > - GFP_KERNEL); > > + *ents = kvmalloc_array(*nents, > > + sizeof(struct virtio_gpu_mem_entry), > > + GFP_KERNEL); > > Shouldn't that be balanced with a kvfree() elsewhere? I think it already is. ents pointer is assigned to vbuf->data_buf, and free_vbuf() already uses kvfree(vbuf->data_buf) to free it. -ss
Re: [PATCH v2 2/4] Kbuild: do not emit debug info for assembly with LLVM_IAS=1
On Tue, Nov 03, 2020 at 04:53:41PM -0800, Nick Desaulniers wrote: > Clang's integrated assembler produces the warning for assembly files: > > warning: DWARF2 only supports one section per compilation unit > > If -Wa,-gdwarf-* is unspecified, then debug info is not emitted. This Is this something that should be called out somewhere? If I understand this correctly, LLVM_IAS=1 + CONFIG_DEBUG_INFO=y won't work? Maybe this should be handled in Kconfig? > will be re-enabled for new DWARF versions in a follow up patch. > > Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with > LLVM=1 LLVM_IAS=1 for x86_64 and arm64. > > Cc: > Link: https://github.com/ClangBuiltLinux/linux/issues/716 > Reported-by: Nathan Chancellor > Suggested-by: Dmitry Golovin If you happen to respin, Dmitry deserves a Reported-by tag too :) > Suggested-by: Sedat Dilek > Signed-off-by: Nick Desaulniers Regardless of the other two comments, this is fine as is as a fix for stable to unblock Android + CrOS since we have been running something similar to it in CI: Reviewed-by: Nathan Chancellor > --- > Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Makefile b/Makefile > index f353886dbf44..75b1a3dcbf30 100644 > --- a/Makefile > +++ b/Makefile > @@ -826,7 +826,9 @@ else > DEBUG_CFLAGS += -g > endif > > +ifndef LLVM_IAS Nit: this should probably match the existing LLVM_IAS check ifneq ($(LLVM_IAS),1) > KBUILD_AFLAGS+= -Wa,-gdwarf-2 > +endif > > ifdef CONFIG_DEBUG_INFO_DWARF4 > DEBUG_CFLAGS += -gdwarf-4 > -- > 2.29.1.341.ge80a0c044ae-goog >
Re: [PATCH v2] mtd: spinand: macronix: Add support for MX35LFxGE4AD
Hi YouChing,
YouChing Lin wrote on Thu, 5 Nov 2020 09:43:13
+0800:
> The Macronix MX35LF2GE4AD / MX35LF4GE4AD are 3V, 2G / 4Gbit serial
> SLC NAND flash device (with on-die ECC).
>
> Validated by read, erase, read back, write, read back and nandtest
> on Xilinx Zynq PicoZed FPGA board which included Macronix SPI Host
> (drivers/spi/spi-mxic.c).
>
> v2: Removed the unnecessary "/*SPINAND_HAS_QE_BIT*/" as per the comments.
>
> v1: Add support for MX35LFxGE4AD
You cannot put the changelog here. Everything you write above the three
dashes will be part of the final commit message and we don't want this
to appear.
>
> Signed-off-by: YouChing Lin
> ---
V2: ...
v1: ...
should be located here
> drivers/mtd/nand/spi/macronix.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/mtd/nand/spi/macronix.c b/drivers/mtd/nand/spi/macronix.c
> index 8e801e4..3786b1b 100644
> --- a/drivers/mtd/nand/spi/macronix.c
> +++ b/drivers/mtd/nand/spi/macronix.c
> @@ -119,6 +119,26 @@ static int mx35lf1ge4ab_ecc_get_status(struct
> spinand_device *spinand,
> _cache_variants),
>SPINAND_HAS_QE_BIT,
>SPINAND_ECCINFO(_ooblayout, NULL)),
> + SPINAND_INFO("MX35LF2GE4AD",
> + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x26),
> + NAND_MEMORG(1, 2048, 64, 64, 2048, 40, 1, 1, 1),
> + NAND_ECCREQ(8, 512),
> + SPINAND_INFO_OP_VARIANTS(_cache_variants,
> + _cache_variants,
> + _cache_variants),
> + 0,
> + SPINAND_ECCINFO(_ooblayout,
> + mx35lf1ge4ab_ecc_get_status)),
> + SPINAND_INFO("MX35LF4GE4AD",
> + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x37),
> + NAND_MEMORG(1, 4096, 128, 64, 2048, 40, 1, 1, 1),
> + NAND_ECCREQ(8, 512),
> + SPINAND_INFO_OP_VARIANTS(_cache_variants,
> + _cache_variants,
> + _cache_variants),
> + 0,
> + SPINAND_ECCINFO(_ooblayout,
> + mx35lf1ge4ab_ecc_get_status)),
> SPINAND_INFO("MX31LF1GE4BC",
>SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x1e),
>NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1),
Thanks,
Miquèl
Re: [PATCH 2/4] clk: sifive: Use common name for prci configuration
On Thu, Nov 5, 2020 at 10:46 AM Stephen Boyd wrote: > > Quoting Zong Li (2020-10-16 02:18:24) > > Use generic name CLK_SIFIVE_PRCI instead of CLK_SIFIVE_FU540_PRCI. This > > patch is prepared for fu740 support. > > > > Signed-off-by: Zong Li > > --- > > Looks ok but needs an ack from riscv maintainers to go through clk > tree. I was worried it would break defconfigs but it seems that the arch > selects the config so this should be OK, right? Yes, this config is selected by arch, the defconfig won't be impacted. > > > arch/riscv/Kconfig.socs | 2 +- > > drivers/clk/sifive/Kconfig | 6 +++--- > > drivers/clk/sifive/Makefile | 2 +- > > 3 files changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs > > index 8a55f6156661..3284d5c291be 100644 > > --- a/arch/riscv/Kconfig.socs > > +++ b/arch/riscv/Kconfig.socs > > @@ -5,7 +5,7 @@ config SOC_SIFIVE > > select SERIAL_SIFIVE if TTY > > select SERIAL_SIFIVE_CONSOLE if TTY > > select CLK_SIFIVE > > - select CLK_SIFIVE_FU540_PRCI > > + select CLK_SIFIVE_PRCI > > select SIFIVE_PLIC > > help > > This enables support for SiFive SoC platform hardware.
linux-next: build warnings after merge of the drivers-x86 tree
Hi all,
After merging the drivers-x86 tree, today's linux-next build (htmldocs)
produced these warnings:
Documentation/ABI/testing/sysfs-class-firmware-attributes:2: WARNING:
Unexpected indentation.
Documentation/ABI/testing/sysfs-class-firmware-attributes:2: WARNING:
Unexpected indentation.
Documentation/ABI/testing/sysfs-class-firmware-attributes:2: WARNING: Block
quote ends without a blank line; unexpected unindent.
Documentation/ABI/testing/sysfs-class-firmware-attributes:173: WARNING:
Unexpected indentation.
Documentation/ABI/testing/sysfs-class-firmware-attributes:173: WARNING:
Unexpected indentation.
Documentation/ABI/testing/sysfs-class-firmware-attributes:173: WARNING: Block
quote ends without a blank line; unexpected unindent.
Documentation/ABI/testing/sysfs-class-firmware-attributes:111: WARNING: Inline
emphasis start-string without end-string.
Introduced by commit
e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver
over WMI for Dell Systems")
--
Cheers,
Stephen Rothwell
pgpAn8FzqM9HL.pgp
Description: OpenPGP digital signature
Re: [PATCH] drm/virtio: use kvmalloc for large allocations
Hi, > - *ents = kmalloc_array(*nents, sizeof(struct virtio_gpu_mem_entry), > - GFP_KERNEL); > + *ents = kvmalloc_array(*nents, > +sizeof(struct virtio_gpu_mem_entry), > +GFP_KERNEL); Shouldn't that be balanced with a kvfree() elsewhere? take care, Gerd
linux-next: build warnings after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (htmldocs) produced
these warnings:
include/linux/dma-buf-map.h:106: warning: Excess function parameter 'vaddr'
description in 'DMA_BUF_MAP_INIT_VADDR'
include/linux/dma-buf-map.h:106: warning: Function parameter or member 'vaddr_'
not described in 'DMA_BUF_MAP_INIT_VADDR'
include/linux/dma-buf-map.h:106: warning: Excess function parameter 'vaddr'
description in 'DMA_BUF_MAP_INIT_VADDR'
Introduced by commit
20e76f1a7059 ("dma-buf: Use struct dma_buf_map in dma_buf_vunmap()
interfaces")
--
Cheers,
Stephen Rothwell
pgpWV14A8HQNN.pgp
Description: OpenPGP digital signature
Re: possible deadlock in send_sigio (2)
syzbot has bisected this issue to:
commit e918188611f073063415f40fae568fa4d86d9044
Author: Boqun Feng
Date: Fri Aug 7 07:42:20 2020 +
locking: More accurate annotations for read_lock()
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15fbef3250
start commit: 4ef8451b Merge tag 'perf-tools-for-v5.10-2020-11-03' of gi..
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=17fbef3250
console output: https://syzkaller.appspot.com/x/log.txt?x=13fbef3250
kernel config: https://syzkaller.appspot.com/x/.config?x=4e93228e2f17fb12
dashboard link: https://syzkaller.appspot.com/bug?extid=907b8537e3b0e55151fc
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=160ab4b250
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12cb8e2a50
Reported-by: syzbot+907b8537e3b0e5515...@syzkaller.appspotmail.com
Fixes: e918188611f0 ("locking: More accurate annotations for read_lock()")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH v4 2/4] mfd: Support ROHM BD9576MUF and BD9573MUF
Morning Lee,
Thanks for taking a look at this :) I see most of the comments being
valid. There's two I would like to clarify though...
On Wed, 2020-11-04 at 15:51 +, Lee Jones wrote:
> On Wed, 28 Oct 2020, Matti Vaittinen wrote:
>
> > Add core support for ROHM BD9576MUF and BD9573MUF PMICs which are
> > mainly used to power the R-Car series processors.
> >
> > Signed-off-by: Matti Vaittinen
> > ---
> > + unsigned int chip_type;
> > +
> > + chip_type = (unsigned int)(uintptr_t)
> > + of_device_get_match_data(>dev);
>
> Not overly keen on this casting.
>
> Why not just leave it as (uintptr_t)?
I didn't do so because on x86_64 the address width is probably 64 bits
whereas the unsigned int is likely to be 32 bits. So the assignment
will crop half of the value. It does not really matter as values are
small - but I would be surprized if no compilers/analyzers emitted a
warning.
I must admit I am not 100% sure though. I sure can change this if you
know it better?
> What happens when you don't cast to (uintptr_t) first?
On some systems at least the gcc will warn:
> warning: cast from pointer to integer of different size [-Wpointer-
to-int-cast]
I am pretty sure I did end up this double casting via trial and error
:)
+
> > +static const struct of_device_id bd957x_of_match[] = {
> > + {
> > + .compatible = "rohm,bd9576",
> > + .data = (void *)ROHM_CHIP_TYPE_BD9576,
> > + },
> > + {
>
> You could put the 2 lines above on a single line.
Braces? I put braces on separate lines on purpose. Been doing this
after we had this discussion:
https://lore.kernel.org/lkml/20180705055226.GJ496@dell/
https://lore.kernel.org/lkml/20180706070559.GW496@dell/
;)
I can change it if you wishfeel it is important - not a point I feel
like fighting over ;)
>
> > + .compatible = "rohm,bd9573",
> > + .data = (void *)ROHM_CHIP_TYPE_BD9573,
> > + },
> > + { },
> > +};
> > +MODULE_DEVICE_TABLE(of, bd957x_of_match);
Best Regards
Matti
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland
SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
"non cogito me" dixit Rene Descarte, deinde evanescavit
(Thanks for the translation Simon)
linux-next: build warning after merge of the akpm-current tree
Hi all,
After merging the akpm-current tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/filesystems/proc.rst:296: WARNING: Malformed table.
Text in column margin in table line 61.
== ===
Field Content
== ===
Namefilename of the executable
Umask file mode creation mask
State state (R is running, S is sleeping, D is sleeping
in an uninterruptible wait, Z is zombie,
T is traced or stopped)
Tgidthread group ID
NgidNUMA group ID (0 if none)
Pid process id
PPidprocess id of the parent process
TracerPid PID of process tracing this process (0 if not)
Uid Real, effective, saved set, and file system UIDs
Gid Real, effective, saved set, and file system GIDs
FDSize number of file descriptor slots currently allocated
Groups supplementary group list
NStgid descendant namespace thread group ID hierarchy
NSpid descendant namespace process ID hierarchy
NSpgid descendant namespace process group ID hierarchy
NSsid descendant namespace session ID hierarchy
VmPeak peak virtual memory size
VmSize total program size
VmLck locked memory size
VmPin pinned memory size
VmHWM peak resident set size ("high water mark")
VmRSS size of memory portions. It contains the three
following parts
(VmRSS = RssAnon + RssFile + RssShmem)
RssAnon size of resident anonymous memory
RssFile size of resident file mappings
RssShmemsize of resident shmem memory (includes SysV shm,
mapping of tmpfs and shared anonymous mappings)
VmData size of private data segments
VmStk size of stack segments
VmExe size of text segment
VmLib size of shared library code
VmPTE size of page table entries
VmSwap amount of swap used by anonymous private data
(shmem swap usage is not included)
HugetlbPagessize of hugetlb memory portions
CoreDumping process's memory is currently being dumped
(killing the process may lead to a corrupted core)
THP_enabled process is allowed to use THP (returns 0 when
PR_SET_THP_DISABLE is set on the process
Threads number of threads
SigQnumber of signals queued/max. number for queue
SigPnd bitmap of pending signals for the thread
ShdPnd bitmap of shared pending signals for the process
SigBlk bitmap of blocked signals
SigIgn bitmap of ignored signals
SigCgt bitmap of caught signals
CapInh bitmap of inheritable capabilities
CapPrm bitmap of permitted capabilities
CapEff bitmap of effective capabilities
CapBnd bitmap of capabilities bounding set
CapAmb bitmap of ambient capabilities
NoNewPrivs no_new_privs, like prctl(PR_GET_NO_NEW_PRIV, ...)
Seccomp seccomp mode, like prctl(PR_GET_SECCOMP, ...)
Speculation_Store_Bypassspeculative store bypass mitigation status
Speculation_Indirect_Branch indirect branch speculation mode
Cpus_allowedmask of CPUs on which this process may run
Cpus_allowed_list Same as previous, but in "list format"
Mems_allowedmask of memory nodes allowed to this process
Mems_allowed_list Same as previous, but in "list format"
voluntary_ctxt_switches number of voluntary context switches
nonvoluntary_ctxt_switches number of non voluntary context switches
== ===
Documentation/filesystems/proc.rst:234: WARNING: Error parsing content block
for the "table" directive: exactly one table expected.
.. table:: Table 1-2: Contents of the status files (as of 4.19)
== ===
Field Content
== ===
Name
Re: [RFC PATCH] .clang-format: Remove conditional comments
On Thu, Nov 5, 2020 at 1:35 AM Nick Desaulniers wrote: > > I'll help you paint your bikeshed. Oh, but what color? I see a red > door, and I want it painted black. > > Sounds to me like Miguel could win over a critic by addressing some of > your (quite valid) concerns. ;) I am happy to take the patch, but we need to at least enable other features that were added meanwhile -- that is the advantage of increasing the minimum! If someone wants to take a look (wink, wink -- Joe, you are very experienced with all the different styles used around the kernel and would be great to have you on board with clang-format), they can use the following list for starters. There are a few important new features: - AlignConsecutiveMacros is probably one of the biggest one for the kernel that we were missing so far. - IndentPPDirectives and AlignEscapedNewlines would be very good to use too -- but the kernel style is not consistent AFAIK, so we would need to decide. Then there are a few others that pertain to us too: - SpaceBeforeSquareBrackets - SpacesInConditionalStatement - SpaceAfterLogicalNot - SpaceInEmptyBlock - IndentGotoLabels Others are also worth checking to see if we can take advantage of them: - IncludeBlocks (and configuring IncludeCategories etc.) - StatementMacros Then there are others that are not related to us, but to be consistent we would explicitly set them in the file. Finally, for extra points, we could already document the new ones in LLVM 11 if any, for the future, but that is optional. If no one is up for the task, I will eventually do it... :-) Cheers, Miguel
Re: [PATCH v2 net] net: sch_generic: aviod concurrent reset and enqueue op for lockless qdisc
On 2020/11/5 14:16, Cong Wang wrote: > On Wed, Nov 4, 2020 at 10:04 PM Cong Wang wrote: >> >> On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote: > From my understanding, we can do anything about the old qdisc (including > destorying the old qdisc) after some_qdisc_is_busy() return false. But the current code does the reset _before_ some_qdisc_is_busy(). ;) >>> >>> If lock is taken when doing reset, it does not matter if the reset is >>> before some_qdisc_is_busy(), right? >> >> Why not? How about the following scenario? >> >> CPU0: CPU1: >> dev_reset_queue() >> net_tx_action() >> -> sch_direct_xmit() >>-> dev_requeue_skb() >> some_qdisc_is_busy() >> // waiting for TX action on CPU1 >> // now some packets are requeued > > Never mind, the skb_bad_txq is also cleared by dev_reset_queue(). > TX action after resetting should get NULL. Yes, maybe it is safe to remove qdisc_reset() now? or issue a warning if there are still skb in the qdisc. > > Thanks. > . >
Re: [PATCH] futex: Handle transient "ownerless" rtmutex state correctly
Thomas Gleixner writes:
> From: Mike Galbraith
>
> Gratian managed to trigger the BUG_ON(!newowner) in fixup_pi_state_owner().
> This is one possible chain of events leading to this:
>
> Task Prio Operation
> T1 120 lock(F)
> T2 120 lock(F) -> blocks (top waiter)
> T3 50 (RT) lock(F) -> boosts T3 and blocks (new top waiter)
> XXtimeout/ -> wakes T2
> signal
> T1 50 unlock(F) -> wakes T3 (rtmutex->owner == NULL, waiter
> bit is set)
> T2 120 cleanup -> try_to_take_mutex() fails because T3 is the top
> waiter
>and the lower priority T2 cannot steal the lock.
> -> fixup_pi_state_owner() sees newowner == NULL ->
> BUG_ON()
>
> The comment states that this is invalid and rt_mutex_real_owner() must
> return a non NULL owner when the trylock failed, but in case of a queued
> and woken up waiter rt_mutex_real_owner() == NULL is a valid transient
> state. The higher priority waiter has simply not yet managed to take over
> the rtmutex.
>
> The BUG_ON() is therefore wrong and this is just another retry condition in
> fixup_pi_state_owner().
>
> Drop the locks, so that T3 can make progress, and then try the fixup again.
>
> Gratian provided a great analysis, traces and a reproducer. The analysis is
> to the point, but it confused the hell out of that tglx dude who had to
> page in all the futex horrors again. Condensed version is above.
>
> [ tglx: Wrote comment and changelog ]
>
> Fixes: c1e2f0eaf015 ("futex: Avoid violating the 10th rule of futex")
> Reported-by: Gratian Crisan
> Signed-off-by: Mike Galbraith
> Signed-off-by: Thomas Gleixner
> Cc: sta...@vger.kernel.org
> Link:
> https://urldefense.com/v3/__https://lore.kernel.org/r/87a6w6x7bb.fsf@ni.com__;!!FbZ0ZwI3Qg!5INAsNbAVSp3jaNkkjFazSRC86BpcZnVM3-oTDYl0KijU6jA5pWYk4KI79_L5F4$
>
LGTM, no crashes in my testing today.
-Gratian
> ---
> kernel/futex.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -2380,10 +2380,22 @@ static int fixup_pi_state_owner(u32 __us
> }
>
> /*
> - * Since we just failed the trylock; there must be an owner.
> + * The trylock just failed, so either there is an owner or
> + * there is a higher priority waiter than this one.
>*/
> newowner = rt_mutex_owner(_state->pi_mutex);
> - BUG_ON(!newowner);
> + /*
> + * If the higher priority waiter has not yet taken over the
> + * rtmutex then newowner is NULL. We can't return here with
> + * that state because it's inconsistent vs. the user space
> + * state. So drop the locks and try again. It's a valid
> + * situation and not any different from the other retry
> + * conditions.
> + */
> + if (unlikely(!newowner)) {
> + ret = -EAGAIN;
> + goto handle_err;
> + }
> } else {
> WARN_ON_ONCE(argowner != current);
> if (oldowner == current) {
Re: [PATCH] applesmc: Re-work SMC comms v1
On Thu, Nov 05, 2020 at 04:47:25PM +1100, Brad Campbell wrote:
> Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()") introduced
> an issue whereby communication with the SMC became unreliable with write
> errors :
>
> [ 120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> [ 120.378621] applesmc: LKSB: write data fail
> [ 120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
> [ 120.512787] applesmc: LKSB: write data fail
>
> The original code appeared to be timing sensitive and was not reliable with
> the timing changes in the aforementioned commit.
>
> This patch re-factors the SMC communication to remove the timing
> dependencies and restore function with the changes previously committed.
>
> Reported-by: Andreas Kemnade
Add
Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
> Signed-off-by: Brad Campbell
>
> ---
> diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
> index a18887990f4a..22cc5122ce9a 100644
> --- a/drivers/hwmon/applesmc.c
> +++ b/drivers/hwmon/applesmc.c
> @@ -42,6 +42,11 @@
>
> #define APPLESMC_MAX_DATA_LENGTH 32
>
> +/* Apple SMC status bits from VirtualSMC */
> +#define SMC_STATUS_AWAITING_DATA 0x01 ///< Data waiting to be read
> +#define SMC_STATUS_IB_CLOSED 0x02 /// A write is pending / will ignore
> input
> +#define SMC_STATUS_BUSY 0x04 ///< Busy in the middle of a command.
> +
Maybe consider using BIT() while at it.
/* Please use standard comments */
Also, what does the "<" mean ? Is that supposed to be negated
(ie bit set means not busy) ? If so, that isn't a standard notation
that I am aware of. Maybe "not set if busy in the middle of a command"
would be better in this case.
> /* wait up to 128 ms for a status change. */
> #define APPLESMC_MIN_WAIT0x0010
> #define APPLESMC_RETRY_WAIT 0x0100
> @@ -151,65 +156,77 @@ static unsigned int key_at_index;
> static struct workqueue_struct *applesmc_led_wq;
>
> /*
> - * wait_read - Wait for a byte to appear on SMC port. Callers must
> - * hold applesmc_lock.
> + * Wait for specific status bits with a mask on the SMC
> + * Used before and after writes, and before reads
> */
> -static int wait_read(void)
> +
> +static int wait_status(u8 val, u8 mask)
> {
> unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
> u8 status;
> int us;
>
> for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
> - usleep_range(us, us * 16);
> status = inb(APPLESMC_CMD_PORT);
> - /* read: wait for smc to settle */
> - if (status & 0x01)
> + if ((status & mask) == val)
> return 0;
> /* timeout: give up */
> if (time_after(jiffies, end))
> break;
> - }
> -
> - pr_warn("wait_read() fail: 0x%02x\n", status);
> + usleep_range(us, us * 16);
> + }
> + pr_warn("wait_status timeout: 0x%02x, 0x%02x, 0x%02x\n", status, val,
> mask);
> return -EIO;
> }
>
> /*
> - * send_byte - Write to SMC port, retrying when necessary. Callers
> + * send_byte_data - Write to SMC data port. Callers
> * must hold applesmc_lock.
> + * Parameter skip must be true on the last write of any
> + * command or it'll time out.
> */
> -static int send_byte(u8 cmd, u16 port)
I would suggest to keep send_byte() and change it to the following.
static int send_byte(u8 cmd, u16 port)
{
return send_byte_data(cmd, port, false);
}
That would limit the number of changes needed later in the code
(it is never called with a hard 'true' as parameter).
> +
> +static int send_byte_data(u8 cmd, u16 port, bool skip)
> {
> - u8 status;
> - int us;
> - unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
> + u8 wstat = SMC_STATUS_BUSY;
>
> + if (skip)
> + wstat = 0;
u8 wstat = skip ? 0 : SMC_STATUS_BUSY;
> + if (wait_status(SMC_STATUS_BUSY,
> + SMC_STATUS_BUSY | SMC_STATUS_IB_CLOSED))
This fits one line, and the error code
should really not be overwritten.
ret = wait_status(SMC_STATUS_BUSY, SMC_STATUS_BUSY |
SMC_STATUS_IB_CLOSED);
if (ret)
return ret;
> + goto fail;
> outb(cmd, port);
> - for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
> - usleep_range(us, us * 16);
> - status = inb(APPLESMC_CMD_PORT);
> - /* write: wait for smc to settle */
> - if (status & 0x02)
> - continue;
> - /* ready: cmd accepted, return */
> - if (status & 0x04)
> - return 0;
> - /* timeout: give up */
> - if (time_after(jiffies, end))
> - break;
> - /* busy: long wait and resend */
> - udelay(APPLESMC_RETRY_WAIT);
> - outb(cmd, port);
> - }
> -
> -
Re: [PATCH v5 06/17] virt: acrn: Introduce VM management interfaces
On Thu, Nov 05, 2020 at 11:10:29AM +0800, Shuo A Liu wrote:
> On Wed 4.Nov'20 at 20:02:35 +0100, Greg Kroah-Hartman wrote:
> > On Mon, Oct 19, 2020 at 02:17:52PM +0800, shuo.a@intel.com wrote:
> > > --- /dev/null
> > > +++ b/include/uapi/linux/acrn.h
> > > @@ -0,0 +1,56 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > > +/*
> > > + * Userspace interface for /dev/acrn_hsm - ACRN Hypervisor Service Module
> > > + *
> > > + * This file can be used by applications that need to communicate with
> > > the HSM
> > > + * via the ioctl interface.
> > > + */
> > > +
> > > +#ifndef _UAPI_ACRN_H
> > > +#define _UAPI_ACRN_H
> > > +
> > > +#include
> > > +
> > > +/**
> > > + * struct acrn_vm_creation - Info to create a User VM
> > > + * @vmid:User VM ID returned from the hypervisor
> > > + * @reserved0: Reserved
> > > + * @vcpu_num:Number of vCPU in the VM. Return from
> > > hypervisor.
> > > + * @reserved1: Reserved
> > > + * @uuid:UUID of the VM. Pass to hypervisor directly.
> > > + * @vm_flag: Flag of the VM creating. Pass to hypervisor
> > > directly.
> > > + * @ioreq_buf: Service VM GPA of I/O request buffer. Pass to
> > > + * hypervisor directly.
> > > + * @cpu_affinity:CPU affinity of the VM. Pass to hypervisor
> > > directly.
> > > + * @reserved2: Reserved
> >
> > Reserved and must be 0?
>
> Not a must.
That's guaranteed to come back and bite you in the end. You all have
read the "how to write a good api" document, right?
> > What are they reserved for?
> >
> > Same for all of the reserved fields, why?
>
> Some reserved fields are to map layout in the hypervisor side, others
> are for future use.
ioctls should not have these, again, please read the documentation. If
you need something new in the future, just make a new ioctl.
> > > + */
> > > +struct acrn_vm_creation {
> > > + __u16 vmid;
> > > + __u16 reserved0;
> > > + __u16 vcpu_num;
> > > + __u16 reserved1;
> > > + __u8uuid[16];
> >
> > We have a userspace-visable uid structure in include/uapi/uuid.h, why
> > not use that?
>
> we just pass the uuid data from user space to hypervisor. So, we can
> remove a header dependeny with using raw data format.
I do not understand this, please use the built-in kernel types we have.
thanks,
greg k-h
Re: [PATCH 1/2] lockdep: Avoid to modify chain keys in validate_chain()
Hi Chris,
Could you try this to see if it fixes the problem? Thanks!
Regards,
Boqun
On Mon, Nov 02, 2020 at 01:37:41PM +0800, Boqun Feng wrote:
> Chris Wilson reported a problem spotted by check_chain_key(): a chain
> key got changed in validate_chain() because we modify the ->read in
> validate_chain() to skip checks for dependency adding, and ->read is
> taken into calculation for chain key since commit f611e8cf98ec
> ("lockdep: Take read/write status in consideration when generate
> chainkey").
>
> Fix this by avoiding to modify ->read in validate_chain() based on two
> facts: a) since we now support recursive read lock detection, there is
> no need to skip checks for dependency adding for recursive readers, b)
> since we have a), there is only one case left (nest_lock) where we want
> to skip checks in validate_chain(), we simply remove the modification
> for ->read and rely on the return value of check_deadlock() to skip the
> dependency adding.
>
> Reported-by: Chris Wilson
> Signed-off-by: Boqun Feng
> Cc: Peter Zijlstra
> ---
> Peter,
>
> I managed to get a reproducer for the problem Chris reported, please see
> patch #2. With this patch, that problem gets fixed.
>
> This small patchset is based on your locking/core, patch #2 actually
> relies on your "s/raw_spin/spin" changes, thanks for taking care of that
> ;-)
>
> Regards,
> Boqun
>
> kernel/locking/lockdep.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 3e99dfef8408..a294326fd998 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -2765,7 +2765,9 @@ print_deadlock_bug(struct task_struct *curr, struct
> held_lock *prev,
> * (Note that this has to be done separately, because the graph cannot
> * detect such classes of deadlocks.)
> *
> - * Returns: 0 on deadlock detected, 1 on OK, 2 on recursive read
> + * Returns: 0 on deadlock detected, 1 on OK, 2 if another lock with the same
> + * lock class is held but nest_lock is also held, i.e. we rely on the
> + * nest_lock to avoid the deadlock.
> */
> static int
> check_deadlock(struct task_struct *curr, struct held_lock *next)
> @@ -2788,7 +2790,7 @@ check_deadlock(struct task_struct *curr, struct
> held_lock *next)
>* lock class (i.e. read_lock(lock)+read_lock(lock)):
>*/
> if ((next->read == 2) && prev->read)
> - return 2;
> + continue;
>
> /*
>* We're holding the nest_lock, which serializes this lock's
> @@ -3592,16 +3594,13 @@ static int validate_chain(struct task_struct *curr,
>
> if (!ret)
> return 0;
> - /*
> - * Mark recursive read, as we jump over it when
> - * building dependencies (just like we jump over
> - * trylock entries):
> - */
> - if (ret == 2)
> - hlock->read = 2;
> /*
>* Add dependency only if this lock is not the head
> - * of the chain, and if it's not a secondary read-lock:
> + * of the chain, and if the new lock introduces no more
> + * lock dependency (because we already hold a lock with the
> + * same lock class) nor deadlock (because the nest_lock
> + * serializes nesting locks), see the comments for
> + * check_deadlock().
>*/
> if (!chain_head && ret != 2) {
> if (!check_prevs_add(curr, hlock))
> --
> 2.28.0
>
Re: possible deadlock in send_sigurg (2)
Hi,
On Wed, Nov 04, 2020 at 04:18:08AM -0800, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit e918188611f073063415f40fae568fa4d86d9044
> Author: Boqun Feng
> Date: Fri Aug 7 07:42:20 2020 +
>
> locking: More accurate annotations for read_lock()
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1414273250
> start commit: 4ef8451b Merge tag 'perf-tools-for-v5.10-2020-11-03' of gi..
> git tree: upstream
> final oops: https://syzkaller.appspot.com/x/report.txt?x=1614273250
> console output: https://syzkaller.appspot.com/x/log.txt?x=1214273250
> kernel config: https://syzkaller.appspot.com/x/.config?x=61033507391c77ff
> dashboard link: https://syzkaller.appspot.com/bug?extid=c5e32344981ad9f33750
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1519786250
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13c59f6c50
>
> Reported-by: syzbot+c5e32344981ad9f33...@syzkaller.appspotmail.com
> Fixes: e918188611f0 ("locking: More accurate annotations for read_lock()")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Thanks for reporting this, and this is actually a deadlock potential
detected by the newly added recursive read deadlock detection as my
analysis:
https://lore.kernel.org/lkml/20200910071523.gf7...@debian-boqun.qqnc3lrjykvubdpftowmye0fmh.lx.internal.cloudapp.net
Besides, other reports[1][2] are caused by the same problem. I made a
fix for this, please have a try and see if it's get fixed.
Regards,
Boqun
[1]: https://lore.kernel.org/lkml/d7136005aee14...@google.com
[2]: https://lore.kernel.org/lkml/6e29ed05b3009...@google.com
->8
>From 7fbe730fcff2d7909be034cf6dc8bf0604d0bf14 Mon Sep 17 00:00:00 2001
From: Boqun Feng
Date: Thu, 5 Nov 2020 14:02:57 +0800
Subject: [PATCH] fs/fcntl: Fix potential deadlock in send_sig{io, urg}()
Syzbot reports a potential deadlock found by the newly added recursive
read deadlock detection in lockdep:
[...]
[...] WARNING: possible irq lock inversion dependency detected
[...] 5.9.0-rc2-syzkaller #0 Not tainted
[...]
[...] syz-executor.1/10214 just changed the state of lock:
[...] 88811f506338 (>f_owner.lock){.+..}-{2:2}, at:
send_sigurg+0x1d/0x200
[...] but this lock was taken by another, HARDIRQ-safe lock in the past:
[...] (>event_lock){-...}-{2:2}
[...]
[...]
[...] and interrupts could create inverse lock ordering between them.
[...]
[...]
[...] other info that might help us debug this:
[...] Chain exists of:
[...] >event_lock --> >fa_lock --> >f_owner.lock
[...]
[...] Possible interrupt unsafe locking scenario:
[...]
[...]CPU0CPU1
[...]
[...] lock(>f_owner.lock);
[...]local_irq_disable();
[...]lock(>event_lock);
[...]lock(>fa_lock);
[...]
[...] lock(>event_lock);
[...]
[...] *** DEADLOCK ***
The corresponding deadlock case is as followed:
CPU 0 CPU 1 CPU 2
read_lock(>lock);
spin_lock_irqsave(>event_lock, ...)
write_lock_irq(>f_owner.lock); //
wait for the lock
read_lock(); // have to wait until the writer
release
// due to the fairness
spin_lock_irqsave(>event_lock); // wait for the lock
The lock dependency on CPU 1 happens if there exists a call sequence:
input_inject_event():
spin_lock_irqsave(>event_lock,...);
input_handle_event():
input_pass_values():
input_to_handler():
handler->event(): // evdev_event()
evdev_pass_values():
spin_lock(>buffer_lock);
__pass_event():
kill_fasync():
kill_fasync_rcu():
read_lock(>fa_lock);
send_sigio():
read_lock(>lock);
To fix this, make the reader in send_sigurg() and send_sigio() use
read_lock_irqsave() and read_lock_irqrestore().
Reported-by: syzbot+22e87cdf94021b984...@syzkaller.appspotmail.com
Reported-by: syzbot+c5e32344981ad9f33...@syzkaller.appspotmail.com
Signed-off-by: Boqun Feng
---
fs/fcntl.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 19ac5baad50f..05b36b28f2e8 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -781,9 +781,10 @@ void send_sigio(struct fown_struct *fown, int fd, int band)
{
struct task_struct *p;
enum pid_type type;
+ unsigned long flags;
struct pid *pid;
-
Re: [PATCH v2 net] net: sch_generic: aviod concurrent reset and enqueue op for lockless qdisc
On 2020/11/5 14:04, Cong Wang wrote: > On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote: From my understanding, we can do anything about the old qdisc (including destorying the old qdisc) after some_qdisc_is_busy() return false. >>> >>> But the current code does the reset _before_ some_qdisc_is_busy(). ;) >> >> If lock is taken when doing reset, it does not matter if the reset is >> before some_qdisc_is_busy(), right? > > Why not? How about the following scenario? > > CPU0: CPU1: > dev_reset_queue() There is no skb in the dqisc now. > net_tx_action() > -> sch_direct_xmit() So when CPU1 calls net_tx_action(), there is no skb to send and no skb to be requeued too. >-> dev_requeue_skb() > some_qdisc_is_busy() > // waiting for TX action on CPU1 > // now some packets are requeued >
Re: [PATCH v2 net] net: sch_generic: aviod concurrent reset and enqueue op for lockless qdisc
On Wed, Nov 4, 2020 at 10:04 PM Cong Wang wrote: > > On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote: > > >> From my understanding, we can do anything about the old qdisc (including > > >> destorying the old qdisc) after some_qdisc_is_busy() return false. > > > > > > But the current code does the reset _before_ some_qdisc_is_busy(). ;) > > > > If lock is taken when doing reset, it does not matter if the reset is > > before some_qdisc_is_busy(), right? > > Why not? How about the following scenario? > > CPU0: CPU1: > dev_reset_queue() > net_tx_action() > -> sch_direct_xmit() >-> dev_requeue_skb() > some_qdisc_is_busy() > // waiting for TX action on CPU1 > // now some packets are requeued Never mind, the skb_bad_txq is also cleared by dev_reset_queue(). TX action after resetting should get NULL. Thanks.
KINDEST MESSAGE.
Dear, My name is Mr Tofil Bama, I am the Bill and Exchange assistant Manager in Bank of Africa Ouagadougou Burkina Faso. In my department I discovered an abandoned sum of eighteen million three hundred thousand United State of American dollars (18.3MILLION USA DOLLARS) in an account that belongs to one of our foreign customer (late Mr Shitu Nuri) who died in Ethiopian Airlines Flight 409 that crashed into the Mediterranean Sea on 25th January 2010. Since I got information about his death I have been expecting his next of kin to come over and claim his money because we cannot release it unless somebody applies for it as the next of kin or relation to the deceased as indicated in our banking guidelines, unfortunately we learnt that all his supposed next of kin or relation died alongside with him in the plane crash leaving nobody behind for the claim. It is therefore upon this discovery that I decided to make this business proposal to you and release the money to you as next of kin to the deceased for safety and subsequent disbursement since nobody is coming for the fund, it is 10 years now the money is lying pending in the account of our deceased and I don't want the money to go into the bank treasury as unclaimed bill. You will be entitled with 40% of the total sum while 60% will be for me after which I will visit your Country to invest my own share when the fund is successfully transferred into your account, Please I would like you to keep this transaction confidential and as a top secret between me and you until we successfully achieve this golden opportunity. Yours sincerely, Mr Tofil Bama.
Re: [PATCH] KVM: x86: use positive error values for msr emulation that causes #GP
> Recent introduction of the userspace msr filtering added code that uses
> negative error codes for cases that result in either #GP delivery to
> the guest, or handled by the userspace msr filtering.
>
> This breaks an assumption that a negative error code returned from the
> msr emulation code is a semi-fatal error which should be returned
> to userspace via KVM_RUN ioctl and usually kill the guest.
>
> Fix this by reusing the already existing KVM_MSR_RET_INVALID error code,
> and by adding a new KVM_MSR_RET_FILTERED error code for the
> userspace filtered msrs.
>
> Fixes: 291f35fb2c1d1 ("KVM: x86: report negative values from wrmsr emulation
> to userspace")
> Reported-by: Qian Cai
> Signed-off-by: Maxim Levitsky
> ---
> arch/x86/kvm/x86.c | 29 +++--
> arch/x86/kvm/x86.h | 8 +++-
> 2 files changed, 22 insertions(+), 15 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 397f599b20e5a..537130d78b2af 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -255,11 +255,10 @@ static struct kmem_cache *x86_emulator_cache;
>
> /*
> * When called, it means the previous get/set msr reached an invalid msr.
> - * Return 0 if we want to ignore/silent this failed msr access, or 1 if we
> want
> - * to fail the caller.
> + * Return true if we want to ignore/silent this failed msr access.
> */
> -static int kvm_msr_ignored_check(struct kvm_vcpu *vcpu, u32 msr,
> -u64 data, bool write)
> +static bool kvm_msr_ignored_check(struct kvm_vcpu *vcpu, u32 msr,
> + u64 data, bool write)
> {
> const char *op = write ? "wrmsr" : "rdmsr";
>
> @@ -267,12 +266,11 @@ static int kvm_msr_ignored_check(struct kvm_vcpu *vcpu,
> u32 msr,
> if (report_ignored_msrs)
> vcpu_unimpl(vcpu, "ignored %s: 0x%x data 0x%llx\n",
> op, msr, data);
> - /* Mask the error */
> - return 0;
> + return true;
> } else {
> vcpu_debug_ratelimited(vcpu, "unhandled %s: 0x%x data
> 0x%llx\n",
>op, msr, data);
> - return -ENOENT;
> + return false;
> }
> }
>
> @@ -1416,7 +1414,8 @@ static int do_get_msr_feature(struct kvm_vcpu *vcpu,
> unsigned index, u64 *data)
> if (r == KVM_MSR_RET_INVALID) {
> /* Unconditionally clear the output for simplicity */
> *data = 0;
> - r = kvm_msr_ignored_check(vcpu, index, 0, false);
> + if (kvm_msr_ignored_check(vcpu, index, 0, false))
> + r = 0;
> }
>
> if (r)
> @@ -1540,7 +1539,7 @@ static int __kvm_set_msr(struct kvm_vcpu *vcpu, u32
> index, u64 data,
> struct msr_data msr;
>
> if (!host_initiated && !kvm_msr_allowed(vcpu, index,
> KVM_MSR_FILTER_WRITE))
> - return -EPERM;
> + return KVM_MSR_RET_FILTERED;
>
> switch (index) {
> case MSR_FS_BASE:
> @@ -1581,7 +1580,8 @@ static int kvm_set_msr_ignored_check(struct kvm_vcpu
> *vcpu,
> int ret = __kvm_set_msr(vcpu, index, data, host_initiated);
>
> if (ret == KVM_MSR_RET_INVALID)
> - ret = kvm_msr_ignored_check(vcpu, index, data, true);
> + if (kvm_msr_ignored_check(vcpu, index, data, true))
> + ret = 0;
>
> return ret;
> }
> @@ -1599,7 +1599,7 @@ int __kvm_get_msr(struct kvm_vcpu *vcpu, u32 index, u64
> *data,
> int ret;
>
> if (!host_initiated && !kvm_msr_allowed(vcpu, index,
> KVM_MSR_FILTER_READ))
> - return -EPERM;
> + return KVM_MSR_RET_FILTERED;
>
> msr.index = index;
> msr.host_initiated = host_initiated;
> @@ -1618,7 +1618,8 @@ static int kvm_get_msr_ignored_check(struct kvm_vcpu
> *vcpu,
> if (ret == KVM_MSR_RET_INVALID) {
> /* Unconditionally clear *data for simplicity */
> *data = 0;
> - ret = kvm_msr_ignored_check(vcpu, index, 0, false);
> + if (kvm_msr_ignored_check(vcpu, index, 0, false))
> + ret = 0;
> }
>
> return ret;
> @@ -1662,9 +1663,9 @@ static int complete_emulated_wrmsr(struct kvm_vcpu
> *vcpu)
> static u64 kvm_msr_reason(int r)
> {
> switch (r) {
> - case -ENOENT:
> + case KVM_MSR_RET_INVALID:
> return KVM_MSR_EXIT_REASON_UNKNOWN;
> - case -EPERM:
> + case KVM_MSR_RET_FILTERED:
> return KVM_MSR_EXIT_REASON_FILTER;
> default:
> return KVM_MSR_EXIT_REASON_INVAL;
> diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> index 3900ab0c6004d..e7ca622a468f5 100644
> --- a/arch/x86/kvm/x86.h
> +++ b/arch/x86/kvm/x86.h
> @@ -376,7 +376,13 @@ int kvm_handle_memory_failure(struct kvm_vcpu *vcpu, int
> r,
>
[RFC, v0 3/3] vfio/platform: add Broadcom msi module
Add Broadcom msi module for platform devices.
Signed-off-by: Vikas Gupta
---
drivers/vfio/platform/Kconfig | 1 +
drivers/vfio/platform/Makefile| 1 +
drivers/vfio/platform/msi/Kconfig | 9 +++
drivers/vfio/platform/msi/Makefile| 2 +
.../vfio/platform/msi/vfio_platform_bcmplt.c | 74 +++
5 files changed, 87 insertions(+)
create mode 100644 drivers/vfio/platform/msi/Kconfig
create mode 100644 drivers/vfio/platform/msi/Makefile
create mode 100644 drivers/vfio/platform/msi/vfio_platform_bcmplt.c
diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig
index dc1a3c44f2c6..7b8696febe61 100644
--- a/drivers/vfio/platform/Kconfig
+++ b/drivers/vfio/platform/Kconfig
@@ -21,3 +21,4 @@ config VFIO_AMBA
If you don't know what to do here, say N.
source "drivers/vfio/platform/reset/Kconfig"
+source "drivers/vfio/platform/msi/Kconfig"
diff --git a/drivers/vfio/platform/Makefile b/drivers/vfio/platform/Makefile
index 3f3a24e7c4ef..9ccdcdbf0e7e 100644
--- a/drivers/vfio/platform/Makefile
+++ b/drivers/vfio/platform/Makefile
@@ -5,6 +5,7 @@ vfio-platform-y := vfio_platform.o
obj-$(CONFIG_VFIO_PLATFORM) += vfio-platform.o
obj-$(CONFIG_VFIO_PLATFORM) += vfio-platform-base.o
obj-$(CONFIG_VFIO_PLATFORM) += reset/
+obj-$(CONFIG_VFIO_PLATFORM) += msi/
vfio-amba-y := vfio_amba.o
diff --git a/drivers/vfio/platform/msi/Kconfig
b/drivers/vfio/platform/msi/Kconfig
new file mode 100644
index ..54d6b70e1e32
--- /dev/null
+++ b/drivers/vfio/platform/msi/Kconfig
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config VFIO_PLATFORM_BCMPLT_MSI
+ tristate "MSI support for Broadcom platform devices"
+ depends on VFIO_PLATFORM && (ARCH_BCM_IPROC || COMPILE_TEST)
+ default ARCH_BCM_IPROC
+ help
+ Enables the VFIO platform driver to handle msi for Broadcom devices
+
+ If you don't know what to do here, say N.
diff --git a/drivers/vfio/platform/msi/Makefile
b/drivers/vfio/platform/msi/Makefile
new file mode 100644
index ..27422d45cecb
--- /dev/null
+++ b/drivers/vfio/platform/msi/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_VFIO_PLATFORM_BCMPLT_MSI) += vfio_platform_bcmplt.o
diff --git a/drivers/vfio/platform/msi/vfio_platform_bcmplt.c
b/drivers/vfio/platform/msi/vfio_platform_bcmplt.c
new file mode 100644
index ..b97a571e90a9
--- /dev/null
+++ b/drivers/vfio/platform/msi/vfio_platform_bcmplt.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 Broadcom.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "../vfio_platform_private.h"
+
+#define RING_SIZE (64 << 10)
+
+#define RING_MSI_ADDR_LS 0x03c
+#define RING_MSI_ADDR_MS 0x040
+#define RING_MSI_DATA_VALUE0x064
+
+static u32 bcm_num_msi(struct vfio_platform_device *vdev)
+{
+ struct vfio_platform_region *reg = >regions[0];
+
+ return (reg->size / RING_SIZE);
+}
+
+static int bcm_write_msi(struct vfio_platform_device *vdev,
+struct msi_desc *desc,
+struct msi_msg *msg)
+{
+ void __iomem *ring;
+ u32 msi_off = vdev->num_irqs - vdev->num_msis;
+ int ring_num = desc->irq - vdev->irqs[msi_off].hwirq;
+ struct vfio_platform_region *reg = >regions[0];
+
+ if (!reg->ioaddr) {
+ reg->ioaddr = ioremap(reg->addr, reg->size);
+ if (!reg->ioaddr)
+ return -ENOMEM;
+ }
+
+ ring = reg->ioaddr + ring_num * RING_SIZE;
+
+ writel_relaxed(msg->address_lo, ring + RING_MSI_ADDR_LS);
+ writel_relaxed(msg->address_hi, ring + RING_MSI_ADDR_MS);
+ writel_relaxed(msg->data, ring + RING_MSI_DATA_VALUE);
+
+ return 0;
+}
+
+static struct vfio_platform_msi_node vfio_platform_bcmflexrm_msi_node = {
+ .owner = THIS_MODULE,
+ .compat = "brcm,iproc-flexrm-mbox",
+ .of_get_msi = bcm_num_msi,
+ .of_msi_write = bcm_write_msi
+};
+
+static int __init vfio_platform_bcmflexrm_msi_module_init(void)
+{
+ __vfio_platform_register_msi(_platform_bcmflexrm_msi_node);
+
+ return 0;
+}
+
+static void __exit vfio_platform_bcmflexrm_msi_module_exit(void)
+{
+ vfio_platform_unregister_msi("brcm,iproc-flexrm-mbox");
+}
+
+module_init(vfio_platform_bcmflexrm_msi_module_init);
+module_exit(vfio_platform_bcmflexrm_msi_module_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Broadcom");
--
2.17.1
smime.p7s
Description: S/MIME Cryptographic Signature
linux-next: Tree for Nov 5
Hi all, Changes since 20201104: The drm-intel-fixes tree lost its build failure. The drm-msm tree gained conflicts against the drm and drm-misc trees. The mfd tree gained a build failure so I used the version from next-20201104. The pinctrl tree lost its build failure. The akpm-current tree gained a build failure for which I reverted a commit. Non-merge commits (relative to Linus' tree): 3085 3498 files changed, 376683 insertions(+), 40297 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 (4ef8451b3326 Merge tag 'perf-tools-for-v5.10-2020-11-03' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux) Merging fixes/fixes (9123e3a74ec7 Linux 5.9-rc1) Merging kbuild-current/fixes (d1889589a4f5 builddeb: Fix rootless build in setuid/setgid directory) Merging arc-current/for-curr (3b57533b460c ARC: [plat-hsdk] Remap CCMs super early in asm boot trampoline) Merging arm-current/fixes (9fa2e7af3d53 ARM: 9019/1: kprobes: Avoid fortify_panic() when copying optprobe template) Merging arm64-fixes/for-next/fixes (7ee31a3aa8f4 arm64: kprobes: Use BRK instead of single-step when executing instructions out-of-line) Merging arm-soc-fixes/arm/fixes (3d696f42c7f4 soc: ti: ti_sci_pm_domains: check for proper args count in xlate) Merging drivers-memory-fixes/fixes (3650b228f83a Linux 5.10-rc1) Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver to platform driver) Merging powerpc-fixes/fixes (99f070b62322 powerpc/smp: Call rcu_cpu_starting() earlier) Merging s390-fixes/fixes (0b2ca2c7d0c9 s390/pci: fix hot-plug of PCI function missing bus) 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 (ac6f929d74ba Merge tag 'linux-can-fixes-for-5.10-20201103' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can) Merging bpf/master (25cf73b9ff88 libbpf: Fix possible use after free in xsk_socket__delete) Merging ipsec/master (a779d91314ca net: xfrm: fix a race condition during allocing spi) Merging netfilter/master (fea07a487c6d net: openvswitch: silence suspicious RCU usage warning) Merging ipvs/master (859191b234f8 Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging wireless-drivers/master (04516706bb99 iwlwifi: pcie: limit memory read spin time) Merging mac80211/master (fea07a487c6d net: openvswitch: silence suspicious RCU usage warning) Merging rdma-fixes/for-rc (00469c97ef64 RDMA/vmw_pvrdma: Fix the active_speed and phys_state value) Merging sound-current/for-linus (26201ddc1373 ALSA: usb-audio: Add implicit feedback quirk for MODX) Merging sound-asoc-fixes/for-linus (961ed2ad57fd Merge remote-tracking branch 'asoc/for-5.10' into asoc-linus) Merging regmap-fixes/for-linus (780f88b04704 Merge remote-tracking branch 'regmap/for-5.10' into regmap-linus) Merging regulator-fixes/for-linus (cf1ad559a20d regulator: defer probe when trying to get voltage from unresolved supply) Merging spi-fixes/for-linus (ae36bbe9efb0 Merge remote-tracking branch 'spi/for-5.10' into spi-linus) Merging p
[RFC, v0 1/3] vfio/platform: add support for msi
MSI support for platform devices.
Signed-off-by: Vikas Gupta
---
drivers/vfio/platform/vfio_platform_common.c | 84 ++-
drivers/vfio/platform/vfio_platform_irq.c | 235 +-
drivers/vfio/platform/vfio_platform_private.h | 23 ++
include/uapi/linux/vfio.h | 1 +
4 files changed, 329 insertions(+), 14 deletions(-)
diff --git a/drivers/vfio/platform/vfio_platform_common.c
b/drivers/vfio/platform/vfio_platform_common.c
index c0771a9567fb..c713f4e4c552 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -26,6 +26,10 @@
#define VFIO_PLATFORM_IS_ACPI(vdev) ((vdev)->acpihid != NULL)
static LIST_HEAD(reset_list);
+
+/* devices having MSI support */
+static LIST_HEAD(msi_list);
+
static DEFINE_MUTEX(driver_lock);
static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char *compat,
@@ -47,6 +51,26 @@ static vfio_platform_reset_fn_t
vfio_platform_lookup_reset(const char *compat,
return reset_fn;
}
+static bool vfio_platform_lookup_msi(struct vfio_platform_device *vdev)
+{
+ bool has_msi = false;
+ struct vfio_platform_msi_node *iter;
+
+ mutex_lock(_lock);
+ list_for_each_entry(iter, _list, link) {
+ if (!strcmp(iter->compat, vdev->compat) &&
+ try_module_get(iter->owner)) {
+ vdev->msi_module = iter->owner;
+ vdev->of_get_msi = iter->of_get_msi;
+ vdev->of_msi_write = iter->of_msi_write;
+ has_msi = true;
+ break;
+ }
+ }
+ mutex_unlock(_lock);
+ return has_msi;
+}
+
static int vfio_platform_acpi_probe(struct vfio_platform_device *vdev,
struct device *dev)
{
@@ -110,6 +134,11 @@ static bool vfio_platform_has_reset(struct
vfio_platform_device *vdev)
return vdev->of_reset ? true : false;
}
+static bool vfio_platform_has_msi(struct vfio_platform_device *vdev)
+{
+ return vdev->of_get_msi ? true : false;
+}
+
static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
{
if (VFIO_PLATFORM_IS_ACPI(vdev))
@@ -126,6 +155,19 @@ static int vfio_platform_get_reset(struct
vfio_platform_device *vdev)
return vdev->of_reset ? 0 : -ENOENT;
}
+static int vfio_platform_get_msi(struct vfio_platform_device *vdev)
+{
+ bool has_msi;
+
+ has_msi = vfio_platform_lookup_msi(vdev);
+ if (!has_msi) {
+ request_module("vfio-msi:%s", vdev->compat);
+ has_msi = vfio_platform_lookup_msi(vdev);
+ }
+
+ return has_msi ? 0 : -ENOENT;
+}
+
static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
{
if (VFIO_PLATFORM_IS_ACPI(vdev))
@@ -135,6 +177,12 @@ static void vfio_platform_put_reset(struct
vfio_platform_device *vdev)
module_put(vdev->reset_module);
}
+static void vfio_platform_put_msi(struct vfio_platform_device *vdev)
+{
+ if (vdev->of_get_msi)
+ module_put(vdev->msi_module);
+}
+
static int vfio_platform_regions_init(struct vfio_platform_device *vdev)
{
int cnt = 0, i;
@@ -313,6 +361,10 @@ static long vfio_platform_ioctl(void *device_data,
if (vfio_platform_has_reset(vdev))
vdev->flags |= VFIO_DEVICE_FLAGS_RESET;
+
+ if (vfio_platform_has_msi(vdev))
+ vdev->flags |= VFIO_DEVICE_FLAGS_MSI;
+
info.flags = vdev->flags;
info.num_regions = vdev->num_regions;
info.num_irqs = vdev->num_irqs;
@@ -679,11 +731,15 @@ int vfio_platform_probe_common(struct
vfio_platform_device *vdev,
return ret;
}
+ ret = vfio_platform_get_msi(vdev);
+ if (ret)
+ dev_info(vdev->device, "msi not supported\n");
+
group = vfio_iommu_group_get(dev);
if (!group) {
dev_err(dev, "No IOMMU group for device %s\n", vdev->name);
ret = -EINVAL;
- goto put_reset;
+ goto put_msi;
}
ret = vfio_add_group_dev(dev, _platform_ops, vdev);
@@ -697,6 +753,8 @@ int vfio_platform_probe_common(struct vfio_platform_device
*vdev,
put_iommu:
vfio_iommu_group_put(group, dev);
+put_msi:
+ vfio_platform_put_msi(vdev);
put_reset:
vfio_platform_put_reset(vdev);
return ret;
@@ -745,6 +803,30 @@ void vfio_platform_unregister_reset(const char *compat,
}
EXPORT_SYMBOL_GPL(vfio_platform_unregister_reset);
+void __vfio_platform_register_msi(struct vfio_platform_msi_node *node)
+{
+ mutex_lock(_lock);
+ list_add(>link, _list);
+ mutex_unlock(_lock);
+}
+EXPORT_SYMBOL_GPL(__vfio_platform_register_msi);
+
+void vfio_platform_unregister_msi(const char *compat)
+{
+ struct vfio_platform_msi_node *iter, *temp;
+
+ mutex_lock(_lock);
[RFC, v0 0/3] msi support for platform devices
This RFC adds support for MSI for platform devices. a) MSI(s) is/are added in addition to the normal interrupts. b) The vendor specific MSI configuration can be done using callbacks which is implemented as msi module. c) Adds a msi handling module for the Broadcom platform devices. Vikas Gupta (3): vfio/platform: add support for msi vfio/platform: change cleanup order vfio/platform: add Broadcom msi module drivers/vfio/platform/Kconfig | 1 + drivers/vfio/platform/Makefile| 1 + drivers/vfio/platform/msi/Kconfig | 9 + drivers/vfio/platform/msi/Makefile| 2 + .../vfio/platform/msi/vfio_platform_bcmplt.c | 74 ++ drivers/vfio/platform/vfio_platform_common.c | 86 ++- drivers/vfio/platform/vfio_platform_irq.c | 235 +- drivers/vfio/platform/vfio_platform_private.h | 23 ++ include/uapi/linux/vfio.h | 1 + 9 files changed, 417 insertions(+), 15 deletions(-) create mode 100644 drivers/vfio/platform/msi/Kconfig create mode 100644 drivers/vfio/platform/msi/Makefile create mode 100644 drivers/vfio/platform/msi/vfio_platform_bcmplt.c -- 2.17.1 smime.p7s Description: S/MIME Cryptographic Signature
[RFC, v0 2/3] vfio/platform: change cleanup order
In the case of msi, vendor specific msi module may require region access to handle msi cleanup so we need to cleanup region after irq cleanup only. Signed-off-by: Vikas Gupta --- drivers/vfio/platform/vfio_platform_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c index c713f4e4c552..b9d68ccdf92f 100644 --- a/drivers/vfio/platform/vfio_platform_common.c +++ b/drivers/vfio/platform/vfio_platform_common.c @@ -283,8 +283,8 @@ static void vfio_platform_release(void *device_data) WARN_ON(1); } pm_runtime_put(vdev->device); - vfio_platform_regions_cleanup(vdev); vfio_platform_irq_cleanup(vdev); + vfio_platform_regions_cleanup(vdev); } mutex_unlock(_lock); -- 2.17.1 smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH v2 net] net: sch_generic: aviod concurrent reset and enqueue op for lockless qdisc
On Mon, Nov 2, 2020 at 11:24 PM Yunsheng Lin wrote: > >> From my understanding, we can do anything about the old qdisc (including > >> destorying the old qdisc) after some_qdisc_is_busy() return false. > > > > But the current code does the reset _before_ some_qdisc_is_busy(). ;) > > If lock is taken when doing reset, it does not matter if the reset is > before some_qdisc_is_busy(), right? Why not? How about the following scenario? CPU0: CPU1: dev_reset_queue() net_tx_action() -> sch_direct_xmit() -> dev_requeue_skb() some_qdisc_is_busy() // waiting for TX action on CPU1 // now some packets are requeued
Re: [PATCH v2 3/4] Kbuild: make DWARF version a choice
Hi Nick,
I love your patch! Yet something to improve:
[auto build test ERROR on kbuild/for-next]
[also build test ERROR on asm-generic/master linus/master v5.10-rc2
next-20201104]
[cannot apply to tip/x86/core]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Nick-Desaulniers/Kbuild-DWARF-v5-support/20201104-085610
base:
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
for-next
config: ia64-randconfig-r034-20201104 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
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
#
https://github.com/0day-ci/linux/commit/f8b8c21feb85f4422b79a96e0b56cf4e8ff53274
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Nick-Desaulniers/Kbuild-DWARF-v5-support/20201104-085610
git checkout f8b8c21feb85f4422b79a96e0b56cf4e8ff53274
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=ia64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
{standard input}: Assembler messages:
>> {standard input}:34: Error: file number 1 already allocated
---
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 1/6] MIPS: Loongson64: Do not write the read only field LPA of CP0_CONFIG3
Hi, Tiezhu,
On Wed, Nov 4, 2020 at 11:51 AM Tiezhu Yang wrote:
>
> On 11/04/2020 10:00 AM, Huacai Chen wrote:
> > Hi, Tiezhu,
> >
> > On Tue, Nov 3, 2020 at 3:13 PM Tiezhu Yang wrote:
> >> The field LPA of CP0_CONFIG3 register is read only for Loongson64, so the
> >> write operations are meaningless, remove them.
> >>
> >> Signed-off-by: Tiezhu Yang
> >> ---
> >>
> >> v2: No changes
> >> v3: No changes
> >>
> >> arch/mips/include/asm/mach-loongson64/kernel-entry-init.h | 8
> >> arch/mips/loongson64/numa.c | 3 ---
> >> 2 files changed, 11 deletions(-)
> >>
> >> diff --git a/arch/mips/include/asm/mach-loongson64/kernel-entry-init.h
> >> b/arch/mips/include/asm/mach-loongson64/kernel-entry-init.h
> >> index 87a5bfb..e4d77f4 100644
> >> --- a/arch/mips/include/asm/mach-loongson64/kernel-entry-init.h
> >> +++ b/arch/mips/include/asm/mach-loongson64/kernel-entry-init.h
> >> @@ -19,10 +19,6 @@
> >> .macro kernel_entry_setup
> >> .setpush
> >> .setmips64
> >> - /* Set LPA on LOONGSON3 config3 */
> >> - mfc0t0, CP0_CONFIG3
> >> - or t0, (0x1 << 7)
> >> - mtc0t0, CP0_CONFIG3
> > Sorry for the late response, I have the same worry as Jiaxun. As you
> > know, Loongson's user manuals are not always correct, but the original
> > code comes from Loongson are usually better. So, my opinion is "Don't
> > change it if it doesn't break anything".
>
> Hi Huacai,
>
> Thanks for your reply, I have confirmed by Loongson user manuals and
> hardware designers, CP0_CONFIG3 register is read only.
>
> Without this patch, the related kernel code is meaningless, with
> this patch, it can reflect the reality.
>
> Thanks,
> Tiezhu
Then you should at least test your code on Loongson-3A R1 two way machine.
Huacai
>
> >
> > Huacai
> >
> >> /* Set ELPA on LOONGSON3 pagegrain */
> >> mfc0t0, CP0_PAGEGRAIN
> >> or t0, (0x1 << 29)
> >> @@ -54,10 +50,6 @@
> >> .macro smp_slave_setup
> >> .setpush
> >> .setmips64
> >> - /* Set LPA on LOONGSON3 config3 */
> >> - mfc0t0, CP0_CONFIG3
> >> - or t0, (0x1 << 7)
> >> - mtc0t0, CP0_CONFIG3
> >> /* Set ELPA on LOONGSON3 pagegrain */
> >> mfc0t0, CP0_PAGEGRAIN
> >> or t0, (0x1 << 29)
> >> diff --git a/arch/mips/loongson64/numa.c b/arch/mips/loongson64/numa.c
> >> index cf9459f..c7e3cced 100644
> >> --- a/arch/mips/loongson64/numa.c
> >> +++ b/arch/mips/loongson64/numa.c
> >> @@ -40,9 +40,6 @@ static void enable_lpa(void)
> >> unsigned long value;
> >>
> >> value = __read_32bit_c0_register($16, 3);
> >> - value |= 0x0080;
> >> - __write_32bit_c0_register($16, 3, value);
> >> - value = __read_32bit_c0_register($16, 3);
> >> pr_info("CP0_Config3: CP0 16.3 (0x%lx)\n", value);
> >>
> >> value = __read_32bit_c0_register($5, 1);
> >> --
> >> 2.1.0
> >>
>
Re: [PATCH] proc: Provide details on indirect branch speculation
On Sun, 1 Nov 2020 at 07:05, Andrew Morton wrote: > > On Fri, 30 Oct 2020 17:27:54 +1100 Anand K Mistry wrote: > > > Similar to speculation store bypass, show information about the indirect > > branch speculation mode of a task in /proc/$pid/status. > > Why is this considered useful? For testing/benchmarking, I needed to see whether IB (Indirect Branch) speculation (see Spectre-v2) is enabled on a task, to see whether an IBPB instruction should be executed on an address space switch. Unfortunately, this information isn't available anywhere else and currently the only way to get it is to hack the kernel to expose it (like this change). It also helped expose a bug with conditional IB speculation on certain CPUs. Another place this could be useful is to audit the system when using sanboxing. With this change, I can confirm that seccomp-enabled process have IB speculation force disabled as expected when the kernel command line parameter `spectre_v2_user=seccomp`. Since there's already a 'Speculation_Store_Bypass' field, I used that as precedence for adding this one. -- Anand K. Mistry Software Engineer Google Australia
[PATCH v15 1/2] Add DT bindings YAML schema for PWM fan controller of LGM SoC
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
Reviewed-by: Rob Herring
---
.../devicetree/bindings/pwm/intel,lgm-pwm.yaml | 44 ++
1 file changed, 44 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 ..11a606536169
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
@@ -0,0 +1,44 @@
+# 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
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+pwm: pwm@e0d0 {
+compatible = "intel,lgm-pwm";
+reg = <0xe0d0 0x30>;
+#pwm-cells = <2>;
+clocks = < 126>;
+resets = < 0x30 21>;
+};
--
2.11.0
[PATCH v15 2/2] Add PWM fan controller driver for LGM SoC
Intel Lightning Mountain(LGM) SoC contains a PWM fan controller.
This PWM controller does not have any other consumer, it is a
dedicated PWM controller for fan attached to the system. Add
driver for this PWM fan controller.
Signed-off-by: Rahul Tanwar
Reviewed-by: Andy Shevchenko
---
drivers/pwm/Kconfig | 11 ++
drivers/pwm/Makefile| 1 +
drivers/pwm/pwm-intel-lgm.c | 244
3 files changed, 256 insertions(+)
create mode 100644 drivers/pwm/pwm-intel-lgm.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 63be5362fd3a..7218bf3665bc 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -232,6 +232,17 @@ config PWM_IMX_TPM
To compile this driver as a module, choose M here: the module
will be called pwm-imx-tpm.
+config PWM_INTEL_LGM
+ tristate "Intel LGM PWM support"
+ depends on HAS_IOMEM
+ depends on (OF && X86) || COMPILE_TEST
+ select REGMAP_MMIO
+ help
+ Generic PWM fan controller driver for LGM SoC.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-intel-lgm.
+
config PWM_IQS620A
tristate "Azoteq IQS620A PWM support"
depends on MFD_IQS62X || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index cbdcd55d69ee..71beaff894c1 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PWM_IMG) += pwm-img.o
obj-$(CONFIG_PWM_IMX1) += pwm-imx1.o
obj-$(CONFIG_PWM_IMX27)+= pwm-imx27.o
obj-$(CONFIG_PWM_IMX_TPM) += pwm-imx-tpm.o
+obj-$(CONFIG_PWM_INTEL_LGM)+= pwm-intel-lgm.o
obj-$(CONFIG_PWM_IQS620A) += pwm-iqs620a.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LP3943) += pwm-lp3943.o
diff --git a/drivers/pwm/pwm-intel-lgm.c b/drivers/pwm/pwm-intel-lgm.c
new file mode 100644
index ..e9e54dda07aa
--- /dev/null
+++ b/drivers/pwm/pwm-intel-lgm.c
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Intel Corporation.
+ *
+ * Limitations:
+ * - The hardware supports fixed period & configures only 2-wire mode.
+ * - Supports normal polarity. Does not support changing polarity.
+ * - When PWM is disabled, output of PWM will become 0(inactive). It doesn't
+ * keep track of running period.
+ * - When duty cycle is changed, PWM output may be a mix of previous setting
+ * and new setting for the first period. From second period, the output is
+ * based on new setting.
+ * - It is a dedicated PWM fan controller. There are no other consumers for
+ * this PWM controller.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LGM_PWM_FAN_CON0 0x0
+#define LGM_PWM_FAN_EN_EN BIT(0)
+#define LGM_PWM_FAN_EN_DIS 0x0
+#define LGM_PWM_FAN_EN_MSK BIT(0)
+#define LGM_PWM_FAN_MODE_2WIRE 0x0
+#define LGM_PWM_FAN_MODE_MSK BIT(1)
+#define LGM_PWM_FAN_DC_MSK GENMASK(23, 16)
+
+#define LGM_PWM_FAN_CON1 0x4
+#define LGM_PWM_FAN_MAX_RPM_MSKGENMASK(15, 0)
+
+#define LGM_PWM_MAX_RPM(BIT(16) - 1)
+#define LGM_PWM_DEFAULT_RPM4000
+#define LGM_PWM_MAX_DUTY_CYCLE (BIT(8) - 1)
+
+#define LGM_PWM_DC_BITS8
+
+#define LGM_PWM_PERIOD_2WIRE_NS(40 * NSEC_PER_MSEC)
+
+struct lgm_pwm_chip {
+ struct pwm_chip chip;
+ struct regmap *regmap;
+ u32 period;
+};
+
+static inline struct lgm_pwm_chip *to_lgm_pwm_chip(struct pwm_chip *chip)
+{
+ return container_of(chip, struct lgm_pwm_chip, chip);
+}
+
+static int lgm_pwm_enable(struct pwm_chip *chip, bool enable)
+{
+ struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
+ struct regmap *regmap = pc->regmap;
+
+ return regmap_update_bits(regmap, LGM_PWM_FAN_CON0, LGM_PWM_FAN_EN_MSK,
+ enable ? LGM_PWM_FAN_EN_EN :
LGM_PWM_FAN_EN_DIS);
+}
+
+static int lgm_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+const struct pwm_state *state)
+{
+ struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
+ u32 duty_cycle, val;
+ int ret;
+
+ /* The hardware only supports normal polarity and fixed period. */
+ if (state->polarity != PWM_POLARITY_NORMAL || state->period <
pc->period)
+ return -EINVAL;
+
+ if (!state->enabled)
+ return lgm_pwm_enable(chip, 0);
+
+ duty_cycle = min_t(u64, state->duty_cycle, pc->period);
+ val = duty_cycle * LGM_PWM_MAX_DUTY_CYCLE / pc->period;
+
+ ret = regmap_update_bits(pc->regmap, LGM_PWM_FAN_CON0,
LGM_PWM_FAN_DC_MSK,
+FIELD_PREP(LGM_PWM_FAN_DC_MSK, val));
+ if (ret)
+ return ret;
+
+ return lgm_pwm_enable(chip, 1);
+}
+
+static void
[PATCH v15 0/2] pwm: intel: Add PWM driver for a new SoC
Patch 1 adds dt binding document in YAML format. Patch 2 add PWM fan controller driver for LGM SoC. v15: - Rebase to latest linux 5.10-rc2 v14: - Address below review concerns from Uwe Kleine-K?nig. * Add limitations info about fixed 2-wire mode support. * Rename clk/reset _disable function names to _release. * Remove clk & rst from driver data structure. Instead use them as arguments. * Add pwm_chip.base = -1. - Resolve missing MODULE_LICENSE warning. v13: - Address below review concerns (Philipp Zabel) * Make unnecessary 2 line comment as 1 line comment. * Move reset_deassert at the last after clk_enable. * Remove unnecessary return ret statement from .remove() - Move platform_set_drvdata() at the top of probe. v12: - Rebase to linux 5.9-rc4 - Add Reviewed-by tags from Andy Shevchenko & Rob Herring. v11: - Address below review concerns (Andy Shevchenko) * Fix a issue with dev_err_probe() usage & improve the usage. * Fix & improve a ordering issue with clk_enable/disable & reset_control assert/deassert. v10: - Removed unused of_device.h and added platform_device.h & mod_devicetable.h v9: - Address code quality related review concerns (Andy Shevchenko) - Use devm_add_action_or_reset() instead of explicit unwind calls. v8: - Remove fan related optional properties usage, keep them as default. If needed, change pwm-fan driver separately in future to add them as generic properties. v7: - Address code quality related review concerns. - Rename fan related property to pwm-*. - Fix one make dt_binding_check reported error. v6: - Readjust .apply op as per review feedback. - Add back pwm-cells property to resolve make dt_binding_check error. pwm-cells is a required property for PWM driver. - Add back fan related optional properties. v5: - Address below review concerns from Uwe Kleine-K?nig. * Improve comments about Limitations. * Use return value of regmap_update_bits if container function returns error code. * Modify .apply op to have strict checking for fixed period supported by PWM HW. * Use u64 as type when use min_t for duty_cycle. * Add reset_control_assert() in failure case in probe where it was missing earlier. - Remove fan specific optional properties from pwm dt binding document (Rob Herring) v4: - Address below review concerns from Uwe Kleine-K?nig. * Improve notes and limitations comments. * Add common prefixes for all #defines. * Modify/Improve logic in .apply & .get_state ops as advised. * Skip error messages in probe when error is -EPROBE_DEFER. * Add dependencies in Kconfig (OF & HAS_IOMEM) and add select REGMAP_MMIO. * Address other code quality related review concerns. - Fix make dt_binding_check reported error in YAML file. v3: - Address below review concerns from Uwe Kleine-K?nig. * Remove fan rpm calibration task from the driver. * Modify apply op as per the review feedback. * Add roundup & round down where necessary. * Address other misc code quality related review concerns. * Use devm_reset_control_get_exclusive(). (Philipp Zabel) * Improve dt binding document. v2: - Address below review concerns from Uwe Kleine-K?nig. * Add notes and limitations about PWM HW. * Rename all functions and structure to lgm_pwm_* * Readjust space aligninment in structure fields to single space. * Switch to using apply instead of config/enable/disable. * Address other code quality related concerns. * Rebase to 5.8-rc1. - Address review concerns in dt binding YAML from Rob Herring. v1: - Initial version. Rahul Tanwar (2): Add DT bindings YAML schema for PWM fan controller of LGM SoC Add PWM fan controller driver for LGM SoC .../devicetree/bindings/pwm/intel,lgm-pwm.yaml | 44 drivers/pwm/Kconfig| 11 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-intel-lgm.c| 244 + 4 files changed, 300 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml create mode 100644 drivers/pwm/pwm-intel-lgm.c -- 2.11.0
[PATCH] applesmc: Re-work SMC comms v1
Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()") introduced
an issue whereby communication with the SMC became unreliable with write
errors :
[ 120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[ 120.378621] applesmc: LKSB: write data fail
[ 120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
[ 120.512787] applesmc: LKSB: write data fail
The original code appeared to be timing sensitive and was not reliable with
the timing changes in the aforementioned commit.
This patch re-factors the SMC communication to remove the timing
dependencies and restore function with the changes previously committed.
Reported-by: Andreas Kemnade
Signed-off-by: Brad Campbell
---
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index a18887990f4a..22cc5122ce9a 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -42,6 +42,11 @@
#define APPLESMC_MAX_DATA_LENGTH 32
+/* Apple SMC status bits from VirtualSMC */
+#define SMC_STATUS_AWAITING_DATA 0x01 ///< Data waiting to be read
+#define SMC_STATUS_IB_CLOSED 0x02 /// A write is pending / will ignore
input
+#define SMC_STATUS_BUSY 0x04 ///< Busy in the middle of a command.
+
/* wait up to 128 ms for a status change. */
#define APPLESMC_MIN_WAIT 0x0010
#define APPLESMC_RETRY_WAIT0x0100
@@ -151,65 +156,77 @@ static unsigned int key_at_index;
static struct workqueue_struct *applesmc_led_wq;
/*
- * wait_read - Wait for a byte to appear on SMC port. Callers must
- * hold applesmc_lock.
+ * Wait for specific status bits with a mask on the SMC
+ * Used before and after writes, and before reads
*/
-static int wait_read(void)
+
+static int wait_status(u8 val, u8 mask)
{
unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
u8 status;
int us;
for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
- usleep_range(us, us * 16);
status = inb(APPLESMC_CMD_PORT);
- /* read: wait for smc to settle */
- if (status & 0x01)
+ if ((status & mask) == val)
return 0;
/* timeout: give up */
if (time_after(jiffies, end))
break;
- }
-
- pr_warn("wait_read() fail: 0x%02x\n", status);
+ usleep_range(us, us * 16);
+ }
+ pr_warn("wait_status timeout: 0x%02x, 0x%02x, 0x%02x\n", status, val,
mask);
return -EIO;
}
/*
- * send_byte - Write to SMC port, retrying when necessary. Callers
+ * send_byte_data - Write to SMC data port. Callers
* must hold applesmc_lock.
+ * Parameter skip must be true on the last write of any
+ * command or it'll time out.
*/
-static int send_byte(u8 cmd, u16 port)
+
+static int send_byte_data(u8 cmd, u16 port, bool skip)
{
- u8 status;
- int us;
- unsigned long end = jiffies + (APPLESMC_MAX_WAIT * HZ) / USEC_PER_SEC;
+ u8 wstat = SMC_STATUS_BUSY;
+ if (skip)
+ wstat = 0;
+ if (wait_status(SMC_STATUS_BUSY,
+ SMC_STATUS_BUSY | SMC_STATUS_IB_CLOSED))
+ goto fail;
outb(cmd, port);
- for (us = APPLESMC_MIN_WAIT; us < APPLESMC_MAX_WAIT; us <<= 1) {
- usleep_range(us, us * 16);
- status = inb(APPLESMC_CMD_PORT);
- /* write: wait for smc to settle */
- if (status & 0x02)
- continue;
- /* ready: cmd accepted, return */
- if (status & 0x04)
- return 0;
- /* timeout: give up */
- if (time_after(jiffies, end))
- break;
- /* busy: long wait and resend */
- udelay(APPLESMC_RETRY_WAIT);
- outb(cmd, port);
- }
-
- pr_warn("send_byte(0x%02x, 0x%04x) fail: 0x%02x\n", cmd, port, status);
+ if (!wait_status(wstat,
+ SMC_STATUS_BUSY))
+ return 0;
+fail:
+ pr_warn("send_byte_data(0x%02x, 0x%04x) fail\n", cmd,
APPLESMC_CMD_PORT);
return -EIO;
}
+/*
+ * send_command - Write a command to the SMC. Callers must hold applesmc_lock.
+ * If SMC is in undefined state, any new command write resets the state
machine.
+ */
+
static int send_command(u8 cmd)
{
- return send_byte(cmd, APPLESMC_CMD_PORT);
+ u8 status;
+
+ if (wait_status(0,
+ SMC_STATUS_IB_CLOSED)) {
+ pr_warn("send_command SMC was busy\n");
+ goto fail; }
+
+ status = inb(APPLESMC_CMD_PORT);
+
+ outb(cmd, APPLESMC_CMD_PORT);
+ if (!wait_status(SMC_STATUS_BUSY,
+ SMC_STATUS_BUSY))
+ return 0;
+fail:
+ pr_warn("send_cmd(0x%02x, 0x%04x) fail\n", cmd, APPLESMC_CMD_PORT);
+ return -EIO;
}
static int send_argument(const char *key)
@@ -217,7 +234,8 @@ static int send_argument(const char *key)
int i;
[PATCH 2/6] arm64: dts: allwinner: pinephone: Set ALDO3 to exactly 3v0
ALDO3 is used as the power supply for the LRADC keys voltage divider,
in addition to supplying AVCC and VCC-PLL. While AVCC and VCC-PLL will
accept any voltage between 2v7 and 3v3, LRADC needs a precise 3v0 input
to maintain the expected 2:3 ratio between the internal 2v0 reference
voltage and the external supply.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index 48050bbd941d..57c89c3b71e9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -270,8 +270,8 @@ _aldo2 {
_aldo3 {
regulator-always-on;
- regulator-min-microvolt = <270>;
- regulator-max-microvolt = <330>;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
regulator-name = "vcc-pll-avcc";
};
--
2.26.2
[PATCH 0/6] PinePhone Device Tree Enhancements
This series fixes a couple of small issues with the PinePhone device tree, and collects some patches adding support for peripherals that recently received driver or DT binding support. Luca Weiss (1): arm64: dts: allwinner: pinephone: Add LED flash Ondrej Jirman (3): arm64: dts: allwinner: pinephone: Add light/proximity sensor arm64: dts: allwinner: pinephone: Add WiFi support arm64: dts: allwinner: pinephone: Add Bluetooth support Samuel Holland (2): arm64: dts: allwinner: pinephone: Remove AC power supply arm64: dts: allwinner: pinephone: Set ALDO3 to exactly 3v0 .../allwinner/sun50i-a64-pinephone-1.0.dts| 5 ++ .../allwinner/sun50i-a64-pinephone-1.1.dts| 5 ++ .../allwinner/sun50i-a64-pinephone-1.2.dts| 14 .../dts/allwinner/sun50i-a64-pinephone.dtsi | 64 +-- 4 files changed, 82 insertions(+), 6 deletions(-) -- 2.26.2
[PATCH 4/6] arm64: dts: allwinner: pinephone: Add light/proximity sensor
From: Ondrej Jirman
Pinephone has STK3311-X proximity sensor. Add support for it.
Signed-off-by: Ondrej Jirman
Signed-off-by: Samuel Holland
---
.../arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index e595a8262920..9544d7658794 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -160,6 +160,16 @@ lis3mdl: lis3mdl@1e {
vddio-supply = <_dldo1>;
};
+ /* Light/proximity sensor */
+ stk3311@48 {
+ compatible = "sensortek,stk3311";
+ reg = <0x48>;
+ interrupt-parent = <>;
+ interrupts = <1 0 IRQ_TYPE_EDGE_FALLING>; /* PB0 */
+ vdd-supply = <_ldo_io0>;
+ leda-supply = <_dldo1>;
+ };
+
/* Accelerometer/gyroscope */
mpu6050@68 {
compatible = "invensense,mpu6050";
--
2.26.2
[PATCH 3/6] arm64: dts: allwinner: pinephone: Add LED flash
From: Luca Weiss
All revisions of the PinePhone have an SGM3140 LED flash. The gpios were
swapped on v1.0 of the board, but this was fixed in later revisions.
Signed-off-by: Luca Weiss
Signed-off-by: Samuel Holland
---
.../boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts | 5 +
.../boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts | 5 +
.../boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts | 5 +
.../boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 11 +++
4 files changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
index 0c42272106af..3d5a2ae9aa39 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.0.dts
@@ -9,3 +9,8 @@ / {
model = "Pine64 PinePhone Developer Batch (1.0)";
compatible = "pine64,pinephone-1.0", "allwinner,sun50i-a64";
};
+
+ {
+ enable-gpios = < 2 3 GPIO_ACTIVE_HIGH>; /* PC3 */
+ flash-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
index 3e99a87e9ce5..c9b9f6e9ee8c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
@@ -28,3 +28,8 @@ {
num-interpolated-steps = <50>;
default-brightness-level = <400>;
};
+
+ {
+ enable-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+ flash-gpios = < 2 3 GPIO_ACTIVE_HIGH>; /* PC3 */
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
index a9f5b670c9b8..94e4f11e0215 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
@@ -38,3 +38,8 @@ {
interrupt-parent = <>;
interrupts = <1 1 IRQ_TYPE_EDGE_RISING>; /* PB1 */
};
+
+ {
+ enable-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+ flash-gpios = < 2 3 GPIO_ACTIVE_HIGH>; /* PC3 */
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index 57c89c3b71e9..e595a8262920 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -49,6 +49,17 @@ red {
};
};
+ sgm3140: led-controller {
+ compatible = "sgmicro,sgm3140";
+ vin-supply = <_dcdc1>;
+
+ sgm3140_flash: led {
+ function = LED_FUNCTION_FLASH;
+ color = ;
+ flash-max-timeout-us = <25>;
+ };
+ };
+
speaker_amp: audio-amplifier {
compatible = "simple-audio-amplifier";
enable-gpios = < 2 7 GPIO_ACTIVE_HIGH>; /* PC7 */
--
2.26.2
[PATCH 6/6] arm64: dts: allwinner: pinephone: Add Bluetooth support
From: Ondrej Jirman
The PinePhone has a Realtek rtl8723cs Bluetooth controller.
Signed-off-by: Ondrej Jirman
Signed-off-by: Samuel Holland
---
.../boot/dts/allwinner/sun50i-a64-pinephone.dtsi| 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index e173096a7e68..1083055a731f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -447,6 +447,19 @@ {
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>, <_rts_cts_pins>;
+ status = "okay";
+
+ bluetooth {
+ compatible = "realtek,rtl8723cs-bt";
+ device-wake-gpios = < 7 6 GPIO_ACTIVE_LOW>; /* PH6 */
+ enable-gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
+ host-wake-gpios = <_pio 0 5 GPIO_ACTIVE_HIGH>; /* PL5 */
+ };
+};
+
/* Connected to the modem (hardware flow control can't be used) */
{
pinctrl-names = "default";
--
2.26.2
[PATCH 1/6] arm64: dts: allwinner: pinephone: Remove AC power supply
The AXP803 in the Pinephone has its ACIN and VBUS pins shorted together.
In this configuration, the VBUS control registers take priority over the
ACIN control registers, which means the ACIN sysfs knobs have no effect.
Remove the AC power supply from the DTS, since VBUS is really the only
power supply.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index 25150aba749d..48050bbd941d 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -251,10 +251,6 @@ axp803: pmic@3a3 {
#include "axp803.dtsi"
-_power_supply {
- status = "okay";
-};
-
_power_supply {
status = "okay";
};
--
2.26.2
[PATCH 5/6] arm64: dts: allwinner: pinephone: Add WiFi support
From: Ondrej Jirman
The PinePhone has a Realtek rtl8723cs WiFi module.
On mainboard revisions 1.0 and 1.1, the reset input is always pulled
high, so no power sequence is needed. On mainboard revision 1.2, the
reset input is connected to PL2.
Signed-off-by: Ondrej Jirman
Signed-off-by: Samuel Holland
---
.../allwinner/sun50i-a64-pinephone-1.2.dts| 9
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 22 +++
2 files changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
index 94e4f11e0215..e7cf9d8577c1 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts
@@ -8,6 +8,11 @@
/ {
model = "Pine64 PinePhone (1.2)";
compatible = "pine64,pinephone-1.2", "allwinner,sun50i-a64";
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
+ };
};
{
@@ -39,6 +44,10 @@ {
interrupts = <1 1 IRQ_TYPE_EDGE_RISING>; /* PB1 */
};
+ {
+ mmc-pwrseq = <_pwrseq>;
+};
+
{
enable-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
flash-gpios = < 2 3 GPIO_ACTIVE_HIGH>; /* PC3 */
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index 9544d7658794..e173096a7e68 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -13,6 +13,7 @@
/ {
aliases {
+ ethernet0 =
serial0 =
};
@@ -49,6 +50,13 @@ red {
};
};
+ reg_vbat_wifi: vbat-wifi {
+ compatible = "regulator-fixed";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vbat-wifi";
+ };
+
sgm3140: led-controller {
compatible = "sgmicro,sgm3140";
vin-supply = <_dcdc1>;
@@ -216,6 +224,20 @@ {
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ vmmc-supply = <_vbat_wifi>;
+ vqmmc-supply = <_dldo4>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ rtl8723cs: wifi@1 {
+ reg = <1>;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
--
2.26.2
Re: [PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND
On 2020-11-04 12:08:12, Will Deacon wrote: > On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote: > > On 2020-09-21 14:15:55, Tyler Hicks wrote: > > > Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels. This > > > config option can be used to extend the kernel command line parameters, > > > specified by the bootloader, with additional command line parameters > > > specified in the kernel configuration. > > > > Hi Catalin and Will - Friendly ping on this series now that we're > > on the other side of the 5.10 merge window. I hope it can be considered > > for 5.10+1. Let me know if I need to rebase/resubmit. Thanks! > > Can you use bootconfig to achieve what you need? Thanks for mentioning bootconfig. I hadn't considered it. After reading the docs and code, I see a few reasons why I can't use it out of the box: 1) It requires "bootconfig" to be appended to the kernel command line. My proposed patch series makes it possible to append new options to the kernel command line in situations where the bootloader is not interactive. This presents a circular dependency problem for my use case. A new config option could be added to force the enablement of bootconfig but that would sort of be a single-use duplicate of CONFIG_CMDLINE_EXTEND's functionality. 2) Not all kernel command line options can be configured using bootconfig. For example, the "nokaslr" and "crashkernel=" parameters are parsed/handled before setup_boot_config() is called. KASLR can be disabled via a kernel config change but there's no config option equivalent for "crashkernel=". Changing the "crashkernel=" command line option is something that I need to support because a development/debug kernel build often requires a larger reservation and we find ourselves adjusting the "crashkernel=" value fairly often. 3) External FIT image build systems do not yet support bootconfig since it is so new. It is completely fair if you file this away in your not-my-problem folder but simple kernel config modifications, as needed for CONFIG_CMDLINE_EXTEND, are something that every image build system is likely to support today. All that said, I do really like the look of bootconfig. Unfortunately, it doesn't let me achieve everything I need. Tyler > > Will >
[PATCH] iscsi: Do Not set param when sock is NULL
Description
=
1. This Kernel panic could be due to a timing issue when there is a race
between the sync thread and the initiator was processing of a login response
from the target. The session re-open can be invoked from two places
a.Sessions sync thread when the iscsid restart
b.From iscsid through iscsi error handler
2. The session reopen sequence is as follows in user-space
(iscsi-initiator-utils)
a.Disconnect the connection
b.Then send the stop connection request to the kernel which
releases the connection (releases the socket)
c.Queues the reopen for 2 seconds delay
d. Once the delay expires, create the TCP connection again by
calling the connect() call
e. Poll for the connection
f.When poll is successful i.e when the TCP connection is
established, it performs
i. Creation of session and connection data structures
ii. Bind the connection to the session. This is the place where we
assign the sock to tcp_sw_conn->sock
iii. Sets the parameters like target name, persistent address etc .
iv. Creates the login pdu
v. Sends the login pdu to kernel
vi. Returns to the main loop to process further events. The kernel then
sends the login request over to the target node
g. Once login response with success is received, it enters into full
feature phase and sets the negotiable parameters like max_recv_data_length,
max_transmit_length, data_digest etc .
3. While setting the negotiable parameters by calling
"iscsi_session_set_neg_params()", kernel panicked as sock was NULL
What happened here is
1. Before initiator received the login response mentioned in above point
2.f.v, another reopen request was sent from the error handler/sync session for
the same session, as the initiator utils was in main loop to process further
events (as
mentioned in point 2.f.vi above).
2. While processing this reopen, it stopped the connection which released
the socket and queued this connection and at this point of time the login
response was received for the earlier one
3. The kernel passed over this response to user-space which then sent the
set_neg_params request to kernel
4. As the connection was stopped, the sock was NULL and hence while the
kernel was processing the set param request from user-space, it panicked
Fix
1. While setting the set_param in kernel, we need to check if sock is NULL
2. If the sock is NULL, then return EPERM (operation not permitted)
3. Due to this error handler will be invoked in user-space again to
recover the session
Signed-off-by: Gulam Mohamed
Reviewed-by: Junxiao Bi
---
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index df47557a02a3..fd668a194053 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -711,6 +711,12 @@ static int iscsi_sw_tcp_conn_set_param(struct
iscsi_cls_conn *cls_conn,
struct iscsi_tcp_conn *tcp_conn = conn->dd_data;
struct iscsi_sw_tcp_conn *tcp_sw_conn = tcp_conn->dd_data;
+ if (!tcp_sw_conn->sock) {
+ iscsi_conn_printk(KERN_ERR, conn,
+ "Cannot set param as sock is NULL\n");
+ return -ENOTCONN;
+ }
+
switch(param) {
case ISCSI_PARAM_HDRDGST_EN:
iscsi_set_param(cls_conn, param, buf, buflen);
--
2.18.4
[PATCH] usb: gadget: Fix spinlock lockup on usb_function_deactivate
There is a spinlock lockup as part of composite_disconnect
when it tries to acquire cdev->lock as part of usb_gadget_deactivate.
This is because the usb_gadget_deactivate is called from
usb_function_deactivate with the same spinlock held.
This would result in the below call stack and leads to stall.
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: 3-...0: (1 GPs behind) idle=162/1/0x4000
softirq=10819/10819 fqs=2356
(detected by 2, t=5252 jiffies, g=20129, q=3770)
Task dump for CPU 3:
task:uvc-gadget_wlhe state:R running task stack:0 pid: 674 ppid:
636 flags:0x0202
Call trace:
__switch_to+0xc0/0x170
_raw_spin_lock_irqsave+0x84/0xb0
composite_disconnect+0x28/0x78
configfs_composite_disconnect+0x68/0x70
usb_gadget_disconnect+0x10c/0x128
usb_gadget_deactivate+0xd4/0x108
usb_function_deactivate+0x6c/0x80
uvc_function_disconnect+0x20/0x58
uvc_v4l2_release+0x30/0x88
v4l2_release+0xbc/0xf0
__fput+0x7c/0x230
fput+0x14/0x20
task_work_run+0x88/0x140
do_notify_resume+0x240/0x6f0
work_pending+0x8/0x200
Fix this by doing an unlock on cdev->lock before the usb_gadget_deactivate
call from usb_function_activate.
Reported-by: Peter Chen
Link: https://lore.kernel.org/linux-usb/20201102094936.GA29581@b29397-desktop/
Tested-by: Peter Chen
Signed-off-by: Sriharsha Allenki
---
drivers/usb/gadget/composite.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index c6d455f2bb92..1a556a628971 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -392,8 +392,11 @@ int usb_function_deactivate(struct usb_function *function)
spin_lock_irqsave(>lock, flags);
- if (cdev->deactivations == 0)
+ if (cdev->deactivations == 0) {
+ spin_unlock_irqrestore(>lock, flags);
status = usb_gadget_deactivate(cdev->gadget);
+ spin_lock_irqsave(>lock, flags);
+ }
if (status == 0)
cdev->deactivations++;
@@ -424,8 +427,11 @@ int usb_function_activate(struct usb_function *function)
status = -EINVAL;
else {
cdev->deactivations--;
- if (cdev->deactivations == 0)
+ if (cdev->deactivations == 0) {
+ spin_unlock_irqrestore(>lock, flags);
status = usb_gadget_activate(cdev->gadget);
+ spin_lock_irqsave(>lock, flags);
+ }
}
spin_unlock_irqrestore(>lock, flags);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
Re: linux-next: build failure after merge of the akpm-current tree
On Wed, Nov 4, 2020 at 9:05 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/numa.h:25,
> from include/linux/nodemask.h:96,
> from include/linux/mount.h:15,
> from fs/pnode.c:9:
> arch/powerpc/include/asm/sparsemem.h:17:16: error: unknown type name
> 'pgprot_t'
>17 | int nid, pgprot_t prot);
> |^~~~
>
> Caused by commit
>
> 45339c019cbc ("mm: fix phys_to_target_node() and
> memory_add_physaddr_to_nid() exports")
>
> I have reverted that commit for today (maybe I should not have added
> it :-().
Ugh, I'll check my cross-compile coverage.
[PATCH v2] x86/speculation: Allow IBPB to be conditionally enabled on CPUs with always-on STIBP
On AMD CPUs which have the feature X86_FEATURE_AMD_STIBP_ALWAYS_ON,
STIBP is set to on and 'spectre_v2_user_stibp ==
SPECTRE_V2_USER_STRICT_PREFERRED'. At the same time, IBPB can be set to
conditional. However, this leads to the case where it's impossible to
turn on IBPB for a process because in the PR_SPEC_DISABLE case in
ib_prctl_set, the (spectre_v2_user_stibp ==
SPECTRE_V2_USER_STRICT_PREFERRED) condition leads to a return before the
task flag is set. Similarly, ib_prctl_get will return PR_SPEC_DISABLE
even though IBPB is set to conditional.
More generally, the following cases are possible:
1. STIBP = conditional && IBPB = on for spectre_v2_user=seccomp,ibpb
2. STIBP = on && IBPB = conditional for AMD CPUs with
X86_FEATURE_AMD_STIBP_ALWAYS_ON
The first case functions correctly today, but only because
spectre_v2_user_ibpb isn't updated to reflect the IBPB mode.
At a high level, this change does one thing. If either STIBP or IBPB is
set to conditional, allow the prctl to change the task flag. Also,
reflect that capability when querying the state. This isn't perfect
since it doesn't take into account if only STIBP or IBPB is
unconditionally on. But it allows the conditional feature to work as
expected, without affecting the unconditional one.
Signed-off-by: Anand K Mistry
---
Changes in v2:
- Fix typo in commit message
- s/is_spec_ib_user/is_spec_ib_user_controlled
- Update comment in ib_prctl_set() to reference X86_FEATURE_AMD_STIBP_ALWAYS_ON
- Have is_spec_ib_user_controlled() check both IBPB and STIBP modes
arch/x86/kernel/cpu/bugs.c | 46 +++---
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index d3f0db463f96..534225afe832 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1254,6 +1254,14 @@ static int ssb_prctl_set(struct task_struct *task,
unsigned long ctrl)
return 0;
}
+static bool is_spec_ib_user_controlled(void)
+{
+ return spectre_v2_user_ibpb == SPECTRE_V2_USER_PRCTL ||
+ spectre_v2_user_ibpb == SPECTRE_V2_USER_SECCOMP ||
+ spectre_v2_user_stibp == SPECTRE_V2_USER_PRCTL ||
+ spectre_v2_user_stibp == SPECTRE_V2_USER_SECCOMP;
+}
+
static int ib_prctl_set(struct task_struct *task, unsigned long ctrl)
{
switch (ctrl) {
@@ -1262,13 +1270,20 @@ static int ib_prctl_set(struct task_struct *task,
unsigned long ctrl)
spectre_v2_user_stibp == SPECTRE_V2_USER_NONE)
return 0;
/*
-* Indirect branch speculation is always disabled in strict
-* mode. It can neither be enabled if it was force-disabled
-* by a previous prctl call.
+* With strict mode for both IBPB and STIBP, the instruction
+* code paths avoid checking this task flag and instead,
+* unconditionally run the instruction. However, STIBP and IBPB
+* are independent and either can be set to conditionally
+* enabled regardless of the mode of the other. If either is set
+* to conditional, allow the task flag to be updated, unless it
+* was force-disabled by a previous prctl call.
+* Currently, this is possible on an AMD CPU which has the
+* feature X86_FEATURE_AMD_STIBP_ALWAYS_ON. In this case, if the
+* kernel is booted with 'spectre_v2_user=seccomp', then
+* spectre_v2_user_ibpb == SPECTRE_V2_USER_SECCOMP and
+* spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED.
*/
- if (spectre_v2_user_ibpb == SPECTRE_V2_USER_STRICT ||
- spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT ||
- spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED ||
+ if (!is_spec_ib_user_controlled() ||
task_spec_ib_force_disable(task))
return -EPERM;
task_clear_spec_ib_disable(task);
@@ -1283,9 +1298,7 @@ static int ib_prctl_set(struct task_struct *task,
unsigned long ctrl)
if (spectre_v2_user_ibpb == SPECTRE_V2_USER_NONE &&
spectre_v2_user_stibp == SPECTRE_V2_USER_NONE)
return -EPERM;
- if (spectre_v2_user_ibpb == SPECTRE_V2_USER_STRICT ||
- spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT ||
- spectre_v2_user_stibp == SPECTRE_V2_USER_STRICT_PREFERRED)
+ if (!is_spec_ib_user_controlled())
return 0;
task_set_spec_ib_disable(task);
if (ctrl == PR_SPEC_FORCE_DISABLE)
@@ -1351,20 +1364,17 @@ static int ib_prctl_get(struct task_struct *task)
if (spectre_v2_user_ibpb == SPECTRE_V2_USER_NONE &&
spectre_v2_user_stibp ==
Re: [REGRESSION] hwmon: (applesmc) avoid overlong udelay()
On 11/4/20 9:05 PM, Brad Campbell wrote: > On 5/11/20 3:43 pm, Guenter Roeck wrote: >> On 11/4/20 6:18 PM, Brad Campbell wrote: >>> On 5/11/20 12:20 am, Andreas Kemnade wrote: On Tue, 3 Nov 2020 16:56:32 +1100 Brad Campbell wrote: >>> > If anyone with a Mac having a conventional SMC and seeing issues on 5.9 > could test this it'd be appreciated. I'm not saying this code is > "correct", but it "works for me". > Seems to work here. dmesg | grep applesmc [ 1.350782] applesmc: key=561 fan=1 temp=33 index=33 acc=0 lux=2 kbd=1 [ 1.350922] applesmc applesmc.768: hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info(). [ 17.748504] applesmc: wait_status looping 2: 0x4a, 0x4c, 0x4f [ 212.008952] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e [ 213.033930] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e [ 213.167908] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e [ 219.087854] applesmc: wait_status looping 2: 0x44, 0x40, 0x4e Tested it on top of 5.9 >>> >>> Much appreciated Andreas. >>> >>> I'm not entirely sure where to go from here. I'd really like some wider >>> testing before cleaning this up and submitting it. It puts extra checks & >>> constraints on the comms with the SMC that weren't there previously. >>> >>> I guess given there doesn't appear to have been a major outcry that the >>> driver broke in 5.9 might indicate that nobody is using it, or that it only >>> broke on certain machines? >>> >>> Can we get some guidance from the hwmon maintainers on what direction >>> they'd like to take? I don't really want to push this forward without >>> broader testing only to find it breaks a whole heap of machines on the >>> basis that it fixes mine. >>> >> >> Trick question ;-). >> >> I'd suggest to keep it simple. Your patch seems to be quite complicated >> and checks a lot of bits. Reducing that to a minimum would help limiting >> the risk that some of those bits are interpreted differently on other >> systems. >> >> Guenter >> >> > Appreciate the feedback. > > This would be the bare minimum based on the bits use in the original code. If > the original code worked "well enough" then this should be relatively safe. > Can you clean that up and submit as patch ? Thanks, Guenter
[PATCH v2] venus: venc: fix handlig of S_SELECTION and G_SELECTION
- return correct width and height for G_SELECTION
- update capture port wxh with rectangle wxh.
- add support for HFI_PROPERTY_PARAM_UNCOMPRESSED_PLANE_ACTUAL_INFO
to set stride info and chroma offset to FW.
Signed-off-by: Dikshita Agarwal
---
drivers/media/platform/qcom/venus/helpers.c| 18 +
drivers/media/platform/qcom/venus/helpers.h| 2 ++
drivers/media/platform/qcom/venus/hfi_cmds.c | 12 +
drivers/media/platform/qcom/venus/hfi_helper.h | 4 +--
drivers/media/platform/qcom/venus/venc.c | 36 ++
5 files changed, 59 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/helpers.c
b/drivers/media/platform/qcom/venus/helpers.c
index 2b6925b..efa2781 100644
--- a/drivers/media/platform/qcom/venus/helpers.c
+++ b/drivers/media/platform/qcom/venus/helpers.c
@@ -1621,3 +1621,21 @@ int venus_helper_get_out_fmts(struct venus_inst *inst,
u32 v4l2_fmt,
return -EINVAL;
}
EXPORT_SYMBOL_GPL(venus_helper_get_out_fmts);
+
+int venus_helper_set_stride(struct venus_inst *inst,
+ unsigned int width, unsigned int height)
+{
+ const u32 ptype = HFI_PROPERTY_PARAM_UNCOMPRESSED_PLANE_ACTUAL_INFO;
+
+ struct hfi_uncompressed_plane_actual_info plane_actual_info;
+
+ plane_actual_info.buffer_type = HFI_BUFFER_INPUT;
+ plane_actual_info.num_planes = 2;
+ plane_actual_info.plane_format[0].actual_stride = width;
+ plane_actual_info.plane_format[0].actual_plane_buffer_height = height;
+ plane_actual_info.plane_format[1].actual_stride = width;
+ plane_actual_info.plane_format[1].actual_plane_buffer_height = height /
2;
+
+ return hfi_session_set_property(inst, ptype, _actual_info);
+}
+EXPORT_SYMBOL_GPL(venus_helper_set_stride);
diff --git a/drivers/media/platform/qcom/venus/helpers.h
b/drivers/media/platform/qcom/venus/helpers.h
index a4a0562..f36c9f71 100644
--- a/drivers/media/platform/qcom/venus/helpers.h
+++ b/drivers/media/platform/qcom/venus/helpers.h
@@ -63,4 +63,6 @@ void venus_helper_get_ts_metadata(struct venus_inst *inst,
u64 timestamp_us,
struct vb2_v4l2_buffer *vbuf);
int venus_helper_get_profile_level(struct venus_inst *inst, u32 *profile, u32
*level);
int venus_helper_set_profile_level(struct venus_inst *inst, u32 profile, u32
level);
+int venus_helper_set_stride(struct venus_inst *inst, unsigned int
aligned_width,
+ unsigned int aligned_height);
#endif
diff --git a/drivers/media/platform/qcom/venus/hfi_cmds.c
b/drivers/media/platform/qcom/venus/hfi_cmds.c
index 7022368..4f75658 100644
--- a/drivers/media/platform/qcom/venus/hfi_cmds.c
+++ b/drivers/media/platform/qcom/venus/hfi_cmds.c
@@ -1205,6 +1205,18 @@ static int pkt_session_set_property_1x(struct
hfi_session_set_property_pkt *pkt,
pkt->shdr.hdr.size += sizeof(u32) + sizeof(*cu);
break;
}
+ case HFI_PROPERTY_PARAM_UNCOMPRESSED_PLANE_ACTUAL_INFO: {
+ struct hfi_uncompressed_plane_actual_info *in = pdata;
+ struct hfi_uncompressed_plane_actual_info *info = prop_data;
+
+ info->buffer_type = in->buffer_type;
+ info->num_planes = in->num_planes;
+ info->plane_format[0] = in->plane_format[0];
+ if (in->num_planes > 1)
+ info->plane_format[1] = in->plane_format[1];
+ pkt->shdr.hdr.size += sizeof(u32) + sizeof(*info);
+ break;
+ }
case HFI_PROPERTY_CONFIG_VENC_MAX_BITRATE:
case HFI_PROPERTY_CONFIG_VDEC_POST_LOOP_DEBLOCKER:
case HFI_PROPERTY_PARAM_BUFFER_ALLOC_MODE:
diff --git a/drivers/media/platform/qcom/venus/hfi_helper.h
b/drivers/media/platform/qcom/venus/hfi_helper.h
index 60ee247..5938a96 100644
--- a/drivers/media/platform/qcom/venus/hfi_helper.h
+++ b/drivers/media/platform/qcom/venus/hfi_helper.h
@@ -908,13 +908,13 @@ struct hfi_uncompressed_plane_actual {
struct hfi_uncompressed_plane_actual_info {
u32 buffer_type;
u32 num_planes;
- struct hfi_uncompressed_plane_actual plane_format[1];
+ struct hfi_uncompressed_plane_actual plane_format[2];
};
struct hfi_uncompressed_plane_actual_constraints_info {
u32 buffer_type;
u32 num_planes;
- struct hfi_uncompressed_plane_constraints plane_format[1];
+ struct hfi_uncompressed_plane_constraints plane_format[2];
};
struct hfi_codec_supported {
diff --git a/drivers/media/platform/qcom/venus/venc.c
b/drivers/media/platform/qcom/venus/venc.c
index 4ecf78e..99bfabf 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -190,8 +190,10 @@ static int venc_enum_fmt(struct file *file, void *fh,
struct v4l2_fmtdesc *f)
pixmp->height = clamp(pixmp->height, frame_height_min(inst),
frame_height_max(inst));
- if
Re: [PATCH v5 14/21] kprobes: Remove NMI context check
On Wed, 4 Nov 2020 09:47:22 -0500
Steven Rostedt wrote:
> On Wed, 4 Nov 2020 11:08:52 +0900
> Masami Hiramatsu wrote:
>
> > kretprobe_hash_lock() and kretprobe_table_lock() will be called from
> > outside of the kprobe pre_handler context. So, please keep in_nmi()
> > in those functions.
> > for the pre_handler_kretprobe(), this looks good to me.
> >
>
> Final version, before sending to Linus.
This looks good to me :)
Thank you!
>
> -- Steve
>
> From: "Steven Rostedt (VMware)"
> Subject: [PATCH] kprobes: Tell lockdep about kprobe nesting
>
> Since the kprobe handlers have protection that prohibits other handlers from
> executing in other contexts (like if an NMI comes in while processing a
> kprobe, and executes the same kprobe, it will get fail with a "busy"
> return). Lockdep is unaware of this protection. Use lockdep's nesting api to
> differentiate between locks taken in INT3 context and other context to
> suppress the false warnings.
>
> Link:
> https://lore.kernel.org/r/20201102160234.fa0ae70915ad9e2b21c08...@kernel.org
>
> Cc: Peter Zijlstra
> Acked-by: Masami Hiramatsu
> Signed-off-by: Steven Rostedt (VMware)
> ---
> kernel/kprobes.c | 25 +
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 8a12a25fa40d..41fdbb7953c6 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1249,7 +1249,13 @@ __acquires(hlist_lock)
>
> *head = _inst_table[hash];
> hlist_lock = kretprobe_table_lock_ptr(hash);
> - raw_spin_lock_irqsave(hlist_lock, *flags);
> + /*
> + * Nested is a workaround that will soon not be needed.
> + * There's other protections that make sure the same lock
> + * is not taken on the same CPU that lockdep is unaware of.
> + * Differentiate when it is taken in NMI context.
> + */
> + raw_spin_lock_irqsave_nested(hlist_lock, *flags, !!in_nmi());
> }
> NOKPROBE_SYMBOL(kretprobe_hash_lock);
>
> @@ -1258,7 +1264,13 @@ static void kretprobe_table_lock(unsigned long hash,
> __acquires(hlist_lock)
> {
> raw_spinlock_t *hlist_lock = kretprobe_table_lock_ptr(hash);
> - raw_spin_lock_irqsave(hlist_lock, *flags);
> + /*
> + * Nested is a workaround that will soon not be needed.
> + * There's other protections that make sure the same lock
> + * is not taken on the same CPU that lockdep is unaware of.
> + * Differentiate when it is taken in NMI context.
> + */
> + raw_spin_lock_irqsave_nested(hlist_lock, *flags, !!in_nmi());
> }
> NOKPROBE_SYMBOL(kretprobe_table_lock);
>
> @@ -2028,7 +2040,12 @@ static int pre_handler_kretprobe(struct kprobe *p,
> struct pt_regs *regs)
>
> /* TODO: consider to only swap the RA after the last pre_handler fired
> */
> hash = hash_ptr(current, KPROBE_HASH_BITS);
> - raw_spin_lock_irqsave(>lock, flags);
> + /*
> + * Nested is a workaround that will soon not be needed.
> + * There's other protections that make sure the same lock
> + * is not taken on the same CPU that lockdep is unaware of.
> + */
> + raw_spin_lock_irqsave_nested(>lock, flags, 1);
> if (!hlist_empty(>free_instances)) {
> ri = hlist_entry(rp->free_instances.first,
> struct kretprobe_instance, hlist);
> @@ -2039,7 +2056,7 @@ static int pre_handler_kretprobe(struct kprobe *p,
> struct pt_regs *regs)
> ri->task = current;
>
> if (rp->entry_handler && rp->entry_handler(ri, regs)) {
> - raw_spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave_nested(>lock, flags, 1);
> hlist_add_head(>hlist, >free_instances);
> raw_spin_unlock_irqrestore(>lock, flags);
> return 0;
> --
> 2.25.4
>
--
Masami Hiramatsu
Re: [RFC PATCH] .clang-format: Remove conditional comments
On Thu, Nov 5, 2020 at 1:33 AM Nick Desaulniers wrote: > > Yeah, that's annoying. Why don't you send me a patch that downgrades > it from hard error to polite warning (in case someone made a typo), > and I'll review it? Sure! Cheers, Miguel
[tip:core/urgent] BUILD SUCCESS 9d820f68b2bdba5b2e7bf135123c3f57c5051d05
defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20201104 i386 randconfig-a006-20201104 i386 randconfig-a005-20201104 i386 randconfig-a001-20201104 i386 randconfig-a002-20201104 i386 randconfig-a003-20201104 i386 randconfig-a004-20201105 i386 randconfig-a006-20201105 i386 randconfig-a005-20201105 i386 randconfig-a001-20201105 i386 randconfig-a002-20201105 i386 randconfig-a003-20201105 x86_64 randconfig-a012-20201104 x86_64 randconfig-a015-20201104 x86_64 randconfig-a013-20201104 x86_64 randconfig-a011-20201104 x86_64 randconfig-a014-20201104 x86_64 randconfig-a016-20201104 i386 randconfig-a015-20201104 i386 randconfig-a013-20201104 i386 randconfig-a014-20201104 i386 randconfig-a016-20201104 i386 randconfig-a011-20201104 i386 randconfig-a012-20201104 riscvallyesconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a004-20201104 x86_64 randconfig-a003-20201104 x86_64 randconfig-a005-20201104 x86_64 randconfig-a002-20201104 x86_64 randconfig-a006-20201104 x86_64 randconfig-a001-20201104 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v2 net-next 3/3] octeontx2-af: Add devlink health reporters for NIX
On Wed, 2020-11-04 at 17:57 +0530, George Cherian wrote: > Add health reporters for RVU NPA block. ^^^ NIX ? Cc: Jiri Anyway, could you please spare some words on what is NPA and what is NIX? Regarding the reporters names, all drivers register well known generic names such as (fw,hw,rx,tx), I don't know if it is a good idea to use vendor specific names, if you are reporting for hw/fw units then just use "hw" or "fw" as the reporter name and append the unit NPA/NIX to the counter/error names. > Only reporter dump is supported. > > Output: > # ./devlink health > pci/0002:01:00.0: >reporter npa > state healthy error 0 recover 0 >reporter nix > state healthy error 0 recover 0 > # ./devlink health dump show pci/0002:01:00.0 reporter nix > NIX_AF_GENERAL: > Memory Fault on NIX_AQ_INST_S read: 0 > Memory Fault on NIX_AQ_RES_S write: 0 > AQ Doorbell error: 0 > Rx on unmapped PF_FUNC: 0 > Rx multicast replication error: 0 > Memory fault on NIX_RX_MCE_S read: 0 > Memory fault on multicast WQE read: 0 > Memory fault on mirror WQE read: 0 > Memory fault on mirror pkt write: 0 > Memory fault on multicast pkt write: 0 >NIX_AF_RAS: > Poisoned data on NIX_AQ_INST_S read: 0 > Poisoned data on NIX_AQ_RES_S write: 0 > Poisoned data on HW context read: 0 > Poisoned data on packet read from mirror buffer: 0 > Poisoned data on packet read from mcast buffer: 0 > Poisoned data on WQE read from mirror buffer: 0 > Poisoned data on WQE read from multicast buffer: 0 > Poisoned data on NIX_RX_MCE_S read: 0 >NIX_AF_RVU: > Unmap Slot Error: 0 > Now i am a little bit skeptic here, devlink health reporter infrastructure was never meant to deal with dump op only, the main purpose is to diagnose/dump and recover. especially in your use case where you only report counters, i don't believe devlink health dump is a proper interface for this. Many of these counters if not most are data path packet based and maybe they should belong to ethtool.
Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support
On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote: > Add support for TEE based trusted keys where TEE provides the functionality > to seal and unseal trusted keys using hardware unique key. Also, this is > an alternative in case platform doesn't possess a TPM device. > > This patch-set has been tested with OP-TEE based early TA which is already > merged in upstream [1]. Is the new RPI400 computer a platform that can be used for testing patch sets like this? I've been looking for a while something ARM64 based with similar convenience as Intel NUC's, and on the surface this new RPI product looks great for kernel testing purposes. /Jarkko > > [1] > https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d7e5b86b > > Changes in v8: > 1. Added static calls support instead of indirect calls. > 2. Documented trusted keys source module parameter. > 3. Refined patch #1 commit message discription. > 4. Addressed misc. comments on patch #2. > 5. Added myself as Trusted Keys co-maintainer instead. > 6. Rebased to latest tpmdd master. > > Changes in v7: > 1. Added a trusted.source module parameter in order to enforce user's >choice in case a particular platform posses both TPM and TEE. > 2. Refine commit description for patch #1. > > Changes in v6: > 1. Revert back to dynamic detection of trust source. > 2. Drop author mention from trusted_core.c and trusted_tpm1.c files. > 3. Rebased to latest tpmdd/master. > > Changes in v5: > 1. Drop dynamic detection of trust source and use compile time flags >instead. > 2. Rename trusted_common.c -> trusted_core.c. > 3. Rename callback: cleanup() -> exit(). > 4. Drop "tk" acronym. > 5. Other misc. comments. > 6. Added review tags for patch #3 and #4. > > Changes in v4: > 1. Pushed independent TEE features separately: > - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062 > 2. Updated trusted-encrypted doc with TEE as a new trust source. > 3. Rebased onto latest tpmdd/master. > > Changes in v3: > 1. Update patch #2 to support registration of multiple kernel pages. > 2. Incoporate dependency patch #4 in this patch-set: >https://patchwork.kernel.org/patch/11091435/ > > Changes in v2: > 1. Add reviewed-by tags for patch #1 and #2. > 2. Incorporate comments from Jens for patch #3. > 3. Switch to use generic trusted keys framework. > > Sumit Garg (4): > KEYS: trusted: Add generic trusted keys framework > KEYS: trusted: Introduce TEE based Trusted Keys > doc: trusted-encrypted: updates with TEE as a new trust source > MAINTAINERS: Add myself as Trusted Keys co-maintainer > > Documentation/admin-guide/kernel-parameters.txt | 12 + > Documentation/security/keys/trusted-encrypted.rst | 203 +++-- > MAINTAINERS | 2 + > include/keys/trusted-type.h | 47 +++ > include/keys/trusted_tee.h| 55 > include/keys/trusted_tpm.h| 17 +- > security/keys/trusted-keys/Makefile | 2 + > security/keys/trusted-keys/trusted_core.c | 354 > ++ > security/keys/trusted-keys/trusted_tee.c | 278 + > security/keys/trusted-keys/trusted_tpm1.c | 336 > 10 files changed, 979 insertions(+), 327 deletions(-) > create mode 100644 include/keys/trusted_tee.h > create mode 100644 security/keys/trusted-keys/trusted_core.c > create mode 100644 security/keys/trusted-keys/trusted_tee.c > > -- > 2.7.4 > >
Re: [PATCH v20 00/20] per memcg lru lock
在 2020/11/5 上午12:59, Johannes Weiner 写道: > On Wed, Nov 04, 2020 at 07:55:39PM +0800, Alex Shi wrote: >> @@ -1380,6 +1383,14 @@ struct lruvec *mem_cgroup_page_lruvec(struct page >> *page, struct pglist_data *pgd >> return lruvec; >> } >> >> +/** >> + * lock_page_lruvec - return lruvec for the locked page. > > I would say "lock and return the lruvec for a given page" > >> + * @page: the page >> + * >> + * This series functions should be used in either conditions: >> + * PageLRU is cleared or unset >> + * or, page->_refcount is zero > > or page is locked > > The other changes look good to me, thanks! > Thanks a lot for both comments! I will pick them and sent out in v21. Thanks! Alex
