* Re: [RFC PATCH next-20200930] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Joe Perches @ 2020-10-01 19:05 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Kees Cook, Paul E . McKenney, Nick Desaulniers, Lai Jiangshan,
Josh Triplett, Steven Rostedt, LKML, rcu, Clang-Built-Linux ML,
Mathieu Desnoyers, Sedat Dilek, Paul Mackerras, linuxppc-dev
In-Reply-To: <CANiq72mSjs4myQQtUoegjRggjTx9UF70nAcWoXRoTeLMOuf0xQ@mail.gmail.com>
On Thu, 2020-10-01 at 12:15 +0200, Miguel Ojeda wrote:
> Hi Joe,
Buenas Miguel.
> On Thu, Oct 1, 2020 at 12:56 AM Joe Perches <joe@perches.com> wrote:
> > So I installed the powerpc cross compiler, and
> > nope, that doesn't work, it makes a mess.
>
> Thanks a lot for reviving the script and sending the treewide cleanup!
No charge...
I think the end result is cleaner and more obvious.
> > So it looks like the best option is to exclude these
> > 2 files from conversion.
>
> Agreed. Nevertheless, is there any reason arch/powerpc/* should not be
> compiling cleanly with compiler.h? (CC'ing the rest of the PowerPC
> reviewers and ML).
That's not a can of worms I care to open.
Perhaps the powerpc folk can do some fishing.
^ permalink raw reply
* Re: [RFC PATCH next-20200930] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Segher Boessenkool @ 2020-10-01 19:39 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Kees Cook, Paul E . McKenney, Sedat Dilek, Nick Desaulniers,
Lai Jiangshan, Josh Triplett, Steven Rostedt, LKML, rcu,
Clang-Built-Linux ML, Mathieu Desnoyers, Joe Perches,
Paul Mackerras, linuxppc-dev
In-Reply-To: <CANiq72mSjs4myQQtUoegjRggjTx9UF70nAcWoXRoTeLMOuf0xQ@mail.gmail.com>
Hi!
On Thu, Oct 01, 2020 at 12:15:39PM +0200, Miguel Ojeda wrote:
> > So it looks like the best option is to exclude these
> > 2 files from conversion.
>
> Agreed. Nevertheless, is there any reason arch/powerpc/* should not be
> compiling cleanly with compiler.h? (CC'ing the rest of the PowerPC
> reviewers and ML).
You need to #include compiler_types.h to get this #define?
(The twice-defined thing is a warning, not an error. It should be fixed
of course, but it is less important; although it may be pointing to a
deeper problem.)
Segher
^ permalink raw reply
* Re: [PATCH v3 devicetree 0/2] Add Seville Ethernet switch to T1040RDB
From: David Miller @ 2020-10-01 20:10 UTC (permalink / raw)
To: vladimir.oltean
Cc: devicetree, andrew, madalin.bucur, radu-andrei.bulie,
linuxppc-dev, linux-kernel, fido_max, robh+dt, paulus, shawnguo,
netdev
In-Reply-To: <20201001132013.1866299-1-vladimir.oltean@nxp.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Thu, 1 Oct 2020 16:20:11 +0300
> Seville is a DSA switch that is embedded inside the T1040 SoC, and
> supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot.
>
> This series adds this switch to the SoC's dtsi files and to the T1040RDB
> board file.
I am assuming the devicetree folks will pick this series up.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH next-20200930] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Joe Perches @ 2020-10-01 20:19 UTC (permalink / raw)
To: Segher Boessenkool, Miguel Ojeda
Cc: Kees Cook, Paul E . McKenney, Nick Desaulniers, Lai Jiangshan,
Josh Triplett, Steven Rostedt, LKML, rcu, Clang-Built-Linux ML,
Mathieu Desnoyers, Sedat Dilek, Paul Mackerras, linuxppc-dev
In-Reply-To: <20201001193937.GM28786@gate.crashing.org>
On Thu, 2020-10-01 at 14:39 -0500, Segher Boessenkool wrch/ote:
> Hi!
>
> On Thu, Oct 01, 2020 at 12:15:39PM +0200, Miguel Ojeda wrote:
> > > So it looks like the best option is to exclude these
> > > 2 files from conversion.
> >
> > Agreed. Nevertheless, is there any reason arch/powerpc/* should not be
> > compiling cleanly with compiler.h? (CC'ing the rest of the PowerPC
> > reviewers and ML).
>
> You need to #include compiler_types.h to get this #define?
Actually no, you need to add
#include <linux/compiler_attributes.h>
to both files and then it builds properly.
Ideally though nothing should include this file directly.
> (The twice-defined thing is a warning, not an error. It should be fixed
> of course, but it is less important; although it may be pointing to a
> deeper problem.)
>
>
> Segher
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/time: Rename mftbl() to mftb()
From: Segher Boessenkool @ 2020-10-01 20:44 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <94dc68d3d9ef9eb549796d4b938b6ba0305a049b.1601556145.git.christophe.leroy@csgroup.eu>
On Thu, Oct 01, 2020 at 12:42:39PM +0000, Christophe Leroy wrote:
> On PPC64, we have mftb().
> On PPC32, we have mftbl() and an #define mftb() mftbl().
>
> mftb() and mftbl() are equivalent, their purpose is to read the
> content of SPRN_TRBL, as returned by 'mftb' simplified instruction.
>
> binutils seems to define 'mftbl' instruction as an equivalent
> of 'mftb'.
>
> However in both 32 bits and 64 bits documentation, only 'mftb' is
> defined, and when performing a disassembly with objdump, the displayed
> instruction is 'mftb'
>
> No need to have two ways to do the same thing with different
> names, rename mftbl() to have only mftb().
There are mttbl and mttbu insns (and no mttb insn); they write a 32-bit
half for the time base. There is an mftb, and an mftbu. mftbu reads
the upper half, while mftb reads the *whole* register. SPR 269 is the
TBU register, while SPR 268 is called both TB and TBL. Yes, it is
confusing :-)
The "mftb" name is much clearer than "mftbl" (on 64-bit), because it
reads the whole 64-bit register. On 32-bit mftbl is clearer (but not
defined in the architecture, not officially an insn or even an extended
mnemonic).
Segher
^ permalink raw reply
* Re: [PATCH 05/14] fs: don't allow kernel reads and writes without iter ops
From: Eric Biggers @ 2020-10-01 22:38 UTC (permalink / raw)
To: Christoph Hellwig, Al Viro, Linus Torvalds
Cc: linux-arch, Kees Cook, x86, linux-kernel, Luis Chamberlain,
linux-fsdevel, linuxppc-dev, Alexey Dobriyan
In-Reply-To: <20200903142242.925828-6-hch@lst.de>
Christoph, Al, and Linus:
On Thu, Sep 03, 2020 at 04:22:33PM +0200, Christoph Hellwig wrote:
> @@ -510,28 +524,31 @@ static ssize_t new_sync_write(struct file *filp, const char __user *buf, size_t
> /* caller is responsible for file_start_write/file_end_write */
> ssize_t __kernel_write(struct file *file, const void *buf, size_t count, loff_t *pos)
> {
> - mm_segment_t old_fs;
> - const char __user *p;
> + struct kvec iov = {
> + .iov_base = (void *)buf,
> + .iov_len = min_t(size_t, count, MAX_RW_COUNT),
> + };
> + struct kiocb kiocb;
> + struct iov_iter iter;
> ssize_t ret;
>
> if (WARN_ON_ONCE(!(file->f_mode & FMODE_WRITE)))
> return -EBADF;
> if (!(file->f_mode & FMODE_CAN_WRITE))
> return -EINVAL;
> + /*
> + * Also fail if ->write_iter and ->write are both wired up as that
> + * implies very convoluted semantics.
> + */
> + if (unlikely(!file->f_op->write_iter || file->f_op->write))
> + return warn_unsupported(file, "write");
>
> - old_fs = get_fs();
> - set_fs(KERNEL_DS);
> - p = (__force const char __user *)buf;
> - if (count > MAX_RW_COUNT)
> - count = MAX_RW_COUNT;
> - if (file->f_op->write)
> - ret = file->f_op->write(file, p, count, pos);
> - else if (file->f_op->write_iter)
> - ret = new_sync_write(file, p, count, pos);
> - else
> - ret = -EINVAL;
> - set_fs(old_fs);
> + init_sync_kiocb(&kiocb, file);
> + kiocb.ki_pos = *pos;
> + iov_iter_kvec(&iter, WRITE, &iov, 1, iov.iov_len);
> + ret = file->f_op->write_iter(&kiocb, &iter);
next-20201001 crashes on boot for me because there is a bad interaction between
this commit in vfs/for-next:
commit 4d03e3cc59828c82ee89ea6e27a2f3cdf95aaadf
Author: Christoph Hellwig <hch@lst.de>
Date: Thu Sep 3 16:22:33 2020 +0200
fs: don't allow kernel reads and writes without iter ops
... and Linus's mainline commit:
commit 90fb702791bf99b959006972e8ee7bb4609f441b
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue Sep 29 17:18:34 2020 -0700
autofs: use __kernel_write() for the autofs pipe writing
Linus's commit made autofs start passing pos=NULL to __kernel_write().
But, Christoph's commit made __kernel_write() no longer accept a NULL pos.
The following fixes it:
diff --git a/fs/autofs/waitq.c b/fs/autofs/waitq.c
index 5ced859dac53..b04c528b19d3 100644
--- a/fs/autofs/waitq.c
+++ b/fs/autofs/waitq.c
@@ -53,7 +53,7 @@ static int autofs_write(struct autofs_sb_info *sbi,
mutex_lock(&sbi->pipe_mutex);
while (bytes) {
- wr = __kernel_write(file, data, bytes, NULL);
+ wr = __kernel_write(file, data, bytes, &file->f_pos);
if (wr <= 0)
break;
data += wr;
I'm not sure what was intended, though.
Full stack trace below.
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 12 PID: 383 Comm: systemd-binfmt Tainted: G T 5.9.0-rc7-next-20201001 #2
Hardware name: Gigabyte Technology Co., Ltd. X399 AORUS Gaming 7/X399 AORUS Gaming 7, BIOS F2 08/31/2017
RIP: 0010:init_sync_kiocb include/linux/fs.h:2050 [inline]
RIP: 0010:__kernel_write+0x16c/0x2b0 fs/read_write.c:546
Code: 24 4a b9 01 00 00 00 0f 45 c7 be 01 00 00 00 48 8d 7c 24 10 48 c7 44 24 40 00 00 00 00 48 c7 44 24 58 00 00 00 00 89 44 24 4c <48> 8b 03 48 c7 44 24 60 00 00 00 00 48 89 44 24 50 4c 89 64 24 38
RSP: 0018:ffffa2fc0102f8b0 EFLAGS: 00010246
RAX: 0000000000020000 RBX: 0000000000000000 RCX: 0000000000000001
RDX: ffffa2fc0102f8b0 RSI: 0000000000000001 RDI: ffffa2fc0102f8c0
RBP: ffff8ad2927e2940 R08: 0000000000000130 R09: ffff8ad29a201800
R10: 000000000000000f R11: ffff8ad292547510 R12: ffff8ad2927e2940
R13: ffffa2fc0102f8e8 R14: ffff8ad29a951768 R15: 0000000000000130
FS: 00007f11023b9000(0000) GS:ffff8ad29ed00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000857b62000 CR4: 00000000003506e0
Call Trace:
autofs_write fs/autofs/waitq.c:56 [inline]
autofs_notify_daemon.constprop.0+0x115/0x260 fs/autofs/waitq.c:163
autofs_wait+0x5b1/0x750 fs/autofs/waitq.c:465
autofs_mount_wait+0x2d/0x60 fs/autofs/root.c:250
autofs_d_automount+0xc4/0x1a0 fs/autofs/root.c:379
follow_automount fs/namei.c:1198 [inline]
__traverse_mounts+0x8d/0x230 fs/namei.c:1243
traverse_mounts fs/namei.c:1272 [inline]
handle_mounts fs/namei.c:1381 [inline]
step_into+0x44e/0x730 fs/namei.c:1691
walk_component+0x7e/0x1b0 fs/namei.c:1867
link_path_walk+0x270/0x3b0 fs/namei.c:2184
path_openat+0x90/0xe40 fs/namei.c:3365
do_filp_open+0x98/0x140 fs/namei.c:3396
do_sys_openat2+0xac/0x170 fs/open.c:1168
do_sys_open fs/open.c:1184 [inline]
__do_sys_openat fs/open.c:1200 [inline]
__se_sys_openat fs/open.c:1195 [inline]
__x64_sys_openat+0x51/0x90 fs/open.c:1195
do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f11031d3c1b
Code: 25 00 00 41 00 3d 00 00 41 00 74 4b 64 8b 04 25 18 00 00 00 85 c0 75 67 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 91 00 00 00 48 8b 4c 24 28 64 48 2b 0c 25
RSP: 002b:00007ffda6c0a1c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 0000000000000020 RCX: 00007f11031d3c1b
RDX: 0000000000080101 RSI: 000055f65e114278 RDI: 00000000ffffff9c
random: lvm: uninitialized urandom read (4 bytes read)
RBP: 000055f65e114278 R08: 00000000ffffffff R09: 000055f65ef055d8
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000080101
R13: 000055f65e11434a R14: 0000000000000000 R15: 0000000000000000
CR2: 0000000000000000
---[ end trace 166ad5429f22801b ]---
^ permalink raw reply related
* Re: [PATCH 05/14] fs: don't allow kernel reads and writes without iter ops
From: Al Viro @ 2020-10-01 22:40 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-arch, linuxppc-dev, Kees Cook, x86, linux-kernel,
Alexey Dobriyan, Luis Chamberlain, linux-fsdevel, Linus Torvalds,
Christoph Hellwig
In-Reply-To: <20201001223852.GA855@sol.localdomain>
On Thu, Oct 01, 2020 at 03:38:52PM -0700, Eric Biggers wrote:
> mutex_lock(&sbi->pipe_mutex);
> while (bytes) {
> - wr = __kernel_write(file, data, bytes, NULL);
> + wr = __kernel_write(file, data, bytes, &file->f_pos);
Better
loff_t dummy = 0;
...
wr = __kernel_write(file, data, bytes, &dummy);
^ permalink raw reply
* Re: [PATCH -next] ASoC: fsl: imx-mc13783: use devm_snd_soc_register_card()
From: Mark Brown @ 2020-10-01 22:46 UTC (permalink / raw)
To: NXP Linux Team, Shawn Guo, Liam Girdwood, Timur Tabi,
Nicolin Chen, Qinglang Miao, Fabio Estevam, Shengjiu Wang,
Sascha Hauer, Xiubo Li, Pengutronix Kernel Team, Jaroslav Kysela,
Takashi Iwai
Cc: alsa-devel, linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <20200929112930.46848-1-miaoqinglang@huawei.com>
On Tue, 29 Sep 2020 19:29:30 +0800, Qinglang Miao wrote:
> Using devm_snd_soc_register_card() can make the code
> shorter and cleaner.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl: imx-mc13783: use devm_snd_soc_register_card()
commit: bc772a46125f344ffabd7596c5b6b8c6ef703ea0
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_spdif: Fix unnecessary check in fsl_spdif_probe()
From: Mark Brown @ 2020-10-01 22:46 UTC (permalink / raw)
To: timur, lgirdwood, Tang Bin, perex, tiwai
Cc: alsa-devel, linuxppc-dev, Zhang Shengju, linux-kernel
In-Reply-To: <20200826150918.16116-1-tangbin@cmss.chinamobile.com>
On Wed, 26 Aug 2020 23:09:18 +0800, Tang Bin wrote:
> The function fsl_spdif_probe() is only called with an openfirmware
> platform device. Therefore there is no need to check that the passed
> in device is NULL.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl_spdif: Fix unnecessary check in fsl_spdif_probe()
commit: 601fd3a7d849cf8a5dbd3628b3c29af9e5377961
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v3 devicetree 0/2] Add Seville Ethernet switch to T1040RDB
From: Vladimir Oltean @ 2020-10-02 0:50 UTC (permalink / raw)
To: David Miller
Cc: devicetree@vger.kernel.org, andrew@lunn.ch, Madalin Bucur (OSS),
Radu-andrei Bulie, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, fido_max@inbox.ru,
robh+dt@kernel.org, paulus@samba.org, shawnguo@kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20201001.131005.812058315852168053.davem@davemloft.net>
On Thu, Oct 01, 2020 at 01:10:05PM -0700, David Miller wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> Date: Thu, 1 Oct 2020 16:20:11 +0300
>
> > Seville is a DSA switch that is embedded inside the T1040 SoC, and
> > supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot.
> >
> > This series adds this switch to the SoC's dtsi files and to the T1040RDB
> > board file.
>
> I am assuming the devicetree folks will pick this series up.
>
> Thanks.
>
I can also resend via net-next if that's easier (the last commit on
arch/powerpc/boot/dts/fsl/t104*, as per today's linux-next, has been in
2018, so there is no conflict).
I need to resend anyway, due to an epic failure where I got the port
numbering wrong...
^ permalink raw reply
* [PATCH v4 net-next 0/2] Add Seville Ethernet switch to T1040RDB
From: Vladimir Oltean @ 2020-10-02 13:41 UTC (permalink / raw)
To: netdev, davem, kuba
Cc: devicetree, andrew, madalin.bucur, radu-andrei.bulie,
linuxppc-dev, linux-kernel, fido_max, robh+dt, paulus, shawnguo
Seville is a DSA switch that is embedded inside the T1040 SoC, and
supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot.
This series adds this switch to the SoC's dtsi files and to the T1040RDB
board file.
I would like to send this series through net-next. There is no conflict
with other patches submitted to T1040 device tree. Maybe this could at
least get an ACK from devicetree maintainers.
Vladimir Oltean (2):
powerpc: dts: t1040: add bindings for Seville Ethernet switch
powerpc: dts: t1040rdb: add ports for Seville Ethernet switch
arch/powerpc/boot/dts/fsl/t1040rdb.dts | 107 ++++++++++++++++++++
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 78 ++++++++++++++
2 files changed, 185 insertions(+)
--
2.25.1
^ permalink raw reply
* [PATCH v4 net-next 1/2] powerpc: dts: t1040: add bindings for Seville Ethernet switch
From: Vladimir Oltean @ 2020-10-02 13:41 UTC (permalink / raw)
To: netdev, davem, kuba
Cc: devicetree, andrew, madalin.bucur, radu-andrei.bulie,
linuxppc-dev, linux-kernel, fido_max, robh+dt, paulus, shawnguo
In-Reply-To: <20201002134106.3485970-1-vladimir.oltean@nxp.com>
Add the description of the embedded L2 switch inside the SoC dtsi file
for NXP T1040.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Maxim Kochetkov <fido_max@inbox.ru>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
Changes in v4:
Retargeting to net-next.
Changes in v3:
Added definition for frame extraction interrupt, even if the driver
doesn't use it at the moment.
Changes in v2:
Make switch node disabled by default.
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 78 +++++++++++++++++++++
1 file changed, 78 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
index 315d0557eefc..f58eb820eb5e 100644
--- a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
@@ -628,6 +628,84 @@ mdio@fd000 {
status = "disabled";
};
};
+
+ seville_switch: ethernet-switch@800000 {
+ compatible = "mscc,vsc9953-switch";
+ reg = <0x800000 0x290000>;
+ interrupts = <26 2 0 0>;
+ interrupt-names = "xtr";
+ little-endian;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ seville_port0: port@0 {
+ reg = <0>;
+ status = "disabled";
+ };
+
+ seville_port1: port@1 {
+ reg = <1>;
+ status = "disabled";
+ };
+
+ seville_port2: port@2 {
+ reg = <2>;
+ status = "disabled";
+ };
+
+ seville_port3: port@3 {
+ reg = <3>;
+ status = "disabled";
+ };
+
+ seville_port4: port@4 {
+ reg = <4>;
+ status = "disabled";
+ };
+
+ seville_port5: port@5 {
+ reg = <5>;
+ status = "disabled";
+ };
+
+ seville_port6: port@6 {
+ reg = <6>;
+ status = "disabled";
+ };
+
+ seville_port7: port@7 {
+ reg = <7>;
+ status = "disabled";
+ };
+
+ seville_port8: port@8 {
+ reg = <8>;
+ phy-mode = "internal";
+ status = "disabled";
+
+ fixed-link {
+ speed = <2500>;
+ full-duplex;
+ };
+ };
+
+ seville_port9: port@9 {
+ reg = <9>;
+ phy-mode = "internal";
+ status = "disabled";
+
+ fixed-link {
+ speed = <2500>;
+ full-duplex;
+ };
+ };
+ };
+ };
};
&qe {
--
2.25.1
^ permalink raw reply related
* [PATCH v4 net-next 2/2] powerpc: dts: t1040rdb: add ports for Seville Ethernet switch
From: Vladimir Oltean @ 2020-10-02 13:41 UTC (permalink / raw)
To: netdev, davem, kuba
Cc: devicetree, andrew, madalin.bucur, radu-andrei.bulie,
linuxppc-dev, linux-kernel, fido_max, robh+dt, paulus, shawnguo
In-Reply-To: <20201002134106.3485970-1-vladimir.oltean@nxp.com>
Define the network interface names for the switch ports and hook them up
to the 2 QSGMII PHYs that are onboard.
A conscious decision was taken to go along with the numbers that are
written on the front panel of the board and not with the hardware
numbers of the switch chip ports.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Maxim Kochetkov <fido_max@inbox.ru>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
Changes in v4:
- Retargeted to net-next.
- Fixed the port labels (ETH5 was ETH4, ETH7 was ETH6, ETH9 was ETH8,
ETH11 was ETH10).
Changes in v3:
Renamed interfaces from swpN to ETHN, as per Andrew Lunn's suggestion.
Changes in v2:
Use the existing way of accessing the mdio bus and not labels.
arch/powerpc/boot/dts/fsl/t1040rdb.dts | 107 +++++++++++++++++++++++++
1 file changed, 107 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1040rdb.dts b/arch/powerpc/boot/dts/fsl/t1040rdb.dts
index 65ff34c49025..af0c8a6f5613 100644
--- a/arch/powerpc/boot/dts/fsl/t1040rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t1040rdb.dts
@@ -64,6 +64,40 @@ mdio@fc000 {
phy_sgmii_2: ethernet-phy@3 {
reg = <0x03>;
};
+
+ /* VSC8514 QSGMII PHY */
+ phy_qsgmii_0: ethernet-phy@4 {
+ reg = <0x4>;
+ };
+
+ phy_qsgmii_1: ethernet-phy@5 {
+ reg = <0x5>;
+ };
+
+ phy_qsgmii_2: ethernet-phy@6 {
+ reg = <0x6>;
+ };
+
+ phy_qsgmii_3: ethernet-phy@7 {
+ reg = <0x7>;
+ };
+
+ /* VSC8514 QSGMII PHY */
+ phy_qsgmii_4: ethernet-phy@8 {
+ reg = <0x8>;
+ };
+
+ phy_qsgmii_5: ethernet-phy@9 {
+ reg = <0x9>;
+ };
+
+ phy_qsgmii_6: ethernet-phy@a {
+ reg = <0xa>;
+ };
+
+ phy_qsgmii_7: ethernet-phy@b {
+ reg = <0xb>;
+ };
};
};
};
@@ -76,3 +110,76 @@ cpld@3,0 {
};
#include "t1040si-post.dtsi"
+
+&seville_switch {
+ status = "okay";
+};
+
+&seville_port0 {
+ managed = "in-band-status";
+ phy-handle = <&phy_qsgmii_0>;
+ phy-mode = "qsgmii";
+ label = "ETH5";
+ status = "okay";
+};
+
+&seville_port1 {
+ managed = "in-band-status";
+ phy-handle = <&phy_qsgmii_1>;
+ phy-mode = "qsgmii";
+ label = "ETH4";
+ status = "okay";
+};
+
+&seville_port2 {
+ managed = "in-band-status";
+ phy-handle = <&phy_qsgmii_2>;
+ phy-mode = "qsgmii";
+ label = "ETH7";
+ status = "okay";
+};
+
+&seville_port3 {
+ managed = "in-band-status";
+ phy-handle = <&phy_qsgmii_3>;
+ phy-mode = "qsgmii";
+ label = "ETH6";
+ status = "okay";
+};
+
+&seville_port4 {
+ managed = "in-band-status";
+ phy-handle = <&phy_qsgmii_4>;
+ phy-mode = "qsgmii";
+ label = "ETH9";
+ status = "okay";
+};
+
+&seville_port5 {
+ managed = "in-band-status";
+ phy-handle = <&phy_qsgmii_5>;
+ phy-mode = "qsgmii";
+ label = "ETH8";
+ status = "okay";
+};
+
+&seville_port6 {
+ managed = "in-band-status";
+ phy-handle = <&phy_qsgmii_6>;
+ phy-mode = "qsgmii";
+ label = "ETH11";
+ status = "okay";
+};
+
+&seville_port7 {
+ managed = "in-band-status";
+ phy-handle = <&phy_qsgmii_7>;
+ phy-mode = "qsgmii";
+ label = "ETH10";
+ status = "okay";
+};
+
+&seville_port8 {
+ ethernet = <&enet0>;
+ status = "okay";
+};
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 05/14] fs: don't allow kernel reads and writes without iter ops
From: Linus Torvalds @ 2020-10-02 16:27 UTC (permalink / raw)
To: Al Viro
Cc: linux-arch, Kees Cook, the arch/x86 maintainers,
Linux Kernel Mailing List, Alexey Dobriyan, Eric Biggers,
Luis Chamberlain, linux-fsdevel, linuxppc-dev, Christoph Hellwig
In-Reply-To: <20201001224051.GI3421308@ZenIV.linux.org.uk>
On Thu, Oct 1, 2020 at 3:41 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Better
> loff_t dummy = 0;
> ...
> wr = __kernel_write(file, data, bytes, &dummy);
No, just fix __kernel_write() to work correctly.
The fact is, NULL _is_ the right pointer for ppos these days.
That commit by Christoph is buggy: it replaces new_sync_write() with a
buggy open-coded version.
Notice how new_sync_write does
kiocb.ki_pos = (ppos ? *ppos : 0);
,,,
if (ret > 0 && ppos)
*ppos = kiocb.ki_pos;
but the open-coded version doesn't.
So just fix that in linux-next. The *last* thing we want is to have
different semantics for the "same" kernel functions.
Linus
^ permalink raw reply
* [PATCH 1/5] powerpc/hv-gpci: Fix starting index value
From: Kajol Jain @ 2020-10-03 7:49 UTC (permalink / raw)
To: mpe, linuxppc-dev; +Cc: kjain, suka, maddy
Commit 9e9f60108423f ("powerpc/perf/{hv-gpci, hv-common}: generate
requests with counters annotated") adds a framework for defining
gpci counters.
In this patch, they adds starting_index value as '0xffffffffffffffff'.
which is wrong as starting_index is of size 32 bits.
Because of this, incase we try to run hv-gpci event we get error.
In power9 machine:
command#: perf stat -e hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
-C 0 -I 1000
event syntax error: '..bie_count_and_time_tlbie_instructions_issued/'
\___ value too big for format, maximum is 4294967295
This patch fix this issue and changes starting_index value to '0xffffffff'
After this patch:
command#: perf stat -e hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ -C 0 -I 1000
1.000085786 1,024 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
2.000287818 1,024 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
^C 2.439113909 17,408 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/
Fixes: 9e9f60108423f ("powerpc/perf/{hv-gpci, hv-common}: generate
requests with counters annotated")
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
arch/powerpc/perf/hv-gpci-requests.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/perf/hv-gpci-requests.h b/arch/powerpc/perf/hv-gpci-requests.h
index e608f9db12dd..8965b4463d43 100644
--- a/arch/powerpc/perf/hv-gpci-requests.h
+++ b/arch/powerpc/perf/hv-gpci-requests.h
@@ -95,7 +95,7 @@ REQUEST(__field(0, 8, partition_id)
#define REQUEST_NAME system_performance_capabilities
#define REQUEST_NUM 0x40
-#define REQUEST_IDX_KIND "starting_index=0xffffffffffffffff"
+#define REQUEST_IDX_KIND "starting_index=0xffffffff"
#include I(REQUEST_BEGIN)
REQUEST(__field(0, 1, perf_collect_privileged)
__field(0x1, 1, capability_mask)
@@ -223,7 +223,7 @@ REQUEST(__field(0, 2, partition_id)
#define REQUEST_NAME system_hypervisor_times
#define REQUEST_NUM 0xF0
-#define REQUEST_IDX_KIND "starting_index=0xffffffffffffffff"
+#define REQUEST_IDX_KIND "starting_index=0xffffffff"
#include I(REQUEST_BEGIN)
REQUEST(__count(0, 8, time_spent_to_dispatch_virtual_processors)
__count(0x8, 8, time_spent_processing_virtual_processor_timers)
@@ -234,7 +234,7 @@ REQUEST(__count(0, 8, time_spent_to_dispatch_virtual_processors)
#define REQUEST_NAME system_tlbie_count_and_time
#define REQUEST_NUM 0xF4
-#define REQUEST_IDX_KIND "starting_index=0xffffffffffffffff"
+#define REQUEST_IDX_KIND "starting_index=0xffffffff"
#include I(REQUEST_BEGIN)
REQUEST(__count(0, 8, tlbie_instructions_issued)
/*
--
2.26.2
^ permalink raw reply related
* [PATCH 2/5] Documentation/ABI: Add ABI documentation for hv-24x7 format
From: Kajol Jain @ 2020-10-03 7:49 UTC (permalink / raw)
To: mpe, linuxppc-dev; +Cc: kjain, suka, maddy
In-Reply-To: <20201003074943.338618-1-kjain@linux.ibm.com>
This patch adds ABI documentation for hv-24x7 format.
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
.../sysfs-bus-event_source-devices-hv_24x7 | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
index e82fc37be802..6bec9a13a493 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
@@ -1,3 +1,28 @@
+What: /sys/bus/event_source/devices/hv_24x7/format
+Date: September 2020
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: Read-only. Attribute group to describe the magic bits
+ that go into perf_event_attr.config for a particular pmu.
+ (See ABI/testing/sysfs-bus-event_source-devices-format).
+
+ Each attribute under this group defines a bit range of the
+ perf_event_attr.config. All supported attributes are listed
+ below.
+
+ chip = "config:16-31"
+ core = "config:16-31"
+ domain = "config:0-3"
+ lpar = "config:0-15"
+ offset = "config:32-63"
+ vcpu = "config:16-31"
+
+ For example,
+
+ PM_PB_CYC = "domain=1,offset=0x80,chip=?,lpar=0x0"
+
+ In this event, '?' after chip specifies that
+ this value will be provided by user while running this event.
+
What: /sys/bus/event_source/devices/hv_24x7/interface/catalog
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
--
2.26.2
^ permalink raw reply related
* [PATCH 3/5] Documentation/ABI: Add ABI documentation for hv-gpci format
From: Kajol Jain @ 2020-10-03 7:49 UTC (permalink / raw)
To: mpe, linuxppc-dev; +Cc: kjain, suka, maddy
In-Reply-To: <20201003074943.338618-1-kjain@linux.ibm.com>
This patch adds ABI documentation for hv-gpci event format.
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
.../sysfs-bus-event_source-devices-hv_gpci | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
index 3ca4e554d2f9..b68a28a712d5 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
@@ -1,3 +1,34 @@
+What: /sys/bus/event_source/devices/hv_gpci/format
+Date: September 2020
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: Read-only. Attribute group to describe the magic bits
+ that go into perf_event_attr.config for a particular pmu.
+ (See ABI/testing/sysfs-bus-event_source-devices-format).
+
+ Each attribute under this group defines a bit range of the
+ perf_event_attr.config. All supported attributes are listed
+ below.
+
+ counter_info_version = "config:16-23"
+ length = "config:24-31"
+ partition_id = "config:32-63"
+ request = "config:0-31"
+ sibling_part_id = "config:32-63"
+ hw_chip_id = "config:32-63"
+ offset = "config:32-63"
+ phys_processor_idx = "config:32-63"
+ secondary_index = "config:0-15"
+ starting_index = "config:32-63"
+
+ For example,
+
+ processor_core_utilization_instructions_completed = "request=0x94,
+ phys_processor_idx=?,counter_info_version=0x8,
+ length=8,offset=0x18"
+
+ In this event, '?' after phys_processor_idx specifies this value
+ this value will be provided by user while running this event.
+
What: /sys/bus/event_source/devices/hv_gpci/interface/collect_privileged
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
--
2.26.2
^ permalink raw reply related
* [PATCH 4/5] powerpc/perf/hv-gpci: Add cpu hotplug support
From: Kajol Jain @ 2020-10-03 7:49 UTC (permalink / raw)
To: mpe, linuxppc-dev; +Cc: kjain, suka, maddy
In-Reply-To: <20201003074943.338618-1-kjain@linux.ibm.com>
Patch here adds cpu hotplug functions to hv_gpci pmu.
A new cpuhp_state "CPUHP_AP_PERF_POWERPC_HV_GPCI_ONLINE" enum
is added.
The online callback function updates the cpumask only if its
empty. As the primary intention of adding hotplug support
is to designate a CPU to make HCALL to collect the
counter data.
The offline function test and clear corresponding cpu in a cpumask
and update cpumask to any other active cpu.
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
arch/powerpc/perf/hv-gpci.c | 46 +++++++++++++++++++++++++++++++++++++
include/linux/cpuhotplug.h | 1 +
2 files changed, 47 insertions(+)
diff --git a/arch/powerpc/perf/hv-gpci.c b/arch/powerpc/perf/hv-gpci.c
index 6884d16ec19b..b9dc407c3159 100644
--- a/arch/powerpc/perf/hv-gpci.c
+++ b/arch/powerpc/perf/hv-gpci.c
@@ -48,6 +48,8 @@ EVENT_DEFINE_RANGE_FORMAT(length, config1, 24, 31);
/* u32, byte offset */
EVENT_DEFINE_RANGE_FORMAT(offset, config1, 32, 63);
+static cpumask_t hv_gpci_cpumask;
+
static struct attribute *format_attrs[] = {
&format_attr_request.attr,
&format_attr_starting_index.attr,
@@ -275,6 +277,45 @@ static struct pmu h_gpci_pmu = {
.capabilities = PERF_PMU_CAP_NO_EXCLUDE,
};
+static int ppc_hv_gpci_cpu_online(unsigned int cpu)
+{
+ if (cpumask_empty(&hv_gpci_cpumask))
+ cpumask_set_cpu(cpu, &hv_gpci_cpumask);
+
+ return 0;
+}
+
+static int ppc_hv_gpci_cpu_offline(unsigned int cpu)
+{
+ int target;
+
+ /* Check if exiting cpu is used for collecting gpci events */
+ if (!cpumask_test_and_clear_cpu(cpu, &hv_gpci_cpumask))
+ return 0;
+
+ /* Find a new cpu to collect gpci events */
+ target = cpumask_last(cpu_active_mask);
+
+ if (target < 0 || target >= nr_cpu_ids) {
+ pr_err("hv_gpci: CPU hotplug init failed\n");
+ return -1;
+ }
+
+ /* Migrate gpci events to the new target */
+ cpumask_set_cpu(target, &hv_gpci_cpumask);
+ perf_pmu_migrate_context(&h_gpci_pmu, cpu, target);
+
+ return 0;
+}
+
+static int hv_gpci_cpu_hotplug_init(void)
+{
+ return cpuhp_setup_state(CPUHP_AP_PERF_POWERPC_HV_GPCI_ONLINE,
+ "perf/powerpc/hv_gcpi:online",
+ ppc_hv_gpci_cpu_online,
+ ppc_hv_gpci_cpu_offline);
+}
+
static int hv_gpci_init(void)
{
int r;
@@ -295,6 +336,11 @@ static int hv_gpci_init(void)
return -ENODEV;
}
+ /* init cpuhotplug */
+ r = hv_gpci_cpu_hotplug_init();
+ if (r)
+ return r;
+
/* sampling not supported */
h_gpci_pmu.capabilities |= PERF_PMU_CAP_NO_INTERRUPT;
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index bf9181cef444..b79d3d4b06e8 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -182,6 +182,7 @@ enum cpuhp_state {
CPUHP_AP_PERF_POWERPC_THREAD_IMC_ONLINE,
CPUHP_AP_PERF_POWERPC_TRACE_IMC_ONLINE,
CPUHP_AP_PERF_POWERPC_HV_24x7_ONLINE,
+ CPUHP_AP_PERF_POWERPC_HV_GPCI_ONLINE,
CPUHP_AP_WATCHDOG_ONLINE,
CPUHP_AP_WORKQUEUE_ONLINE,
CPUHP_AP_RCUTREE_ONLINE,
--
2.26.2
^ permalink raw reply related
* [PATCH 5/5] powerpc/hv-gpci: Add sysfs files inside hv-gpci device to show cpumask
From: Kajol Jain @ 2020-10-03 7:49 UTC (permalink / raw)
To: mpe, linuxppc-dev; +Cc: kjain, suka, maddy
In-Reply-To: <20201003074943.338618-1-kjain@linux.ibm.com>
Patch here adds a cpumask attr to hv_gpci pmu along with ABI documentation.
Primary use to expose the cpumask is for the perf tool which has the
capability to parse the driver sysfs folder and understand the
cpumask file. Having cpumask file will reduce the number of perf command
line parameters (will avoid "-C" option in the perf tool
command line). It can also notify the user which is
the current cpu used to retrieve the counter data.
command:# cat /sys/devices/hv_gpci/cpumask
0
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
.../sysfs-bus-event_source-devices-hv_gpci | 7 +++++++
arch/powerpc/perf/hv-gpci.c | 18 ++++++++++++++++++
2 files changed, 25 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
index b68a28a712d5..7162c5d675fe 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
@@ -72,3 +72,10 @@ Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
A number indicating the latest version of the gpci interface
that the kernel is aware of.
+
+What: /sys/devices/hv_gpci/cpumask
+Date: October 2020
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: read only
+ This sysfs file exposes the cpumask which is designated to make
+ HCALLs to retrieve hv-gpci pmu event counter data.
diff --git a/arch/powerpc/perf/hv-gpci.c b/arch/powerpc/perf/hv-gpci.c
index b9dc407c3159..159dca8d5d65 100644
--- a/arch/powerpc/perf/hv-gpci.c
+++ b/arch/powerpc/perf/hv-gpci.c
@@ -96,7 +96,15 @@ static ssize_t kernel_version_show(struct device *dev,
return sprintf(page, "0x%x\n", COUNTER_INFO_VERSION_CURRENT);
}
+static ssize_t cpumask_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return cpumap_print_to_pagebuf(true, buf, &hv_gpci_cpumask);
+}
+
static DEVICE_ATTR_RO(kernel_version);
+static DEVICE_ATTR_RO(cpumask);
+
HV_CAPS_ATTR(version, "0x%x\n");
HV_CAPS_ATTR(ga, "%d\n");
HV_CAPS_ATTR(expanded, "%d\n");
@@ -113,6 +121,15 @@ static struct attribute *interface_attrs[] = {
NULL,
};
+static struct attribute *cpumask_attrs[] = {
+ &dev_attr_cpumask.attr,
+ NULL,
+};
+
+static struct attribute_group cpumask_attr_group = {
+ .attrs = cpumask_attrs,
+};
+
static struct attribute_group interface_group = {
.name = "interface",
.attrs = interface_attrs,
@@ -122,6 +139,7 @@ static const struct attribute_group *attr_groups[] = {
&format_group,
&event_group,
&interface_group,
+ &cpumask_attr_group,
NULL,
};
--
2.26.2
^ permalink raw reply related
* Re: [PATCH] crypto: talitos - Fix sparse warnings
From: Christophe Leroy @ 2020-10-03 17:15 UTC (permalink / raw)
To: Herbert Xu
Cc: linuxppc-dev, Kim Phillips, Linux Crypto Mailing List,
Horia Geantă
In-Reply-To: <20201002124341.GA1587@gondor.apana.org.au>
Quoting Herbert Xu <herbert@gondor.apana.org.au>:
> On Fri, Oct 02, 2020 at 10:42:23PM +1000, Herbert Xu wrote:
>>
>> I don't think that's a valid optimisation unless it's backed up
>> with real numbers.
>
> Also it only matters on little-endian as they're no-ops on big-endian.
> If I'm right then this driver never even worked on little-endian.
>
The following changes fix the sparse warnings with less churn:
---
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 7c547352a862..992d58a4dbf1 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -460,7 +460,7 @@ DEF_TALITOS2_DONE(ch1_3, TALITOS2_ISR_CH_1_3_DONE)
/*
* locate current (offending) descriptor
*/
-static u32 current_desc_hdr(struct device *dev, int ch)
+static __be32 current_desc_hdr(struct device *dev, int ch)
{
struct talitos_private *priv = dev_get_drvdata(dev);
int tail, iter;
@@ -478,7 +478,7 @@ static u32 current_desc_hdr(struct device *dev, int ch)
iter = tail;
while (priv->chan[ch].fifo[iter].dma_desc != cur_desc &&
- priv->chan[ch].fifo[iter].desc->next_desc != cur_desc) {
+ priv->chan[ch].fifo[iter].desc->next_desc != cpu_to_be32(cur_desc)) {
iter = (iter + 1) & (priv->fifo_len - 1);
if (iter == tail) {
dev_err(dev, "couldn't locate current descriptor\n");
@@ -486,7 +486,7 @@ static u32 current_desc_hdr(struct device *dev, int ch)
}
}
- if (priv->chan[ch].fifo[iter].desc->next_desc == cur_desc) {
+ if (priv->chan[ch].fifo[iter].desc->next_desc == cpu_to_be32(cur_desc)) {
struct talitos_edesc *edesc;
edesc = container_of(priv->chan[ch].fifo[iter].desc,
@@ -501,13 +501,13 @@ static u32 current_desc_hdr(struct device *dev, int ch)
/*
* user diagnostics; report root cause of error based on execution
unit status
*/
-static void report_eu_error(struct device *dev, int ch, u32 desc_hdr)
+static void report_eu_error(struct device *dev, int ch, __be32 desc_hdr)
{
struct talitos_private *priv = dev_get_drvdata(dev);
int i;
if (!desc_hdr)
- desc_hdr = in_be32(priv->chan[ch].reg + TALITOS_DESCBUF);
+ desc_hdr = cpu_to_be32(in_be32(priv->chan[ch].reg + TALITOS_DESCBUF));
switch (desc_hdr & DESC_HDR_SEL0_MASK) {
case DESC_HDR_SEL0_AFEU:
---
Christophe
^ permalink raw reply related
* Re: [PATCH v4 net-next 0/2] Add Seville Ethernet switch to T1040RDB
From: David Miller @ 2020-10-04 0:03 UTC (permalink / raw)
To: vladimir.oltean
Cc: devicetree, andrew, madalin.bucur, netdev, radu-andrei.bulie,
linuxppc-dev, linux-kernel, fido_max, robh+dt, paulus, kuba,
shawnguo
In-Reply-To: <20201002134106.3485970-1-vladimir.oltean@nxp.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri, 2 Oct 2020 16:41:04 +0300
> Seville is a DSA switch that is embedded inside the T1040 SoC, and
> supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot.
>
> This series adds this switch to the SoC's dtsi files and to the T1040RDB
> board file.
>
> I would like to send this series through net-next. There is no conflict
> with other patches submitted to T1040 device tree. Maybe this could at
> least get an ACK from devicetree maintainers.
Series applied, thank you.
^ permalink raw reply
* [PATCH 0/4] treewide: Make definitions of struct kernel_param_ops const
From: Joe Perches @ 2020-10-04 0:18 UTC (permalink / raw)
To: Sean Christopherson, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson,
Joerg Roedel, Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan,
Joel Fernandes, kvm-ppc, kvm, rcu, linux-mm
Cc: linuxppc-dev, linux-kernel
Using const is good as it reduces data size.
Joe Perches (4):
KVM: PPC: Book3S HV: Make struct kernel_param_ops definition const
kvm x86/mmu: Make struct kernel_param_ops definitions const
rcu/tree: Make struct kernel_param_ops definitions const
mm/zswap: Make struct kernel_param_ops definitions const
arch/powerpc/kvm/book3s_hv.c | 2 +-
arch/x86/kvm/mmu/mmu.c | 4 ++--
kernel/rcu/tree.c | 4 ++--
mm/zswap.c | 6 +++---
4 files changed, 8 insertions(+), 8 deletions(-)
--
2.26.0
^ permalink raw reply
* [PATCH 1/4] KVM: PPC: Book3S HV: Make struct kernel_param_ops definition const
From: Joe Perches @ 2020-10-04 0:18 UTC (permalink / raw)
To: Paul Mackerras
Cc: kvm-ppc, Athira Rajeev, Tianjia Zhang, Ram Pai, linux-kernel,
Sean Christopherson, Bharata B Rao, Davidlohr Bueso,
Nicholas Piggin, Paolo Bonzini, Laurent Dufour, linuxppc-dev
In-Reply-To: <cover.1601770305.git.joe@perches.com>
This should be const, so make it so.
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/powerpc/kvm/book3s_hv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 4ba06a2a306c..2b215852cdc9 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -111,7 +111,7 @@ module_param(one_vm_per_core, bool, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(one_vm_per_core, "Only run vCPUs from the same VM on a core (requires indep_threads_mode=N)");
#ifdef CONFIG_KVM_XICS
-static struct kernel_param_ops module_param_ops = {
+static const struct kernel_param_ops module_param_ops = {
.set = param_set_int,
.get = param_get_int,
};
--
2.26.0
^ permalink raw reply related
* Where is the declaration of buffer used in kernel_param_ops .get functions?
From: Joe Perches @ 2020-10-04 1:19 UTC (permalink / raw)
To: Greg KH; +Cc: kvm, linux-kernel, kvm-ppc, rcu, linux-mm, linuxppc-dev
In-Reply-To: <cover.1601770305.git.joe@perches.com>
These patches came up because I was looking for
the location of the declaration of the buffer used
in kernel/params.c struct kernel_param_ops .get
functions.
I didn't find it.
I want to see if it's appropriate to convert the
sprintf family of functions used in these .get
functions to sysfs_emit.
Patches submitted here:
https://lore.kernel.org/lkml/5d606519698ce4c8f1203a2b35797d8254c6050a.1600285923.git.joe@perches.com/T/
Anyone know if it's appropriate to change the
sprintf-like uses in these functions to sysfs_emit
and/or sysfs_emit_at?
^ permalink raw reply
* Re: Where is the declaration of buffer used in kernel_param_ops .get functions?
From: Matthew Wilcox @ 2020-10-04 1:36 UTC (permalink / raw)
To: Joe Perches
Cc: kvm, Greg KH, linux-kernel, kvm-ppc, rcu, linux-mm, linuxppc-dev
In-Reply-To: <250919192de237dadf36218ee6b4dabf1bd4cbde.camel@perches.com>
On Sat, Oct 03, 2020 at 06:19:18PM -0700, Joe Perches wrote:
> These patches came up because I was looking for
> the location of the declaration of the buffer used
> in kernel/params.c struct kernel_param_ops .get
> functions.
>
> I didn't find it.
>
> I want to see if it's appropriate to convert the
> sprintf family of functions used in these .get
> functions to sysfs_emit.
>
> Patches submitted here:
> https://lore.kernel.org/lkml/5d606519698ce4c8f1203a2b35797d8254c6050a.1600285923.git.joe@perches.com/T/
>
> Anyone know if it's appropriate to change the
> sprintf-like uses in these functions to sysfs_emit
> and/or sysfs_emit_at?
There's a lot of preprocessor magic to wade through.
I'm pretty sure this comes through include/linux/moduleparam.h
and kernel/module.c.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox