On Wed, May 01, 2024 at 11:31:02AM -0400, Michael S. Tsirkin wrote:
> On Wed, May 01, 2024 at 12:51:51PM +0200, Peter Zijlstra wrote:
> > On Tue, Apr 30, 2024 at 12:50:05PM +0200, Tobias Huschle wrote:
<...>
> >
> > I'm still wondering why exactly it is imperat
On Wed, May 01, 2024 at 12:51:51PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 30, 2024 at 12:50:05PM +0200, Tobias Huschle wrote:
<...>
> >
> > Let's now assume, that ocassionally, task 2 runs a little bit longer than
> > task 1. In CFS, this means, that task 2
It took me a while, but I was able to figure out why EEVDF behaves
different then CFS does. I'm still waiting for some official confirmation
of my assumptions but it all seems very plausible to me.
Leaving aside all the specifics of vhost and kworkers, a more general
description of the scenario w
On 2024-03-19 09:29, Michael S. Tsirkin wrote:
On Tue, Mar 19, 2024 at 09:21:06AM +0100, Tobias Huschle wrote:
On 2024-03-15 11:31, Michael S. Tsirkin wrote:
> On Fri, Mar 15, 2024 at 09:33:49AM +0100, Tobias Huschle wrote:
> > On Thu, Mar 14, 2024 at 11:09:25AM -0400, Michael S. Tsir
On 2024-03-15 11:31, Michael S. Tsirkin wrote:
On Fri, Mar 15, 2024 at 09:33:49AM +0100, Tobias Huschle wrote:
On Thu, Mar 14, 2024 at 11:09:25AM -0400, Michael S. Tsirkin wrote:
>
Could you remind me pls, what is the kworker doing specifically that
vhost is relying on?
The kworker
On Thu, Mar 14, 2024 at 11:09:25AM -0400, Michael S. Tsirkin wrote:
>
> Thanks a lot! To clarify it is not that I am opposed to changing vhost.
> I would like however for some documentation to exist saying that if you
> do abc then call API xyz. Then I hope we can feel a bit safer that
> future sc
On Tue, Mar 12, 2024 at 09:45:57AM +, Luis Machado wrote:
> On 3/11/24 17:05, Michael S. Tsirkin wrote:
> >
> > Are we going anywhere with this btw?
> >
> >
>
> I think Tobias had a couple other threads related to this, with other
> potential fixe
On Thu, Feb 01, 2024 at 03:08:07AM -0500, Michael S. Tsirkin wrote:
> On Thu, Feb 01, 2024 at 08:38:43AM +0100, Tobias Huschle wrote:
> > On Sun, Jan 21, 2024 at 01:44:32PM -0500, Michael S. Tsirkin wrote:
> > > On Mon, Jan 08, 2024 at 02:13:25PM +0100, Tobias Huschle wrote:
>
On Sun, Jan 21, 2024 at 01:44:32PM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 08, 2024 at 02:13:25PM +0100, Tobias Huschle wrote:
> > On Thu, Dec 14, 2023 at 02:14:59AM -0500, Michael S. Tsirkin wrote:
> > - Along with the wakeup of the kworker, need_resched needs to
> >
On Sun, Jan 21, 2024 at 01:44:32PM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 08, 2024 at 02:13:25PM +0100, Tobias Huschle wrote:
> > On Thu, Dec 14, 2023 at 02:14:59AM -0500, Michael S. Tsirkin wrote:
> > >
> > > Peter, would appreciate feedback on
On Thu, Dec 14, 2023 at 02:14:59AM -0500, Michael S. Tsirkin wrote:
>
> Peter, would appreciate feedback on this. When is cond_resched()
> insufficient to give up the CPU? Should
> Documentation/kernel-hacking/hacking.rst
> be updated to require schedule() instead?
>
Happy new year everybody!
On Wed, Dec 13, 2023 at 07:00:53AM -0500, Michael S. Tsirkin wrote:
> On Wed, Dec 13, 2023 at 11:37:23AM +0100, Tobias Huschle wrote:
> > On Tue, Dec 12, 2023 at 11:15:01AM -0500, Michael S. Tsirkin wrote:
> > > On Tue, Dec 12, 2023 at 11:00:12AM +0800, Jason Wang wrote:
>
On Tue, Dec 12, 2023 at 11:15:01AM -0500, Michael S. Tsirkin wrote:
> On Tue, Dec 12, 2023 at 11:00:12AM +0800, Jason Wang wrote:
> > On Tue, Dec 12, 2023 at 12:54 AM Michael S. Tsirkin wrote:
We played around with the suggestions and some other ideas.
I would like to share some initial results.
On Fri, Dec 08, 2023 at 05:31:18AM -0500, Michael S. Tsirkin wrote:
> On Fri, Dec 08, 2023 at 10:24:16AM +0100, Tobias Huschle wrote:
> > On Thu, Dec 07, 2023 at 01:48:40AM -0500, Michael S. Tsirkin wrote:
> > > On Thu, Dec 07, 2023 at 07:22:12AM +0100, Tobias Huschle wrote
On Thu, Dec 07, 2023 at 01:48:40AM -0500, Michael S. Tsirkin wrote:
> On Thu, Dec 07, 2023 at 07:22:12AM +0100, Tobias Huschle wrote:
> > 3. vhost looping endlessly, waiting for kworker to be scheduled
> >
> > I dug a little deeper on what the vhost is doing. I'm n
On Tue, Nov 28, 2023 at 04:55:11PM +0800, Abel Wu wrote:
> On 11/27/23 9:56 PM, Tobias Huschle Wrote:
> > On Wed, Nov 22, 2023 at 11:00:16AM +0100, Peter Zijlstra wrote:
> > > On Tue, Nov 21, 2023 at 02:17:21PM +0100, Tobias Huschle wrote:
[...]
>
> What are the wei
On Tue, Nov 28, 2023 at 04:55:11PM +0800, Abel Wu wrote:
> On 11/27/23 9:56 PM, Tobias Huschle Wrote:
> > On Wed, Nov 22, 2023 at 11:00:16AM +0100, Peter Zijlstra wrote:
> > > On Tue, Nov 21, 2023 at 02:17:21PM +0100, Tobias Huschle wrote:
[...]
> > - At depth 4, the c
On Wed, Nov 22, 2023 at 11:00:16AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 21, 2023 at 02:17:21PM +0100, Tobias Huschle wrote:
>
> The below should also work for internal entities, but last time I poked
> around with it I had some regressions elsewhere -- you know, fix one,
>
On Fri, Nov 17, 2023 at 09:07:55PM +0800, Abel Wu wrote:
> On 11/17/23 8:37 PM, Peter Zijlstra Wrote:
[...]
> > Ah, so if this is a cgroup issue, it might be worth trying this patch
> > that we have in tip/sched/urgent.
>
> And please also apply this fix:
> https://lore.kernel.org/all/2023111708
On Fri, Nov 17, 2023 at 10:23:18AM +0100, Peter Zijlstra wrote:
>
> Your email is pretty badly mangled by wrapping, please try and
> reconfigure your MUA, esp. the trace and debug output is unreadable.
Just saw that .. sorry, will append the trace and latency data again.
[...]
>
> So bear with
Hi,
when testing the EEVDF scheduler we stumbled upon a performance
regression in a uperf scenario and would like to
kindly ask for feedback on whether we are going into the right direction
with our analysis so far.
The base scenario are two KVM guests running on an s390 LPAR. One guest
host
On Thu, Apr 15, 2021 at 02:39, Vladimir Oltean wrote:
> On Wed, Apr 14, 2021 at 08:39:53PM +0200, Tobias Waldekranz wrote:
>> In order to have two entries for the same destination, they must belong
>> to different FIDs. But that FID is also used for automatic learning. So
>
On Wed, Apr 14, 2021 at 17:14, Marek Behun wrote:
> On Tue, 13 Apr 2021 20:16:24 +0200
> Tobias Waldekranz wrote:
>
>> You could imagine a different mode in which the DSA driver would receive
>> the bucket allocation from the bond/team driver (which in turn could
>
On Tue, Apr 13, 2021 at 17:14, Marek Behun wrote:
> On Tue, 13 Apr 2021 16:46:32 +0200
> Tobias Waldekranz wrote:
>
>> On Tue, Apr 13, 2021 at 02:27, Marek Behun wrote:
>> > On Tue, 13 Apr 2021 01:54:50 +0200
>> > Marek Behun wrote:
>> >
>> &g
On Tue, Apr 13, 2021 at 02:27, Marek Behun wrote:
> On Tue, 13 Apr 2021 01:54:50 +0200
> Marek Behun wrote:
>
>> I will look into this, maybe ask some follow-up questions.
>
> Tobias,
>
> it seems that currently the LAGs in mv88e6xxx driver do not use the
> H
On Tue, Apr 13, 2021 at 01:54, Marek Behun wrote:
> On Tue, 13 Apr 2021 01:13:53 +0200
> Tobias Waldekranz wrote:
>
>> > ...you could get the isolation in place. But you will still lookup the
>> > DA in the ATU, and there you will find a destination of either cpu0 or
&
On Tue, Apr 13, 2021 at 01:09, Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 00:55, Marek Behun wrote:
>> On Tue, 13 Apr 2021 00:05:51 +0200
>> Tobias Waldekranz wrote:
>>
>>> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
>>> > On Mo
On Tue, Apr 13, 2021 at 00:55, Marek Behun wrote:
> On Tue, 13 Apr 2021 00:05:51 +0200
> Tobias Waldekranz wrote:
>
>> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
>> > On Mon, 12 Apr 2021 23:22:45 +0200
>> > Tobias Waldekranz wrote:
>> >
>&g
On Tue, Apr 13, 2021 at 01:06, Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 11:49:22PM +0200, Tobias Waldekranz wrote:
>> On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
>> > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
>> >> On Mon
On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
> On Mon, 12 Apr 2021 23:22:45 +0200
> Tobias Waldekranz wrote:
>
>> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
>> > On Mon, 12 Apr 2021 14:46:11 +0200
>> > Tobias Waldekranz wrote:
>> >
>&g
On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
>> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
>> > On Mon, 12 Apr 2021 14:46:11 +0200
>> > Tobias Waldekranz wrote:
>> >
>&
On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> On Mon, 12 Apr 2021 14:46:11 +0200
> Tobias Waldekranz wrote:
>
>> I agree. Unless you only have a few really wideband flows, a LAG will
>> typically do a great job with balancing. This will happen without the
>
On Mon, Apr 12, 2021 at 17:35, Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 02:46:11PM +0200, Tobias Waldekranz wrote:
>> On Sun, Apr 11, 2021 at 21:50, Vladimir Oltean wrote:
>> > On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
>> >> On S
On Sun, Apr 11, 2021 at 21:50, Vladimir Oltean wrote:
> On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
>> On Sat, 10 Apr 2021 15:34:46 +0200
>> Ansuel Smith wrote:
>>
>> > Hi,
>> > this is a respin of the Marek series in hope that this time we can
>> > finally make some progress wi
On Mon, Mar 22, 2021 at 18:19, Vladimir Oltean wrote:
> On Mon, Mar 22, 2021 at 04:44:41PM +0100, Tobias Waldekranz wrote:
>> I do not know if it is a problem or not, more of an observation: This is
>> not guaranteed to be an exact replay of the events that the bridge port
&g
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> On reception of an skb, the bridge checks if it was marked as 'already
> forwarded in hardware' (checks if skb->offload_fwd_mark == 1), and if it
> is, it puts a mark of its own on that skb, with the switchdev mark
7;ll think we're offloading the bridge master of the LAG, when in
> fact we're not even offloading the LAG. In turn, this will make us set
> skb->offload_fwd_mark = true, which is incorrect and the bridge doesn't
> like it.
>
> Signed-off-by: Vladimir Oltean
> ---
Reviewed-by: Tobias Waldekranz
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> When a DSA port joins a LAG that already had an FDB entry pointing to it:
>
> ip link set bond0 master br0
> bridge fdb add dev bond0 00:01:02:03:04:05 master static
> ip link set swp0 master bond0
>
> the DSA port
creation time, so:
> (a) drivers had to hardcode the initial value for the address ageing time,
> because they didn't get any notification
> (b) that hardcoded value can be out of sync, if the user changes the
> ageing time before enslaving the port to the bridge
>
> Si
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Make sure that the multicast router setting of the bridge is picked up
> correctly by DSA when joining, regardless of whether there are
> sandwiched interfaces or not. The SWITCHDEV_ATTR_ID_BRIDGE_MROUTER port
> att
emitted by the
> bridge for this port.
>
> Signed-off-by: Vladimir Oltean
> ---
Reviewed-by: Tobias Waldekranz
But this new bridge port will not see any STP state
> change notification and will remain FORWARDING, which is how the
> standalone code leaves it in.
>
> Add a function to the bridge which retrieves the current STP state, such
> that drivers can synchronize to it when they may have
t;
> Signed-off-by: Vladimir Oltean
> ---
Reviewed-by: Tobias Waldekranz
idge port is handled in the next
> patches.
>
> Signed-off-by: Vladimir Oltean
> ---
Reviewed-by: Tobias Waldekranz
The V3 and S3 SoCs feature an i2s peripheral identical to that of the H3.
Add it to the dts.
Signed-off-by: Tobias Schramm
---
arch/arm/boot/dts/sun8i-v3.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3.dtsi b/arch/arm/boot/dts/sun8i-v3.dtsi
The V3s, V3 and S3 SoCs have a dma controller. Add it to the dts.
Signed-off-by: Tobias Schramm
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index f8f19d8fa795..89286d3d35d1
The V3/S3 add an i2s peripheral over the features of the V3s. Add a label
to the soc node, such that the V3 dts can add the i2s peripheral.
Signed-off-by: Tobias Schramm
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts
The V3 and S3 sun8i SoCs have an i2s peripheral. This set of
patches adds it to their dts.
Additionally this patchset also adds the V3s DMA controller to its
dts, since the i2s peripheral requires DMA to function properly.
Tobias Schramm (3):
ARM: dts: sun8i: V3s/V3/S3: add dma controller node
SIGN,
+ POWER_SUPPLY_PROP_CHARGE_NOW,
POWER_SUPPLY_PROP_CURRENT_NOW,
};
Reviewed-by: Tobias Schramm
Tested-by: Tobias Schramm
Cheers,
Tobias
clock rate.
Cheers,
Tobias
Changelog:
v2:
- use sdm instead of postdivider for audio-pll
- change patch subject to reflect use of sdm
Tobias Schramm (1):
clk: sunxi-ng: v3s: use sigma-delta modulation for audio-pll
drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 33 ++--
1
Previously it was not possible to achieve clock rates of 24.576MHz and
22.5792MHz, which are commonly required core clocks for the i2s
peripheral of v3s based SoCs.
Add support for those clock rates through the audio pll's sigma-delta
modulator.
Signed-off-by: Tobias Schramm
---
driver
ssible. I
read you'd prefer me to use SDM like the other SoCs though? Shall I send
a v2 utilizing SDM?
Cheers,
Tobias
f 1
That should have of course been "from 1 to 128".
from 0 to 127). Thus 24MHz * 128 / 25 / 5 = 24.576MHz. Since this
requires the postdiv to be set to 5 it is not supported yet.
Cheers,
Tobias
from 0 to 127). Thus 24MHz * 128 / 25 / 5 = 24.576MHz. Since this
requires the postdiv to be set to 5 it is not supported yet.
Cheers,
Tobias
On 2021-02-16 at 12:17:30 +0100, Dmitry Vyukov wrote:
> On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov wrote:
> > > I was fixing KASAN support for my sv48 patchset so I took a look at your
> > > issue: I built a kernel on top of the branch riscv/fixes using
> > > https://github.com/google/syzkalle
ttery.c | 6 ++
1 file changed, 6 insertions(+)
[ ... ]
Reviewed-by: Tobias Schramm
Review retracted.
Please resend the patch with the "Signed-off-by" line included. Then I
can mark it as reviewed.
Sorry for the confusion,
Tobias Schramm
TER,
POWER_SUPPLY_PROP_CHARGE_FULL,
POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
+ POWER_SUPPLY_PROP_CHARGE_NOW,
POWER_SUPPLY_PROP_CURRENT_NOW,
};
Reviewed-by: Tobias Schramm
Tested-by: Tobias Schramm
-by: Tobias Schramm
---
drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.c
index 0e36ca3bf3d5..c6cf590b235a 100644
--- a/drivers/clk/sunxi-ng
On Wed, Feb 10, 2021 at 10:41, Mickey Rachamim wrote:
>> Until that day arrives, are there any chances of Marvell opening up CPSS in
>> the same way DSDT was re-licensed some years back?
> The CPSS code is available to everyone on Marvell Extranet (Requires simple
> registration process)
Right,
On 2021-02-09 at 00:37:24 +0100, Shuah Khan wrote:
> On 2/5/21 12:57 AM, Tobias Klauser wrote:
> > On 2021-02-05 at 08:06:37 +0100, Palmer Dabbelt wrote:
> > > On Thu, 04 Feb 2021 06:50:42 PST (-0800), tklau...@distanz.ch wrote:
> >
> > [...]
> >
> >
On Tue, Feb 09, 2021 at 20:31, Mickey Rachamim wrote:
> Hi Andrew, Jakub, Tobias,
>
> On Tuesday, February 9, 2021 7:35 PM Jakub Kicinski wrote:
>> Sounds like we have 3 people who don't like FW-heavy designs dominating the
>> kernel - this conversation can only go one
On Mon, Feb 08, 2021 at 23:30, Andrew Lunn wrote:
>> > I took a quick look at it, and what I found left me very puzzled. I hope
>> > you do not mind me asking a generic question about the policy around
>> > switchdev drivers. If someone published a driver using something similar
>> > to the follow
On Mon, Feb 08, 2021 at 13:05, Jakub Kicinski wrote:
> On Mon, 08 Feb 2021 20:54:29 +0100 Tobias Waldekranz wrote:
>> On Thu, Feb 04, 2021 at 21:16, Jakub Kicinski wrote:
>> > On Wed, 3 Feb 2021 18:54:56 +0200 Vadym Kochan wrote:
>> >> From: Serhiy Boiko
>&
- The Hash parameters are not configurable. They are applied
>> during the LAG creation stage.
>> - Enslaving a port to the LAG device that already has an
>> upper device is not supported.
>
> Tobias, Vladimir, you worked on LAG support recently, would you mind
> taking a lo
On 2021-02-05 at 08:06:37 +0100, Palmer Dabbelt wrote:
> On Thu, 04 Feb 2021 06:50:42 PST (-0800), tklau...@distanz.ch wrote:
[...]
> Reviewed-by: Palmer Dabbelt
> Acked-by: Palmer Dabbelt
Thank you!
> Not sure if you want this through the RISC-V tree, so I'm leaving it out for
> now and ass
Signed-off-by: Tobias Klauser
---
tools/testing/selftests/vDSO/vdso_config.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/vDSO/vdso_config.h
b/tools/testing/selftests/vDSO/vdso_config.h
index 6a6fe8d4ff55..6188b16827d1 100644
--- a/tools/testing
On Sun, Jan 31, 2021 at 09:13, DENG Qingfang wrote:
> On Sun, Jan 31, 2021 at 8:39 AM Vladimir Oltean wrote:
>>
>> Tobias has a point in a way too, you should get used to adding the
>> 'master static' flags to your bridge fdb commands, otherwise weird
>> thin
On Sat, Jan 30, 2021 at 21:43, DENG Qingfang wrote:
> Having multiple destination ports for a unicast address does not make
> sense.
> Make port_db_load_purge override existent unicast portvec instead of
> adding a new port bit.
Is this the layer we want to solve this problem at? What are the
con
0 AX 0 0 4
> > [13] .rodata PROGBITS 000bb648 000ab648
> > 0002b076 A 0 0 8
> > [14] .sdata2 PROGBITS 000e66c0 000d66c0
> >0163
n assembling the fid from VTU op [3:0]
> and [11:8].
>
> Signed-off-by: Rasmus Villemoes
We might also want to give mv88e6250_g1_vtu_loadpurge the same
treatment.
Reviewed-by: Tobias Waldekranz
Tested-by: Tobias Waldekranz
aking VLAN filtering.
>
> When the VTU entry is initially created, those bits are all zero, and
> we should make sure to keep them that way when the entry is updated.
>
> Fixes: 92307069a96c (net: dsa: mv88e6xxx: Avoid VTU corruption on 6097)
> Signed-off-by: Rasmus Villemoes
R
Add the futex test binary introduced by commit a4fd8414659b
("selftests/timens: Add a test for futex()") to .gitignore.
Signed-off-by: Tobias Klauser
---
tools/testing/selftests/timens/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/timens/.gi
ype
‘long int’, but argument 7 has type ‘long long int’ [-Wformat=]
The tv_sec member of __kernel_timespec is long long, both in
uapi/linux/time_types.h and locally in vdso_test_correctness.c.
Signed-off-by: Tobias Klauser
---
tools/testing/selftests/vDSO/vdso_test_correctness.c | 2 +-
1 file change
Add the test binaries introduced by commit 693f5ca08ca0 ("kselftest:
Extend vDSO selftest"), commit 03f55c7952c9 ("kselftest: Extend vDSO
selftest to clock_getres") and commit c7e5789b24d3 ("kselftest: Move
test_vdso to the vDSO test suite") to .gitignore.
On Mon Nov 9, 2020 at 3:38 PM CET, Vladimir Oltean wrote:
> On Mon, Nov 09, 2020 at 02:31:11PM +0200, Vladimir Oltean wrote:
> > I need to sit on this for a while. How many DSA drivers do we have that
> > don't do SA learning in hardware for CPU-injected packets? ocelot/felix
> > and mv88e6xxx? Who
On Mon, Nov 09, 2020 at 12:03, Vladimir Oltean wrote:
> On Mon, Nov 09, 2020 at 09:09:37AM +0100, Tobias Waldekranz wrote:
>> one. But now you have also increased the background load of an already
>> choked resource, the MDIO bus.
>
> In practice, DSA switches are already ve
On Mon, Nov 09, 2020 at 02:30, Vladimir Oltean wrote:
> On Mon, Nov 09, 2020 at 12:59:39AM +0100, Andrew Lunn wrote:
>> We also need to make sure the static entries get removed correctly
>> when a host moves. The mv88e6xxx will not replace a static entry with
>> a dynamically learned one. It will
On 2020-10-28 at 00:36:46 +0100, Ian Rogers wrote:
> Avoid an unused variable warning.
>
> Signed-off-by: Ian Rogers
Reviewed-by: Tobias Klauser
On 2020-10-28 at 00:36:45 +0100, Ian Rogers wrote:
> The bpf_caps array is shorter without CAP_BPF, avoid out of bounds reads
> if this isn't defined. Working around this avoids -Wno-array-bounds with
> clang.
>
> Signed-off-by: Ian Rogers
Reviewed-by: Tobias Klauser
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 000601bb62330f18dc8f5d2d0b82e9aec3e207c4
Gitweb:
https://git.kernel.org/tip/000601bb62330f18dc8f5d2d0b82e9aec3e207c4
Author:Tobias Klauser
AuthorDate:Thu, 09 Jul 2020 15:05:59 +02:00
The following commit has been merged into the core/rcu branch of tip:
Commit-ID: 77f808607a62c3685381a5732a88b30bad8893b5
Gitweb:
https://git.kernel.org/tip/77f808607a62c3685381a5732a88b30bad8893b5
Author:Tobias Klauser
AuthorDate:Thu, 02 Jul 2020 18:28:10 +02:00
On 2020-09-30 19:10, Pavel Machek wrote:
Hi Pavel,
> > In the error path of the for_each_available_child_of_node loop in
> > aw2013_probe_dt, add missing call to of_node_put to avoid leaking
> > the iterator.
> >
> > Fixes: 59ea3c9faf32 ("leds: add aw2013
In one of the error paths of the for_each_child_of_node loop in
tlc591xx_probe, add missing call to of_node_put.
Fixes: 1ab4531ad132 ("leds: tlc591xx: simplify driver by using the managed led
API")
Signed-off-by: Tobias Jordan
Reviewed-by: Marek Behún
---
v3: removed linebreak from
Add missing of_node_put calls when exiting the for_each_child_of_node
loop in rcar_gyroadc_parse_subdevs early.
Also add goto-exception handling for the error paths in that loop.
Fixes: 059c53b32329 ("iio: adc: Add Renesas GyroADC driver")
Signed-off-by: Tobias Jordan
---
v2:
: f110f3188e56 ("iio: temperature: Add support for LTC2983")
Signed-off-by: Tobias Jordan
---
drivers/iio/temperature/ltc2983.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/iio/temperature/ltc2983.c
b/drivers/iio/temperature/ltc2983.c
index 55ff28a0f1c7..438e0ee
c53b32329 ("iio: adc: Add Renesas GyroADC driver")
Signed-off-by: Tobias Jordan
---
drivers/iio/adc/rcar-gyroadc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iio/adc/rcar-gyroadc.c b/drivers/iio/adc/rcar-gyroadc.c
index dcaefc108ff6..3746b0276b80 100644
--- a/driver
In one of the error paths of the for_each_child_of_node loop in
tlc591xx_probe, add missing call to of_node_put.
Fixes: 1ab4531ad132 ("leds: tlc591xx: simplify driver by using the
managed led API")
Signed-off-by: Tobias Jordan
---
v2: rebased to Pavel's for-next branch
dr
In the for_each_available_child_of_node loop of integrator_lm_populate,
add a call to of_node_put to avoid leaking the iterator if we bail out.
Fixes: ccea5e8a5918 ("bus: Add driver for Integrator/AP logic modules")
Signed-off-by: Tobias Jordan
---
drivers/bus/arm-integrator-lm.c | 1
In the for_each_available_child_of_node loop of qcom_ebi2_probe, add a
call to of_node_put to avoid leaking the iterator if we bail out.
Fixes: 335a12754808 ("bus: qcom: add EBI2 driver")
Signed-off-by: Tobias Jordan
---
drivers/bus/qcom-ebi2.c | 4 +++-
1 file changed, 3 insert
In the error path of the for_each_available_child_of_node loop in
aw2013_probe_dt, add missing call to of_node_put to avoid leaking the
iterator.
Fixes: 59ea3c9faf32 ("leds: add aw2013 driver")
Signed-off-by: Tobias Jordan
---
drivers/leds/leds-aw2013.c | 4 +++-
1 file changed, 3
In the error path of the for_each_available_child_of_node loop in
omnia_leds_probe, add missing call to of_node_put to fix leaking the
iterator.
Fixes: 089381b27abe ("leds: initial support for Turris Omnia LEDs")
Signed-off-by: Tobias Jordan
---
drivers/leds/leds-turris-omnia.c | 4 ++
In one of the error paths of the for_each_child_of_node loop in
tlc591xx_probe, add missing call to of_node_put.
Fixes: 1ab4531ad132 ("leds: tlc591xx: simplify driver by using the
managed led API")
Signed-off-by: Tobias Jordan
---
drivers/leds/leds-tlc591xx.c | 1 +
1 file changed, 1
Fix error paths in for_each_child_of_node loops that were missing an
of_node_put call.
Fixes: 92a81562e695 ("leds: lp55xx: Add multicolor framework support to
lp55xx")
Signed-off-by: Tobias Jordan
---
drivers/leds/leds-lp55xx-common.c | 8 ++--
1 file changed, 6 insertions(+), 2
, but that missed the leak of the original endpoint
and also the first error path which was obviously wrong as well.
Fix the leak of endpoint in the error path by calling of_node_put on
it.
Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
Signed-off-by: Tobias Jorda
, but that missed the leak of the original port_node
and also the first error path which was obviously wrong as well.
Fix the leak of port_node in the error paths by calling of_node_put on
it.
Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
Signed-off-by: Tobias
#x27;s maybe time to save them some effort.
[1]: https://lists.elisa.tech/g/devel/message/1089
Fixes: 46c5801eaf86 ("crc32: bolt on crc32c")
Signed-off-by: Tobias Jordan
---
Sorry for spamming people in CC:, there doesn't seem to be a designated
maintainer for lib/crc*.
li
ncorrect type in argument 3 (different
address spaces)
kernel/stackleak.c:31:50:expected void *
kernel/stackleak.c:31:50:got void [noderef] __user *buffer
Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
Cc: Christoph Hellwig
Cc: Al Viro
Sig
ng: incorrect type in argument 3 (different
address spaces)
kernel/trace/ftrace.c:7544:43:expected void *
kernel/trace/ftrace.c:7544:43:got void [noderef] __user *buffer
Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
Cc: Christoph Hellwig
Cc: Al V
.h:374:5:int extern [addressable] [signed]
[toplevel] dirtytime_interval_handler( ... )
Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
Cc: Christoph Hellwig
Cc: Al Viro
Signed-off-by: Tobias Klauser
---
fs/fs-writeback.c | 2 +-
1 file changed, 1 insertio
This commit enables ddr modes for eMMC storage on emmc2.
The bcm2711 supports eMMC storage using ddr modes. The board
layout of the Raspberry Pi 4 supports them, too.
Signed-off-by: Tobias Schramm
---
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch
1 - 100 of 825 matches
Mail list logo
