Re: [PATCH] cpufreq: remove redundant assignment to ret
On 13-08-19, 13:21, Colin King wrote:
> From: Colin Ian King
>
> Variable ret is initialized to a value that is never read and it is
> re-assigned later. The initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
> ---
> drivers/cpufreq/cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index c28ebf2810f1..26d82e0a2de5 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2140,7 +2140,7 @@ int cpufreq_driver_target(struct cpufreq_policy *policy,
> unsigned int target_freq,
> unsigned int relation)
> {
> - int ret = -EINVAL;
> + int ret;
>
> down_write(&policy->rwsem);
>
Acked-by: Viresh Kumar
--
viresh
Re: [PATCH 1/2] cpufreq: drivers: Enable frequency invariance in qcom-cpufreq-hw
On 09-08-19, 11:37, Quentin Perret wrote: > Actually, one nit, the $subject should probably be formatted as: > > cpufreq: qcom-hw: invoke frequency-invariance setter function > > for consistency with other patches in this area. Applied with these changes. Thanks. -- viresh
Re: [PATCH v2] iommu/amd: Override wrong IVRS IOAPIC on Raven Ridge systems
Hi Kai-Heng,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc5 next-20190816]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Kai-Heng-Feng/iommu-amd-Override-wrong-IVRS-IOAPIC-on-Raven-Ridge-systems/20190819-133843
config: x86_64-randconfig-f001-201933 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers//iommu/amd_iommu_quirks.c:87:13: error: redefinition of
>> 'amd_iommu_apply_ivrs_quirks'
void __init amd_iommu_apply_ivrs_quirks(void)
^~~
In file included from drivers//iommu/amd_iommu_quirks.c:11:0:
drivers//iommu/amd_iommu.h:11:13: note: previous definition of
'amd_iommu_apply_ivrs_quirks' was here
static void amd_iommu_apply_ivrs_quirks(void) { }
^~~
drivers//iommu/amd_iommu.h:11:13: warning: 'amd_iommu_apply_ivrs_quirks'
defined but not used [-Wunused-function]
vim +/amd_iommu_apply_ivrs_quirks +87 drivers//iommu/amd_iommu_quirks.c
86
> 87 void __init amd_iommu_apply_ivrs_quirks(void)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v7 0/2] Add Macronix raw NAND controller driver
Hello, v7 patch including: 1. compatible rename to "mxic,multi-itfc-v009-nand-controller" 2. using interrupts instead of polling RY/#BS pin 3. removed sdr timing setup in mxic_nfc_hw_init(). 4. And other patches based on Boris comments. v6 patch including: 1. compatible rename to "mxicy,multi-itfc-v009-nand-morph" 2. remove xxx_clk to xxx in DTS and driver. 3. patch mxic_nfc_data_xfer() v5 patch including: 1. compatible rename to "macronix,nand-controller" 2. handle three clock in one 3. other minor patches v4 patch back to only raw NAND controller driver instead of MFD, raw NAND and SPI driver. This is based on MFD maintainer, Lee Jones comments: MFD is for registering child devices of chips which offer genuine cross-subsystem functionality. It is not designed for mode selecting, or as a place to shove shared code just because a better location doesn't appear to exist. v3 patch is to rename the title of SPI controller driver. "Patch Macronix SPI controller driver according to MX25F0A MFD driver" v2s patches is to support Macronix MX25F0A MFD driver for raw nand and spi controller which is separated form previous patchset: https://patchwork.kernel.org/patch/10874679/ thanks for your review. best regards, Mason Mason Yang (2): mtd: rawnand: Add Macronix raw NAND controller driver dt-bindings: mtd: Document Macronix raw NAND controller bindings .../devicetree/bindings/mtd/mxic-nand.txt | 36 ++ drivers/mtd/nand/raw/Kconfig | 6 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/mxic_nand.c | 584 + 4 files changed, 627 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/mxic-nand.txt create mode 100644 drivers/mtd/nand/raw/mxic_nand.c -- 1.9.1
[PATCH v7 2/2] dt-bindings: mtd: Document Macronix raw NAND controller bindings
Document the bindings used by the Macronix raw NAND controller.
Signed-off-by: Mason Yang
---
.../devicetree/bindings/mtd/mxic-nand.txt | 36 ++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/mxic-nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/mxic-nand.txt
b/Documentation/devicetree/bindings/mtd/mxic-nand.txt
new file mode 100644
index 000..46c5529
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/mxic-nand.txt
@@ -0,0 +1,36 @@
+Macronix Raw NAND Controller Device Tree Bindings
+-
+
+Required properties:
+- compatible: should be "mxic,multi-itfc-v009-nand-controller"
+- reg: should contain 1 entry for the registers
+- #address-cells: should be set to 1
+- #size-cells: should be set to 0
+- interrupts: interrupt line connected to this raw NAND controller
+- clock-names: should contain "ps", "send" and "send_dly"
+- clocks: should contain 3 phandles for the "ps", "send" and
+"send_dly" clocks
+
+Children nodes:
+- children nodes represent the available NAND chips.
+
+See Documentation/devicetree/bindings/mtd/nand-controller.yaml
+for more details on generic bindings.
+
+Example:
+
+ nand: nand-controller@43c3 {
+ compatible = "mxic,multi-itfc-v009-nand-controller";
+ reg = <0x43c3 0x1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 15>;
+ clock-names = "send", "send_dly", "ps";
+
+ nand@0 {
+ reg = <0>;
+ nand-ecc-mode = "soft";
+ nand-ecc-algo = "bch";
+ };
+ };
--
1.9.1
[PATCH v7 1/2] mtd: rawnand: Add Macronix raw NAND controller driver
Add a driver for Macronix raw NAND controller. Signed-off-by: Mason Yang --- drivers/mtd/nand/raw/Kconfig | 6 + drivers/mtd/nand/raw/Makefile| 1 + drivers/mtd/nand/raw/mxic_nand.c | 584 +++ 3 files changed, 591 insertions(+) create mode 100644 drivers/mtd/nand/raw/mxic_nand.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index 5a711d8..9cff36a 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -407,6 +407,12 @@ config MTD_NAND_MTK Enables support for NAND controller on MTK SoCs. This controller is found on mt27xx, mt81xx, mt65xx SoCs. +config MTD_NAND_MXIC + tristate "Macronix raw NAND controller" + depends on HAS_IOMEM || COMPILE_TEST + help + This selects the Macronix raw NAND controller driver. + config MTD_NAND_TEGRA tristate "NVIDIA Tegra NAND controller" depends on ARCH_TEGRA || COMPILE_TEST diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index efaf5cd..9b43fbf 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_MTD_NAND_HISI504)+= hisi504_nand.o obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o +obj-$(CONFIG_MTD_NAND_MXIC)+= mxic_nand.o obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o diff --git a/drivers/mtd/nand/raw/mxic_nand.c b/drivers/mtd/nand/raw/mxic_nand.c new file mode 100644 index 000..b493edb --- /dev/null +++ b/drivers/mtd/nand/raw/mxic_nand.c @@ -0,0 +1,584 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2019 Macronix International Co., Ltd. + * + * Author: + * Mason Yang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "internals.h" + +#define HC_CFG 0x0 +#define HC_CFG_IF_CFG(x) ((x) << 27) +#define HC_CFG_DUAL_SLAVE BIT(31) +#define HC_CFG_INDIVIDUAL BIT(30) +#define HC_CFG_NIO(x) (((x) / 4) << 27) +#define HC_CFG_TYPE(s, t) ((t) << (23 + ((s) * 2))) +#define HC_CFG_TYPE_SPI_NOR0 +#define HC_CFG_TYPE_SPI_NAND 1 +#define HC_CFG_TYPE_SPI_RAM2 +#define HC_CFG_TYPE_RAW_NAND 3 +#define HC_CFG_SLV_ACT(x) ((x) << 21) +#define HC_CFG_CLK_PH_EN BIT(20) +#define HC_CFG_CLK_POL_INV BIT(19) +#define HC_CFG_BIG_ENDIAN BIT(18) +#define HC_CFG_DATA_PASS BIT(17) +#define HC_CFG_IDLE_SIO_LVL(x) ((x) << 16) +#define HC_CFG_MAN_START_ENBIT(3) +#define HC_CFG_MAN_START BIT(2) +#define HC_CFG_MAN_CS_EN BIT(1) +#define HC_CFG_MAN_CS_ASSERT BIT(0) + +#define INT_STS0x4 +#define INT_STS_EN 0x8 +#define INT_SIG_EN 0xc +#define INT_STS_ALLGENMASK(31, 0) +#define INT_RDY_PINBIT(26) +#define INT_RDY_SR BIT(25) +#define INT_LNR_SUSP BIT(24) +#define INT_ECC_ERRBIT(17) +#define INT_CRC_ERRBIT(16) +#define INT_LWR_DISBIT(12) +#define INT_LRD_DISBIT(11) +#define INT_SDMA_INT BIT(10) +#define INT_DMA_FINISH BIT(9) +#define INT_RX_NOT_FULLBIT(3) +#define INT_RX_NOT_EMPTY BIT(2) +#define INT_TX_NOT_FULLBIT(1) +#define INT_TX_EMPTY BIT(0) + +#define HC_EN 0x10 +#define HC_EN_BIT BIT(0) + +#define TXD(x) (0x14 + ((x) * 4)) +#define RXD0x24 + +#define SS_CTRL(s) (0x30 + ((s) * 4)) +#define LRD_CFG0x44 +#define LWR_CFG0x80 +#define RWW_CFG0x70 +#define OP_READBIT(23) +#define OP_DUMMY_CYC(x)((x) << 17) +#define OP_ADDR_BYTES(x) ((x) << 14) +#define OP_CMD_BYTES(x)(((x) - 1) << 13) +#define OP_OCTA_CRC_EN BIT(12) +#define OP_DQS_EN BIT(11) +#define OP_ENHC_EN BIT(10) +#define OP_PREAMBLE_EN BIT(9) +#define OP_DATA_DDRBIT(8) +#define OP_DATA_BUSW(x)((x) << 6) +#define OP_ADDR_DDRBIT(5) +#define OP_ADDR_BUSW(x)((x) << 3) +#define OP_CMD_DDR BIT(2) +#define OP_CMD_BUSW(x) (x) +#define OP_BUSW_1 0 +#define OP_BUSW_2 1 +#define OP_BUSW_4 2 +#define OP_BUSW_8 3 + +#define OCTA_CRC 0x38 +#define OCTA_CRC_IN_EN(s) BIT(3 + ((s) * 16)) +#define OCTA_CRC_CHUNK(s, x) ((fls((x) / 32)) << (1 + ((s) * 16))) +#define OCTA_CRC_OUT_EN(s) BIT(0 + ((s) * 16)) + +#define ONFI_DIN_CNT(s)(0x3c + (s)) +
[PATCH] fuse: BUG_ON correction in fuse_dev_splice_write()
commit 963545357202 ("fuse: reduce allocation size for splice_write")
changed size of bufs array, so BUG_ON which checks the index of the array
shold also be fixed.
Fixes: 963545357202 ("fuse: reduce allocation size for splice_write")
Signed-off-by: Vasily Averin
---
fs/fuse/dev.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index ea8237513dfa..f4ef6e01642c 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -2029,7 +2029,7 @@ static ssize_t fuse_dev_splice_write(struct
pipe_inode_info *pipe,
struct file *out, loff_t *ppos,
size_t len, unsigned int flags)
{
- unsigned nbuf;
+ unsigned nbuf, bsize;
unsigned idx;
struct pipe_buffer *bufs;
struct fuse_copy_state cs;
@@ -2043,7 +2043,8 @@ static ssize_t fuse_dev_splice_write(struct
pipe_inode_info *pipe,
pipe_lock(pipe);
- bufs = kvmalloc_array(pipe->nrbufs, sizeof(struct pipe_buffer),
+ bsize = pipe->nrbufs;
+ bufs = kvmalloc_array(bsize, sizeof(struct pipe_buffer),
GFP_KERNEL);
if (!bufs) {
pipe_unlock(pipe);
@@ -2064,7 +2065,7 @@ static ssize_t fuse_dev_splice_write(struct
pipe_inode_info *pipe,
struct pipe_buffer *ibuf;
struct pipe_buffer *obuf;
- BUG_ON(nbuf >= pipe->buffers);
+ BUG_ON(nbuf >= bsize);
BUG_ON(!pipe->nrbufs);
ibuf = &pipe->bufs[pipe->curbuf];
obuf = &bufs[nbuf];
--
2.17.1
Re: [PATCH] cpufreq: qcom-hw: Update logic to detect turbo frequency
On 07-08-19, 17:15, Sibi Sankar wrote: > The core count read back from the each domain's look up table serves > as an indicator for the onset of the turbo frequency and not accurate > representation of number of cores in a paticular domain. Update turbo > detection logic accordingly to add support for SM8150 SoCs. > > Signed-off-by: Sibi Sankar > --- Applied. Thanks. -- viresh
Re: [PATCH] fuse: BUG_ON's correction in fuse_dev_splice_write()
On 8/1/19 2:01 PM, Miklos Szeredi wrote:
> On Tue, Jul 23, 2019 at 8:33 AM Vasily Averin wrote:
>>
>> commit 963545357202 ("fuse: reduce allocation size for splice_write")
>> changed size of bufs array, so first BUG_ON should be corrected too.
>> Second BUG_ON become useless, first one also includes the second check:
>> any unsigned nbuf value cannot be less than 0.
>
> This patch seems broken: it assumes that pipe->nrbufs doesn't change.
> Have you actually tested it?
You're right, I've missed it.
I've prepared second patch version which fixes first BUG_ON only.
checkpatch.pl also advises to replace BUG_ONs to WARN_ONs and 'unsigned' to
'unsigned int'
however I'm don't understand what it's better here:
- keep all as is,
- or merge all changes together,
- or do it in separate patches,
- or do something else?
I believe it makes sense to remove BUG_ONs in separate patch, or may be merge
it with current one,
but I do not like an idea to fight against bare 'unsigned' in fuse.
Could you please comment it?
Thank you,
Vasily Averin
[BUG 5.3-rc5] rwsem: use after free on task_struct if task exits with rwsem held
Hi folks, In trying to track down an XFS regression, I stumbled across KASAN warnings about use-after-free behave in rwsems. Essentially, the XFS regression is triggering an ASSERT, which is BUG()ing a kernel thread that is holding the superblock s_umount rwsem in write mode (it is a mount problem). Once that thread has been killed (segv), the rwsem it held now has no valid owner - the owning task_struct has been freed. When the next attempt to access that superblock occurs (because it's visible in the superblock list), either by attmepting to do something through the block device (e.g. bdev_invalidate()) or by trying to mount the block device again, we get use-after-free warnings on the superblock s_umount rwsem. Need 5.3-rc5 w/ CONFIG_XFS_DEBUG=y (needed for the BUG to trigger), CONFIG_KASAN=y (to change the memory allocation alignment to cause IO failures that cause the conditions for the BUG to to trigger). Access through the bdev (I was only able to reproduce this one through /dev/pmem0) from a thrid party: # while [ 1 ]; do sudo xfs_io -fd -c "pwrite -S 0x0 -b 1m 0 8g" /dev/pmem0; mkfs.xfs -f -l size=2000m /dev/pmem0; mount -o logbsize=256k /dev/pmem0 /mnt/test; umount /dev/pmem0; done On the third or fourth loop, everything gets really, really slow when mounting - instaed of taking about 100ms to mount the filesystem, it takes a couple of minutes before it finally fails, triggering a BUG() that kills the mount process: [ 59.316335] XFS (pmem0): Mounting V5 Filesystem [ 59.322858] XFS (pmem0): Ending clean mount [ 59.368816] XFS (pmem0): Unmounting Filesystem [ 63.864465] XFS (pmem0): Mounting V5 Filesystem [ 63.880840] XFS (pmem0): Ending clean mount [ 63.928850] XFS (pmem0): Unmounting Filesystem [ 68.433309] XFS (pmem0): Mounting V5 Filesystem [ 68.436485] XFS (pmem0): totally zeroed log [ 188.034629] XFS: Assertion failed: head_blk != tail_blk, file: fs/xfs/xfs_log_recover.c, line: 5236 [ 188.040585] [ cut here ] [ 188.041687] kernel BUG at fs/xfs/xfs_message.c:102! [ 188.042870] invalid opcode: [#1] PREEMPT SMP KASAN [ 188.044129] CPU: 1 PID: 4740 Comm: mount Not tainted 5.3.0-rc5-dgc+ #1506 . . Very shortly afterwards: [ 193.777801] == [ 193.780976] BUG: KASAN: use-after-free in rwsem_down_read_slowpath+0x685/0x8f0 [ 193.784072] Read of size 4 at addr 888237048038 by task systemd-udevd/2382 [ 193.787147] [ 193.787763] CPU: 2 PID: 2382 Comm: systemd-udevd Tainted: G D 5.3.0-rc5-dgc+ #1506 [ 193.789828] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 193.791764] Call Trace: [ 193.792358] dump_stack+0x7c/0xc0 [ 193.793153] print_address_description+0x6c/0x322 [ 193.794256] ? rwsem_down_read_slowpath+0x685/0x8f0 [ 193.795398] __kasan_report.cold.6+0x1c/0x3e [ 193.796415] ? rwsem_down_read_slowpath+0x685/0x8f0 [ 193.797554] ? rwsem_down_read_slowpath+0x685/0x8f0 [ 193.798702] kasan_report+0xe/0x12 [ 193.799511] rwsem_down_read_slowpath+0x685/0x8f0 [ 193.800696] ? unwind_get_return_address_ptr+0x50/0x50 [ 193.802075] ? unwind_next_frame+0x6d6/0x8a0 [ 193.803423] ? __down_timeout+0x1c0/0x1c0 [ 193.808628] ? unwind_next_frame+0x6d6/0x8a0 [ 193.809631] ? _raw_spin_lock+0x87/0xe0 [ 193.810540] ? _raw_spin_lock+0x87/0xe0 [ 193.811449] ? __cpuidle_text_end+0x5/0x5 [ 193.812404] ? set_init_blocksize+0xe0/0xe0 [ 193.813391] ? preempt_count_sub+0x43/0x50 [ 193.814357] ? __might_sleep+0x31/0xd0 [ 193.815238] ? set_init_blocksize+0xe0/0xe0 [ 193.816237] ? ___might_sleep+0xc8/0xe0 [ 193.817146] down_read+0x18d/0x1a0 [ 193.817952] ? refcount_sub_and_test_checked+0xaf/0x150 [ 193.819178] ? rwsem_down_read_slowpath+0x8f0/0x8f0 [ 193.820326] ? _raw_spin_lock+0x87/0xe0 [ 193.821234] __get_super.part.12+0xf8/0x130 [ 193.82] fsync_bdev+0xf/0x60 [ 193.822993] invalidate_partition+0x1e/0x40 [ 193.823992] rescan_partitions+0x8a/0x420 [ 193.824947] blkdev_reread_part+0x1e/0x30 [ 193.825896] blkdev_ioctl+0xb0b/0xe60 [ 193.826766] ? __blkdev_driver_ioctl+0x80/0x80 [ 193.827827] ? __bpf_prog_run64+0xc0/0xc0 [ 193.828770] ? stack_trace_save+0x8a/0xb0 [ 193.829729] ? save_stack+0x4d/0x80 [ 193.830567] ? __seccomp_filter+0x133/0xa10 [ 193.831556] ? preempt_count_sub+0x43/0x50 [ 193.832532] block_ioctl+0x6d/0x80 [ 193.88] do_vfs_ioctl+0x134/0x9c0 [ 193.834205] ? ioctl_preallocate+0x140/0x140 [ 193.835217] ? selinux_file_ioctl+0x2b7/0x360 [ 193.836255] ? selinux_capable+0x20/0x20 [ 193.837185] ? syscall_trace_enter+0x233/0x540 [ 193.838231] ksys_ioctl+0x60/0x90 [ 193.839017] __x64_sys_ioctl+0x3d/0x50 [ 193.839921] do_syscall_64+0x70/0x230 [ 193.840789] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 193.841971] RIP: 0033:0x7fade328a427 [ 193.842820] Code: 00 00 90 48 8b 05 69 aa 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0
Re: [PATCH V2 04/10] cpufreq: powerpc_cbe: Switch to QoS requests instead of cpufreq notifier
On 19-08-19, 08:42, Rafael J. Wysocki wrote: > OK, thanks! > > The series is on hold, though, because the acpi-cpufreq patch turned > out to be problematic and I didn't have the time to have a deeper look > at the problem last week. And so was I wondering why it is present in bleeding-edge only :) I don't think I am cc'd to any bug reports on that, can you please help me with some information on it ? -- viresh
Re: [PATCH V2 04/10] cpufreq: powerpc_cbe: Switch to QoS requests instead of cpufreq notifier
On Mon, Aug 19, 2019 at 4:26 AM Viresh Kumar wrote: > > On 09-08-19, 11:01, Rafael J. Wysocki wrote: > > On Fri, Aug 9, 2019 at 4:34 AM Viresh Kumar wrote: > > > > > > On 23-07-19, 11:44, Viresh Kumar wrote: > > > > The cpufreq core now takes the min/max frequency constraints via QoS > > > > requests and the CPUFREQ_ADJUST notifier shall get removed later on. > > > > > > > > Switch over to using the QoS request for maximum frequency constraint > > > > for ppc_cbe_cpufreq driver. > > > > > > > > Signed-off-by: Viresh Kumar > > > > --- > > > > drivers/cpufreq/ppc_cbe_cpufreq.c | 19 +- > > > > drivers/cpufreq/ppc_cbe_cpufreq.h | 8 +++ > > > > drivers/cpufreq/ppc_cbe_cpufreq_pmi.c | 96 +-- > > > > 3 files changed, 86 insertions(+), 37 deletions(-) > > > > > > -8<- > > > > If you do it this way, Patchwork will not pick up the patch. > > > > Please send afresh with "[Update]" or bumped up version number in the > > subject (or both). > > Okay, will take care of this in future. Was away on holidays and so > the late reply. Thanks. OK, thanks! The series is on hold, though, because the acpi-cpufreq patch turned out to be problematic and I didn't have the time to have a deeper look at the problem last week.
[PATCH net-next v2] r8152: divide the tx and rx bottom functions
Move the tx bottom function from NAPI to a new tasklet. Then, for
multi-cores, the bottom functions of tx and rx may be run at same
time with different cores. This is used to improve performance.
On x86, Tx/Rx 943/943 Mbits/sec -> 945/944.
For arm platform, Tx/Rx: 917/917 Mbits/sec -> 933/933.
Signed-off-by: Hayes Wang
---
v2: add the performance number in the commit message.
---
drivers/net/usb/r8152.c | 39 ++-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 40d18e866269..3ed9f8e082c9 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -619,7 +619,7 @@ enum rtl8152_flags {
RTL8152_LINK_CHG,
SELECTIVE_SUSPEND,
PHY_RESET,
- SCHEDULE_NAPI,
+ SCHEDULE_TASKLET,
GREEN_ETHERNET,
DELL_TB_RX_AGG_BUG,
};
@@ -733,6 +733,7 @@ struct r8152 {
#ifdef CONFIG_PM_SLEEP
struct notifier_block pm_notifier;
#endif
+ struct tasklet_struct tx_tl;
struct rtl_ops {
void (*init)(struct r8152 *);
@@ -1401,7 +1402,7 @@ static void write_bulk_callback(struct urb *urb)
return;
if (!skb_queue_empty(&tp->tx_queue))
- napi_schedule(&tp->napi);
+ tasklet_schedule(&tp->tx_tl);
}
static void intr_callback(struct urb *urb)
@@ -2179,8 +2180,12 @@ static void tx_bottom(struct r8152 *tp)
} while (res == 0);
}
-static void bottom_half(struct r8152 *tp)
+static void bottom_half(unsigned long data)
{
+ struct r8152 *tp;
+
+ tp = (struct r8152 *)data;
+
if (test_bit(RTL8152_UNPLUG, &tp->flags))
return;
@@ -2192,7 +2197,7 @@ static void bottom_half(struct r8152 *tp)
if (!netif_carrier_ok(tp->netdev))
return;
- clear_bit(SCHEDULE_NAPI, &tp->flags);
+ clear_bit(SCHEDULE_TASKLET, &tp->flags);
tx_bottom(tp);
}
@@ -2203,16 +2208,12 @@ static int r8152_poll(struct napi_struct *napi, int
budget)
int work_done;
work_done = rx_bottom(tp, budget);
- bottom_half(tp);
if (work_done < budget) {
if (!napi_complete_done(napi, work_done))
goto out;
if (!list_empty(&tp->rx_done))
napi_schedule(napi);
- else if (!skb_queue_empty(&tp->tx_queue) &&
-!list_empty(&tp->tx_free))
- napi_schedule(napi);
}
out:
@@ -2366,11 +2367,11 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff
*skb,
if (!list_empty(&tp->tx_free)) {
if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
- set_bit(SCHEDULE_NAPI, &tp->flags);
+ set_bit(SCHEDULE_TASKLET, &tp->flags);
schedule_delayed_work(&tp->schedule, 0);
} else {
usb_mark_last_busy(tp->udev);
- napi_schedule(&tp->napi);
+ tasklet_schedule(&tp->tx_tl);
}
} else if (skb_queue_len(&tp->tx_queue) > tp->tx_qlen) {
netif_stop_queue(netdev);
@@ -4020,9 +4021,11 @@ static void set_carrier(struct r8152 *tp)
} else {
if (netif_carrier_ok(netdev)) {
netif_carrier_off(netdev);
+ tasklet_disable(&tp->tx_tl);
napi_disable(napi);
tp->rtl_ops.disable(tp);
napi_enable(napi);
+ tasklet_enable(&tp->tx_tl);
netif_info(tp, link, netdev, "carrier off\n");
}
}
@@ -4055,10 +4058,10 @@ static void rtl_work_func_t(struct work_struct *work)
if (test_and_clear_bit(RTL8152_SET_RX_MODE, &tp->flags))
_rtl8152_set_rx_mode(tp->netdev);
- /* don't schedule napi before linking */
- if (test_and_clear_bit(SCHEDULE_NAPI, &tp->flags) &&
+ /* don't schedule tasket before linking */
+ if (test_and_clear_bit(SCHEDULE_TASKLET, &tp->flags) &&
netif_carrier_ok(tp->netdev))
- napi_schedule(&tp->napi);
+ tasklet_schedule(&tp->tx_tl);
mutex_unlock(&tp->control);
@@ -4144,6 +4147,7 @@ static int rtl8152_open(struct net_device *netdev)
goto out_unlock;
}
napi_enable(&tp->napi);
+ tasklet_enable(&tp->tx_tl);
mutex_unlock(&tp->control);
@@ -4171,6 +4175,7 @@ static int rtl8152_close(struct net_device *netdev)
#ifdef CONFIG_PM_SLEEP
unregister_pm_notifier(&tp->pm_notifier);
#endif
+ tasklet_disable(&tp->tx_tl);
if (!test_bit(RTL8152_UNPLUG, &tp->flags))
napi_disable(&tp->napi);
clear_bit(WORK_ENABLE, &tp->flags);
@@ -4440,6 +4445,7 @@ static int rtl8152_pre_reset(struct usb_interface *intf)
return 0;
Re: [PATCH v2] jffs2: remove C++ style comments from uapi header
- Ursprüngliche Mail - > This patch missed the fixes pull requests. > Which version is this targeting for? v5.4-rc1 ? Damn, I forgot about this one. I'll do another fixes PR this week for UBI/UBIFS, so it will be in tree before the next merge window opens. Sorry for the delay! Thanks, //richard
Re: Re: [PATCH net-next 1/1] Added BASE-T1 PHY support to PHY Subsystem
On 16.08.2019 23:13, Heiner Kallweit wrote:
>
> On 15.08.2019 17:32, Christian Herber wrote:
>> BASE-T1 is a category of Ethernet PHYs.
>> They use a single copper pair for transmission.
>> This patch add basic support for this category of PHYs.
>> It coveres the discovery of abilities and basic configuration.
>> It includes setting fixed speed and enabling auto-negotiation.
>> BASE-T1 devices should always Clause-45 managed.
>> Therefore, this patch extends phy-c45.c.
>> While for some functions like auto-neogtiation different registers are
>> used, the layout of these registers is the same for the used fields.
>> Thus, much of the logic of basic Clause-45 devices can be reused.
>>
>> Signed-off-by: Christian Herber
>> ---
>> drivers/net/phy/phy-c45.c| 113 +++
>> drivers/net/phy/phy-core.c | 4 +-
>> include/uapi/linux/ethtool.h | 2 +
>> include/uapi/linux/mdio.h| 21 +++
>> 4 files changed, 129 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
>> index b9d4145781ca..9ff0b8c785de 100644
>> --- a/drivers/net/phy/phy-c45.c
>> +++ b/drivers/net/phy/phy-c45.c
>> @@ -8,13 +8,23 @@
>> #include
>> #include
>>
>> +#define IS_100BASET1(phy) (linkmode_test_bit( \
>> +ETHTOOL_LINK_MODE_100baseT1_Full_BIT, \
>> +(phy)->supported))
>> +#define IS_1000BASET1(phy) (linkmode_test_bit( \
>> + ETHTOOL_LINK_MODE_1000baseT1_Full_BIT, \
>> + (phy)->supported))
>> +
> Why is there no such macro for 10BaseT1?
>
>> +static u32 get_aneg_ctrl(struct phy_device *phydev);
>> +static u32 get_aneg_stat(struct phy_device *phydev);
>> +
>> /**
>>* genphy_c45_setup_forced - configures a forced speed
>>* @phydev: target phy_device struct
>>*/
>> int genphy_c45_pma_setup_forced(struct phy_device *phydev)
>> {
>> - int ctrl1, ctrl2, ret;
>> + int ctrl1, ctrl2, base_t1_ctrl = 0, ret;
>>
>>/* Half duplex is not supported */
>>if (phydev->duplex != DUPLEX_FULL)
>> @@ -28,6 +38,16 @@ int genphy_c45_pma_setup_forced(struct phy_device *phydev)
>>if (ctrl2 < 0)
>>return ctrl2;
>>
>> + if (IS_100BASET1(phydev) || IS_1000BASET1(phydev)) {
>
> 10BaseT1 doesn't need to be considered here?
> And maybe it would be better to have a flag for BaseT1 at phy_device level
> (based on bit MDIO_PMA_EXTABLE_BASET1?) instead of checking whether certain
> T1 modes are supported. Then we would be more future-proof in case of new
> T1 modes.
>
>> + base_t1_ctrl = phy_read_mmd(phydev,
>> + MDIO_MMD_PMAPMD,
>> + MDIO_PMA_BASET1CTRL);
>> + if (base_t1_ctrl < 0)
>> + return base_t1_ctrl;
>> +
>> + base_t1_ctrl &= ~(MDIO_PMA_BASET1CTRL_TYPE);
>> + }
>> +
>>ctrl1 &= ~MDIO_CTRL1_SPEEDSEL;
>>/*
>> * PMA/PMD type selection is 1.7.5:0 not 1.7.3:0. See 45.2.1.6.1
>> @@ -41,12 +61,21 @@ int genphy_c45_pma_setup_forced(struct phy_device
>> *phydev)
>>break;
>>case SPEED_100:
>>ctrl1 |= MDIO_PMA_CTRL1_SPEED100;
>> - ctrl2 |= MDIO_PMA_CTRL2_100BTX;
>> + if (IS_100BASET1(phydev)) {
>> + ctrl2 |= MDIO_PMA_CTRL2_BT1;
>> + base_t1_ctrl |= MDIO_PMA_BASET1CTRL_TYPE_100BT1;
>> + } else {
>> + ctrl2 |= MDIO_PMA_CTRL2_100BTX;
>> + }
>>break;
>>case SPEED_1000:
>>ctrl1 |= MDIO_PMA_CTRL1_SPEED1000;
>> - /* Assume 1000base-T */
>> - ctrl2 |= MDIO_PMA_CTRL2_1000BT;
>> + if (IS_1000BASET1(phydev)) {
>> + ctrl2 |= MDIO_PMA_CTRL2_BT1;
>> + base_t1_ctrl |= MDIO_PMA_BASET1CTRL_TYPE_1000BT1;
>> + } else {
>> + ctrl2 |= MDIO_PMA_CTRL2_1000BT;
>> + }
>>break;
>>case SPEED_2500:
>>ctrl1 |= MDIO_CTRL1_SPEED2_5G;
>> @@ -75,6 +104,14 @@ int genphy_c45_pma_setup_forced(struct phy_device
>> *phydev)
>>if (ret < 0)
>>return ret;
>>
>> + if (IS_100BASET1(phydev) || IS_1000BASET1(phydev)) {
>> + ret = phy_write_mmd(phydev,
>> + MDIO_MMD_PMAPMD,
>> + MDIO_PMA_BASET1CTRL,
>> + base_t1_ctrl);
>> + if (ret < 0)
>> + return ret;
>> + }
>>return genphy_c45_an_disable_aneg(phydev);
>> }
>> EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
>> @@ -135,8 +172,7 @@ EXPORT_SYMBOL_GPL(genphy_c45_an_config_aneg);
>>*/
>> int genphy_c45_an_disable_aneg(struct phy_device *phydev)
>> {
>> -
>> - return phy_clear_bits_mmd(phydev, MDIO_MMD_AN, MDIO_
[PATCH] powerpc/603: fix handling of the DIRTY flag
If a page is already mapped RW without the DIRTY flag, the DIRTY
flag is never set and a TLB store miss exception is taken forever.
This is easily reproduced with the following app:
void main(void)
{
volatile char *ptr = mmap(0, 4096, PROT_READ | PROT_WRITE, MAP_SHARED |
MAP_ANONYMOUS, -1, 0);
*ptr = *ptr;
}
When DIRTY flag is not set, bail out of TLB miss handler and take
a minor page fault which will set the DIRTY flag.
Fixes: f8b58c64eaef ("powerpc/603: let's handle PAGE_DIRTY directly")
Cc: sta...@vger.kernel.org
Reported-by: Doug Crawford
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_32.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index f255e22184b4..534dd2718795 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -557,9 +557,9 @@ DataStoreTLBMiss:
cmplw 0,r1,r3
mfspr r2, SPRN_SPRG_PGDIR
#ifdef CONFIG_SWAP
- li r1, _PAGE_RW | _PAGE_PRESENT | _PAGE_ACCESSED
+ li r1, _PAGE_RW | _PAGE_DIRTY | _PAGE_PRESENT | _PAGE_ACCESSED
#else
- li r1, _PAGE_RW | _PAGE_PRESENT
+ li r1, _PAGE_RW | _PAGE_DIRTY | _PAGE_PRESENT
#endif
bge-112f
lis r2, (swapper_pg_dir - PAGE_OFFSET)@ha /* if kernel address,
use */
--
2.13.3
Re: [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ; -)
On Fri 16-08-19 16:20:07, Ira Weiny wrote: > On Fri, Aug 16, 2019 at 12:05:28PM -0700, 'Ira Weiny' wrote: > > On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote: > > > On Wed 14-08-19 11:08:49, Ira Weiny wrote: > > > > On Wed, Aug 14, 2019 at 12:17:14PM +0200, Jan Kara wrote: > > > > > Hello! > > > > > > > > > > On Fri 09-08-19 15:58:14, ira.we...@intel.com wrote: > > > > > > Pre-requisites > > > > > > == > > > > > > Based on mmotm tree. > > > > > > > > > > > > Based on the feedback from LSFmm, the LWN article, the RFC series > > > > > > since > > > > > > then, and a ton of scenarios I've worked in my mind and/or > > > > > > tested...[1] > > > > > > > > > > > > Solution summary > > > > > > > > > > > > > > > > > > The real issue is that there is no use case for a user to have RDMA > > > > > > pinn'ed > > > > > > memory which is then truncated. So really any solution we present > > > > > > which: > > > > > > > > > > > > A) Prevents file system corruption or data leaks > > > > > > ...and... > > > > > > B) Informs the user that they did something wrong > > > > > > > > > > > > Should be an acceptable solution. > > > > > > > > > > > > Because this is slightly new behavior. And because this is going > > > > > > to be > > > > > > specific to DAX (because of the lack of a page cache) we have made > > > > > > the user > > > > > > "opt in" to this behavior. > > > > > > > > > > > > The following patches implement the following solution. > > > > > > > > > > > > 0) Registrations to Device DAX char devs are not affected > > > > > > > > > > > > 1) The user has to opt in to allowing page pins on a file with an > > > > > > exclusive > > > > > >layout lease. Both exclusive and layout lease flags are user > > > > > > visible now. > > > > > > > > > > > > 2) page pins will fail if the lease is not active when the file > > > > > > back page is > > > > > >encountered. > > > > > > > > > > > > 3) Any truncate or hole punch operation on a pinned DAX page will > > > > > > fail. > > > > > > > > > > So I didn't fully grok the patch set yet but by "pinned DAX page" do > > > > > you > > > > > mean a page which has corresponding file_pin covering it? Or do you > > > > > mean a > > > > > page which has pincount increased? If the first then I'd rephrase > > > > > this to > > > > > be less ambiguous, if the second then I think it is wrong. > > > > > > > > I mean the second. but by "fail" I mean hang. Right now the "normal" > > > > page > > > > pincount processing will hang the truncate. Given the discussion with > > > > John H > > > > we can make this a bit better if we use something like FOLL_PIN and the > > > > page > > > > count bias to indicate this type of pin. Then I could fail the truncate > > > > outright. but that is not done yet. > > > > > > > > so... I used the word "fail" to be a bit more vague as the final > > > > implementation > > > > may return ETXTBUSY or hang as noted. > > > > > > Ah, OK. Hanging is fine in principle but with longterm pins, your work > > > makes sure they actually fail with ETXTBUSY, doesn't it? The thing is that > > > e.g. DIO will use page pins as well for its buffers and we must wait there > > > until the pin is released. So please just clarify your 'fail' here a bit > > > :). > > > > It will fail with ETXTBSY. I've fixed a bug... See below. > > > > > > > > > > > 4) The user has the option of holding the lease or releasing it. > > > > > > If they > > > > > >release it no other pin calls will work on the file. > > > > > > > > > > Last time we spoke the plan was that the lease is kept while the > > > > > pages are > > > > > pinned (and an attempt to release the lease would block until the > > > > > pages are > > > > > unpinned). That also makes it clear that the *lease* is what is making > > > > > truncate and hole punch fail with ETXTBUSY and the file_pin structure > > > > > is > > > > > just an implementation detail how the existence is efficiently > > > > > tracked (and > > > > > what keeps the backing file for the pages open so that the lease does > > > > > not > > > > > get auto-destroyed). Why did you change this? > > > > > > > > closing the file _and_ unmaping it will cause the lease to be released > > > > regardless of if we allow this or not. > > > > > > > > As we discussed preventing the close seemed intractable. > > > > > > Yes, preventing the application from closing the file is difficult. But > > > from a quick look at your patches it seemed to me that you actually hold a > > > backing file reference from the file_pin structure thus even though the > > > application closes its file descriptor, the struct file (and thus the > > > lease) lives further until the file_pin gets released. And that should > > > last > > > as long as the pages are pinned. Am I missing something? > > > > > > > I thought about failing the munmap but that seemed wrong as well. But > > > > more > > > > importan
Re: [RFC PATCH v2 00/19] RDMA/FS DAX truncate proposal V1,000,002 ;-)
On Sat 17-08-19 12:26:03, Dave Chinner wrote: > On Fri, Aug 16, 2019 at 12:05:28PM -0700, Ira Weiny wrote: > > On Thu, Aug 15, 2019 at 03:05:58PM +0200, Jan Kara wrote: > > > On Wed 14-08-19 11:08:49, Ira Weiny wrote: > > > > On Wed, Aug 14, 2019 at 12:17:14PM +0200, Jan Kara wrote: > > 2) Second reason is that I thought I did not have a good way to tell if the > >lease was actually in use. What I mean is that letting the lease go > > should > >be ok IFF we don't have any pins... I was thinking that without John's > > code > >we don't have a way to know if there are any pins... But that is > > wrong... > >All we have to do is check > > > > !list_empty(file->file_pins) > > > > So now with this detail I think you are right, we should be able to hold the > > lease through the struct file even if the process no longer has any > > "references" to it (ie closes and munmaps the file). > > I really, really dislike the idea of zombie layout leases. It's a > nasty hack for poor application behaviour. This is a "we allow use > after layout lease release" API, and I think encoding largely > untraceable zombie objects into an API is very poor design. > > From the fcntl man page: > > LEASES > Leases are associated with an open file description (see > open(2)). This means that duplicate file descriptors > (created by, for example, fork(2) or dup(2)) re‐ fer to > the same lease, and this lease may be modified or > released using any of these descriptors. Furthermore, the > lease is released by either an explicit F_UNLCK operation on > any of these duplicate file descriptors, or when all such > file descriptors have been closed. > > Leases are associated with *open* file descriptors, not the > lifetime of the struct file in the kernel. If the application closes > the open fds that refer to the lease, then the kernel does not > guarantee, and the application has no right to expect, that the > lease remains active in any way once the application closes all > direct references to the lease. > > IOWs, applications using layout leases need to hold the lease fd > open for as long as the want access to the physical file layout. It > is a also a requirement of the layout lease that the holder releases > the resources it holds on the layout before it releases the layout > lease, exclusive lease or not. Closing the fd indicates they do not > need access to the file any more, and so the lease should be > reclaimed at that point. > > I'm of a mind to make the last close() on a file block if there's an > active layout lease to prevent processes from zombie-ing layout > leases like this. i.e. you can't close the fd until resources that > pin the lease have been released. Yeah, so this was my initial though as well [1]. But as the discussion in that thread revealed, the problem with blocking last close is that kernel does not really expect close to block. You could easily deadlock e.g. if the process gets SIGKILL, file with lease has fd 10, and the RDMA context holding pages pinned has fd 15. Or you could wait for another process to release page pins and blocking SIGKILL on that is also bad. So in the end the least bad solution we've come up with were these "zombie" leases as you call them and tracking them in /proc so that userspace at least has a way of seeing them. But if you can come up with a different solution, I'm certainly not attached to the current one... Honza [1] https://lore.kernel.org/lkml/20190606104203.gf7...@quack2.suse.cz -- Jan Kara SUSE Labs, CR
Re: Re: [PATCH net-next 0/1] Add BASE-T1 PHY support
On 16.08.2019 22:59, Heiner Kallweit wrote: > On 15.08.2019 17:32, Christian Herber wrote: >> This patch adds basic support for BASE-T1 PHYs in the framework. >> BASE-T1 PHYs main area of application are automotive and industrial. >> BASE-T1 is standardized in IEEE 802.3, namely >> - IEEE 802.3bw: 100BASE-T1 >> - IEEE 802.3bp 1000BASE-T1 >> - IEEE 802.3cg: 10BASE-T1L and 10BASE-T1S >> >> There are no products which contain BASE-T1 and consumer type PHYs like >> 1000BASE-T. However, devices exist which combine 100BASE-T1 and 1000BASE-T1 >> PHYs with auto-negotiation. > > Is this meant in a way that *currently* there are no PHY's combining Base-T1 > with normal Base-T modes? Or are there reasons why this isn't possible in > general? I'm asking because we have PHY's combining copper and fiber, and e.g. > the mentioned Aquantia PHY that combines NBase-T with 1000Base-T2. > >> >> The intention of this patch is to make use of the existing Clause 45 >> functions. >> BASE-T1 adds some additional registers e.g. for aneg control, which follow a >> similiar register layout as the existing devices. The bits which are used in >> BASE-T1 specific registers are the same as in basic registers, thus the >> existing functions can be resued, with get_aneg_ctrl() selecting the correct >> register address. >> > If Base-T1 can't be combined with other modes then at a first glance I see no > benefit in defining new registers e.g. for aneg control, and the standard ones > are unused. Why not using the standard registers? Can you shed some light on > that? > > Are the new registers internally shadowed to the standard location? > That's something I've seen on other PHY's: one register appears in different > places in different devices. > >> The current version of ethtool has been prepared for 100/1000BASE-T1 and >> works >> with this patch. 10BASE-T1 needs to be added to ethtool. >> >> Christian Herber (1): >>Added BASE-T1 PHY support to PHY Subsystem >> >> drivers/net/phy/phy-c45.c| 113 +++ >> drivers/net/phy/phy-core.c | 4 +- >> include/uapi/linux/ethtool.h | 2 + >> include/uapi/linux/mdio.h| 21 +++ >> 4 files changed, 129 insertions(+), 11 deletions(-) >> > > Heiner > Hi Heiner, I do not think the Aquantia part you are describing is publicly documented, so i cannot comment on that part. There are multiple reasons why e.g. xBASE-T1 plus 1000BASE-T is unlikely. First, the is no use-case known to me, where this would be required. Second, there is no way that you can do an auto-negotiation between the two, as these both have their own auto-neg defined (Clause 28/73 vs. Clause 98). Thirdly, if you would ever have a product with both, I believe it would just include two full PHYs and a way to select which flavor you want. Of course, this is the theory until proven otherwise, but to me it is sufficient to use a single driver. The registers are different in the fields they include. It is just that the flags which are used by the Linux driver, like restarting auto-neg, are at the same position. Christian
Re: [PATCH][V2] drivers: thermal: processor_thermal_device: fix missing bitwise-or operators
On Mon, 2019-07-29 at 14:09 -0700, Srinivas Pandruvada wrote:
> On Mon, 2019-07-29 at 13:03 +0100, Colin King wrote:
> > From: Colin Ian King
> >
> > The variable val is having the top 8 bits cleared and then the
> > variable is being
> > re-assinged and setting just the top 8 bits. I believe the
> > intention
> > was bitwise-or
> > in the top 8 bits. Fix this by replacing the = operators with &=
> > and
> > > = instead.
> >
> > Addresses-Coverity: ("Unused value")
> > Fixes: b0c74b08517e ("drivers: thermal: processor_thermal_device:
> > Export sysfs inteface for TCC offset")
> > Signed-off-by: Colin Ian King
>
> Reviewed-by: Srinivas Pandruvada >
Hi, Colin,
thanks for the fix, as b0c74b08517e ("drivers: thermal:
processor_thermal_device: Export sysfs inteface for TCC offset") has
not been shipped in upstream yet, I will fold this fix into the
original patch directly.
thanks,
rui
>
> > ---
> >
> > V2: Add in &= operator missing from V1. Doh.
> >
> > ---
> > .../thermal/intel/int340x_thermal/processor_thermal_device.c | 4
> > ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git
> > a/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
> > b/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
> > index 6f6ac6a8e82d..97333fc4be42 100644
> > ---
> > a/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
> > +++
> > b/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c
> > @@ -163,8 +163,8 @@ static int tcc_offset_update(int tcc)
> > if (err)
> > return err;
> >
> > - val = ~GENMASK_ULL(31, 24);
> > - val = (tcc & 0xff) << 24;
> > + val &= ~GENMASK_ULL(31, 24);
> > + val |= (tcc & 0xff) << 24;
> >
> > err = wrmsrl_safe(MSR_IA32_TEMPERATURE_TARGET, val);
> > if (err)
>
>
linux-next: manual merge of the gpio-brgl tree with the gpio tree
Hi all,
Today's linux-next merge of the gpio-brgl tree got a conflict in:
include/linux/gpio/driver.h
between commit:
379ce1ff51aa ("gpio: stubs in headers should be inline")
from the gpio tree and commit:
9091373ab7ea ("gpio: remove less important #ifdef around declarations")
from the gpio-brgl tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/gpio/driver.h
index 72d48a2bab65,f28f534f451a..
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@@ -20,12 -20,6 +20,8 @@@ struct module
enum gpiod_flags;
enum gpio_lookup_flags;
- #ifdef CONFIG_GPIOLIB
-
- #ifdef CONFIG_GPIOLIB_IRQCHIP
-
+struct gpio_chip;
+
/**
* struct gpio_irq_chip - GPIO interrupt controller
*/
@@@ -530,38 -443,6 +523,35 @@@ struct bgpio_pdata
int ngpio;
};
+#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
+
+void gpiochip_populate_parent_fwspec_twocell(struct gpio_chip *chip,
+ struct irq_fwspec *fwspec,
+ unsigned int parent_hwirq,
+ unsigned int parent_type);
+void gpiochip_populate_parent_fwspec_fourcell(struct gpio_chip *chip,
+struct irq_fwspec *fwspec,
+unsigned int parent_hwirq,
+unsigned int parent_type);
+
+#else
+
+static inline void gpiochip_populate_parent_fwspec_twocell(struct gpio_chip
*chip,
+ struct irq_fwspec *fwspec,
+ unsigned int parent_hwirq,
+ unsigned int parent_type)
+{
+}
+
+static inline void gpiochip_populate_parent_fwspec_fourcell(struct gpio_chip
*chip,
+ struct irq_fwspec *fwspec,
+ unsigned int parent_hwirq,
+ unsigned int parent_type)
+{
+}
+
+#endif /* CONFIG_IRQ_DOMAIN_HIERARCHY */
+
-
- #if IS_ENABLED(CONFIG_GPIO_GENERIC)
-
int bgpio_init(struct gpio_chip *gc, struct device *dev,
unsigned long sz, void __iomem *dat, void __iomem *set,
void __iomem *clr, void __iomem *dirout, void __iomem *dirin,
pgpTvwNcJTNaS.pgp
Description: OpenPGP digital signature
Re: add a not device managed memremap_pages v3
On Mon, Aug 19, 2019 at 10:57:52AM +0530, Bharata B Rao wrote: > On Sun, Aug 18, 2019 at 11:05:53AM +0200, Christoph Hellwig wrote: > > Hi Dan and Jason, > > > > Bharata has been working on secure page management for kvmppc guests, > > and one I thing I noticed is that he had to fake up a struct device > > just so that it could be passed to the devm_memremap_pages > > instrastructure for device private memory. > > > > This series adds non-device managed versions of the > > devm_request_free_mem_region and devm_memremap_pages functions for > > his use case. > > Tested kvmppc ultravisor patchset with migrate_vma changes and this > patchset. (Had to manually patch mm/memremap.c instead of kernel/memremap.c > though) Oh. I rebased to the hmm tree, and that didn't have the rename yet. And I didn't even notice that as git handled it transparently.
Re: [PATCH 1/2] riscv: Add memmove string operation.
Hi Paul,
On Thu, Aug 15, 2019 at 11:27:51AM -0700, Paul Walmsley wrote:
> On Thu, 15 Aug 2019, Nick Hu wrote:
>
> > On Wed, Aug 14, 2019 at 10:03:39AM -0700, Paul Walmsley wrote:
> >
> > > Thanks for the explanation. What do you think about Palmer's idea to
> > > define a generic C set of KASAN string operations, derived from the
> > > newlib
> > > code?
> >
> > That sounds good to me. But it should be another topic. We need to
> > investigate
> > it further about replacing something generic and fundamental in lib/string.c
> > with newlib C functions. Some blind spots may exist. So I suggest, let's
> > consider KASAN for now.
>
> OK. Here is the problem for us as maintainers. You, Palmer, and I all
> agree that a C-language version would be better. We'd rather not merge a
> pure assembly-language version unless it had significant advantages, and
> right now we're not anticipating that. So that suggests that a C-language
> memmove() is the right way to go.
>
> But if we merge a C-language memmove() into arch/riscv, other kernel
> developers would probably ask us why we're doing that, since there's
> nothing RISC-V-specific about it. So do you think you might reconsider
> sending patches to add a generic C-language memmove()?
>
>
> - Paul
About pushing mem*() generic, let's start with the reason why in the first place
KASAN needs re-implement its own string operations:
In mm/kasan/common.c:
#undef memset
void *memset(void *addr, int c, size_t len)
{
check_memory_region((unsigned long)addr, len, true, _RET_IP_);
return __memset(addr, c, len);
}
KASAN would call the string operations with the prefix '__', which should be
just an alias to the proper one.
In the past, every architecture that supports KASAN does this in assembly.
E.g. ARM64:
In arch/arm64/lib/memset.S:
ENTRY(__memset)
ENTRY(memset)
...
...
EXPORT_SYMBOL(memset)
EXPORT_SYMBOL(__memset) // export this as an alias
In arch/arm64/include/asm/string.h
#define __HAVE_ARCH_MEMSET
extern void *memset(void *, int, __kernel_size_t);
extern void *__memset(void *, int, __kernel_size_t);
Now, if we are going to replace the current string operations with newlib ones
and let KASAN use them, we must provide something like this:
In lib/string.c:
void *___memset(...)
{
...
}
In include/linux/string.h:
#ifndef __HAVE_ARCH_MEMCPY
#ifdef CONFIG_KASAN
static inline void* __memset(...)
{
___memset(...);
}
extern void memset(...); // force those who include this header uses the
memset wrapped by KASAN
#else
static inline void *memset(...)
{
___memset(...);
}
#endif
#endif
Does this look OK to you?
Nick
Re: [PATCH 2/2] clk: qcom: clk-rpmh: Add support for SM8150
On 16-08-19, 09:58, Stephen Boyd wrote: > Quoting Vinod Koul (2019-08-15 21:24:40) > > On 14-08-19, 10:19, Stephen Boyd wrote: > > > Quoting Vinod Koul (2019-08-14 05:29:58) > > > > Add support for rpmh clocks found in SM8150 > > > > > > > > Signed-off-by: Vinod Koul > > > > --- > > > > > > Patch looks OK, but can you convert this driver to use the new parent > > > style and then update the binding to handle it? We can fix the other > > > platforms and dts files that use this driver in parallel, but sm8150 > > > will be forward looking. > > > > Yes but that would also impact sdm845 as it uses this driver, so I > > wanted to get this one done so that we have support for rpm clock and > > then do the conversion. > > > > Would that be okay with you to get this in and then I convert this? > > > > How does it impact sdm845? The new way of specifying parents supports > fallback to legacy string matching. Yes it does, I have managed to convert this as well as sdm845 and test. I will send updates shortly Thanks -- ~Vinod
Re: [PATCH v6 00/12] implement KASLR for powerpc/fsl_booke/32
Hi Michael, Is there anything more I should do to get this feature meeting the requirements of the mainline? Thanks, Jason On 2019/8/9 18:07, Jason Yan wrote: This series implements KASLR for powerpc/fsl_booke/32, as a security feature that deters exploit attempts relying on knowledge of the location of kernel internals. Since CONFIG_RELOCATABLE has already supported, what we need to do is map or copy kernel to a proper place and relocate. Freescale Book-E parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1 entries are not suitable to map the kernel directly in a randomized region, so we chose to copy the kernel to a proper place and restart to relocate. Entropy is derived from the banner and timer base, which will change every build and boot. This not so much safe so additionally the bootloader may pass entropy via the /chosen/kaslr-seed node in device tree. We will use the first 512M of the low memory to randomize the kernel image. The memory will be split in 64M zones. We will use the lower 8 bit of the entropy to decide the index of the 64M zone. Then we chose a 16K aligned offset inside the 64M zone to put the kernel in. KERNELBASE |--> 64M <--| | | +---+++---+ | |||kernel|| | +---+++---+ | | |-> offset<-| kernstart_virt_addr We also check if we will overlap with some areas like the dtb area, the initrd area or the crashkernel area. If we cannot find a proper area, kaslr will be disabled and boot from the original kernel. Changes since v5: - Rename M_IF_NEEDED to MAS2_M_IF_NEEDED - Define some global variable as __ro_after_init - Replace kimage_vaddr with kernstart_virt_addr - Depend on RELOCATABLE, not select it - Modify the comment block below the SPDX tag - Remove some useless headers in kaslr_booke.c and move is_second_reloc declarationto mmu_decl.h - Remove DBG() and use pr_debug() and rewrite comment above get_boot_seed(). - Add a patch to document the KASLR implementation. - Split a patch from patch #10 which exports kaslr offset in VMCOREINFO ELF notes. - Remove extra logic around finding nokaslr string in cmdline. - Make regions static global and __initdata Changes since v4: - Add Reviewed-by tag from Christophe - Remove an unnecessary cast - Remove unnecessary parenthesis - Fix checkpatch warning Changes since v3: - Add Reviewed-by and Tested-by tag from Diana - Change the comment in fsl_booke_entry_mapping.S to be consistent with the new code. Changes since v2: - Remove unnecessary #ifdef - Use SZ_64M instead of0x400 - Call early_init_dt_scan_chosen() to init boot_command_line - Rename kaslr_second_init() to kaslr_late_init() Changes since v1: - Remove some useless 'extern' keyword. - Replace EXPORT_SYMBOL with EXPORT_SYMBOL_GPL - Improve some assembly code - Use memzero_explicit instead of memset - Use boot_command_line and remove early_command_line - Do not print kaslr offset if kaslr is disabled Jason Yan (12): powerpc: unify definition of M_IF_NEEDED powerpc: move memstart_addr and kernstart_addr to init-common.c powerpc: introduce kernstart_virt_addr to store the kernel base powerpc/fsl_booke/32: introduce create_tlb_entry() helper powerpc/fsl_booke/32: introduce reloc_kernel_entry() helper powerpc/fsl_booke/32: implement KASLR infrastructure powerpc/fsl_booke/32: randomize the kernel image offset powerpc/fsl_booke/kaslr: clear the original kernel if randomized powerpc/fsl_booke/kaslr: support nokaslr cmdline parameter powerpc/fsl_booke/kaslr: dump out kernel offset information on panic powerpc/fsl_booke/kaslr: export offset in VMCOREINFO ELF notes powerpc/fsl_booke/32: Document KASLR implementation Documentation/powerpc/kaslr-booke32.rst | 42 ++ arch/powerpc/Kconfig | 11 + arch/powerpc/include/asm/nohash/mmu-book3e.h | 10 + arch/powerpc/include/asm/page.h | 7 + arch/powerpc/kernel/Makefile | 1 + arch/powerpc/kernel/early_32.c| 2 +- arch/powerpc/kernel/exceptions-64e.S | 12 +- arch/powerpc/kernel/fsl_booke_entry_mapping.S | 27 +- arch/powerpc/kernel/head_fsl_booke.S | 55 ++- arch/powerpc/kernel/kaslr_booke.c | 393 ++ arch/powerpc/kernel/machine_kexec.c | 1 + arch/powerpc/kernel/misc_64.S | 7 +- arch/powerpc/kernel/setup-common.c| 20 + arch/powerpc/mm/init-common.c | 7 + arch/powerpc/mm/init_32.c | 5 - arch/powerpc/mm/init_64.c | 5 - arch/powerpc/mm/mmu_decl.h| 11 + arch/power
Re: Suspend/Resume Broken on AM43/AM33 Platforms
Quoting Keerthy (2019-08-18 21:24:58)
> Hi Stephen,
>
> commit 03a3bb7ae63150230c5de645dc95e673ebf17e1a
> Author: Stephen Boyd
> Date: Mon Aug 5 16:32:41 2019 -0700
>
> hwrng: core - Freeze khwrng thread during suspend
>
> Commit seems to be breaking suspend/resume on TI AM43/AM33 platforms.
>
>
> rtcwake: wakeup from "mem" using /dev/rtc0 at Sun Nov 18 02:12:12 2018
> [ 54.033833] PM: suspend entry (deep)
> [ 54.037741] Filesystems sync: 0.000 seconds
> [ 54.062730] Freezing user space processes ... (elapsed 0.001 seconds)
> done.
> [ 54.071313] OOM killer disabled.
> [ 54.074572] Freezing remaining freezable tasks ...
> [ 74.083121] Freezing of tasks failed after 20.003 seconds (1 tasks
> refusing to freeze, wq_busy=0):
> [ 74.092257] hwrng R running task0 289 2
> 0x0020
> [ 74.099511] [] (__schedule) from []
> (schedule+0x3c/0xc0)
> [ 74.106720] [] (schedule) from []
> (add_hwgenerator_randomness+0xb0/0x100)
> [ 74.115358] [] (add_hwgenerator_randomness) from
> [] (hwrng_fillfn+0xc0/0x14c [rng_core])
Thanks for the report. I suspect we need to check for freezer in
add_hwgenerator_randomness(). I find it odd that there's another caller
of add_hwgenerator_randomness(), but maybe the ath9k driver can be
converted to some sort of hwrng driver instead of calling into the
kthread directly.
Anyway, can you try this patch?
---8<---
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 5d5ea4ce1442..e2e85ca16410 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2429,6 +2429,7 @@ void add_hwgenerator_randomness(const char *buffer,
size_t count,
size_t entropy)
{
struct entropy_store *poolp = &input_pool;
+ bool frozen = false;
if (unlikely(crng_init == 0)) {
crng_fast_load(buffer, count);
@@ -2439,9 +2440,12 @@ void add_hwgenerator_randomness(const char *buffer,
size_t count,
* We'll be woken up again once below random_write_wakeup_thresh,
* or when the calling thread is about to terminate.
*/
- wait_event_interruptible(random_write_wait, kthread_should_stop() ||
+ wait_event_interruptible(random_write_wait,
+ kthread_freezable_should_stop(&frozen) ||
ENTROPY_BITS(&input_pool) <= random_write_wakeup_bits);
- mix_pool_bytes(poolp, buffer, count);
- credit_entropy_bits(poolp, entropy);
+ if (!frozen) {
+ mix_pool_bytes(poolp, buffer, count);
+ credit_entropy_bits(poolp, entropy);
+ }
}
EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc
On Mon, Aug 19, 2019 at 08:09:04AM +0200, Borislav Petkov wrote: > On Sun, Aug 18, 2019 at 10:29:35AM +0200, Christoph Hellwig wrote: > > The sifive_l2_cache.c is in no way related to RISC-V architecture > > memory management. It is a little stub driver working around the fact > > that the EDAC maintainers prefer their drivers to be structured in a > > certain way > > That changed recently so I guess we can do the per-IP block driver after > all, if people would still prefer it. That would seem like the best idea. But I don't really know this code well enough myself, and I really need to get this code out of the forced on RISC-V codebase as some SOCs I'm working with simply don't have the memory for it.. So unless someone signs up to do a per-IP block edac drivers instead very quickly I'd still like to see something like this go into 5.4 for now.
Re: [PATCH 2/4] x86/vmware: Add a header file for hypercall definitions
On Mon, Aug 19, 2019 at 12:28:05AM +0200, Thomas Hellström (VMware) wrote: > Unfortunately we can't use it, because it's unconditionally set on AMD even > if the VMware hypervisor > doesn't support it (by version or by configuration). AMD sets it because they don't support VMCALL. Nothing stops us from making that conditional depending on what the hypervisor can/supports. I'm thinking it would be even cleaner if we use those two flags: X86_FEATURE_VMMCALL X86_FEATURE_VMCALL to denote hw support for either one or the other instruction and switch accordingly. Just like KVM does. In your case, the HV would set the preferred flag in arch/x86/kernel/cpu/vmware.c - just like the others do in their respective CPU init files - and the alternatives code would switch to it when it runs. Or is there more? :) Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] ARM: dts: socfpga: update to new Denali NAND binding
On Tue, Jun 25, 2019 at 12:39 AM Dinh Nguyen wrote:
>
>
>
> On 6/21/19 6:23 AM, Masahiro Yamada wrote:
> > With commit d8e8fd0ebf8b ("mtd: rawnand: denali: decouple controller
> > and NAND chips"), the Denali NAND controller driver migrated to the
> > new controller/chip representation.
> >
> > Update DT for it.
> >
> > Signed-off-by: Masahiro Yamada
> > ---
> >
> > arch/arm/boot/dts/socfpga.dtsi| 2 +-
> > arch/arm/boot/dts/socfpga_arria10.dtsi| 2 +-
> > .../boot/dts/socfpga_arria10_socdk_nand.dts | 20 ---
> > 3 files changed, 15 insertions(+), 9 deletions(-)
> >
>
> Applied! Thanks!
>
> Dinh
You did not send this to upstream for v5.3-rc1.
Which version is this aiming for?
--
Best Regards
Masahiro Yamada
Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On Mon, Aug 19, 2019 at 09:44:25AM +0800, Zhao, Yakui wrote: > Not sure whether it can be sent in two patch sets? > The first is to add the required APIs for ACRN driver. > The second is to add the ACRN driver One patchset adding the APIs and its user(s). And make sure to refresh on https://www.kernel.org/doc/html/latest/process/submitting-patches.html before sending. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] FS: timerfd: Fix unexpected return value of timerfd_read function.
Hi tgls,
> BIOS is the more likely candidate.
We would check BIOS and update.
> We expect TSC not to go backwards. If it does it's broken and not usable as
> a clocksource for the kernel. The problem is that this is not necessarily
> easy to detect.
We used relative timer with CLOCK_REALTIME which behaves similar to
CLOCK_MONOTONIC.
We are unable to recreate this problem. So, we have instrumented
kernel code to find the possibility.
During normal run, we do see small amount (~1000 cycles) of backward
time drifts one in a while.
This is likely happens due to the race between multiple processors and
ISR routines.
We have added a hook to read_tsc() and observed backward time drift
when isr comes between reading tsc register and returning the value.
This drifting time differs based on the number of isr handled and the
time taken to service each isr.
During our testing, we observed, if the drifting time goes beyond 5000
cycles, timerfd_read() returns 0 sometimes.
We don't see any problem, if the drifting time is lesser than 5000 cycles.
> Again:
>
> You cannot fix a hardware problem by hacking around it at exactly one place
> where you can observe it. If that problem exists on your machine, then any
> other time related function is affected as well.
The system is up and running more than 6 months.
We don't see any log in dmesg to comment on whether it is a hardware issue.
Other than timerfd_read(), we see no functionality issue . Do we have
any data collected in the kernel to help us in analyzing in the
direction of BIOS or hardware?
> Are you going to submit patches against _ALL_ time{r} related syscalls to
> fix^Wpaper over this? Either against the kernel or against the man pages
>
> i.e. time went backwards since the timer was expired. That's absolutely
> unexpected behaviour and no, we are not papering over it.
Agreed. Our intention is not to put a workaround. Intention is to
write a reliable application that handles all values returned by a
system call.
At present, the application doesn't know whether 0 return value is a
bug or valid case.
> Did you ever quantify how much time goes backwards in that case?
It should be more than 5000 cycles. Found it through kernel instrumentation.
> Is the timer expiry and the timerfd_read() on the same CPU or on different
> ones?
We don't have data to answer this. However, the kernel is configured
to allow timer migration.
So, we believe, the timer expiry and timerfd_read happens on different CPUs.
> Can you please provide a full dmesg from boot to after the point where this
> failure happens?
We don't see any logs in dmesg during the occurrence of this problem.
We may not be able to share complete dmesg logs due to security reasons.
We haven't seen any time drifting related messages too.
Let us know, if you are looking for any specific log message.
Thanks,
Arul
Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc
On Sun, Aug 18, 2019 at 10:29:35AM +0200, Christoph Hellwig wrote: > The sifive_l2_cache.c is in no way related to RISC-V architecture > memory management. It is a little stub driver working around the fact > that the EDAC maintainers prefer their drivers to be structured in a > certain way That changed recently so I guess we can do the per-IP block driver after all, if people would still prefer it. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH] x86/PCI: Add missing SPDX license header.
Add the missing "SPDX-License-Identifier" license header to the arch/x86/pci/numachip.c. Use GPL-2.0 identifier derived using the comment mentioning license from the top of the file. Signed-off-by: Krzysztof Wilczynski --- arch/x86/pci/numachip.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/pci/numachip.c b/arch/x86/pci/numachip.c index 2e565e65c893..b73157e834e0 100644 --- a/arch/x86/pci/numachip.c +++ b/arch/x86/pci/numachip.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * This file is subject to the terms and conditions of the GNU General Public * License. See the file "COPYING" in the main directory of this archive -- 2.22.0
[PATCH] x86/PCI: Replace deprecated EXTRA_CFLAGS with ccflags-y.
Update arch/x86/pci/Makefile replacing the deprecated EXTRA_CFLAGS with the ccflags-y matching recommendation as per the section 3.7 "Compilation flags" of the "Linux Kernel Makefiles" (see: Documentation/kbuild/makefiles.txt). Signed-off-by: Krzysztof Wilczynski --- arch/x86/pci/Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/x86/pci/Makefile b/arch/x86/pci/Makefile index c806b57d3f22..48bcada5cabe 100644 --- a/arch/x86/pci/Makefile +++ b/arch/x86/pci/Makefile @@ -24,6 +24,4 @@ obj-y += bus_numa.o obj-$(CONFIG_AMD_NB) += amd_bus.o obj-$(CONFIG_PCI_CNB20LE_QUIRK)+= broadcom_bus.o -ifeq ($(CONFIG_PCI_DEBUG),y) -EXTRA_CFLAGS += -DDEBUG -endif +ccflags-$(CONFIG_PCI_DEBUG)+= -DDEBUG -- 2.22.0
Re: [PATCH] mtd: spi-nor: fix a memory leak bug
On 08/18/2019 08:39 PM, Wenwen Wang wrote: > In spi_nor_parse_4bait(), 'dwords' is allocated through kmalloc(). However, > it is not deallocated in the following execution if spi_nor_read_sfdp() > fails, leading to a memory leak. To fix this issue, free 'dwords' before > returning the error. Looks good. Would you add a Fixes tag? > > Signed-off-by: Wenwen Wang > --- > drivers/mtd/spi-nor/spi-nor.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > index 03cc788..a41a466 100644 > --- a/drivers/mtd/spi-nor/spi-nor.c > +++ b/drivers/mtd/spi-nor/spi-nor.c > @@ -3453,7 +3453,7 @@ static int spi_nor_parse_4bait(struct spi_nor *nor, > addr = SFDP_PARAM_HEADER_PTP(param_header); > ret = spi_nor_read_sfdp(nor, addr, len, dwords); > if (ret) > - return ret; > + goto out; > > /* Fix endianness of the 4BAIT DWORDs. */ > for (i = 0; i < SFDP_4BAIT_DWORD_MAX; i++) >
[PATCH] kbuild: add CONFIG_ASM_MODVERSIONS
Add CONFIG_ASM_MODVERSIONS to remove one if-conditional nesting from Makefile.build This also avoid $(wildcard ...) evaluation for every descending, but I did not see measurable performance improvement. Signed-off-by: Masahiro Yamada --- arch/Kconfig | 7 +++ arch/alpha/Kconfig | 1 + arch/arm64/Kconfig | 1 + arch/ia64/Kconfig | 1 + arch/m68k/Kconfig | 1 + arch/mips/Kconfig | 1 + arch/powerpc/Kconfig | 1 + arch/riscv/Kconfig | 1 + arch/s390/Kconfig | 1 + arch/sparc/Kconfig | 1 + arch/um/Kconfig| 1 + arch/x86/Kconfig | 1 + init/Kconfig | 8 scripts/Makefile.build | 7 +-- 14 files changed, 27 insertions(+), 6 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index a7b57dd42c26..7d7b1b6af851 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -289,6 +289,13 @@ config ARCH_32BIT_OFF_T still support 32-bit off_t. This option is enabled for all such architectures explicitly. +config HAVE_ASM_MODVERSIONS + bool + help + This symbol should be selected by an architecure if it provides + to support the module versioning for symbols + exported from assembly code. + config HAVE_REGS_AND_STACK_ACCESS_API bool help diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index f7b19b813a70..ef179033a7c2 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -11,6 +11,7 @@ config ALPHA select PCI_DOMAINS if PCI select PCI_SYSCALL if PCI select HAVE_AOUT + select HAVE_ASM_MODVERSIONS select HAVE_IDE select HAVE_OPROFILE select HAVE_PCSPKR_PLATFORM diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 3adcec05b1f6..cb16d4ade6aa 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -135,6 +135,7 @@ config ARM64 select HAVE_ARCH_TRANSPARENT_HUGEPAGE select HAVE_ARCH_VMAP_STACK select HAVE_ARM_SMCCC + select HAVE_ASM_MODVERSIONS select HAVE_EBPF_JIT select HAVE_C_RECORDMCOUNT select HAVE_CMPXCHG_DOUBLE diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 7468d8e50467..3dead116a6d7 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -17,6 +17,7 @@ config IA64 select FORCE_PCI if (!IA64_HP_SIM) select PCI_DOMAINS if PCI select PCI_SYSCALL if PCI + select HAVE_ASM_MODVERSIONS select HAVE_UNSTABLE_SCHED_CLOCK select HAVE_EXIT_THREAD select HAVE_IDE diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index c518d695c376..00a20fa0bdcc 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -14,6 +14,7 @@ config M68K select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE select HAVE_IDE select HAVE_AOUT if MMU + select HAVE_ASM_MODVERSIONS select HAVE_DEBUG_BUGVERBOSE select GENERIC_IRQ_SHOW select GENERIC_ATOMIC64 diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index d50fafd7bf3a..3db919b5c93a 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -44,6 +44,7 @@ config MIPS select HAVE_ARCH_SECCOMP_FILTER select HAVE_ARCH_TRACEHOOK select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES && 64BIT + select HAVE_ASM_MODVERSIONS select HAVE_EBPF_JIT if (!CPU_MICROMIPS) select HAVE_CONTEXT_TRACKING select HAVE_COPY_THREAD_TLS diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index d8dcd8820369..ec1e047200f3 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -177,6 +177,7 @@ config PPC select HAVE_ARCH_NVRAM_OPS select HAVE_ARCH_SECCOMP_FILTER select HAVE_ARCH_TRACEHOOK + select HAVE_ASM_MODVERSIONS select HAVE_C_RECORDMCOUNT select HAVE_CBPF_JITif !PPC64 select HAVE_STACKPROTECTOR if PPC64 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r13) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 59a4727ecd6c..66603f02675a 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -31,6 +31,7 @@ config RISCV select GENERIC_SMP_IDLE_THREAD select GENERIC_ATOMIC64 if !64BIT select HAVE_ARCH_AUDITSYSCALL + select HAVE_ASM_MODVERSIONS select HAVE_MEMBLOCK_NODE_MAP select HAVE_DMA_CONTIGUOUS select HAVE_FUTEX_CMPXCHG if FUTEX diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index a4ad2733eedf..c06ebe34e0f9 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -131,6 +131,7 @@ config S390 select HAVE_ARCH_TRACEHOOK select HAVE_ARCH_TRANSPARENT_HUGEPAGE select HAVE_ARCH_VMAP_STACK + select HAVE_ASM_MODVERSIONS select HAVE_EBPF_JIT if PACK_STACK && HAVE_MARCH_Z196_FEATURES select HAVE_CMPXCHG_DOUBLE select HAVE_CMPXCHG_LOCAL diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index 7926a2e11bdc..fbc1aecf0f94 100644 --- a
Re: [PATCH] test_bpf: Fix a new clang warning about xor-ing two numbers
On 8/18/19 9:34 PM, Nathan Chancellor wrote:
> r369217 in clang added a new warning about potential misuse of the xor
> operator as an exponentiation operator:
>
> ../lib/test_bpf.c:870:13: warning: result of '10 ^ 300' is 294; did you
> mean '1e300'? [-Wxor-used-as-pow]
> { { 4, 10 ^ 300 }, { 20, 10 ^ 300 } },
> ~~~^
> 1e300
> ../lib/test_bpf.c:870:13: note: replace expression with '0xA ^ 300' to
> silence this warning
> ../lib/test_bpf.c:870:31: warning: result of '10 ^ 300' is 294; did you
> mean '1e300'? [-Wxor-used-as-pow]
> { { 4, 10 ^ 300 }, { 20, 10 ^ 300 } },
> ~~~^
> 1e300
> ../lib/test_bpf.c:870:31: note: replace expression with '0xA ^ 300' to
> silence this warning
>
> The commit link for this new warning has some good logic behind wanting
> to add it but this instance appears to be a false positive. Adopt its
> suggestion to silence the warning but not change the code. According to
> the differential review link in the clang commit, GCC may eventually
> adopt this warning as well.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/643
> Link:
> https://github.com/llvm/llvm-project/commit/920890e26812f808a74c60ebc14cc636dac661c1
> Signed-off-by: Nathan Chancellor
Verified that latest trunk clang indeed has this warning, and below
change indeed fixed the warning in the correct way.
Acked-by: Yonghong Song
> ---
>
> I highly doubt that 1e300 was intented but if it was (or something else
> was), please let me know. Commit history wasn't entirely clear on why
> this expression was used over just a raw number.
>
> lib/test_bpf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/test_bpf.c b/lib/test_bpf.c
> index c41705835cba..5ef3eccee27c 100644
> --- a/lib/test_bpf.c
> +++ b/lib/test_bpf.c
> @@ -867,7 +867,7 @@ static struct bpf_test tests[] = {
> },
> CLASSIC,
> { },
> - { { 4, 10 ^ 300 }, { 20, 10 ^ 300 } },
> + { { 4, 0xA ^ 300 }, { 20, 0xA ^ 300 } },
> },
> {
> "SPILL_FILL",
>
[PATCH v3] arch : arm : add a criteria for pfn_valid
From: Zhaoyang Huang
pfn_valid can be wrong when parsing a invalid pfn whose phys address
exceeds BITS_PER_LONG as the MSB will be trimed when shifted.
The issue originally arise from bellowing call stack, which corresponding to
an access of the /proc/kpageflags from userspace with a invalid pfn parameter
and leads to kernel panic.
[46886.723249] c7 [] (stable_page_flags) from []
[46886.723264] c7 [] (kpageflags_read) from []
[46886.723280] c7 [] (proc_reg_read) from []
[46886.723290] c7 [] (__vfs_read) from []
[46886.723301] c7 [] (vfs_read) from []
[46886.723315] c7 [] (SyS_pread64) from []
(ret_fast_syscall+0x0/0x28)
Signed-off-by: Zhaoyang Huang
---
v2: use __pfn_to_phys/__phys_to_pfn instead of max_pfn as the criteria
v3: update commit message to describe the defection's context
---
arch/arm/mm/init.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index c2daabb..cc769fa 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -177,6 +177,11 @@ static void __init zone_sizes_init(unsigned long min,
unsigned long max_low,
#ifdef CONFIG_HAVE_ARCH_PFN_VALID
int pfn_valid(unsigned long pfn)
{
+ phys_addr_t addr = __pfn_to_phys(pfn);
+
+ if (__phys_to_pfn(addr) != pfn)
+ return 0;
+
return memblock_is_map_memory(__pfn_to_phys(pfn));
}
EXPORT_SYMBOL(pfn_valid);
--
1.9.1
[PATCH] fuse: redundant get_fuse_inode() calls in fuse_writepages_fill()
Currently fuse_writepages_fill() calls get_fuse_inode() few times with
the same argument.
Signed-off-by: Vasily Averin
---
fs/fuse/file.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index e076c2cf65b0..bc9b64ef7b5d 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -1874,7 +1874,7 @@ static int fuse_writepages_fill(struct page *page,
if (!data->ff) {
err = -EIO;
- data->ff = fuse_write_file_get(fc, get_fuse_inode(inode));
+ data->ff = fuse_write_file_get(fc, fi);
if (!data->ff)
goto out_unlock;
}
@@ -1919,8 +1919,6 @@ static int fuse_writepages_fill(struct page *page,
* under writeback, so we can release the page lock.
*/
if (data->req == NULL) {
- struct fuse_inode *fi = get_fuse_inode(inode);
-
err = -ENOMEM;
req = fuse_request_alloc_nofs(FUSE_REQ_INLINE_PAGES);
if (!req) {
--
2.17.1
Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On 2019年08月19日 13:25, Greg KH wrote: On Mon, Aug 19, 2019 at 09:44:25AM +0800, Zhao, Yakui wrote: On 2019年08月16日 14:39, Borislav Petkov wrote: On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: The first three patches are the changes under x86/acrn, which adds the required APIs for the driver and reports the X2APIC caps. The remaining patches add the ACRN driver module, which accepts the ioctl from user-space and then communicate with the low-level ACRN hypervisor by using hypercall. I have a problem with that: you're adding interfaces to arch/x86/ and its users go into staging. Why? Why not directly put the driver where it belongs, clean it up properly and submit it like everything else is submitted? Thanks for your reply and the concern. After taking a look at several driver examples(gma500, android), it seems that they are firstly added into drivers/staging/XXX and then moved to drivers/XXX after the driver becomes mature. So we refer to this method to upstream ACRN driver part. Those two examples are probably the worst examples to ever look at :) The code quality of those submissions was horrible, gma500 took a very long time to clean up and there are parts of the android code that are still in staging to this day. If the new driver can also be added by skipping the staging approach, we will refine it and then submit it in normal process. That is the normal process, staging should not be needed at all for any code. It is a fall-back for when the company involved has no idea of how to upstream their code, which should NOT be the case here. Thanks for your explanation. OK. We will submit it in normal process. thanks, greg k-h
Re: [PATCH] powerpc: optimise WARN_ON()
Le 18/08/2019 à 14:01, Segher Boessenkool a écrit : On Sat, Aug 17, 2019 at 09:04:42AM +, Christophe Leroy wrote: Unlike BUG_ON(x), WARN_ON(x) uses !!(x) as the trigger of the t(d/w)nei instruction instead of using directly the value of x. This leads to GCC adding unnecessary pair of addic/subfe. And it has to, it is passed as an "r" to an asm, GCC has to put the "!!" value into a register. By using (x) instead of !!(x) like BUG_ON() does, the additional instructions go away: But is it correct? What happens if you pass an int to WARN_ON, on a 64-bit kernel? On a 64-bit kernel, an int is still in a 64-bit register, so there would be no problem with tdnei, would it ? an int 0 is the same as an long 0, right ? It is on 32-bit kernel that I see a problem, if one passes a long long to WARN_ON(), the forced cast to long will just drop the upper size of it. So as of today, BUG_ON() is buggy for that. (You might want to have 64-bit generate either tw or td. But, with your __builtin_trap patch, all that will be automatic). Yes I'll discard this patch and focus on the __builtin_trap() one which should solve most issues. Christophe
Re: [PATCH 3/3] firmware: add mutex fw_lock_fallback for race condition
On Thu, Aug 15, 2019 at 05:09:45PM -0700, Scott Branden wrote: > A race condition exists between _request_firmware_prepare checking > if firmware is assigned and firmware_fallback_sysfs creating a sysfs > entry (kernel trace below). To avoid such condition add a mutex > fw_lock_fallback to protect against such condition. I am not buying this fix, and it seems sloppy. More below. > misc test_firmware: Falling back to sysfs fallback for: nope-test-firmware.bin So the fallback kicks in with the file that is not there. > sysfs: cannot create duplicate filename > '/devices/virtual/misc/test_firmware/nope-test-firmware.bin' And we have a duplicate entry, for the *device* created to allow us to create a file entry to allow us to copy the file. Your tests had a loop, so there is actually a race between two entries being created while one one failed. > CPU: 4 PID: 2059 Comm: test_firmware-3 Not tainted 5.3.0-rc4 #1 > Hardware name: Dell Inc. OptiPlex 7010/0KRC95, BIOS A13 03/25/2013 > Call Trace: > dump_stack+0x67/0x90 > sysfs_warn_dup.cold+0x17/0x24 > sysfs_create_dir_ns+0xb3/0xd0 > kobject_add_internal+0xa6/0x2a0 > kobject_add+0x7e/0xb0 Note: kobject_add(). > ? _cond_resched+0x15/0x30 > device_add+0x121/0x670 > firmware_fallback_sysfs+0x15c/0x3c9 > _request_firmware+0x432/0x5a0 > ? devres_find+0x63/0xc0 > request_firmware_into_buf+0x63/0x80 > test_fw_run_batch_request+0x96/0xe0 > kthread+0xfb/0x130 > ? reset_store+0x30/0x30 > ? kthread_park+0x80/0x80 > ret_from_fork+0x3a/0x50 > kobject_add_internal failed for nope-test-firmware.bin with -EEXIST, don't > try to register things with the same name in the same directory. So above it makes it even clearer, two kobjets with the same name. > Signed-off-by: Scott Branden > --- > drivers/base/firmware_loader/main.c | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/drivers/base/firmware_loader/main.c > b/drivers/base/firmware_loader/main.c > index bf44c79beae9..ce9896e3b782 100644 > --- a/drivers/base/firmware_loader/main.c > +++ b/drivers/base/firmware_loader/main.c > @@ -88,6 +88,7 @@ static inline struct fw_priv *to_fw_priv(struct kref *ref) > /* fw_lock could be moved to 'struct fw_sysfs' but since it is just > * guarding for corner cases a global lock should be OK */ > DEFINE_MUTEX(fw_lock); > +DEFINE_MUTEX(fw_lock_fallback); The reason I don't like this fix is that this mutex is named after ther fallback interface... but... > > static struct firmware_cache fw_cache; > > @@ -758,6 +759,17 @@ _request_firmware(const struct firmware **firmware_p, > const char *name, > if (!firmware_p) > return -EINVAL; > > + /* > + * There is a race condition between _request_firmware_prepare checking > + * if firmware is assigned and firmware_fallback_sysfs creating sysfs > + * entries with duplicate names. > + * Yet, with this lock the firmware_test locks up with cache enabled > + * and no event used during firmware test. > + * This points to some very racy code I don't know how to entirely fix. > + */ > + if (opt_flags & FW_OPT_NOCACHE) > + mutex_lock(&fw_lock_fallback); Whoa.. What does no-cache have anything to do with the fallback interface other than the fact we enable this feature for the fallback interface? We don't need to penalize non-fallback users who *also* may want to enable the no-cache feature. So, the fix should be within the boundaries of the creation / deletion of the kobject, not this nocache feature. Can you please re-evaluate this code and look for a more compartamentalized solution to the fallback code only? Luis
Re: [RFC PATCH 08/15] drivers/acrn: add VM memory management for ACRN char device
On 2019年08月16日 20:58, Dan Carpenter wrote:
On Fri, Aug 16, 2019 at 10:25:49AM +0800, Zhao Yakui wrote:
+int hugepage_map_guest(struct acrn_vm *vm, struct vm_memmap *memmap)
+{
+ struct page *page = NULL, *regions_buf_pg = NULL;
+ unsigned long len, guest_gpa, vma;
+ struct vm_memory_region *region_array;
+ struct set_regions *regions;
+ int max_size = PAGE_SIZE / sizeof(struct vm_memory_region);
+ int ret;
+
+ if (!vm || !memmap)
+ return -EINVAL;
+
+ len = memmap->len;
+ vma = memmap->vma_base;
+ guest_gpa = memmap->gpa;
+
+ /* prepare set_memory_regions info */
+ regions_buf_pg = alloc_page(GFP_KERNEL);
+ if (!regions_buf_pg)
+ return -ENOMEM;
+
+ regions = kzalloc(sizeof(*regions), GFP_KERNEL);
+ if (!regions) {
+ __free_page(regions_buf_pg);
+ return -ENOMEM;
It's better to do a goto err_free_regions_buf here. More comments
below.
+ }
+ regions->mr_num = 0;
+ regions->vmid = vm->vmid;
+ regions->regions_gpa = page_to_phys(regions_buf_pg);
+ region_array = page_to_virt(regions_buf_pg);
+
+ while (len > 0) {
+ unsigned long vm0_gpa, pagesize;
+
+ ret = get_user_pages_fast(vma, 1, 1, &page);
+ if (unlikely(ret != 1) || (!page)) {
+ pr_err("failed to pin huge page!\n");
+ ret = -ENOMEM;
+ goto err;
goto err is a red flag. It's better if error labels do one specific
named thing like:
err_regions:
kfree(regions);
err_free_regions_buf:
__free_page(regions_buf_pg);
We should unwind in the opposite/mirror order from how things were
allocated. Then we can remove the if statements in the error handling.
Thanks for the review.
Will follow your suggestion to unwind the error handling.
In this situation, say the user triggers an -EFAULT in
get_user_pages_fast() in the second iteration through the loop. That
means that "page" is the non-NULL page from the previous iteration. We
have already added it to add_guest_map(). But now we're freeing it
without removing it from the map so probably it leads to a use after
free.
The best way to write the error handling in a loop like this is to
clean up the partial iteration that has succeed (nothing here), and then
unwind all the successful iterations at the bottom of the function.
"goto unwind_loop;"
In theory we should cleanup the previous success iteration if it
encounters one error in the current iteration.
But it will be quite complex to cleanup up the previous iteration.
call the set_memory_regions for MR_DEL op.
call the remove_guest_map for the added hash item
call the put_page for returned page in get_user_pages_fast.
In fact as this driver is mainly used for embedded IOT usage, it doesn't
handle the complex cleanup when such error is encountered. Instead the
clean up is handled in free_guest_vm.
+ }
+
+ vm0_gpa = page_to_phys(page);
+ pagesize = PAGE_SIZE << compound_order(page);
+
+ ret = add_guest_map(vm, vm0_gpa, guest_gpa, pagesize);
+ if (ret < 0) {
+ pr_err("failed to add memseg for huge page!\n");
+ goto err;
So then here, it would be:
pr_err("failed to add memseg for huge page!\n");
put_page(page);
goto unwind_loop;
regards,
dan carpenter
+ }
+
+ /* fill each memory region into region_array */
+ region_array[regions->mr_num].type = MR_ADD;
+ region_array[regions->mr_num].gpa = guest_gpa;
+ region_array[regions->mr_num].vm0_gpa = vm0_gpa;
+ region_array[regions->mr_num].size = pagesize;
+ region_array[regions->mr_num].prot =
+ (MEM_TYPE_WB & MEM_TYPE_MASK) |
+ (memmap->prot & MEM_ACCESS_RIGHT_MASK);
+ regions->mr_num++;
+ if (regions->mr_num == max_size) {
+ pr_debug("region buffer full, set & renew regions!\n");
+ ret = set_memory_regions(regions);
+ if (ret < 0) {
+ pr_err("failed to set regions,ret=%d!\n", ret);
+ goto err;
+ }
+ regions->mr_num = 0;
+ }
+
+ len -= pagesize;
+ vma += pagesize;
+ guest_gpa += pagesize;
+ }
+
+ ret = set_memory_regions(regions);
+ if (ret < 0) {
+ pr_err("failed to set regions, ret=%d!\n", ret);
+ goto err;
+ }
+
+ __free_page(regions_buf_pg);
+ kfree(regions);
+
+ return 0;
+err:
+ if (regions_buf_pg)
+ __fr
Re: [PATCH v3 2/3] genirq: introduce update_irq_devid()
在 2019/8/15 下午10:58, Thomas Gleixner 写道: Ben, On Thu, 15 Aug 2019, Ben Luo wrote: Sometimes, only the dev_id field of irqaction need to be changed. E.g. KVM VM with device passthru via VFIO may switch irq injection path between KVM irqfd and userspace eventfd. These two paths share the same irq num and handler for the same vector of a device, s/irq num/interrupt number/ Changelogs are text and should not contain cryptic abbreviations. only with different dev_id referencing to different fds' contexts. So, instead of free/request irq, only update dev_id of irqaction. Please write functions like this: function_name() so they can be easily identified in the text as such. This narrows the gap for setting up new irq (and irte, if has) What does that mean: "narrows the gap" What's the gap and why is it only made smaller and not closed? Sorry for confusing. The so called 'gap' is a time window between free_irq() and request_irq(). For example, interrupt affinity setting in a VM (with VFIO passthrough device) will trigger VFIO to do free-then-setup interrupt as below. After free_irq(), the target IRTE is invalidated, an in-flight interrupt (buffering in hardware layer which cannot be synchronized in software) may cause a DMAR fault before IRTE being setup again with exactly the same value as this entry was before cleared [1566032533719954] modify_irte with index:28 irte_hi: irte_lo: 0x81465520 : modify_irte+0x0/0x160 [kernel] ... 0x810d2a89 : free_irq+0x39/0x90 [kernel] 0xa02891e0 : vfio_msi_set_vector_signal+0x80/0x280 [vfio_pci] 0x0 (inexact) [1566032533719982] DMAR FAULT begin [1566032533719971] modify_irte with index:28 irte_hi:0004a601 irte_lo:3fff00ac002d 0x81465520 : modify_irte+0x0/0x160 [kernel] ... 0x810d3d2b : request_threaded_irq+0x10b/0x1a0 [kernel] 0xa02892d6 : vfio_msi_set_vector_signal+0x176/0x280 [vfio_pci] 0x0 (inexact) By using a new function who only updates devid, this gap can actually be closed since this new function won't modify irte. When posted interrupt is in use, the target IRTE does need to be modified because this IRTE will be used by IOMMU to find the target CPU since hypervisor is bypassed. That is also the reason why still call irq_bypass_register_producer() although the token of producer has not been changed. irq_bypass_register_producer() will modify irte if posted interrupt is in use: [1566032533720007] index:28 irte_hi:00010004a601 irte_lo:adb54bc000b98001 0x81465520 : modify_irte+0x0/0x160 [kernel] ... 0xa0338386 : vfio_msi_set_vector_signal+0x1b6/0x2c0 [vfio_pci] and also gains some performance benefit. Signed-off-by: Ben Luo Reviewed-by: Liu Jiang I prefer to see the 'reviewed-by' as a reply on LKML rather than coming from some internal process. Reviewed-by: Thomas Gleixner While I reviewed the previous version, I surely did not give a 'Reviewed-by' tag. That tag means that the person did review the patch and did not find an issue. I surely found issues, right? Sorry for that，I will amend the commit messages diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 6f9b20f..a76ef61 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -2064,6 +2064,84 @@ int request_threaded_irq(unsigned int irq, irq_handler_t handler, EXPORT_SYMBOL(request_threaded_irq); /** + * update_irq_devid - update irq dev_id to a new one Can you please name this: irq_update_devid(). We try to have a consistent name space for new functions. ok, will name it to irq_update_devid() in next version. + * @irq: Interrupt line to update + * @dev_id: A cookie to find the irqaction to update + * @new_dev_id: New cookie passed to the handler function Can you please arrange these in tabular fashion: * @irq: Interrupt line to update * @dev_id:A cookie to find the irqaction to update * @new_dev_id:New cookie passed to the handler function + * Sometimes, only the cookie data need to be changed. + * Instead of free/request irq, only update dev_id here + * Not only to gain some performance benefit, but also + * reduce the risk of losing interrupt. + * + * E.g. irq affinity setting in a VM with VFIO passthru Again. Please write it out 'interrupt' and everything else. + * device is carried out in a free-then-request-irq way + * since lack of this very function. The free_irq() That does not make sense. The function is there for such a use case. So immediately when the VFIO change is merged this comment is stale and bogus. + * eventually triggers deactivation of IR domain, which + * will cleanup IRTE. There is a gap before request_irq() + * finally setup the IRTE again. In this gap, a in-flight + * irq buffering in hardware layer may trigger DMAR fault + * and be lost. Exactly this information
Re: [PATCH -next] clk: st: clkgen-pll: remove unused variable 'st_pll3200c32_407_a0'
Acked-by: Gabriel Fernandez
From: Stephen Boyd
Sent: Friday, August 16, 2019 7:36 PM
To: YueHaibing; alli...@lohutok.net; gre...@linuxfoundation.org;
mturque...@baylibre.com; Gabriel FERNANDEZ
Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; YueHaibing
Subject: Re: [PATCH -next] clk: st: clkgen-pll: remove unused variable
'st_pll3200c32_407_a0'
Quoting YueHaibing (2019-08-16 06:55:23)
> drivers/clk/st/clkgen-pll.c:64:37: warning:
> st_pll3200c32_407_a0 defined but not used [-Wunused-const-variable=]
>
> It is never used, so can be removed.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
> ---
Adding Gabriel, please ack/review.
> drivers/clk/st/clkgen-pll.c | 13 -
> 1 file changed, 13 deletions(-)
>
> diff --git a/drivers/clk/st/clkgen-pll.c b/drivers/clk/st/clkgen-pll.c
> index d8a688b..c3952f2 100644
> --- a/drivers/clk/st/clkgen-pll.c
> +++ b/drivers/clk/st/clkgen-pll.c
> @@ -61,19 +61,6 @@ static const struct clk_ops stm_pll3200c32_ops;
> static const struct clk_ops stm_pll3200c32_a9_ops;
> static const struct clk_ops stm_pll4600c28_ops;
>
> -static const struct clkgen_pll_data st_pll3200c32_407_a0 = {
> - /* 407 A0 */
> - .pdn_status = CLKGEN_FIELD(0x2a0, 0x1,8),
> - .pdn_ctrl = CLKGEN_FIELD(0x2a0, 0x1,8),
> - .locked_status = CLKGEN_FIELD(0x2a0, 0x1,24),
> - .ndiv = CLKGEN_FIELD(0x2a4, C32_NDIV_MASK, 16),
> - .idf= CLKGEN_FIELD(0x2a4, C32_IDF_MASK, 0x0),
> - .num_odfs = 1,
> - .odf= { CLKGEN_FIELD(0x2b4, C32_ODF_MASK, 0) },
> - .odf_gate = { CLKGEN_FIELD(0x2b4, 0x1,6) },
> - .ops= &stm_pll3200c32_ops,
> -};
> -
> static const struct clkgen_pll_data st_pll3200c32_cx_0 = {
> /* 407 C0 PLL0 */
> .pdn_status = CLKGEN_FIELD(0x2a0, 0x1,8),
Re: [PATCH -next] clk: st: clkgen-fsyn: remove unused variable 'st_quadfs_fs660c32_ops'
Acked-by: Gabriel Fernandez
From: Stephen Boyd
Sent: Friday, August 16, 2019 7:36 PM
To: YueHaibing; i...@metux.net; mturque...@baylibre.com; r...@kernel.org;
Gabriel FERNANDEZ
Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; YueHaibing
Subject: Re: [PATCH -next] clk: st: clkgen-fsyn: remove unused variable
'st_quadfs_fs660c32_ops'
Quoting YueHaibing (2019-08-16 06:53:41)
> drivers/clk/st/clkgen-fsyn.c:70:29: warning:
> st_quadfs_fs660c32_ops defined but not used [-Wunused-const-variable=]
>
> It is never used, so can be removed.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
> ---
Adding Gabriel, please ack/review.
> drivers/clk/st/clkgen-fsyn.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/clk/st/clkgen-fsyn.c b/drivers/clk/st/clkgen-fsyn.c
> index ca1ccdb..a156bd0 100644
> --- a/drivers/clk/st/clkgen-fsyn.c
> +++ b/drivers/clk/st/clkgen-fsyn.c
> @@ -67,7 +67,6 @@ struct clkgen_quadfs_data {
> };
>
> static const struct clk_ops st_quadfs_pll_c32_ops;
> -static const struct clk_ops st_quadfs_fs660c32_ops;
>
> static int clk_fs660c32_dig_get_params(unsigned long input,
> unsigned long output, struct stm_fs *fs);
Re: add a not device managed memremap_pages v3
On Sun, Aug 18, 2019 at 11:05:53AM +0200, Christoph Hellwig wrote: > Hi Dan and Jason, > > Bharata has been working on secure page management for kvmppc guests, > and one I thing I noticed is that he had to fake up a struct device > just so that it could be passed to the devm_memremap_pages > instrastructure for device private memory. > > This series adds non-device managed versions of the > devm_request_free_mem_region and devm_memremap_pages functions for > his use case. Tested kvmppc ultravisor patchset with migrate_vma changes and this patchset. (Had to manually patch mm/memremap.c instead of kernel/memremap.c though) For the series, Tested-by: Bharata B Rao
Re: [RFC PATCH 04/15] drivers/acrn: add the basic framework of acrn char device driver
On Mon, Aug 19, 2019 at 12:02:33PM +0800, Zhao, Yakui wrote: > > > On 2019年08月16日 15:05, Greg KH wrote: > > On Fri, Aug 16, 2019 at 10:25:45AM +0800, Zhao Yakui wrote: > > > ACRN hypervisor service module is the important middle layer that allows > > > the Linux kernel to communicate with the ACRN hypervisor. It includes > > > the management of virtualized CPU/memory/device/interrupt for other ACRN > > > guest. The user-space applications can use the provided ACRN ioctls to > > > interact with ACRN hypervisor through different hypercalls. > > > > > > Add one basic framework firstly and the following patches will > > > add the corresponding implementations, which includes the management of > > > virtualized CPU/memory/interrupt and the emulation of MMIO/IO/PCI access. > > > The device file of /dev/acrn_hsm can be accessed in user-space to > > > communicate with ACRN module. > > > > > > Co-developed-by: Jason Chen CJ > > > Signed-off-by: Jason Chen CJ > > > Co-developed-by: Jack Ren > > > Signed-off-by: Jack Ren > > > Co-developed-by: Mingqiang Chi > > > Signed-off-by: Mingqiang Chi > > > Co-developed-by: Liu Shuo > > > Signed-off-by: Liu Shuo > > > Signed-off-by: Zhao Yakui > > > --- > > > drivers/staging/Kconfig | 2 + > > > > Also, your subject line for all of these patches are wrong, it is not > > drivers/acrn :( > > Thanks for the pointing out it. > > It will be fixed. > > > > > And you forgot to cc: the staging maintainer :( > > Do you mean that the maintainer of staging subsystem is also added in the > patch commit log? Did you not run scripts/get_maintainer.pl on your patches to determine who to send patches to? Always do that. > > As I have said with NUMEROUS Intel patches in the past, I now refuse to > > take patches from you all WITHOUT having it signed-off-by someone from > > the Intel "OTC" group (or whatever the Intel Linux group is called these > > days). They are a resource you can not ignore, and if you do, you just > > end up making the rest of the kernel community grumpy by having us do > > their work for them :( > > > > Please work with them. > > OK. I will work with some peoples in OTC group to prepare the better ACRN > driver. Thank you. greg k-h
Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On Mon, Aug 19, 2019 at 10:39:32AM +0800, Zhao, Yakui wrote: > > > On 2019年08月16日 15:03, Greg KH wrote: > > On Fri, Aug 16, 2019 at 08:39:25AM +0200, Borislav Petkov wrote: > > > On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: > > > > The first three patches are the changes under x86/acrn, which adds the > > > > required APIs for the driver and reports the X2APIC caps. > > > > The remaining patches add the ACRN driver module, which accepts the > > > > ioctl > > > > from user-space and then communicate with the low-level ACRN hypervisor > > > > by using hypercall. > > > > > > I have a problem with that: you're adding interfaces to arch/x86/ and > > > its users go into staging. Why? Why not directly put the driver where > > > it belongs, clean it up properly and submit it like everything else is > > > submitted? > > > > > > I don't want to have stuff in arch/x86/ which is used solely by code in > > > staging and the latter is lingering there indefinitely because no one is > > > cleaning it up... > > > > I agree, stuff in drivers/staging/ must be self-contained, with no > > changes outside of the code's subdirectory needed in order for it to > > work. That way it is trivial for us to delete it when it never gets > > cleaned up :) > > Thanks for pointing out the rule of drivers/staging. > The acrn staging driver is one self-contained driver. But it has some > dependency on arch/x86/acrn and need to call the APIs in arch/x86/acrn. Then it should not be in drivers/staging/ Please work to get this accepted "normally". thanks, greg k-h
Re: [PATCH 2/3] selftest: firmware: Add request_firmware_into_buf tests
On Thu, Aug 15, 2019 at 05:09:44PM -0700, Scott Branden wrote: > Add tests cases for checking request_firmware_into_buf api. > API was introduced into kernel with no testing present previously. > > Signed-off-by: Scott Branden Acked-by: Luis Chamberlain Luis
Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On Mon, Aug 19, 2019 at 09:44:25AM +0800, Zhao, Yakui wrote: > > > On 2019年08月16日 14:39, Borislav Petkov wrote: > > On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: > > > The first three patches are the changes under x86/acrn, which adds the > > > required APIs for the driver and reports the X2APIC caps. > > > The remaining patches add the ACRN driver module, which accepts the ioctl > > > from user-space and then communicate with the low-level ACRN hypervisor > > > by using hypercall. > > > > I have a problem with that: you're adding interfaces to arch/x86/ and > > its users go into staging. Why? Why not directly put the driver where > > it belongs, clean it up properly and submit it like everything else is > > submitted? > > Thanks for your reply and the concern. > > After taking a look at several driver examples(gma500, android), it seems > that they are firstly added into drivers/staging/XXX and then moved to > drivers/XXX after the driver becomes mature. > So we refer to this method to upstream ACRN driver part. Those two examples are probably the worst examples to ever look at :) The code quality of those submissions was horrible, gma500 took a very long time to clean up and there are parts of the android code that are still in staging to this day. > If the new driver can also be added by skipping the staging approach, > we will refine it and then submit it in normal process. That is the normal process, staging should not be needed at all for any code. It is a fall-back for when the company involved has no idea of how to upstream their code, which should NOT be the case here. thanks, greg k-h
Re: [PATCH 1/3] test_firmware: add support for request_firmware_into_buf
On Thu, Aug 15, 2019 at 05:09:43PM -0700, Scott Branden wrote: > Add test config into_buf to allow request_firmware_into_buf to be > called instead of request_firmware/request_firmware_direct. The number > of parameters differ calling request_firmware_into_buf and support > has not been added to test such api in test_firmware until now. > > Signed-off-by: Scott Branden Thanks for the patch! Acked-by: Luis Chamberlain Luis
[PATCH v2] RISC-V: Fix FIXMAP area corruption on RV32 systems
Currently, various virtual memory areas of Linux RISC-V are organized
in increasing order of their virtual addresses is as follows:
1. User space area (This is lowest area and starts at 0x0)
2. FIXMAP area
3. VMALLOC area
4. Kernel area (This is highest area and starts at PAGE_OFFSET)
The maximum size of user space aread is represented by TASK_SIZE.
On RV32 systems, TASK_SIZE is defined as VMALLOC_START which causes the
user space area to overlap the FIXMAP area. This allows user space apps
to potentially corrupt the FIXMAP area and kernel OF APIs will crash
whenever they access corrupted FDT in the FIXMAP area.
On RV64 systems, TASK_SIZE is set to fixed 256GB and no other areas
happen to overlap so we don't see any FIXMAP area corruptions.
This patch fixes FIXMAP area corruption on RV32 systems by setting
TASK_SIZE to FIXADDR_START. We also move FIXADDR_TOP, FIXADDR_SIZE,
and FIXADDR_START defines to asm/pgtable.h so that we can avoid cyclic
header includes.
Signed-off-by: Anup Patel
Tested-by: Alistair Francis
Reviewed-by: Christoph Hellwig
---
Changes since v1:
- Drop braces from "#define FIXADDR_TOP"
---
arch/riscv/include/asm/fixmap.h | 4
arch/riscv/include/asm/pgtable.h | 12 ++--
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
index 9c66033c3a54..161f28d04a07 100644
--- a/arch/riscv/include/asm/fixmap.h
+++ b/arch/riscv/include/asm/fixmap.h
@@ -30,10 +30,6 @@ enum fixed_addresses {
__end_of_fixed_addresses
};
-#define FIXADDR_SIZE (__end_of_fixed_addresses * PAGE_SIZE)
-#define FIXADDR_TOP(VMALLOC_START)
-#define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE)
-
#define FIXMAP_PAGE_IO PAGE_KERNEL
#define __early_set_fixmap __set_fixmap
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index a364aba23d55..c24a083b3e12 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -420,14 +420,22 @@ static inline void pgtable_cache_init(void)
#define VMALLOC_END (PAGE_OFFSET - 1)
#define VMALLOC_START(PAGE_OFFSET - VMALLOC_SIZE)
+#define FIXADDR_TOP VMALLOC_START
+#ifdef CONFIG_64BIT
+#define FIXADDR_SIZE PMD_SIZE
+#else
+#define FIXADDR_SIZE PGDIR_SIZE
+#endif
+#define FIXADDR_START(FIXADDR_TOP - FIXADDR_SIZE)
+
/*
- * Task size is 0x40 for RV64 or 0xb80 for RV32.
+ * Task size is 0x40 for RV64 or 0x9fc0 for RV32.
* Note that PGDIR_SIZE must evenly divide TASK_SIZE.
*/
#ifdef CONFIG_64BIT
#define TASK_SIZE (PGDIR_SIZE * PTRS_PER_PGD / 2)
#else
-#define TASK_SIZE VMALLOC_START
+#define TASK_SIZE FIXADDR_START
#endif
#include
--
2.17.1
Re: [RFC PATCH 10/15] drivers/acrn: add interrupt injection support
On 2019年08月16日 21:12, Dan Carpenter wrote:
On Fri, Aug 16, 2019 at 10:25:51AM +0800, Zhao Yakui wrote:
+ case IC_VM_INTR_MONITOR: {
+ struct page *page;
+
+ ret = get_user_pages_fast(ioctl_param, 1, 1, &page);
+ if (unlikely(ret != 1) || !page) {
Not required.
Do you mean that it is enough to check the condition of "ret != 1"?
OK. It will be removed.
+ pr_err("acrn-dev: failed to pin intr hdr buffer!\n");
+ return -ENOMEM;
+ }
+
+ ret = hcall_vm_intr_monitor(vm->vmid, page_to_phys(page));
+ if (ret < 0) {
+ pr_err("acrn-dev: monitor intr data err=%ld\n", ret);
+ return -EFAULT;
+ }
+ break;
+ }
+
regards,
dan carpenter
[PATCH] Kconfig: Fix the reference to the IDT77105 Phy driver in the description of ATM_NICSTAR_USE_IDT77105
This should be IDT77105, not IDT77015. Signed-off-by: Christophe JAILLET --- drivers/atm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/atm/Kconfig b/drivers/atm/Kconfig index 2e2efa577437..8c37294f1d1e 100644 --- a/drivers/atm/Kconfig +++ b/drivers/atm/Kconfig @@ -200,7 +200,7 @@ config ATM_NICSTAR_USE_SUNI make the card work). config ATM_NICSTAR_USE_IDT77105 - bool "Use IDT77015 PHY driver (25Mbps)" + bool "Use IDT77105 PHY driver (25Mbps)" depends on ATM_NICSTAR help Support for the PHYsical layer chip in ForeRunner LE25 cards. In -- 2.20.1
Re: [RFC PATCH 11/15] drivers/acrn: add the support of handling emulated ioreq
On 2019年08月16日 21:39, Dan Carpenter wrote:
On Fri, Aug 16, 2019 at 10:25:52AM +0800, Zhao Yakui wrote:
+int acrn_ioreq_create_client(unsigned short vmid,
+ioreq_handler_t handler,
+void *client_priv,
+char *name)
+{
+ struct acrn_vm *vm;
+ struct ioreq_client *client;
+ int client_id;
+
+ might_sleep();
+
+ vm = find_get_vm(vmid);
+ if (unlikely(!vm || !vm->req_buf)) {
+ pr_err("acrn-ioreq: failed to find vm from vmid %d\n", vmid);
+ put_vm(vm);
+ return -EINVAL;
+ }
+
+ client_id = alloc_client();
+ if (unlikely(client_id < 0)) {
+ pr_err("acrn-ioreq: vm[%d] failed to alloc ioreq client\n",
+ vmid);
+ put_vm(vm);
+ return -EINVAL;
+ }
+
+ client = acrn_ioreq_get_client(client_id);
+ if (unlikely(!client)) {
+ pr_err("failed to get the client.\n");
+ put_vm(vm);
+ return -EINVAL;
Do we need to clean up the alloc_client() allocation?
Thanks for the review.
The function of acrn_iocreq_get_client is used to return the client for
the given client_id. (The ref_count of client is also added). If it is
NULL, it indicates that it is already released in another place.
In the function of acrn_ioreq_create_client, we don't need to clean up
the alloc_client as it always exists in course of creating_client.
regards,
dan carpenter
+ }
+
+ if (handler) {
+ client->handler = handler;
+ client->acrn_create_kthread = true;
+ }
+
+ client->ref_vm = vm;
+ client->vmid = vmid;
+ client->client_priv = client_priv;
+ if (name)
+ strncpy(client->name, name, sizeof(client->name) - 1);
+ rwlock_init(&client->range_lock);
+ INIT_LIST_HEAD(&client->range_list);
+ init_waitqueue_head(&client->wq);
+
+ /* When it is added to ioreq_client_list, the refcnt is increased */
+ spin_lock_bh(&vm->ioreq_client_lock);
+ list_add(&client->list, &vm->ioreq_client_list);
+ spin_unlock_bh(&vm->ioreq_client_lock);
+
+ pr_info("acrn-ioreq: created ioreq client %d\n", client_id);
+
+ return client_id;
+}
Re: [PATCH v2] arch : arm : add a criteria for pfn_valid
On Mon, Aug 19, 2019 at 09:36:09AM +0800, Zhaoyang Huang wrote:
> From: Zhaoyang Huang
>
> pfn_valid can be wrong when parsing a invalid pfn whose phys address
> exceeds BITS_PER_LONG as the MSB will be trimed when shifted.
I'd appreciate to see in the changelog that this could be triggered from
userspace via /proc/kpageflags
Otherwise:
Reviewed-by: Mike Rapoport
> Signed-off-by: Zhaoyang Huang
> ---
> arch/arm/mm/init.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index c2daabb..cc769fa 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -177,6 +177,11 @@ static void __init zone_sizes_init(unsigned long min,
> unsigned long max_low,
> #ifdef CONFIG_HAVE_ARCH_PFN_VALID
> int pfn_valid(unsigned long pfn)
> {
> + phys_addr_t addr = __pfn_to_phys(pfn);
> +
> + if (__phys_to_pfn(addr) != pfn)
> + return 0;
> +
> return memblock_is_map_memory(__pfn_to_phys(pfn));
> }
> EXPORT_SYMBOL(pfn_valid);
> --
> 1.9.1
>
--
Sincerely yours,
Mike.
linux-next: manual merge of the tip tree with the ia64 tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/ia64/include/asm/sn/sn_sal.h
between commit:
cf07cb1ff4ea ("ia64: remove support for the SGI SN2 platform")
from the ia64 tree and commit:
5828efb95bc4 ("efi: ia64: move SAL systab handling out of generic EFI code")
from the tip tree.
I fixed it up (the former removed the code updated by the latter) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpBiD6V7COLo.pgp
Description: OpenPGP digital signature
Re: [PATCH] RISC-V: Fix FIXMAP area corruption on RV32 systems
On Sun, Aug 18, 2019 at 11:49 PM Christoph Hellwig wrote: > > > +#define FIXADDR_TOP (VMALLOC_START) > > Nit: no need for the braces, the definitions below don't use it > either. Sure, I will update and send v2 soon. > > > +#ifdef CONFIG_64BIT > > +#define FIXADDR_SIZE PMD_SIZE > > +#else > > +#define FIXADDR_SIZE PGDIR_SIZE > > +#endif > > +#define FIXADDR_START(FIXADDR_TOP - FIXADDR_SIZE) > > + > > /* > > - * Task size is 0x40 for RV64 or 0xb80 for RV32. > > + * Task size is 0x40 for RV64 or 0x9fc0 for RV32. > > * Note that PGDIR_SIZE must evenly divide TASK_SIZE. > > */ > > #ifdef CONFIG_64BIT > > #define TASK_SIZE (PGDIR_SIZE * PTRS_PER_PGD / 2) > > #else > > -#define TASK_SIZE VMALLOC_START > > +#define TASK_SIZE FIXADDR_START > > #endif > > Mentioning the addresses is a little weird. IMHO this would be > a much nicer place to explain the high-level memory layout, including > maybe a little ASCII art. Also we could have one #ifdef CONFIG_64BIT > for both related values. Last but not least instead of saying that > something should be dividable it would be nice to have a BUILD_BUG_ON > to enforce it. > > Either way we are late in the cycle, so I guess this is ok for now: > > Reviewed-by: Christoph Hellwig > > But I'd love to see this area improved a little further as it is full > of mine fields. I agree with you. We also have Sparsemem and KASAN patches which touch virtual memory layout so it's important to have virtual memory layout documented clearly. I can add the required documentation as separate patch. I think the best place to add ASCII art would be asm/pgtable.h where all virtual memory related defines are placed. Suggestions?? Regards, Anup
[PATCH] Kconfig: Fix the reference to the RFD77402 ToF sensor in the 'help' section
This should be RFD77402, not RFD77420.
Signed-off-by: Christophe JAILLET
---
Not sure that the Kconfig prefix is correct. I have choosen it because of
commit 21cf20a84a ("Kconfig: change configuration of srf04 ultrasonic iio
sensor")
---
drivers/iio/proximity/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
index 6b5cce6f1a7b..d53601447da4 100644
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -62,7 +62,7 @@ config RFD77402
tristate "RFD77402 ToF sensor"
depends on I2C
help
- Say Y to build a driver for the RFD77420 Time-of-Flight (distance)
+ Say Y to build a driver for the RFD77402 Time-of-Flight (distance)
sensor module with I2C interface.
To compile this driver as a module, choose M here: the
--
2.20.1
Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc
On Sun, Aug 18, 2019 at 2:01 PM Christoph Hellwig wrote:
>
> The sifive_l2_cache.c is in no way related to RISC-V architecture
> memory management. It is a little stub driver working around the fact
> that the EDAC maintainers prefer their drivers to be structured in a
> certain way that doesn't fit the SiFive SOCs.
>
> Move the file to drivers/soc and add a Kconfig option for it, as well
> as the whole drivers/soc boilerplate for CONFIG_SOC_SIFIVE.
>
> Fixes: a967a289f169 ("RISC-V: sifive_l2_cache: Add L2 cache controller driver
> for SiFive SoCs")
> Signed-off-by: Christoph Hellwig
> ---
> arch/riscv/mm/Makefile | 1 -
> drivers/edac/Kconfig | 2 +-
> drivers/soc/Kconfig| 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/sifive/Kconfig | 10 ++
> drivers/soc/sifive/Makefile| 4
> .../riscv/mm => drivers/soc/sifive}/sifive_l2_cache.c | 0
> 7 files changed, 17 insertions(+), 2 deletions(-)
> create mode 100644 drivers/soc/sifive/Kconfig
> create mode 100644 drivers/soc/sifive/Makefile
> rename {arch/riscv/mm => drivers/soc/sifive}/sifive_l2_cache.c (100%)
>
> diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
> index 74055e1d6f21..d2101d0741d4 100644
> --- a/arch/riscv/mm/Makefile
> +++ b/arch/riscv/mm/Makefile
> @@ -11,6 +11,5 @@ obj-y += extable.o
> obj-y += ioremap.o
> obj-y += cacheflush.o
> obj-y += context.o
> -obj-y += sifive_l2_cache.o
>
> obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index 200c04ce5b0e..9241b3e7a050 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -462,7 +462,7 @@ config EDAC_ALTERA_SDMMC
>
> config EDAC_SIFIVE
> bool "Sifive platform EDAC driver"
> - depends on EDAC=y && RISCV
> + depends on EDAC=y && SIFIVE_L2
> help
> Support for error detection and correction on the SiFive SoCs.
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 833e04a7835c..1778f8c62861 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -14,6 +14,7 @@ source "drivers/soc/qcom/Kconfig"
> source "drivers/soc/renesas/Kconfig"
> source "drivers/soc/rockchip/Kconfig"
> source "drivers/soc/samsung/Kconfig"
> +source "drivers/soc/sifive/Kconfig"
> source "drivers/soc/sunxi/Kconfig"
> source "drivers/soc/tegra/Kconfig"
> source "drivers/soc/ti/Kconfig"
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 2ec355003524..8b49d782a1ab 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -20,6 +20,7 @@ obj-y += qcom/
> obj-y += renesas/
> obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
> obj-$(CONFIG_SOC_SAMSUNG) += samsung/
> +obj-$(CONFIG_SOC_SIFIVE) += sifive/
> obj-y += sunxi/
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-y += ti/
> diff --git a/drivers/soc/sifive/Kconfig b/drivers/soc/sifive/Kconfig
> new file mode 100644
> index ..9ffb2e8a48cd
> --- /dev/null
> +++ b/drivers/soc/sifive/Kconfig
> @@ -0,0 +1,10 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +if SOC_SIFIVE
> +
> +config SIFIVE_L2
> + tristate "Sifive L2 Cache controller"
> + help
> + Support for the L2 cache controller on SiFive platforms.
> +
> +endif
> diff --git a/drivers/soc/sifive/Makefile b/drivers/soc/sifive/Makefile
> new file mode 100644
> index ..9b4a85558347
> --- /dev/null
> +++ b/drivers/soc/sifive/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_SIFIVE_L2)+= sifive_l2_cache.o
> +
> diff --git a/arch/riscv/mm/sifive_l2_cache.c
> b/drivers/soc/sifive/sifive_l2_cache.c
> similarity index 100%
> rename from arch/riscv/mm/sifive_l2_cache.c
> rename to drivers/soc/sifive/sifive_l2_cache.c
> --
> 2.20.1
>
LGTM.
Reviewed-by: Anup Patel
Regards,
Anup
[PATCH] test_bpf: Fix a new clang warning about xor-ing two numbers
r369217 in clang added a new warning about potential misuse of the xor
operator as an exponentiation operator:
../lib/test_bpf.c:870:13: warning: result of '10 ^ 300' is 294; did you
mean '1e300'? [-Wxor-used-as-pow]
{ { 4, 10 ^ 300 }, { 20, 10 ^ 300 } },
~~~^
1e300
../lib/test_bpf.c:870:13: note: replace expression with '0xA ^ 300' to
silence this warning
../lib/test_bpf.c:870:31: warning: result of '10 ^ 300' is 294; did you
mean '1e300'? [-Wxor-used-as-pow]
{ { 4, 10 ^ 300 }, { 20, 10 ^ 300 } },
~~~^
1e300
../lib/test_bpf.c:870:31: note: replace expression with '0xA ^ 300' to
silence this warning
The commit link for this new warning has some good logic behind wanting
to add it but this instance appears to be a false positive. Adopt its
suggestion to silence the warning but not change the code. According to
the differential review link in the clang commit, GCC may eventually
adopt this warning as well.
Link: https://github.com/ClangBuiltLinux/linux/issues/643
Link:
https://github.com/llvm/llvm-project/commit/920890e26812f808a74c60ebc14cc636dac661c1
Signed-off-by: Nathan Chancellor
---
I highly doubt that 1e300 was intented but if it was (or something else
was), please let me know. Commit history wasn't entirely clear on why
this expression was used over just a raw number.
lib/test_bpf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index c41705835cba..5ef3eccee27c 100644
--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -867,7 +867,7 @@ static struct bpf_test tests[] = {
},
CLASSIC,
{ },
- { { 4, 10 ^ 300 }, { 20, 10 ^ 300 } },
+ { { 4, 0xA ^ 300 }, { 20, 0xA ^ 300 } },
},
{
"SPILL_FILL",
--
2.23.0
Re: [PATCH] libfdt: reduce the number of headers included from libfdt_env.h
On Thu, Aug 1, 2019 at 11:30 AM Masahiro Yamada
wrote:
>
> On Tue, Jun 18, 2019 at 1:21 AM Masahiro Yamada
> wrote:
> >
> > Currently, libfdt_env.h includes just for INT_MAX.
> >
> > pulls in a lots of broat.
> >
> > Thanks to commit 54d50897d544 ("linux/kernel.h: split *_MAX and *_MIN
> > macros into "), can be replaced with
> > .
> >
> > This saves including dozens of headers.
> >
> > Signed-off-by: Masahiro Yamada
> > ---
>
> ping?
ping x2.
>
>
> > include/linux/libfdt_env.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/libfdt_env.h b/include/linux/libfdt_env.h
> > index edb0f0c30904..2231eb855e8f 100644
> > --- a/include/linux/libfdt_env.h
> > +++ b/include/linux/libfdt_env.h
> > @@ -2,7 +2,7 @@
> > #ifndef LIBFDT_ENV_H
> > #define LIBFDT_ENV_H
> >
> > -#include /* For INT_MAX */
> > +#include /* For INT_MAX */
> > #include
> >
> > #include
> > --
> > 2.17.1
> >
>
>
> --
> Best Regards
> Masahiro Yamada
--
Best Regards
Masahiro Yamada
Re: next/master boot: 254 boots: 16 failed, 231 passed with 4 offline, 1 untried/unknown, 2 conflicts (next-20190726)
On Fri 26 Jul 06:48 PDT 2019, Mark Brown wrote: > On Fri, Jul 26, 2019 at 05:18:01AM -0700, kernelci.org bot wrote: > > The past few versions of -next failed to boot on apq8096-db820c: > > > defconfig: > > gcc-8: > > apq8096-db820c: 1 failed lab > > with an RCU stall towards the end of boot: > > 00:03:40.521336 [ 18.487538] qcom_q6v5_pas adsp-pil: adsp-pil supply px > not found, using dummy regulator > 00:04:01.523104 [ 39.499613] rcu: INFO: rcu_preempt detected stalls on > CPUs/tasks: > 00:04:01.533371 [ 39.499657] rcu: 2-...!: (0 ticks this GP) > idle=9ca/1/0x4000 softirq=1450/1450 fqs=50 > 00:04:01.537544 [ 39.504689] (detected by 0, t=5252 jiffies, g=2425, > q=619) > 00:04:01.541727 [ 39.513539] Task dump for CPU 2: > 00:04:01.547929 [ 39.519096] seq R running task0 > 199198 0x > > Full details and logs at: > > https://kernelci.org/boot/id/5d3aa7ea59b5142ba868890f/ > > The last version that worked was from the 15th and there seem to be > similar issues in mainline since -rc1. As you might have seen this problem has come and gone on the apq8096-db820c and I've finally managed to narrow it down a little bit. The problem first appears on next-20190701, with the introduction of CONFIG_RANDOMIZE_BASE in the defconfig, but after further efforts I've concluded that disabling kpti removes or hides the problem. With kpti=no on the command line I've now successfully booted the db820c 100+ times without problems (a clear improvement from the 75% failure rate with kpti=yes). Unfortunately I'm not yet certain why this is causing issues and I'm also seeing the same rcu stall on SDA845 under certain (erroneous?) conditions (where I don't expect them). Regards, Bjorn
[PATCH] net/ncsi: add control packet payload to NC-SI commands from netlink
This patch adds support for NCSI_CMD_SEND_CMD netlink command to load packet
data payload (up to 16 bytes) to standard NC-SI commands.
Packet data will be loaded from NCSI_ATTR_DATA attribute similar to NC-SI OEM
commands
Signed-off-by: Ben Wei
---
net/ncsi/internal.h | 7 ---
net/ncsi/ncsi-netlink.c | 9 +
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/net/ncsi/internal.h b/net/ncsi/internal.h index
0b3f0673e1a2..4ff442faf5dc 100644
--- a/net/ncsi/internal.h
+++ b/net/ncsi/internal.h
@@ -328,9 +328,10 @@ struct ncsi_cmd_arg {
unsigned short payload; /* Command packet payload length */
unsigned int req_flags; /* NCSI request properties */
union {
- unsigned char bytes[16]; /* Command packet specific data */
- unsigned short words[8];
- unsigned int dwords[4];
+#define NCSI_MAX_DATA_BYTES 16
+ unsigned char bytes[NCSI_MAX_DATA_BYTES]; /* Command packet
specific data */
+ unsigned short words[NCSI_MAX_DATA_BYTES / sizeof(unsigned
short)];
+ unsigned int dwords[NCSI_MAX_DATA_BYTES / sizeof(unsigned
int)];
};
unsigned char*data; /* NCSI OEM data */
struct genl_info *info; /* Netlink information */
diff --git a/net/ncsi/ncsi-netlink.c b/net/ncsi/ncsi-netlink.c index
8b386d766e7d..7d2a43f30eb1 100644
--- a/net/ncsi/ncsi-netlink.c
+++ b/net/ncsi/ncsi-netlink.c
@@ -459,6 +459,15 @@ static int ncsi_send_cmd_nl(struct sk_buff *msg, struct
genl_info *info)
nca.payload = ntohs(hdr->length);
nca.data = data + sizeof(*hdr);
+ if (nca.payload <= NCSI_MAX_DATA_BYTES) {
+ memcpy(nca.bytes, nca.data, nca.payload);
+ } else {
+ netdev_info(ndp->ndev.dev, "NCSI:payload size %u exceeds max
%u\n",
+ nca.payload, NCSI_MAX_DATA_BYTES);
+ ret = -EINVAL;
+ goto out_netlink;
+ }
+
ret = ncsi_xmit_cmd(&nca);
out_netlink:
if (ret != 0) {
--
2.17.1
Re: [PATCH] powerpc: remove meaningless KBUILD_ARFLAGS addition
Hi, On Fri, Jul 19, 2019 at 12:43 PM Michael Ellerman wrote: > > Segher Boessenkool writes: > > On Thu, Jul 18, 2019 at 11:19:58AM +0900, Masahiro Yamada wrote: > >> On Thu, Jul 18, 2019 at 1:46 AM Segher Boessenkool > >> wrote: > >> Kbuild always uses thin archives as far as vmlinux is concerned. > >> > >> But, there are some other call-sites. > >> > >> masahiro@pug:~/ref/linux$ git grep '$(AR)' -- :^Documentation :^tools > >> arch/powerpc/boot/Makefile:BOOTAR := $(AR) > >> arch/unicore32/lib/Makefile:$(Q)$(AR) p $(GNU_LIBC_A) $(notdir $@) > $@ > >> arch/unicore32/lib/Makefile:$(Q)$(AR) p $(GNU_LIBGCC_A) $(notdir $@) > > >> $@ > >> lib/raid6/test/Makefile: $(AR) cq $@ $^ > >> scripts/Kbuild.include:ar-option = $(call try-run, $(AR) rc$(1) > >> "$$TMP",$(1),$(2)) > >> scripts/Makefile.build: cmd_ar_builtin = rm -f $@; $(AR) > >> rcSTP$(KBUILD_ARFLAGS) $@ $(real-prereqs) > >> scripts/Makefile.lib: cmd_ar = rm -f $@; $(AR) > >> rcsTP$(KBUILD_ARFLAGS) $@ $(real-prereqs) > >> > >> Probably, you are interested in arch/powerpc/boot/Makefile. > > > > That one seems fine actually. The raid6 one I don't know. > > > > > > My original commit message was > > > > Without this, some versions of GNU ar fail to create > > an archive index if the object files it is packing > > together are of a different object format than ar's > > default format (for example, binutils compiled to > > default to 64-bit, with 32-bit objects). > > > > but I cannot reproduce the problem anymore. Shortly after my patch the > > thin archive code happened to binutils, and that overhauled some other > > things, which might have fixed it already? > > > >> > Yes, I know. This isn't about built-in.[oa], it is about *other* > >> > archives we at least *used to* create. If we *know* we do not anymore, > >> > then this workaround can of course be removed (and good riddance). > >> > >> If it is not about built-in.[oa], > >> which archive are you talking about? > >> > >> Can you pin-point the one? > > > > No, not anymore. Lost in the mists of time, I guess? I think we'll > > just have to file it as "it seems to work fine now". > > Yeah I think so. If someone finds a case it breaks we can fix it then. > > > Thank you (and everyone else) for the time looking at this! > > Likewise. > > cheers So, we agreed to apply this patch, right? Please let me know if there is some improvement that should be get done. -- Best Regards Masahiro Yamada
Suspend/Resume Broken on AM43/AM33 Platforms
Hi Stephen, commit 03a3bb7ae63150230c5de645dc95e673ebf17e1a Author: Stephen Boyd Date: Mon Aug 5 16:32:41 2019 -0700 hwrng: core - Freeze khwrng thread during suspend Commit seems to be breaking suspend/resume on TI AM43/AM33 platforms. rtcwake: wakeup from "mem" using /dev/rtc0 at Sun Nov 18 02:12:12 2018 [ 54.033833] PM: suspend entry (deep) [ 54.037741] Filesystems sync: 0.000 seconds [ 54.062730] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 54.071313] OOM killer disabled. [ 54.074572] Freezing remaining freezable tasks ... [ 74.083121] Freezing of tasks failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0): [ 74.092257] hwrng R running task0 289 2 0x0020 [ 74.099511] [] (__schedule) from [] (schedule+0x3c/0xc0) [ 74.106720] [] (schedule) from [] (add_hwgenerator_randomness+0xb0/0x100) [ 74.115358] [] (add_hwgenerator_randomness) from [] (hwrng_fillfn+0xc0/0x14c [rng_core]) [ 74.125356] [] (hwrng_fillfn [rng_core]) from [] (kthread+0x134/0x148) [ 74.133764] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 74.141093] Exception stack(0xec611fb0 to 0xec611ff8) [ 74.146239] 1fa0: [ 74.154478] 1fc0: [ 74.162764] 1fe0: 0013 [ 74.169499] Restarting kernel threads ... done. [ 74.175628] OOM killer enabled. [ 74.178796] Restarting tasks ... done. [ 74.226769] PM: suspend exit rtcwake: write error 1 One task refusing to freeze is the final error i am seeing. - Keerthy
Re: [PATCH] staging: media: hantro: Remove call to memset after dma_alloc_coherent
On Mon, Aug 19, 2019 at 1:17 PM Tomasz Figa wrote: > > Hi Hans, > > On Thu, Jul 25, 2019 at 8:50 PM Boris Brezillon > wrote: > > > > On Thu, 25 Jul 2019 08:36:02 +0530 > > Hariprasad Kelam wrote: > > > > > fix below issue reported by coccicheck > > > /drivers/staging/media/hantro/hantro_vp8.c:149:16-34: WARNING: > > > dma_alloc_coherent use in aux_buf -> cpu already zeroes out memory, so > > > memset is not needed > > > > > > Signed-off-by: Hariprasad Kelam > > > > Reviewed-by: Boris Brezillon > > > > > --- > > > drivers/staging/media/hantro/hantro_vp8.c | 2 -- > > > 1 file changed, 2 deletions(-) > > > > > > diff --git a/drivers/staging/media/hantro/hantro_vp8.c > > > b/drivers/staging/media/hantro/hantro_vp8.c > > > index 66c4533..363ddda 100644 > > > --- a/drivers/staging/media/hantro/hantro_vp8.c > > > +++ b/drivers/staging/media/hantro/hantro_vp8.c > > > @@ -151,8 +151,6 @@ int hantro_vp8_dec_init(struct hantro_ctx *ctx) > > > if (!aux_buf->cpu) > > > return -ENOMEM; > > > > > > - memset(aux_buf->cpu, 0, aux_buf->size); > > > - > > > /* > > >* Allocate probability table buffer, > > >* total 1208 bytes, 4K page is far enough. > > > > Is this something you will pick to your tree? Ah, sorry, this is already applied. Not sure why searching for it the first time didn't show anything. I guess I need to start repeating my searches by default. Sorry for the noise. Best regards, Tomasz
[PATCH] .gitignore: ignore modules.order explicitly
The pattern '*.order' was added by commit c6025f4c8bbe ("kbuild: ignore
*.order files") to ignore modules.order files.
I do not see any other user of the '.order' extension.
Ignore 'modules.order' explicitly instead of '*.order'.
Signed-off-by: Masahiro Yamada
---
.gitignore | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gitignore b/.gitignore
index 2030c7a4d2f8..ce2c6348d372 100644
--- a/.gitignore
+++ b/.gitignore
@@ -34,7 +34,6 @@
*.mod.c
*.o
*.o.*
-*.order
*.patch
*.s
*.so
@@ -46,6 +45,7 @@
*.xz
Module.symvers
modules.builtin
+modules.order
#
# Top-level generic files
--
2.17.1
Re: [PATCH] staging: media: hantro: Remove call to memset after dma_alloc_coherent
Hi Hans, On Thu, Jul 25, 2019 at 8:50 PM Boris Brezillon wrote: > > On Thu, 25 Jul 2019 08:36:02 +0530 > Hariprasad Kelam wrote: > > > fix below issue reported by coccicheck > > /drivers/staging/media/hantro/hantro_vp8.c:149:16-34: WARNING: > > dma_alloc_coherent use in aux_buf -> cpu already zeroes out memory, so > > memset is not needed > > > > Signed-off-by: Hariprasad Kelam > > Reviewed-by: Boris Brezillon > > > --- > > drivers/staging/media/hantro/hantro_vp8.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/drivers/staging/media/hantro/hantro_vp8.c > > b/drivers/staging/media/hantro/hantro_vp8.c > > index 66c4533..363ddda 100644 > > --- a/drivers/staging/media/hantro/hantro_vp8.c > > +++ b/drivers/staging/media/hantro/hantro_vp8.c > > @@ -151,8 +151,6 @@ int hantro_vp8_dec_init(struct hantro_ctx *ctx) > > if (!aux_buf->cpu) > > return -ENOMEM; > > > > - memset(aux_buf->cpu, 0, aux_buf->size); > > - > > /* > >* Allocate probability table buffer, > >* total 1208 bytes, 4K page is far enough. > Is this something you will pick to your tree? Best regards, Tomasz
Re: [PATCH v2] jffs2: remove C++ style comments from uapi header
On Mon, Jul 29, 2019 at 4:14 PM Richard Weinberger wrote: > > On Sun, Jul 14, 2019 at 10:08 AM Richard Weinberger wrote: > > > > - Ursprüngliche Mail - > > > Looks like this trivial patch missed the pull request. > > > > > > > > > My motivation is to make sure UAPI headers > > > are really compilable in user-space, > > > and now checked by the following commit: > > > > > > commit d6fc9fcbaa655cff2d2be05e16867d1918f78b85 > > > Author: Masahiro Yamada > > > Date: Mon Jul 1 09:58:40 2019 +0900 > > > > > >kbuild: compile-test exported headers to ensure they are self-contained > > > > > > > > > > > > Is there a chance for it being merged, > > Appled. > > -- > Thanks, > //richard I checked next-20190819, but I still do not see this patch. Where has this patch gone? -- Best Regards Masahiro Yamada
Re: [PATCH v2] jffs2: remove C++ style comments from uapi header
On Sun, Jul 14, 2019 at 5:08 PM Richard Weinberger wrote: > > - Ursprüngliche Mail - > > Looks like this trivial patch missed the pull request. > > > > > > My motivation is to make sure UAPI headers > > are really compilable in user-space, > > and now checked by the following commit: > > > > commit d6fc9fcbaa655cff2d2be05e16867d1918f78b85 > > Author: Masahiro Yamada > > Date: Mon Jul 1 09:58:40 2019 +0900 > > > >kbuild: compile-test exported headers to ensure they are self-contained > > > > > > > > Is there a chance for it being merged, > > Sure. I think it is okay to send it for -rc2. > > Thanks, > //richard This patch missed the fixes pull requests. Which version is this targeting for? v5.4-rc1 ? -- Best Regards Masahiro Yamada
Re: [RFC PATCH 04/15] drivers/acrn: add the basic framework of acrn char device driver
On 2019年08月16日 15:05, Greg KH wrote: On Fri, Aug 16, 2019 at 10:25:45AM +0800, Zhao Yakui wrote: ACRN hypervisor service module is the important middle layer that allows the Linux kernel to communicate with the ACRN hypervisor. It includes the management of virtualized CPU/memory/device/interrupt for other ACRN guest. The user-space applications can use the provided ACRN ioctls to interact with ACRN hypervisor through different hypercalls. Add one basic framework firstly and the following patches will add the corresponding implementations, which includes the management of virtualized CPU/memory/interrupt and the emulation of MMIO/IO/PCI access. The device file of /dev/acrn_hsm can be accessed in user-space to communicate with ACRN module. Co-developed-by: Jason Chen CJ Signed-off-by: Jason Chen CJ Co-developed-by: Jack Ren Signed-off-by: Jack Ren Co-developed-by: Mingqiang Chi Signed-off-by: Mingqiang Chi Co-developed-by: Liu Shuo Signed-off-by: Liu Shuo Signed-off-by: Zhao Yakui --- drivers/staging/Kconfig | 2 + Also, your subject line for all of these patches are wrong, it is not drivers/acrn :( Thanks for the pointing out it. It will be fixed. And you forgot to cc: the staging maintainer :( Do you mean that the maintainer of staging subsystem is also added in the patch commit log? As I have said with NUMEROUS Intel patches in the past, I now refuse to take patches from you all WITHOUT having it signed-off-by someone from the Intel "OTC" group (or whatever the Intel Linux group is called these days). They are a resource you can not ignore, and if you do, you just end up making the rest of the kernel community grumpy by having us do their work for them :( Please work with them. OK. I will work with some peoples in OTC group to prepare the better ACRN driver. greg k-h
Re: [PATCH v4 1/3] kasan: support backing vmalloc space with real shadow memory
>> > Instead, share backing space across multiple mappings. Allocate
>> > a backing page the first time a mapping in vmalloc space uses a
>> > particular page of the shadow region. Keep this page around
>> > regardless of whether the mapping is later freed - in the mean time
>> > the page could have become shared by another vmalloc mapping.
>> >
>> > This can in theory lead to unbounded memory growth, but the vmalloc
>> > allocator is pretty good at reusing addresses, so the practical memory
>> > usage grows at first but then stays fairly stable.
>>
>> I guess people having gigabytes of memory don't mind, but I'm concerned
>> about tiny targets with very little amount of memory. I have boards with as
>> little as 32Mbytes of RAM. The shadow region for the linear space already
>> takes one eighth of the RAM. I'd rather avoid keeping unused shadow pages
>> busy.
>
> I think this depends on how much shadow would be in constant use vs what
> would get left unused. If the amount in constant use is sufficiently
> large (or the residue is sufficiently small), then it may not be
> worthwhile to support KASAN_VMALLOC on such small systems.
I'm not unsympathetic to the cause of small-memory systems, but this is
useful as-is for x86, especially for VMAP_STACK. arm64 and s390 have
already been able to make use of it as well. So unless the design is
going to make it difficult to extend to small-memory systems - if it
bakes in concepts or APIs that are going to make things harder - I think
it might be worth merging as is. (pending the fixes for documentation
nits etc that you point out.)
>> Each page of shadow memory represent 8 pages of real memory. Could we use
>> page_ref to count how many pieces of a shadow page are used so that we can
>> free it when the ref count decreases to 0.
I'm not sure how much of a difference it will make, but I'll have a look.
>> > This requires architecture support to actually use: arches must stop
>> > mapping the read-only zero page over portion of the shadow region that
>> > covers the vmalloc space and instead leave it unmapped.
>>
>> Why 'must' ? Couldn't we switch back and forth from the zero page to real
>> page on demand ?
This code as currently written will not work if the architecture maps
the zero page over the portion of the shadow region that covers the
vmalloc space. So it's an implementation 'must' rather than a laws of
the universe 'must'.
We could perhaps map the zero page, but:
- you have to be really careful to get it right. If you accidentally
map the zero page onto memory where you shouldn't, you may permit
memory accesses that you should catch.
We could ameliorate this by taking Mark's suggestion and mapping a
poision page over the vmalloc space instead.
- I'm not sure what benefit is provided by having something mapped vs
leaving a hole, other than making the fault addresses more obvious.
- This gets complex, especially to do swapping correctly with respect
to various architectures' quirks (see e.g. 56eecdb912b5 "mm: Use
ptep/pmdp_set_numa() for updating _PAGE_NUMA bit" - ppc64 at least
requires that set_pte_at is never called on a valid PTE).
>> If the zero page is not mapped for unused vmalloc space, bad memory accesses
>> will Oops on the shadow memory access instead of Oopsing on the real bad
>> access, making it more difficult to locate and identify the issue.
I suppose. It's pretty easy on at least x86 and my draft ppc64
implementation to identify when an access falls into the shadow region
and then to reverse engineer the memory access that was being checked
based on the offset. As Andy points out, the fault handler could do this
automatically.
> I agree this isn't nice, though FWIW this can already happen today for
> bad addresses that fall outside of the usual kernel address space. We
> could make the !KASAN_INLINE checks resilient to this by using
> probe_kernel_read() to check the shadow, and treating unmapped shadow as
> poison.
>
> It's also worth noting that flipping back and forth isn't generally safe
> unless going via an invalid table entry, so there'd still be windows
> where a bad access might not have shadow mapped.
>
> We'd need to reuse the common p4d/pud/pmd/pte tables for unallocated
> regions, or the tables alone would consume significant amounts of memory
> (e..g ~32GiB for arm64 defconfig), and thus we'd need to be able to
> switch all levels between pgd and pte, which is much more complicated.
>
> I strongly suspect that the additional complexity will outweigh the
> benefit.
>
I'm not opposed to this in principle but I am also concerned about the
complexity involved.
Regards,
Daniel
> [...]
>
>> > +#ifdef CONFIG_KASAN_VMALLOC
>> > +static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
>> > +void *unused)
>> > +{
>> > + unsigned long page;
>> > + pte_t pte;
>> > +
>> > + if (likely(!pte_none(*ptep)))
>> > + return 0;
>>
>> Prior to
Re: [PATCH v4 06/10] modpost: Add modinfo flag to livepatch modules
Hi Joe, On Sat, Aug 17, 2019 at 4:01 AM Joe Lawrence wrote: > > On 8/16/19 8:43 AM, Joe Lawrence wrote: > > On 8/16/19 4:19 AM, Miroslav Benes wrote: > >> Hi, > >> > >>> I cleaned up the build system, and pushed it based on my > >>> kbuild tree. > >>> > >>> Please see: > >>> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git > >>> klp-cleanup > >> > >> This indeed looks much simpler and cleaner (as far as I can judge with my > >> limited kbuild knowledge). We just need to remove MODULE_INFO(livepatch, > >> "Y") from lib/livepatch/test_klp_convert_mod_a.c to make it compile and > >> work (test_klp_convert_mod_a is not a livepatch module, it is just a dummy > >> module which is then livepatched by lib/livepatch/test_klp_convert1.c). > >> > > > > Yeah, Masahiro this is great, thanks for reworking this! > > > > I did tweak one module like Miroslav mentioned and I think a few of the > > newly generated files need to be cleaned up as part of "make clean", but > > all said, this is a nice improvement. > > > > Well actually, now I see this comment in the top-level Makefile: > > # Cleaning is done on three levels. > > # make clean Delete most generated files > > #Leave enough to build external modules > > # make mrproper Delete the current configuration, and all generated > files > # make distclean Remove editor backup files, patch leftover files and > the like > > I didn't realize that we're supposed to be able to still build external > modules after "make clean". If that's the case, then one might want to > build an external klp-module after doing that. Yes. 'make clean' must keep all the build artifacts needed for building external modules. > With that in mind, shouldn't Symbols.list to persist until mrproper? > And I think modules-livepatch could go away during clean, what do you think? > > -- Joe Symbols.list should be kept by the time mrproper is run. So, please add it to MRROPER_FILES instead of CLEAN_FILES. modules.livepatch is a temporary file, so you can add it to CLEAN_FILES. How is this feature supposed to work for external modules? klp-convert receives: "symbols from vmlinux" + "symbols from no-klp in-tree modules" + "symbols from no-klp external modules" ?? BTW, 'Symbols.list' sounds like a file to list out symbols for generic purposes, but in fact, the file format is very specific for the klp-convert tool. Perhaps, is it better to rename it so it infers this is for livepatching? What do you think? -- Best Regards Masahiro Yamada
Re: [PATCH v4 06/10] modpost: Add modinfo flag to livepatch modules
On Fri, Aug 16, 2019 at 9:43 PM Joe Lawrence wrote: > > On 8/16/19 4:19 AM, Miroslav Benes wrote: > > Hi, > > > >> I cleaned up the build system, and pushed it based on my > >> kbuild tree. > >> > >> Please see: > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git > >> klp-cleanup > > > > This indeed looks much simpler and cleaner (as far as I can judge with my > > limited kbuild knowledge). We just need to remove MODULE_INFO(livepatch, > > "Y") from lib/livepatch/test_klp_convert_mod_a.c to make it compile and > > work (test_klp_convert_mod_a is not a livepatch module, it is just a dummy > > module which is then livepatched by lib/livepatch/test_klp_convert1.c). > > > > Yeah, Masahiro this is great, thanks for reworking this! > > I did tweak one module like Miroslav mentioned and I think a few of the > newly generated files need to be cleaned up as part of "make clean", but > all said, this is a nice improvement. > > Are you targeting the next merge window for your kbuild branch? (This > appears to be what the klp-cleanup branch was based on.) I can review this series from the build system point of view, but I am not familiar enough with live-patching itself. Some possibilities: [1] Merge this series thru the live-patch tree after the kbuild base patches land. This requires one extra development cycle (targeting for 5.5-rc1) but I think this is the official way if you do not rush into it. [2] Create an immutable branch in kbuild tree, and the live-patch tree will use it as the basis for queuing this series. We will have to coordinate the pull request order, but we can merge this feature for 5.4-rc1 [3] Apply this series to my kbuild tree, with proper Acked-by from the livepatch maintainers. I am a little bit uncomfortable with applying patches I do not understand, though... -- Best Regards Masahiro Yamada
[PATCH v1 1/2] dt-bindings: phy: intel-emmc-phy: Add new compatible for LGM eMMC PHY
From: Ramuthevar Vadivel Murugan
Add a new compatible to use the host controller driver with the
eMMC PHY on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../bindings/phy/intel-lgm-emmc-phy.yaml | 70 ++
1 file changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/intel-lgm-emmc-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/intel-lgm-emmc-phy.yaml
b/Documentation/devicetree/bindings/phy/intel-lgm-emmc-phy.yaml
new file mode 100644
index ..52156ff091ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel-lgm-emmc-phy.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel-lgm-emmc-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM e-MMC PHY Device Tree Bindings
+
+maintainers:
+ - Rob Herring
+ - Mark Rutland
+
+intel,syscon:
+ $ref: /schemas/types.yaml#definitions/phandle
+ description:
+- |
+ e-MMC phy module connected through chiptop. Phandle to a node that can
+ contain the following properties
+* reg, Access the e-MMC, get the base address from syscon.
+* reset, reset the e-MMC module.
+
+properties:
+ "#phy-cells":
+const: 0
+
+ compatible:
+const: intel,lgm-emmc-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: e-MMC phy module clock
+
+ clock-names:
+items:
+ - const: emmcclk
+
+ resets:
+maxItems: 1
+
+required:
+ - "#phy-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+sysconf: chiptop@e002 {
+compatible = "intel,chiptop-lgm", "syscon";
+reg = <0xe002 0x100>;
+#reset-cells = <1>;
+ };
+
+ - |
+emmc_phy: emmc_phy {
+compatible = "intel,lgm-emmc-phy";
+intel,syscon = <&sysconf>;
+clocks = <&emmc>;
+clock-names = "emmcclk";
+#phy-cells = <0>;
+};
+
+...
--
2.11.0
[PATCH v1 2/2] phy: intel-lgm-emmc: Add support for eMMC PHY
From: Ramuthevar Vadivel Murugan
Adds support for eMMC PHY on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/phy/Kconfig| 1 +
drivers/phy/Makefile | 1 +
drivers/phy/intel/Kconfig | 8 ++
drivers/phy/intel/Makefile | 2 +
drivers/phy/intel/phy-intel-emmc.c | 276 +
5 files changed, 288 insertions(+)
create mode 100644 drivers/phy/intel/Kconfig
create mode 100644 drivers/phy/intel/Makefile
create mode 100644 drivers/phy/intel/phy-intel-emmc.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 0263db2ac874..b3ed94b98d9b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -69,5 +69,6 @@ source "drivers/phy/socionext/Kconfig"
source "drivers/phy/st/Kconfig"
source "drivers/phy/tegra/Kconfig"
source "drivers/phy/ti/Kconfig"
+source "drivers/phy/intel/Kconfig"
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 0d9fddc498a6..3f1fc9efbbed 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -19,6 +19,7 @@ obj-y += broadcom/\
cadence/ \
freescale/ \
hisilicon/ \
+ intel/ \
marvell/ \
motorola/\
mscc/\
diff --git a/drivers/phy/intel/Kconfig b/drivers/phy/intel/Kconfig
new file mode 100644
index ..aa34e0fa9824
--- /dev/null
+++ b/drivers/phy/intel/Kconfig
@@ -0,0 +1,8 @@
+#
+# Phy drivers for Intel X86 LGM platform
+#
+config PHY_INTEL_EMMC
+ tristate "Intel EMMC PHY driver"
+ select GENERIC_PHY
+ help
+ Enable this to support the Intel EMMC PHY
diff --git a/drivers/phy/intel/Makefile b/drivers/phy/intel/Makefile
new file mode 100644
index ..6b876a75599d
--- /dev/null
+++ b/drivers/phy/intel/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PHY_INTEL_EMMC)+= phy-intel-emmc.o
diff --git a/drivers/phy/intel/phy-intel-emmc.c
b/drivers/phy/intel/phy-intel-emmc.c
new file mode 100644
index ..2fd4e42f18f8
--- /dev/null
+++ b/drivers/phy/intel/phy-intel-emmc.c
@@ -0,0 +1,276 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel eMMC PHY driver
+ * Copyright (C) 2019 Intel, Corp.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* eMMC phy register definitions */
+#define EMMC_PHYCTRL0_REG 0xa8
+#define DR_TY_MASK GENMASK(30, 28)
+#define DR_TY_50OHM(x) ((~(x) << 28) & DR_TY_MASK)
+#define OTAPDLYENA BIT(14)
+#define OTAPDLYSEL_MASKGENMASK(13, 10)
+#define OTAPDLYSEL_SHIFT(x)(((x) << 10) & OTAPDLYSEL_MASK)
+
+#define EMMC_PHYCTRL1_REG 0xac
+#define PDB_MASK 1
+#define ENDLL_MASK BIT(7)
+#define ENDLL_VAL BIT(7)
+
+#define EMMC_PHYCTRL2_REG 0xb0
+#define FRQSEL_25M 0
+#define FRQSEL_150M3
+#define FRQSEL_MASKGENMASK(24, 22)
+#define FRQSEL_SHIFT(x)((x) << 22)
+
+#define EMMC_PHYSTAT_REG 0xbc
+#define CALDONE_MASK 1
+#define DLLRDY_MASK1
+#define IS_CALDONE(x) x) >> 9) & CALDONE_MASK) == 1)
+#define IS_DLLRDY(x) x) >> 8) & DLLRDY_MASK) == 1)
+
+struct intel_emmc_phy {
+ struct regmap *syscfg;
+ struct clk *emmcclk;
+};
+
+static int intel_emmc_phy_power(struct phy *phy, bool on_off)
+{
+ struct intel_emmc_phy *priv = phy_get_drvdata(phy);
+ unsigned int caldone;
+ unsigned int dllrdy;
+ unsigned int freqsel = 0;
+ unsigned long rate;
+ int ret, quot;
+
+ /*
+* Keep phyctrl_pdb and phyctrl_endll low to allow
+* initialization of CALIO state M/C DFFs
+*/
+ ret = regmap_update_bits(priv->syscfg, EMMC_PHYCTRL1_REG,
+PDB_MASK | ENDLL_MASK, 0);
+ if (ret) {
+ dev_err(&phy->dev, "CALIO power down bar failed: %d\n", ret);
+ return ret;
+ }
+
+ /* Already finish power_off above */
+ if (!on_off)
+ return 0;
+
+ rate = clk_get_rate(priv->emmcclk);
+ quot = DIV_ROUND_CLOSEST(rate, 5000);
+ if (quot > FRQSEL_150M)
+ dev_warn(&phy->dev, "Unsupported rate: %lu\n", rate);
+ freqsel = clamp_t(int, quot, FRQSEL_25M, FRQSEL_150M);
+
+ /*
+* According to the user manual, calpad calibration
+* cycle takes more than 2us without the minimal recommended
+* value, so we may need a little margin here
+*/
+ usleep_range(3, 6);
+ regmap_update_bits(priv->syscfg, EMMC_PHYC
Re: [PATCH v7 1/7] driver core: Add support for linking devices during device addition
On 8/15/19 6:50 PM, Saravana Kannan wrote:
> On Wed, Aug 7, 2019 at 7:04 PM Frank Rowand wrote:
>>
>>> Date: Tue, 23 Jul 2019 17:10:54 -0700
>>> Subject: [PATCH v7 1/7] driver core: Add support for linking devices during
>>> device addition
>>> From: Saravana Kannan
>>>
>>> When devices are added, the bus might want to create device links to track
>>> functional dependencies between supplier and consumer devices. This
>>> tracking of supplier-consumer relationship allows optimizing device probe
>>> order and tracking whether all consumers of a supplier are active. The
>>> add_links bus callback is added to support this.
>>
>> Change above to:
>>
>> When devices are added, the bus may create device links to track which
>> suppliers a consumer device depends upon. This
>> tracking of supplier-consumer relationship may be used to defer probing
>> the driver of a consumer device before the driver(s) for its supplier
>> device(s)
>> are probed. It may also be used by a supplier driver to determine if
>> all of its consumers have been successfully probed.
>> The add_links bus callback is added to create the supplier device links
>>
>>>
>>> However, when consumer devices are added, they might not have a supplier
>>> device to link to despite needing mandatory resources/functionality from
>>> one or more suppliers. A waiting_for_suppliers list is created to track
>>> such consumers and retry linking them when new devices get added.
>>
>> Change above to:
>>
>> If a supplier device has not yet been created when the consumer device
>> attempts
>> to link it, the consumer device is added to the wait_for_suppliers list.
>> When supplier devices are created, the supplier device link will be added to
>> the relevant consumer devices on the wait_for_suppliers list.
>>
>
> I'll take these commit text suggestions if we decide to revert the
> entire series at the end of this review.
>
>>>
>>> Signed-off-by: Saravana Kannan
>>> ---
>>> drivers/base/core.c| 83 ++
>>> include/linux/device.h | 14 +++
>>> 2 files changed, 97 insertions(+)
>>>
>>> diff --git a/drivers/base/core.c b/drivers/base/core.c
>>> index da84a73f2ba6..1b4eb221968f 100644
>>> --- a/drivers/base/core.c
>>> +++ b/drivers/base/core.c
>>> @@ -44,6 +44,8 @@ early_param("sysfs.deprecated", sysfs_deprecated_setup);
>>> #endif
>>>
>>> /* Device links support. */
>>> +static LIST_HEAD(wait_for_suppliers);
>>> +static DEFINE_MUTEX(wfs_lock);
>>>
>>> #ifdef CONFIG_SRCU
>>> static DEFINE_MUTEX(device_links_lock);
>>> @@ -401,6 +403,51 @@ struct device_link *device_link_add(struct device
>>> *consumer,
>>> }
>>> EXPORT_SYMBOL_GPL(device_link_add);
>>>
>>> +/**
>>
>>> + * device_link_wait_for_supplier - Mark device as waiting for supplier
>>
>> * device_link_wait_for_supplier - Add device to wait_for_suppliers list
>
As a meta-comment, I found this series very hard to understand in the context
of reading the new code for the first time. When I read the code again in
six months or a year or two years it will not be in near term memory and it
will be as if I am reading it for the first time. A lot of my suggestions
for changes of names are in that context -- the current names may be fine
when one has recently read the code, but not so much when trying to read
the whole thing again with a blank mind.
The code also inherits a good deal of complexity because it does not stand
alone in a nice discrete chunk, but instead delicately weaves into a more
complex body of code.
When I was trying to understand the code, I wrote a lot of additional
comments within my reply email to provide myself context, information
about various things, and questions that I needed to answer (or if I
could not answer to then ask you). Then I ended up being able to remove
many of those notes before sending the reply.
> I intentionally chose "Mark device..." because that's a better
> description of the semantics of the function instead of trying to
> describe the implementation. Whether I'm using a linked list or some
> other data structure should not be the one line documentation of a
> function. Unless the function is explicitly about operating on that
> specific data structure.
I agree with the intent of trying to describe the semantics of a function,
especially at the API level where other systems (or drivers) would be using
the function. But for this case the function is at the implementation level
and describing explicitly what it is doing makes this much more readable for
me.
I also find "Mark device" to be vague and not descriptive of what the
intent is.
>
>>
>>
>>> + * @consumer: Consumer device
>>> + *
>>> + * Marks the consumer device as waiting for suppliers to become available.
>>> The
>>> + * consumer device will never be probed until it's unmarked as waiting for
>>> + * suppliers. The caller is responsible for adding the link to the supplier
>>> + * once the supplier device is present.
>>> + *
>>> + * T
Re: linux-next: build failure after merge of the security tree
Hi James,
On Mon, 19 Aug 2019 13:21:19 +1000 Stephen Rothwell
wrote:
>
> On Mon, 12 Aug 2019 10:34:17 -0700 Kees Cook wrote:
> >
> > On Mon, Aug 12, 2019 at 02:58:23PM +1000, Stephen Rothwell wrote:
> > >
> > > After merging the security tree, today's linux-next build (arm
> > > multi_v7_defconfig) failed like below.
> > >
> > > Caused by commit
> > >
> > > 45d29f9e9b8b ("security: Support early LSMs")
> > >
> > > I have added the following fix for today:
> > >
> > > From: Stephen Rothwell
> > > Date: Mon, 12 Aug 2019 14:54:20 +1000
> > > Subject: [PATCH] early_security_init() needs a stub got !CONFIG_SECURITY
^^^
for
If you do decide to apply this patch, please fix the subject typo, thanks :-)
--
Cheers,
Stephen Rothwell
pgpHsIAp02F6u.pgp
Description: OpenPGP digital signature
[PATCH v2 linux-next] qcom: qcs404: move COMPILE_TEST to INTERCONNECT_QCOM
There is one compilation error when CONFIG_INTERCONNECT_QCOM_QCS404=y and
CONFIG_INTERCONNECT_QCOM_SMD_RPM=y, as well as CONFIG_COMPILE_TEST=y,
but CONFIG_QCOM_SMD_RPM is not set, logs as below:
drivers/interconnect/qcom/smd-rpm.o: In function `qcom_icc_rpm_smd_send':
smd-rpm.c:(.text+0xe4): undefined reference to `qcom_rpm_smd_write'
Makefile:1071: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
This is because
INTERCONNECT_QCOM_QCS404 depends on QCOM_SMD_RPM || COMPILE_TEST.
Here CONFIG_COMPILE_TEST=y, so CONFIG_INTERCONNECT_QCOM_SMD_RPM
is selected. If CONFIG_QCOM_SMD_RPM is not set, then
qcom_rpm_smd_write() is not defined, and compilation error happen.
Fix this by moving COMPILE_TEST from CONFIG_INTERCONNECT_QCOM_QCS404 to
CONFIG_INTERCONNECT_QCOM, qcom's interconnect drivers can be compiled on
different platform.
Fixes: 5e4e6c4d3ae0 ("interconnect: qcom: Add QCS404 interconnect provider
driver")
Signed-off-by: Mao Wenan
---
v2: change subject of patch, and move COMPILE_TEST to INTERCONNECT_QCOM.
drivers/interconnect/qcom/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/interconnect/qcom/Kconfig
b/drivers/interconnect/qcom/Kconfig
index 339e8f1..7207248 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -1,14 +1,14 @@
# SPDX-License-Identifier: GPL-2.0-only
config INTERCONNECT_QCOM
bool "Qualcomm Network-on-Chip interconnect drivers"
- depends on ARCH_QCOM
+ depends on ARCH_QCOM || COMPILE_TEST
help
Support for Qualcomm's Network-on-Chip interconnect hardware.
config INTERCONNECT_QCOM_QCS404
tristate "Qualcomm QCS404 interconnect driver"
depends on INTERCONNECT_QCOM
- depends on QCOM_SMD_RPM || COMPILE_TEST
+ depends on QCOM_SMD_RPM
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on qcs404-based
--
2.7.4
Re: [PATCH 1/1] dt-bindings: power/supply/sbs_sbs-battery: Addition of force_load binding Add device tree binding documentation for addition of force_load boolean value to allow loading a battery duri
There is a force load option when loading the driver as a module. This adds the equivalent methodology for the binding path. Though I suppose you could in fact just force load if the gpio detect isn't present. Thats a good idea, just wasn't the existing driver flow. I can't think of any reason why we couldn't do that though. I'll update the patch and resubmit V3 Will add a note about it in the docs Please note I'd submitted this incorrectly when using our patch script last time, it's now correctly part of the combined patch Regards Richard Tresidder Richard Tresidder ** On 17/08/2019 5:14 am, Rob Herring wrote: On Thu, Jul 25, 2019 at 02:50:45PM +0800, Richard Tresidder wrote: Signed-off-by: Richard Tresidder --- Notes: Add device tree binding documentation for addition of force_load boolean value to allow loading a battery during boot even if not present at that time. Accompanying patch to drivers/power/supply/sbs-battery.c submitted to linux...@vger.kernel.org Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt index 4e78e51..187d7bb 100644 --- a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt +++ b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt @@ -15,7 +15,8 @@ Optional properties : after an external change notification. - sbs,battery-detect-gpios : The gpio which signals battery detection and a flag specifying its polarity. - + - sbs,force-load : Allow loading of a hot-pluggable battery when there is no + GPIO detect available and the module is statically built. What's a module? That's Linux specific and nothing to do with the binding. Can't you just force load if sbs,battery-detect-gpios is not present? Rob
Re: [PATCH v2] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
Tony Chuang 於 2019年8月16日 週五 下午6:44寫道：
>
> > From: Jian-Hong Pan
> >
> > There is a mass of jobs between spin lock and unlock in the hardware
> > IRQ which will occupy much time originally. To make system work more
> > efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
> > reduce the time in hardware IRQ.
> >
> > Signed-off-by: Jian-Hong Pan
> > ---
> > v2:
> > Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
> > rtw_pci_interrupt_handler. Because the interrupts are already disabled
> > in the hardware interrupt handler.
> >
> > drivers/net/wireless/realtek/rtw88/pci.c | 33 +++-
> > 1 file changed, 27 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> > b/drivers/net/wireless/realtek/rtw88/pci.c
> > index 00ef229552d5..0740140d7e46 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -866,12 +866,28 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> > void *dev)
> > {
> > struct rtw_dev *rtwdev = dev;
> > struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > - u32 irq_status[4];
> >
> > spin_lock(&rtwpci->irq_lock);
> > if (!rtwpci->irq_enabled)
> > goto out;
> >
> > + /* disable RTW PCI interrupt to avoid more interrupts before the end
> > of
> > + * thread function
> > + */
> > + rtw_pci_disable_interrupt(rtwdev, rtwpci);
>
> So basically it's to prevent back-to-back interrupts.
>
> Nothing wrong about it, I just wondering why we don't like
> back-to-back interrupts. Does it means that those interrupts
> fired between irq_handler and threadfin would increase
> much more time to consume them.
1. It is one of the reasons. Besides, the hardware interrupt has
higher priority than soft IRQ. If next hardware interrupt is coming
faster then the soft IRQ (BH), the software IRQ may always become
pended.
2. Keep the data's state until the interrupt is fully dealt.
3. The process of request_threaded_irq is documented:
https://www.kernel.org/doc/htmldocs/kernel-api/API-request-threaded-irq.html
> > +out:
> > + spin_unlock(&rtwpci->irq_lock);
> > +
> > + return IRQ_WAKE_THREAD;
> > +}
> > +
> > +static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
> > +{
> > + struct rtw_dev *rtwdev = dev;
> > + struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > + unsigned long flags;
> > + u32 irq_status[4];
> > +
> > rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
> >
> > if (irq_status[0] & IMR_MGNTDOK)
> > @@ -891,8 +907,11 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> > void *dev)
> > if (irq_status[0] & IMR_ROK)
> > rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
> >
> > -out:
> > - spin_unlock(&rtwpci->irq_lock);
> > + /* all of the jobs for this interrupt have been done */
> > + spin_lock_irqsave(&rtwpci->irq_lock, flags);
>
> I suggest to protect the ISRs. Because next patches will require
> to check if the TX DMA path is empty. This means I will also add
> this rtwpci->irq_lock to the TX path, and check if the skb_queue
> does not have any pending SKBs not DMAed successfully.
Ah ... Okay for the TX path
> > + if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
>
> Why check the flag here? Is there any racing or something?
> Otherwise it looks to break the symmetry.
According to backtrace, I notice rtw_pci_stop will be invoked in
rtw_power_off, rtw_core_stop which clears the running state.
rtw_core_stop is invoked by rtw_enter_ips due to IEEE80211_CONF_IDLE.
If the stop command comes between the hardware interrupt and soft IRQ
(BH) and there is no start command again, I think user wants the WiFi
stop instead of becoming start again.
Jian-Hong Pan
Re: linux-next: build failure after merge of the security tree
Hi all,
On Mon, 12 Aug 2019 10:34:17 -0700 Kees Cook wrote:
>
> On Mon, Aug 12, 2019 at 02:58:23PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the security tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like below.
> >
> > Caused by commit
> >
> > 45d29f9e9b8b ("security: Support early LSMs")
> >
> > I have added the following fix for today:
> >
> > From: Stephen Rothwell
> > Date: Mon, 12 Aug 2019 14:54:20 +1000
> > Subject: [PATCH] early_security_init() needs a stub got !CONFIG_SECURITY
> >
> > An arm multi_v7_defconfig fails like this:
> >
> > init/main.c: In function 'start_kernel':
> > init/main.c:596:2: error: implicit declaration of function
> > 'early_security_init'; did you mean 'security_init'?
> > [-Werror=implicit-function-declaration]
> > early_security_init();
> > ^~~
> > security_init
> >
> > Fixes: 45d29f9e9b8b ("security: Support early LSMs")
> > Signed-off-by: Stephen Rothwell
>
> Acked-by: Kees Cook
>
> -Kees
>
> > ---
> > include/linux/security.h | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/include/linux/security.h b/include/linux/security.h
> > index 807dc0d24982..23e1c3f17d48 100644
> > --- a/include/linux/security.h
> > +++ b/include/linux/security.h
> > @@ -473,6 +473,11 @@ static inline int security_init(void)
> > return 0;
> > }
> >
> > +static inline int early_security_init(void)
> > +{
> > + return 0;
> > +}
> > +
> > static inline int security_binder_set_context_mgr(struct task_struct *mgr)
> > {
> > return 0;
> > --
> > 2.20.1
I am still applying that patch ...
--
Cheers,
Stephen Rothwell
pgpJFs7gyWMlU.pgp
Description: OpenPGP digital signature
[PATCH net-next] r8152: fix accessing skb after napi_gro_receive
Fix accessing skb after napi_gro_receive which is caused by
commit 47922fcde536 ("r8152: support skb_add_rx_frag").
Fixes: 47922fcde536 ("r8152: support skb_add_rx_frag")
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 40d18e866269..b1db6df6f4ab 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2094,10 +2094,10 @@ static int rx_bottom(struct r8152 *tp, int budget)
skb->protocol = eth_type_trans(skb, netdev);
rtl_rx_vlan_tag(rx_desc, skb);
if (work_done < budget) {
- napi_gro_receive(napi, skb);
work_done++;
stats->rx_packets++;
stats->rx_bytes += skb->len;
+ napi_gro_receive(napi, skb);
} else {
__skb_queue_tail(&tp->rx_queue, skb);
}
--
2.21.0
Re: [PATCH v12 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
Hi, Bibby:
On Mon, 2019-08-19 at 10:53 +0800, Bibby Hsieh wrote:
> GCE cannot know the register base address, this function
> can help cmdq client to get the cmdq_client_reg structure.
Reviewed-by: CK Hu
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++
> include/linux/soc/mediatek/mtk-cmdq.h | 21 +++
> 2 files changed, 50 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 340a92a254e5..1bed07362b7a 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -27,6 +27,35 @@ struct cmdq_instruction {
> u8 op;
> };
>
> +int cmdq_dev_get_client_reg(struct device *dev,
> + struct cmdq_client_reg *client_reg, int idx)
> +{
> + struct of_phandle_args spec;
> + int err;
> +
> + if (!client_reg)
> + return -ENOENT;
> +
> + err = of_parse_phandle_with_fixed_args(dev->of_node,
> +"mediatek,gce-client-reg",
> +3, idx, &spec);
> + if (err < 0) {
> + dev_err(dev,
> + "error %d can't parse gce-client-reg property (%d)",
> + err, idx);
> +
> + return err;
> + }
> +
> + client_reg->subsys = (u8)spec.args[0];
> + client_reg->offset = (u16)spec.args[1];
> + client_reg->size = (u16)spec.args[2];
> + of_node_put(spec.np);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(cmdq_dev_get_client_reg);
> +
> static void cmdq_client_timeout(struct timer_list *t)
> {
> struct cmdq_client *client = from_timer(client, t, timer);
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index a345870a6d10..6215d4fc4ba3 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -15,6 +15,12 @@
>
> struct cmdq_pkt;
>
> +struct cmdq_client_reg {
> + u8 subsys;
> + u16 offset;
> + u16 size;
> +};
> +
> struct cmdq_client {
> spinlock_t lock;
> u32 pkt_cnt;
> @@ -24,6 +30,21 @@ struct cmdq_client {
> u32 timeout_ms; /* in unit of microsecond */
> };
>
> +/**
> + * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
> + * node of CMDQ client
> + * @dev: device of CMDQ mailbox clienti
> + * @client_reg: CMDQ client reg pointer
> + * @idx: the index of desired reg
> + *
> + * Return: 0 for success; else the error code is returned
> + *
> + * Help CMDQ client pasing the cmdq client reg
> + * from the device node of CMDQ client.
> + */
> +int cmdq_dev_get_client_reg(struct device *dev,
> + struct cmdq_client_reg *client_reg, int idx);
> +
> /**
> * cmdq_mbox_create() - create CMDQ mailbox client and channel
> * @dev: device of CMDQ mailbox client
linux-5.3.0-rc5: new build warning
Hi, I've just built 5.3.0-rc5 and a warning that I do not recall having seen before was emitted: ... HOSTCC scripts/extract-cert HOSTCC /mnt/kernel/linux/tools/objtool/fixdep.o HOSTLD arch/x86/tools/relocs HOSTLD /mnt/kernel/linux/tools/objtool/fixdep-in.o LINK /mnt/kernel/linux/tools/objtool/fixdep CC /mnt/kernel/linux/tools/objtool/builtin-check.o CC /mnt/kernel/linux/tools/objtool/builtin-orc.o GEN /mnt/kernel/linux/tools/objtool/arch/x86/lib/inat-tables.c awk: arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape sequence `\:' is not a known regexp operator awk: arch/x86/tools/gen-insn-attr-x86.awk:350: (FILENAME=arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape sequence `\&' is not a known regexp operator CC /mnt/kernel/linux/tools/objtool/exec-cmd.o CC /mnt/kernel/linux/tools/objtool/check.o CC /mnt/kernel/linux/tools/objtool/arch/x86/decode.o CC /mnt/kernel/linux/tools/objtool/orc_gen.o CC /mnt/kernel/linux/tools/objtool/help.o CC /mnt/kernel/linux/tools/objtool/orc_dump.o CC /mnt/kernel/linux/tools/objtool/pager.o ... Happy to test the fix, but please cc me as I'm not subscribed Chris
oops on cdrom eject
I mentioned this on irc and I'll probably dig into a bit further. Fedora 30, 5.1.18 was fine, 5.2.9 oops on CD eject with the below. Dave. [10384.391028] FAT-fs (sdc1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. [10385.221284] ISO 9660 Extensions: Microsoft Joliet Level 3 [10385.351758] ISOFS: changing to secondary root [10408.030879] VFS: busy inodes on changed media or resized disk sr0 [10408.338449] WARNING: CPU: 0 PID: 3026 at fs/block_dev.c:1868 __blkdev_put+0x1c0/0x1e0 [10408.338451] Modules linked in: nls_utf8 vfat fat isofs rfcomm fuse xt_CHECKSUM xt_MASQUERADE tun bridge stp llc nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables bnep sunrpc snd_hda_codec_analog snd_hda_codec_generic arc4 rt2800pci rt2800mmio rt2800lib ledtrig_audio rt2x00pci rt2x00mmio coretemp rt2x00lib mac80211 iTCO_wdt iTCO_vendor_support kvm snd_hda_intel snd_hda_codec uvcvideo snd_hda_core btusb videobuf2_vmalloc irqbypass btrtl videobuf2_memops snd_hwdep videobuf2_v4l2 snd_seq btbcm videobuf2_common btintel cfg80211 snd_seq_device bluetooth videodev snd_pcm ir_rc6_decoder rc_rc6_mce mceusb joydev media snd_timer snd soundcore [10408.338501] eeprom_93cx6 ecdh_generic i2c_i801 rfkill lpc_ich ecc pcc_cpufreq acpi_cpufreq binfmt_misc nouveau mxm_wmi wmi i2c_algo_bit serio_raw firewire_ohci drm_kms_helper firewire_core ata_generic pata_acpi ttm crc_itu_t drm r8169 video uas usb_storage [10408.338519] CPU: 0 PID: 3026 Comm: umount Not tainted 5.2.8-200.fc30.x86_64 #1 [10408.338520] Hardware name: HP-Pavilion FK936AA-ABG IQ518a/EVE, BIOS 5.0607/10/2008 [10408.338523] RIP: 0010:__blkdev_put+0x1c0/0x1e0 [10408.338525] Code: 41 5e 41 5f c3 49 8b 85 d8 03 00 00 48 8b 40 08 48 85 c0 0f 84 49 ff ff ff 8b 74 24 04 4c 89 ef e8 45 5c 8c 00 e9 38 ff ff ff <0f> 0b e9 97 fe ff ff e8 04 79 16 00 eb 9d e8 2d 31 da ff 66 66 2e [10408.338527] RSP: 0018:b547c37cbe40 EFLAGS: 00010202 [10408.338529] RAX: RBX: 8bc06474f0c0 RCX: [10408.338530] RDX: 0002 RSI: 0081 RDI: 8bc06474f0d8 [10408.338531] RBP: 8bc05faf4800 R08: 0001 R09: 8bc06bb294b0 [10408.338533] R10: 045b0f50 R11: R12: 8bc06474f0d8 [10408.338534] R13: 8bc064ef2800 R14: 8bbffe1fa5dc R15: [10408.338536] FS: 7fb3d486a080() GS:8bc06ba0() knlGS: [10408.338537] CS: 0010 DS: ES: CR0: 80050033 [10408.338539] CR2: 55c47e137d00 CR3: be11c000 CR4: 06f0 [10408.338540] Call Trace: [10408.338549] deactivate_locked_super+0x36/0x70 [10408.338552] cleanup_mnt+0x3f/0x70 [10408.338555] task_work_run+0x87/0xa0 [10408.338559] exit_to_usermode_loop+0xc2/0xd0 [10408.338562] do_syscall_64+0x183/0x1a0 [10408.338566] ? page_fault+0x8/0x30 [10408.338568] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [10408.338571] RIP: 0033:0x7fb3d4ab433b [10408.338574] Code: 4b 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 90 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1d 4b 0c 00 f7 d8 64 89 01 48 [10408.338575] RSP: 002b:7ffed4ca5ae8 EFLAGS: 0246 ORIG_RAX: 00a6 [10408.338577] RAX: RBX: 7fb3d4be01c4 RCX: 7fb3d4ab433b [10408.338578] RDX: 00323131315f3832 RSI: RDI: 55ab43d30630 [10408.338580] RBP: 55ab43d30420 R08: R09: 7fb3d4af55a0 [10408.338581] R10: 64656d2f6e75722f R11: 0246 R12: 55ab43d30630 [10408.338582] R13: R14: 55ab43d30518 R15: 55ab43d30e60 [10408.338585] ---[ end trace 0c7c3cb099ae73de ]---
Re: [PATCH v2] kbuild: Require W=1 for -Wimplicit-fallthrough with clang
On Mon, Aug 19, 2019 at 3:43 AM Nathan Chancellor wrote: > > On Mon, Aug 19, 2019 at 01:43:08AM +0900, Masahiro Yamada wrote: > > Hi. > > > > On Fri, Aug 16, 2019 at 7:59 AM Nathan Huckleberry wrote: > > > > > > Clang is updating to support -Wimplicit-fallthrough on C > > > https://reviews.llvm.org/D64838. Since clang does not > > > support the comment version of fallthrough annotations > > > this update causes an additional 50k warnings. Most > > > of these warnings (>49k) are duplicates from header files. > > > > > > This patch is intended to be reverted after the warnings > > > have been cleaned up. > > > > > > Signed-off-by: Nathan Huckleberry > > > Suggested-by: Nathan Chancellor > > > Reviewed-by: Nathan Chancellor > > > --- > > > Changes v1->v2 > > > * Move code to preexisting ifdef > > > scripts/Makefile.extrawarn | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn > > > index a74ce2e3c33e..95973a1ee999 100644 > > > --- a/scripts/Makefile.extrawarn > > > +++ b/scripts/Makefile.extrawarn > > > @@ -70,5 +70,6 @@ KBUILD_CFLAGS += -Wno-initializer-overrides > > > KBUILD_CFLAGS += -Wno-format > > > KBUILD_CFLAGS += -Wno-sign-compare > > > KBUILD_CFLAGS += -Wno-format-zero-length > > > +KBUILD_CFLAGS += $(call cc-option,-Wno-implicit-fallthrough) > > > endif > > > endif > > > -- > > > 2.23.0.rc1.153.gdeed80330f-goog > > > > > > > > > Perhaps, is the following even cleaner? > > > > > > > > diff --git a/Makefile b/Makefile > > index 1b23f95db176..cebc6bf5372e 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -751,6 +751,9 @@ else > > # These warnings generated too much noise in a regular build. > > # Use make W=1 to enable them (see scripts/Makefile.extrawarn) > > KBUILD_CFLAGS += -Wno-unused-but-set-variable > > + > > +# Warn about unmarked fall-throughs in switch statement. > > +KBUILD_CFLAGS += $(call cc-option,-Wimplicit-fallthrough,) > > endif > > > > KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable) > > @@ -845,9 +848,6 @@ NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) > > -print-file-name=include) > > # warn about C99 declaration after statement > > KBUILD_CFLAGS += -Wdeclaration-after-statement > > > > -# Warn about unmarked fall-throughs in switch statement. > > -KBUILD_CFLAGS += $(call cc-option,-Wimplicit-fallthrough,) > > - > > # Variable Length Arrays (VLAs) should not be used anywhere in the kernel > > KBUILD_CFLAGS += -Wvla > > > > > > > > -- > > Best Regards > > Masahiro Yamada > > I like this more than anything suggested so far. I think a comment > should be added regarding why this is only enabled for GCC right now but > that is pretty easy to revert once we have figured out the right course > of action. Agree. This is well-explained in the commit log, but adding a short comment will be nice. BTW, I personally like the traditional comment version of fallthrough annotations. Is there a plan for Clang to support it as well as the attribute? Thanks. -- Best Regards Masahiro Yamada
[PATCH v12 02/12] dt-binding: gce: add gce header file for mt8183
Add documentation for the mt8183 gce. Add gce header file defined the gce hardware event, subsys number and constant for mt8183. Signed-off-by: Bibby Hsieh Reviewed-by: Rob Herring --- .../devicetree/bindings/mailbox/mtk-gce.txt | 6 +- include/dt-bindings/gce/mt8183-gce.h | 177 ++ 2 files changed, 180 insertions(+), 3 deletions(-) create mode 100644 include/dt-bindings/gce/mt8183-gce.h diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index cfe40b01d164..1f7f8f2a3f49 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -9,7 +9,7 @@ CMDQ driver uses mailbox framework for communication. Please refer to mailbox.txt for generic information about mailbox device-tree bindings. Required properties: -- compatible: Must be "mediatek,mt8173-gce" +- compatible: can be "mediatek,mt8173-gce" or "mediatek,mt8183-gce" - reg: Address range of the GCE unit - interrupts: The interrupt signal from the GCE block - clock: Clocks according to the common clock binding @@ -28,8 +28,8 @@ Required properties for a client device: - mediatek,gce-subsys: u32, specify the sub-system id which is corresponding to the register address. -Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h'. Such as -sub-system ids, thread priority, event ids. +Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h' +or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, event ids. Example: diff --git a/include/dt-bindings/gce/mt8183-gce.h b/include/dt-bindings/gce/mt8183-gce.h new file mode 100644 index ..aeb95154fac2 --- /dev/null +++ b/include/dt-bindings/gce/mt8183-gce.h @@ -0,0 +1,177 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2019 MediaTek Inc. + * Author: Bibby Hsieh + * + */ + +#ifndef _DT_BINDINGS_GCE_MT8183_H +#define _DT_BINDINGS_GCE_MT8183_H + +#define CMDQ_NO_TIMEOUT0x + +#define CMDQ_THR_MAX_COUNT 24 + +/* GCE HW thread priority */ +#define CMDQ_THR_PRIO_LOWEST 0 +#define CMDQ_THR_PRIO_HIGHEST 1 + +/* GCE SUBSYS */ +#define SUBSYS_13000 +#define SUBSYS_14001 +#define SUBSYS_14012 +#define SUBSYS_14023 +#define SUBSYS_15024 +#define SUBSYS_18805 +#define SUBSYS_18816 +#define SUBSYS_18827 +#define SUBSYS_18838 +#define SUBSYS_18849 +#define SUBSYS_100010 +#define SUBSYS_100111 +#define SUBSYS_100212 +#define SUBSYS_100313 +#define SUBSYS_100414 +#define SUBSYS_100515 +#define SUBSYS_102016 +#define SUBSYS_102817 +#define SUBSYS_170018 +#define SUBSYS_170119 +#define SUBSYS_170220 +#define SUBSYS_170321 +#define SUBSYS_180022 +#define SUBSYS_180123 +#define SUBSYS_180224 +#define SUBSYS_180425 +#define SUBSYS_180526 +#define SUBSYS_180827 +#define SUBSYS_180a28 +#define SUBSYS_180b29 + +#define CMDQ_EVENT_DISP_RDMA0_SOF 0 +#define CMDQ_EVENT_DISP_RDMA1_SOF 1 +#define CMDQ_EVENT_MDP_RDMA0_SOF 2 +#define CMDQ_EVENT_MDP_RSZ0_SOF 4 +#define CMDQ_EVENT_MDP_RSZ1_SOF 5 +#define CMDQ_EVENT_MDP_TDSHP_SOF 6 +#define CMDQ_EVENT_MDP_WROT0_SOF 7 +#define CMDQ_EVENT_MDP_WDMA0_SOF 8 +#define CMDQ_EVENT_DISP_OVL0_SOF 9 +#define CMDQ_EVENT_DISP_OVL0_2L_SOF10 +#define CMDQ_EVENT_DISP_OVL1_2L_SOF11 +#define CMDQ_EVENT_DISP_WDMA0_SOF 12 +#define CMDQ_EVENT_DISP_COLOR0_SOF 13 +#define CMDQ_EVENT_DISP_CCORR0_SOF 14 +#define CMDQ_EVENT_DISP_AAL0_SOF 15 +#define CMDQ_EVENT_DISP_GAMMA0_SOF 16 +#define CMDQ_EVENT_DISP_DITHER0_SOF17 +#define CMDQ_EVENT_DISP_PWM0_SOF 18 +#define CMDQ_EVENT_DISP_DSI0_SOF 19 +#define CMDQ_EVENT_DISP_DPI0_SOF
[PATCH v12 10/12] soc: mediatek: cmdq: add polling function
add polling function in cmdq helper functions
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 28
include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
include/linux/soc/mediatek/mtk-cmdq.h| 15 +
3 files changed, 44 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index e1e41914ed7a..340a92a254e5 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -220,6 +220,34 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
}
EXPORT_SYMBOL(cmdq_pkt_clear_event);
+int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value, u32 mask)
+{
+ struct cmdq_instruction *inst;
+
+ if (mask != 0x) {
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_MASK;
+ inst->value = ~mask;
+ offset = offset | 0x1;
+ }
+
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_POLL;
+ inst->value = value;
+ inst->offset = offset;
+ inst->subsys = subsys;
+
+ return 0;
+}
+EXPORT_SYMBOL(cmdq_pkt_poll);
+
static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
struct cmdq_instruction *inst;
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index c8adedefaf42..9e3502945bc1 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -46,6 +46,7 @@
enum cmdq_code {
CMDQ_CODE_MASK = 0x02,
CMDQ_CODE_WRITE = 0x04,
+ CMDQ_CODE_POLL = 0x08,
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 9618debb9ceb..a345870a6d10 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -99,6 +99,21 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
*/
int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
+/**
+ * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
+ * execute an instruction that wait for a specified hardware
+ * register to check for the value. All GCE hardware
+ * threads will be blocked by this instruction.
+ * @pkt: the CMDQ packet
+ * @subsys:the CMDQ sub system code
+ * @offset:register offset from CMDQ sub system
+ * @value: the specified target register value
+ * @mask: the specified target register mask
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value, u32 mask);
/**
* cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
* packet and call back at the end of done packet
--
2.18.0
[PATCH v12 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
GCE cannot know the register base address, this function
can help cmdq client to get the cmdq_client_reg structure.
Signed-off-by: Bibby Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++
include/linux/soc/mediatek/mtk-cmdq.h | 21 +++
2 files changed, 50 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 340a92a254e5..1bed07362b7a 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -27,6 +27,35 @@ struct cmdq_instruction {
u8 op;
};
+int cmdq_dev_get_client_reg(struct device *dev,
+ struct cmdq_client_reg *client_reg, int idx)
+{
+ struct of_phandle_args spec;
+ int err;
+
+ if (!client_reg)
+ return -ENOENT;
+
+ err = of_parse_phandle_with_fixed_args(dev->of_node,
+ "mediatek,gce-client-reg",
+ 3, idx, &spec);
+ if (err < 0) {
+ dev_err(dev,
+ "error %d can't parse gce-client-reg property (%d)",
+ err, idx);
+
+ return err;
+ }
+
+ client_reg->subsys = (u8)spec.args[0];
+ client_reg->offset = (u16)spec.args[1];
+ client_reg->size = (u16)spec.args[2];
+ of_node_put(spec.np);
+
+ return 0;
+}
+EXPORT_SYMBOL(cmdq_dev_get_client_reg);
+
static void cmdq_client_timeout(struct timer_list *t)
{
struct cmdq_client *client = from_timer(client, t, timer);
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index a345870a6d10..6215d4fc4ba3 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -15,6 +15,12 @@
struct cmdq_pkt;
+struct cmdq_client_reg {
+ u8 subsys;
+ u16 offset;
+ u16 size;
+};
+
struct cmdq_client {
spinlock_t lock;
u32 pkt_cnt;
@@ -24,6 +30,21 @@ struct cmdq_client {
u32 timeout_ms; /* in unit of microsecond */
};
+/**
+ * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
+ *node of CMDQ client
+ * @dev: device of CMDQ mailbox clienti
+ * @client_reg: CMDQ client reg pointer
+ * @idx: the index of desired reg
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Help CMDQ client pasing the cmdq client reg
+ * from the device node of CMDQ client.
+ */
+int cmdq_dev_get_client_reg(struct device *dev,
+ struct cmdq_client_reg *client_reg, int idx);
+
/**
* cmdq_mbox_create() - create CMDQ mailbox client and channel
* @dev: device of CMDQ mailbox client
--
2.18.0
[PATCH v12 07/12] soc: mediatek: cmdq: reorder the parameter
The order of gce instructions is [subsys offset value]
so reorder the parameter of cmdq_pkt_write_mask
and cmdq_pkt_write function.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 6 +++---
include/linux/soc/mediatek/mtk-cmdq.h | 10 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index ff9fef5a032b..082b8978651e 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -136,7 +136,7 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt,
enum cmdq_code code,
return 0;
}
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset)
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
{
u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
(subsys << CMDQ_SUBSYS_SHIFT);
@@ -145,8 +145,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32
subsys, u32 offset)
}
EXPORT_SYMBOL(cmdq_pkt_write);
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value,
- u32 subsys, u32 offset, u32 mask)
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
+ u32 offset, u32 value, u32 mask)
{
u32 offset_mask = offset;
int err = 0;
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 4e8899972db4..39d813dde4b4 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -60,26 +60,26 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt);
/**
* cmdq_pkt_write() - append write command to the CMDQ packet
* @pkt: the CMDQ packet
- * @value: the specified target register value
* @subsys:the CMDQ sub system code
* @offset:register offset from CMDQ sub system
+ * @value: the specified target register value
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset);
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
/**
* cmdq_pkt_write_mask() - append write command with mask to the CMDQ packet
* @pkt: the CMDQ packet
- * @value: the specified target register value
* @subsys:the CMDQ sub system code
* @offset:register offset from CMDQ sub system
+ * @value: the specified target register value
* @mask: the specified target register mask
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value,
- u32 subsys, u32 offset, u32 mask);
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
+ u32 offset, u32 value, u32 mask);
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
--
2.18.0
[PATCH v12 12/12] arm64: dts: add gce node for mt8183
add gce device node for mt8183
Signed-off-by: Bibby Hsieh
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 08274bfcebd8..a81c995bbea9 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
/ {
compatible = "mediatek,mt8183";
@@ -212,6 +213,15 @@
clock-names = "spi", "wrap";
};
+ gce: mailbox@10238000 {
+ compatible = "mediatek,mt8183-gce";
+ reg = <0 0x10238000 0 0x4000>;
+ interrupts = ;
+ #mbox-cells = <3>;
+ clocks = <&infracfg CLK_INFRA_GCE>;
+ clock-names = "gce";
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt8183-uart",
"mediatek,mt6577-uart";
--
2.18.0
[PATCH v12 09/12] soc: mediatek: cmdq: define the instruction struct
Define an instruction structure for gce driver to append command.
This structure can make the client's code more readability.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 105 +++
include/linux/mailbox/mtk-cmdq-mailbox.h | 2 +
2 files changed, 73 insertions(+), 34 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 7aa0517ff2f3..e1e41914ed7a 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -9,12 +9,24 @@
#include
#include
-#define CMDQ_ARG_A_WRITE_MASK 0x
#define CMDQ_WRITE_ENABLE_MASK BIT(0)
#define CMDQ_EOC_IRQ_ENBIT(0)
#define CMDQ_EOC_CMD ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
<< 32 | CMDQ_EOC_IRQ_EN)
+struct cmdq_instruction {
+ union {
+ u32 value;
+ u32 mask;
+ };
+ union {
+ u16 offset;
+ u16 event;
+ };
+ u8 subsys;
+ u8 op;
+};
+
static void cmdq_client_timeout(struct timer_list *t)
{
struct cmdq_client *client = from_timer(client, t, timer);
@@ -110,10 +122,8 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
}
EXPORT_SYMBOL(cmdq_pkt_destroy);
-static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
- u32 arg_a, u32 arg_b)
+static struct cmdq_instruction *cmdq_pkt_append_command(struct cmdq_pkt *pkt)
{
- u64 *cmd_ptr;
if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
/*
@@ -127,81 +137,108 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt,
enum cmdq_code code,
pkt->cmd_buf_size += CMDQ_INST_SIZE;
WARN_ONCE(1, "%s: buffer size %u is too small !\n",
__func__, (u32)pkt->buf_size);
- return -ENOMEM;
+ return NULL;
}
- cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
- (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
+
pkt->cmd_buf_size += CMDQ_INST_SIZE;
- return 0;
+ return pkt->va_base + pkt->cmd_buf_size - CMDQ_INST_SIZE;
}
int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
{
- u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
- (subsys << CMDQ_SUBSYS_SHIFT);
+ struct cmdq_instruction *inst;
+
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_WRITE;
+ inst->value = value;
+ inst->offset = offset;
+ inst->subsys = subsys;
- return cmdq_pkt_append_command(pkt, CMDQ_CODE_WRITE, arg_a, value);
+ return 0;
}
EXPORT_SYMBOL(cmdq_pkt_write);
int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask)
{
- u32 offset_mask = offset;
- int err = 0;
+ struct cmdq_instruction *inst;
+ u16 offset_mask = offset;
if (mask != 0x) {
- err = cmdq_pkt_append_command(pkt, CMDQ_CODE_MASK, 0, ~mask);
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_MASK;
+ inst->mask = ~mask;
offset_mask |= CMDQ_WRITE_ENABLE_MASK;
}
- err |= cmdq_pkt_write(pkt, value, subsys, offset_mask);
- return err;
+ return cmdq_pkt_write(pkt, subsys, offset_mask, value);
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
- u32 arg_b;
+ struct cmdq_instruction *inst;
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
- /*
-* WFE arg_b
-* bit 0-11: wait value
-* bit 15: 1 - wait, 0 - no wait
-* bit 16-27: update value
-* bit 31: 1 - update, 0 - no update
-*/
- arg_b = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_WFE;
+ inst->value = CMDQ_WFE_OPTION;
+ inst->event = event;
- return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event, arg_b);
+ return 0;
}
EXPORT_SYMBOL(cmdq_pkt_wfe);
int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
{
+ struct cmdq_instruction *inst;
+
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
- return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event,
- CMDQ_WFE_UPDATE);
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_WFE;
+ inst->value = CMDQ_WFE_UPDATE;
+ inst->event = event;
+
+ return 0;
[PATCH v12 01/12] dt-binding: gce: remove thread-num property
"thread-num" is an unused property so we remove it from example. Signed-off-by: Bibby Hsieh Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 7d72b21c9e94..cfe40b01d164 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -39,7 +39,6 @@ Example: interrupts = ; clocks = <&infracfg CLK_INFRA_GCE>; clock-names = "gce"; - thread-num = CMDQ_THR_MAX_COUNT; #mbox-cells = <3>; }; -- 2.18.0
[PATCH v12 00/12] support gce on mt8183 platform
Changes since v11: - correct some data type to avoid type conversion. Changes since v10: - remove subsys-cell from gce device node - use of_parse_phandle_with_fixed_args instead of of_parse_phandle_with_args Changes since v8 and v9: - change the error return code in cmdq_dev_get_client_reg() Changes since v7: - remove the memory allocation out of cmdq_dev_get_client_reg() - rebase onto 5.2-rc1 Changes since v6: - remove cmdq_dev_get_event function and gce event property - separate some changes to indepentent patch - change the binding document related to gce-client-reg property Changes since v5: - fix typo - remove gce-event-name form the dt-binding - add reasons in commit message Changes since v4: - refine the architecture of the packet encoder function - refine the gce enevt property - change the patch's title Changes since v3: - fix a typo in dt-binding and dtsi - cast the return value to right format Changes since v2: - according to CK's review comment, change the property name and refine the parameter - change the patch's title - remove unused property from dt-binding and dts Changes since v1: - add prefix "cmdq" in the commit subject - add dt-binding document for get event and subsys function - add fix up tag in fixup patch - fix up some coding style (alignment) MTK will support gce function on mt8183 platform. dt-binding: gce: add gce header file for mt8183 mailbox: mediatek: cmdq: support mt8183 gce function arm64: dts: add gce node for mt8183 Besides above patches, we refine gce driver on those patches. soc: mediatek: cmdq: reorder the parameter soc: mediatek: cmdq: change the type of input parameter mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data soc: mediatek: cmdq: clear the event in cmdq initial flow In order to enhance the convenience of gce usage, we add new helper functions and refine the method of instruction combining. dt-binding: gce: remove thread-num property dt-binding: gce: add binding for gce client reg property soc: mediatek: cmdq: define the instruction struct soc: mediatek: cmdq: add polling function soc: mediatek: cmdq: add cmdq_dev_get_client_reg function Bibby Hsieh (12): dt-binding: gce: remove thread-num property dt-binding: gce: add gce header file for mt8183 dt-binding: gce: add binding for gce client reg property mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data mailbox: mediatek: cmdq: support mt8183 gce function soc: mediatek: cmdq: clear the event in cmdq initial flow soc: mediatek: cmdq: reorder the parameter soc: mediatek: cmdq: change the type of input parameter soc: mediatek: cmdq: define the instruction struct soc: mediatek: cmdq: add polling function soc: mediatek: cmdq: add cmdq_dev_get_client_reg function arm64: dts: add gce node for mt8183 .../devicetree/bindings/mailbox/mtk-gce.txt | 23 ++- arch/arm64/boot/dts/mediatek/mt8183.dtsi | 10 + drivers/mailbox/mtk-cmdq-mailbox.c| 18 +- drivers/soc/mediatek/mtk-cmdq-helper.c| 172 + include/dt-bindings/gce/mt8183-gce.h | 177 ++ include/linux/mailbox/mtk-cmdq-mailbox.h | 5 + include/linux/soc/mediatek/mtk-cmdq.h | 53 +- 7 files changed, 396 insertions(+), 62 deletions(-) create mode 100644 include/dt-bindings/gce/mt8183-gce.h -- 2.18.0
[PATCH v12 06/12] soc: mediatek: cmdq: clear the event in cmdq initial flow
GCE hardware stored event information in own internal sysram,
if the initial value in those sysram is not zero value
it will cause a situation that gce can wait the event immediately
after client ask gce to wait event but not really trigger the
corresponding hardware.
In order to make sure that the wait event function is
exactly correct, we need to clear the sysram value in
cmdq initial flow.
Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver")
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/mailbox/mtk-cmdq-mailbox.c | 5 +
include/linux/mailbox/mtk-cmdq-mailbox.h | 2 ++
include/linux/soc/mediatek/mtk-cmdq.h| 3 ---
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index 69daaadc3a5f..9a6ce9f5a7db 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -21,6 +21,7 @@
#define CMDQ_NUM_CMD(t)(t->cmd_buf_size /
CMDQ_INST_SIZE)
#define CMDQ_CURR_IRQ_STATUS 0x10
+#define CMDQ_SYNC_TOKEN_UPDATE 0x68
#define CMDQ_THR_SLOT_CYCLES 0x30
#define CMDQ_THR_BASE 0x100
#define CMDQ_THR_SIZE 0x80
@@ -104,8 +105,12 @@ static void cmdq_thread_resume(struct cmdq_thread *thread)
static void cmdq_init(struct cmdq *cmdq)
{
+ int i;
+
WARN_ON(clk_enable(cmdq->clock) < 0);
writel(CMDQ_THR_ACTIVE_SLOT_CYCLES, cmdq->base + CMDQ_THR_SLOT_CYCLES);
+ for (i = 0; i <= CMDQ_MAX_EVENT; i++)
+ writel(i, cmdq->base + CMDQ_SYNC_TOKEN_UPDATE);
clk_disable(cmdq->clock);
}
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index ccb73422c2fa..911475da7a53 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -19,6 +19,8 @@
#define CMDQ_WFE_UPDATEBIT(31)
#define CMDQ_WFE_WAIT BIT(15)
#define CMDQ_WFE_WAIT_VALUE0x1
+/** cmdq event maximum */
+#define CMDQ_MAX_EVENT 0x3ff
/*
* CMDQ_CODE_MASK:
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 54ade13a9b15..4e8899972db4 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -13,9 +13,6 @@
#define CMDQ_NO_TIMEOUT0xu
-/** cmdq event maximum */
-#define CMDQ_MAX_EVENT 0x3ff
-
struct cmdq_pkt;
struct cmdq_client {
--
2.18.0
[PATCH v12 04/12] mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data
The interrupt mask and thread number has positive correlation,
so we move the CMDQ_IRQ_MASK into cmdq driver data and calculate
it by thread number.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/mailbox/mtk-cmdq-mailbox.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index 00d5219094e5..8fddd26288e8 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -18,7 +18,6 @@
#include
#define CMDQ_OP_CODE_MASK (0xff << CMDQ_OP_CODE_SHIFT)
-#define CMDQ_IRQ_MASK 0x
#define CMDQ_NUM_CMD(t)(t->cmd_buf_size /
CMDQ_INST_SIZE)
#define CMDQ_CURR_IRQ_STATUS 0x10
@@ -72,6 +71,7 @@ struct cmdq {
void __iomem*base;
u32 irq;
u32 thread_nr;
+ u32 irq_mask;
struct cmdq_thread *thread;
struct clk *clock;
boolsuspended;
@@ -285,11 +285,11 @@ static irqreturn_t cmdq_irq_handler(int irq, void *dev)
unsigned long irq_status, flags = 0L;
int bit;
- irq_status = readl(cmdq->base + CMDQ_CURR_IRQ_STATUS) & CMDQ_IRQ_MASK;
- if (!(irq_status ^ CMDQ_IRQ_MASK))
+ irq_status = readl(cmdq->base + CMDQ_CURR_IRQ_STATUS) & cmdq->irq_mask;
+ if (!(irq_status ^ cmdq->irq_mask))
return IRQ_NONE;
- for_each_clear_bit(bit, &irq_status, fls(CMDQ_IRQ_MASK)) {
+ for_each_clear_bit(bit, &irq_status, cmdq->thread_nr) {
struct cmdq_thread *thread = &cmdq->thread[bit];
spin_lock_irqsave(&thread->chan->lock, flags);
@@ -473,6 +473,9 @@ static int cmdq_probe(struct platform_device *pdev)
dev_err(dev, "failed to get irq\n");
return -EINVAL;
}
+
+ cmdq->thread_nr = (u32)(unsigned long)of_device_get_match_data(dev);
+ cmdq->irq_mask = GENMASK(cmdq->thread_nr - 1, 0);
err = devm_request_irq(dev, cmdq->irq, cmdq_irq_handler, IRQF_SHARED,
"mtk_cmdq", cmdq);
if (err < 0) {
@@ -489,7 +492,6 @@ static int cmdq_probe(struct platform_device *pdev)
return PTR_ERR(cmdq->clock);
}
- cmdq->thread_nr = (u32)(unsigned long)of_device_get_match_data(dev);
cmdq->mbox.dev = dev;
cmdq->mbox.chans = devm_kcalloc(dev, cmdq->thread_nr,
sizeof(*cmdq->mbox.chans), GFP_KERNEL);
--
2.18.0
[PATCH v12 03/12] dt-binding: gce: add binding for gce client reg property
cmdq driver provide a function that get the relationship of sub system number from device node for client. add specification for #subsys-cells, mediatek,gce-client-reg. Signed-off-by: Bibby Hsieh Reviewed-by: Rob Herring --- .../devicetree/bindings/mailbox/mtk-gce.txt | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 1f7f8f2a3f49..7b13787ab13d 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -25,8 +25,16 @@ Required properties: Required properties for a client device: - mboxes: Client use mailbox to communicate with GCE, it should have this property and list of phandle, mailbox specifiers. -- mediatek,gce-subsys: u32, specify the sub-system id which is corresponding - to the register address. +Optional properties for a client device: +- mediatek,gce-client-reg: Specify the sub-system id which is corresponding + to the register address, it should have this property and list of phandle, + sub-system specifiers. + <&phandle subsys_number start_offset size> + phandle: Label name of a gce node. + subsys_number: specify the sub-system id which is corresponding + to the register address. + start_offset: the start offset of register address that GCE can access. + size: the total size of register address that GCE can access. Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h' or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, event ids. @@ -48,9 +56,9 @@ Example for a client device: compatible = "mediatek,mt8173-mmsys"; mboxes = <&gce 0 CMDQ_THR_PRIO_LOWEST 1>, <&gce 1 CMDQ_THR_PRIO_LOWEST 1>; - mediatek,gce-subsys = ; mutex-event-eof = ; - + mediatek,gce-client-reg = <&gce SUBSYS_1400 0x3000 0x1000>, + <&gce SUBSYS_1401 0x2000 0x100>; ... }; -- 2.18.0
