Re: [PATCH -next] vdpa: Mark macaddr_buf with static keyword
On Fri, Dec 18, 2020 at 09:51:35AM +0800, Zou Wei wrote: Fix the following sparse warning: drivers/vdpa/vdpa_sim/vdpa_sim_net.c:36:4: warning: symbol 'macaddr_buf' was not declared. Should it be static? Reported-by: Hulk Robot Signed-off-by: Zou Wei --- drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Stefano Garzarella I built with W=1 but I didn't have this warning. Thanks for fixing, Stefano diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c index c10b698..f048242 100644 --- a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c +++ b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c @@ -33,7 +33,7 @@ static char *macaddr; module_param(macaddr, charp, 0); MODULE_PARM_DESC(macaddr, "Ethernet MAC address"); -u8 macaddr_buf[ETH_ALEN]; +static u8 macaddr_buf[ETH_ALEN]; static struct vdpasim *vdpasim_net_dev; -- 2.6.2
Re: [PATCH v2] net: mhi: Add raw IP mode support
Hi Jakub, On Thu, 17 Dec 2020 at 17:58, Jakub Kicinski wrote: > > On Thu, 17 Dec 2020 16:34:09 +0100 Loic Poulain wrote: > > MHI net is protocol agnostic, the payload protocol depends on the modem > > configuration, which can be either RMNET (IP muxing and aggregation) or > > raw IP. This patch adds support for incomming IPv4/IPv6 packets, that > > was previously unconditionnaly reported as RMNET packets. > > Now it sounds a lot more like an extension than a fix. Is the interface > usable without this change? If it is we should merge this into net-next > after the merge window. Yes, without this change, interface is usable when modem is configured with RMNET protocol, it's an extension to raw ip support. > > Either way you need to cc netdev for this patch to get into patchwork. I'll resubmit after the merge window. Thanks, Loic
[PATCH] KVM: x86: change in pv_eoi_get_pending() to make code more readable
Signed-off-by: Stephen Zhang --- arch/x86/kvm/lapic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 3136e05..7882322 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -674,7 +674,7 @@ static bool pv_eoi_get_pending(struct kvm_vcpu *vcpu) (unsigned long long)vcpu->arch.pv_eoi.msr_val); return false; } - return val & 0x1; + return val & KVM_PV_EOI_ENABLED; } static void pv_eoi_set_pending(struct kvm_vcpu *vcpu) -- 1.8.3.1
[PATCH] driver: staging: count ashmem_range into SLAB_RECLAIMBLE
From: Zhaoyang Huang
Add SLAB_RECLAIM_ACCOUNT to ashmem_range cache since it has registered
shrinker, which make memAvailable more presiced.
Signed-off-by: Zhaoyang Huang
---
drivers/staging/android/ashmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 74d497d..b79301f 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -893,7 +893,7 @@ static int __init ashmem_init(void)
ashmem_range_cachep = kmem_cache_create("ashmem_range_cache",
sizeof(struct ashmem_range),
- 0, 0, NULL);
+ 0, SLAB_RECLAIM_ACCOUNT, NULL);
if (!ashmem_range_cachep) {
pr_err("failed to create slab cache\n");
goto out_free1;
--
1.9.1
RE: [PATCH v7 1/4] dt-bindings: soc: imx8m: add DT Binding doc for soc unique ID
> -Original Message- > From: Rob Herring > Sent: 2020年12月16日 4:33 > To: Alice Guo (OSS) > Cc: shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de; > feste...@gmail.com; k...@kernel.org; devicet...@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; > dl-linux-imx > > Subject: Re: [PATCH v7 1/4] dt-bindings: soc: imx8m: add DT Binding doc for > soc > unique ID > > On Tue, Dec 15, 2020 at 04:35:48PM +0800, Alice Guo (OSS) wrote: > > From: Alice Guo > > > > Add DT Binding doc for the Unique ID of i.MX 8M series. > > > > Signed-off-by: Alice Guo > > --- > > > > Changes for v7: > > - change to a separate schema file > > Changes for v6: > > - none > > Changes for v5: > > - correct the error of using allOf > > Changes for v4: > > - use allOf to limit new version DTS files for i.MX8M to include > >"fsl,imx8m*-soc", nvmem-cells and nvmem-cells-names Changes for v3: > > - put it into Documentation/devicetree/bindings/arm/fsl.yaml > > - modify the description of nvmem-cells > > - use "make ARCH=arm64 dtbs_check" to make sure it is right Changes > > for v2: > > - remove the subject prefix "LF-2571-1" > > > > .../bindings/soc/imx/imx8m-soc.yaml | 54 > +++ > > 1 file changed, 54 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/soc/imx/imx8m-soc.yaml > > > > diff --git a/Documentation/devicetree/bindings/soc/imx/imx8m-soc.yaml > > b/Documentation/devicetree/bindings/soc/imx/imx8m-soc.yaml > > new file mode 100644 > > index ..a2f7dc0c9b35 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/soc/imx/imx8m-soc.yaml > > @@ -0,0 +1,54 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/soc/imx/imx8m-soc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: NXP i.MX8M Series SoC > > + > > +maintainers: > > + - Alice Guo > > + > > +description: | > > + NXP i.MX8M series SoCs contain fuse entries from which SoC Unique > > +ID can be > > + obtained. > > + > > +select: > > + properties: > > +compatible: > > + contains: > > +enum: > > + - fsl,imx8mm > > + - fsl,imx8mn > > + - fsl,imx8mp > > + - fsl,imx8mq > > + required: > > +- compatible > > + > > +properties: > > + soc: > > +type: object > > +properties: > > + compatible: > > +items: > > + - enum: > > + - fsl,imx8mm-soc > > + - fsl,imx8mn-soc > > + - fsl,imx8mp-soc > > + - fsl,imx8mq-soc > > + - const: simple-bus > > + > > + nvmem-cells: > > +maxItems: 1 > > +description: Phandle to the SOC Unique ID provided by a nvmem > > + node > > + > > + nvmem-cells-names: > > +const: soc_unique_id > > + > > +required: > > + - compatible > > + - nvmem-cells > > + - nvmem-cell-names > > Anything else should be a node, so: > >additionalProperties: > type: object Hi, Rob Thank you for your advice. When I add "additionalProperties: type: object", use make ARCH=arm64 dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/soc/imx/imx8m-soc.yaml, and then: linux-next/arch/arm64/boot/dts/freescale/imx8mm-beacon-kit.dt.yaml: /: #size-cells: [[2]] is not of type 'object' From schema: /home/nxf55104/virtualization/upstream/linux-next/Documentation/devicetree/bindings/soc/imx/imx8m-soc.yaml ... so I think I should remain it unchanged in v8. Alice > > + > > +additionalProperties: true > > +... > > -- > > 2.17.1 > >
Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency improvement
On Thu, 2020-12-17 at 10:14 -0500, Tejun Heo wrote: > Hello, > > On Thu, Dec 17, 2020 at 07:48:49PM +0800, Ian Kent wrote: > > > What could be done is to make the kernfs node attr_mutex > > > a pointer and dynamically allocate it but even that is too > > > costly a size addition to the kernfs node structure as > > > Tejun has said. > > > > I guess the question to ask is, is there really a need to > > call kernfs_refresh_inode() from functions that are usually > > reading/checking functions. > > > > Would it be sufficient to refresh the inode in the write/set > > operations in (if there's any) places where things like > > setattr_copy() is not already called? > > > > Perhaps GKH or Tejun could comment on this? > > My memory is a bit hazy but invalidations on reads is how sysfs > namespace is > implemented, so I don't think there's an easy around that. The only > thing I > can think of is embedding the lock into attrs and doing xchg dance > when > attaching it. Sounds like your saying it would be ok to add a lock to the attrs structure, am I correct? Assuming it is then, to keep things simple, use two locks. One global lock for the allocation and an attrs lock for all the attrs field updates including the kernfs_refresh_inode() update. The critical section for the global lock could be reduced and it changed to a spin lock. In __kernfs_iattrs() we would have something like: take the allocation lock do the allocated checks assign if existing attrs release the allocation lock return existing if found othewise release the allocation lock allocate and initialize attrs take the allocation lock check if someone beat us to it free and grab exiting attrs otherwise assign the new attrs release the allocation lock return attrs Add a spinlock to the attrs struct and use it everywhere for field updates. Am I on the right track or can you see problems with this? Ian
Re: [xfs] 237d7887ae: xfstests.xfs.513.fail
Hi，
The patch https://www.spinics.net/lists/linux-xfs/msg47389.html for xfstests
will fix this regression.
Thanks,
Kaixu
On 2020/12/18 13:58, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 237d7887ae723af7d978e8b9a385fdff416f357b ("xfs: show the proper user
> quota options")
> https://git.kernel.org/cgit/fs/xfs/xfs-linux.git xfs-5.11-merge
>
>
> in testcase: xfstests
> version: xfstests-x86_64-d41dcbd-1_20201215
> with following parameters:
>
> disk: 4HDD
> fs: xfs
> test: xfs-group-51
> ucode: 0x21
>
> test-description: xfstests is a regression test suite for xfs and other files
> ystems.
> test-url: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
>
>
> on test machine: 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 8G
> memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
>
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot
>
> 2020-12-18 01:24:14 export TEST_DIR=/fs/sdb1
> 2020-12-18 01:24:14 export TEST_DEV=/dev/sdb1
> 2020-12-18 01:24:14 export FSTYP=xfs
> 2020-12-18 01:24:14 export SCRATCH_MNT=/fs/scratch
> 2020-12-18 01:24:14 mkdir /fs/scratch -p
> 2020-12-18 01:24:14 export SCRATCH_DEV=/dev/sdb4
> 2020-12-18 01:24:14 export SCRATCH_LOGDEV=/dev/sdb2
> 2020-12-18 01:24:14 export
> SCRATCH_XFS_LIST_METADATA_FIELDS=u3.sfdir3.hdr.parent.i4
> 2020-12-18 01:24:14 export SCRATCH_XFS_LIST_FUZZ_VERBS=random
> 2020-12-18 01:24:14 sed "s:^:xfs/:"
> //lkp/benchmarks/xfstests/tests/xfs-group-51
> 2020-12-18 01:24:14 ./check xfs/510 xfs/511 xfs/512 xfs/513 xfs/514 xfs/515
> xfs/516 xfs/517 xfs/518 xfs/519
> FSTYP -- xfs (debug)
> PLATFORM -- Linux/x86_64 lkp-ivb-d05 5.10.0-rc5-00026-g237d7887ae72 #1
> SMP Fri Dec 18 08:12:46 CST 2020
> MKFS_OPTIONS -- -f -bsize=4096 /dev/sdb4
> MOUNT_OPTIONS -- /dev/sdb4 /fs/scratch
>
> xfs/5101s
> xfs/5112s
> xfs/5122s
> xfs/513 - output mismatch (see
> /lkp/benchmarks/xfstests/results//xfs/513.out.bad)
> --- tests/xfs/513.out 2020-12-15 12:31:26.0 +
> +++ /lkp/benchmarks/xfstests/results//xfs/513.out.bad 2020-12-18
> 01:24:44.695412845 +
> @@ -77,7 +77,11 @@
> TEST: "-o usrquota" "pass" "usrquota" "true"
> TEST: "-o quota" "pass" "usrquota" "true"
> TEST: "-o uqnoenforce" "pass" "usrquota" "true"
> +[FAILED]: mount /dev/loop0 /fs/sdb1/513.mnt -o uqnoenforce
> +ERROR: did not expect to find "usrquota" in
> "rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,uqnoenforce"
> TEST: "-o qnoenforce" "pass" "usrquota" "true"
> +[FAILED]: mount /dev/loop0 /fs/sdb1/513.mnt -o qnoenforce
> ...
> (Run 'diff -u /lkp/benchmarks/xfstests/tests/xfs/513.out
> /lkp/benchmarks/xfstests/results//xfs/513.out.bad' to see the entire diff)
> xfs/514 - output mismatch (see
> /lkp/benchmarks/xfstests/results//xfs/514.out.bad)
> --- tests/xfs/514.out 2020-12-15 12:31:26.0 +
> +++ /lkp/benchmarks/xfstests/results//xfs/514.out.bad 2020-12-18
> 01:24:46.007412903 +
> @@ -1,2 +1,5 @@
> QA output created by 514
> Silence is golden
> +attr_remove not documented in the xfs_db manpage
> +attr_set not documented in the xfs_db manpage
> +logformat not documented in the xfs_db manpage
> ...
> (Run 'diff -u /lkp/benchmarks/xfstests/tests/xfs/514.out
> /lkp/benchmarks/xfstests/results//xfs/514.out.bad' to see the entire diff)
> xfs/515 - output mismatch (see
> /lkp/benchmarks/xfstests/results//xfs/515.out.bad)
> --- tests/xfs/515.out 2020-12-15 12:31:26.0 +
> +++ /lkp/benchmarks/xfstests/results//xfs/515.out.bad 2020-12-18
> 01:24:47.082412951 +
> @@ -1,2 +1,3 @@
> QA output created by 515
> Silence is golden
> +limit not documented in the xfs_quota manpage
> ...
> (Run 'diff -u /lkp/benchmarks/xfstests/tests/xfs/515.out
> /lkp/benchmarks/xfstests/results//xfs/515.out.bad' to see the entire diff)
> xfs/51632s
> xfs/517 [not run] rmapbt not supported by scratch filesystem type: xfs
> xfs/5183s
> xfs/519 [not run] Reflink not supported by scratch filesystem type: xfs
> Ran: xfs/510 xfs/511 xfs/512 xfs/513 xfs/514 xfs/515 xfs/516 xfs/517 xfs/518
> xfs/519
> Not run: xfs/517 xfs/519
> Failures: xfs/513 xfs/514 xfs/515
> Failed 3 of 10 tests
>
>
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml # job file is attached in this email
> bin/lkp run job.yaml
>
>
>
> Thanks,
> Oliver Sang
>
--
kaixuxia
Re: [PATCH] JFS: more checks for invalid superblock
Hi Randy,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on shaggy/jfs-next]
[also build test WARNING on linux/master linus/master v5.10 next-20201217]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Randy-Dunlap/JFS-more-checks-for-invalid-superblock/20201218-132143
base: https://github.com/kleikamp/linux-shaggy jfs-next
config: i386-randconfig-s002-20201217 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-184-g1b896707-dirty
#
https://github.com/0day-ci/linux/commit/11cb0575aca69504da8b7984fc7f3e439b1a2331
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Randy-Dunlap/JFS-more-checks-for-invalid-superblock/20201218-132143
git checkout 11cb0575aca69504da8b7984fc7f3e439b1a2331
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> fs/jfs/jfs_mount.c:373:17: sparse: sparse: restricted __le32 degrades to
>> integer
vim +373 fs/jfs/jfs_mount.c
324
325 jfs_info("superblock: flag:0x%08x state:0x%08x size:0x%Lx",
326 le32_to_cpu(j_sb->s_flag), le32_to_cpu(j_sb->s_state),
327 (unsigned long long) le64_to_cpu(j_sb->s_size));
328
329 /* validate the descriptors for Secondary AIM and AIT */
330 if ((j_sb->s_flag & cpu_to_le32(JFS_BAD_SAIT)) !=
331 cpu_to_le32(JFS_BAD_SAIT)) {
332 expected_AIM_bytesize = 2 * PSIZE;
333 AIM_bytesize = lengthPXD(&(j_sb->s_aim2)) * bsize;
334 expected_AIT_bytesize = 4 * PSIZE;
335 AIT_bytesize = lengthPXD(&(j_sb->s_ait2)) * bsize;
336 AIM_byte_addr = addressPXD(&(j_sb->s_aim2)) * bsize;
337 AIT_byte_addr = addressPXD(&(j_sb->s_ait2)) * bsize;
338 byte_addr_diff0 = AIT_byte_addr - AIM_byte_addr;
339 fsckwsp_addr = addressPXD(&(j_sb->s_fsckpxd)) * bsize;
340 byte_addr_diff1 = fsckwsp_addr - AIT_byte_addr;
341 if ((AIM_bytesize != expected_AIM_bytesize) ||
342 (AIT_bytesize != expected_AIT_bytesize) ||
343 (byte_addr_diff0 != AIM_bytesize) ||
344 (byte_addr_diff1 <= AIT_bytesize))
345 j_sb->s_flag |= cpu_to_le32(JFS_BAD_SAIT);
346 }
347
348 if ((j_sb->s_flag & cpu_to_le32(JFS_GROUPCOMMIT)) !=
349 cpu_to_le32(JFS_GROUPCOMMIT))
350 j_sb->s_flag |= cpu_to_le32(JFS_GROUPCOMMIT);
351
352 /* validate fs state */
353 if (j_sb->s_state != cpu_to_le32(FM_CLEAN) &&
354 !sb_rdonly(sb)) {
355 jfs_err("jfs_mount: Mount Failure: File System Dirty.");
356 rc = -EINVAL;
357 goto out;
358 }
359
360 sbi->state = le32_to_cpu(j_sb->s_state);
361 sbi->mntflag = le32_to_cpu(j_sb->s_flag);
362
363 /*
364 * JFS always does I/O by 4K pages. Don't tell the buffer cache
365 * that we use anything else (leave s_blocksize alone).
366 */
367 sbi->bsize = bsize;
368 sbi->l2bsize = le16_to_cpu(j_sb->s_l2bsize);
369
370 /* check some fields for possible corruption */
371 if (sbi->l2bsize != ilog2((u32)bsize) ||
372 j_sb->pad != 0 ||
> 373 j_sb->s_state > FM_STATE_MAX) {
374 rc = -EINVAL;
375 jfs_err("jfs_mount: Mount Failure: superblock is
corrupt!");
376 goto out;
377 }
378
379 /*
380 * For now, ignore s_pbsize, l2bfactor. All I/O going through
buffer
381 * cache.
382 */
383 sbi->nbperpage = PSIZE >> sbi->l2bsize;
384 sbi->l2nbperpage = L2PSIZE - sbi->l2bsize;
385 sbi->l2niperblk = sbi->l2bsize - L2DISIZE;
386 if (sbi->mntflag & JFS_INLINELOG)
387 sbi->logpxd = j_sb->s_logpxd;
388 else {
389 sbi->logdev =
new_decode_dev(le32_t
Re: [PATCH 12/13] cpufreq: qcom-hw: Implement CPRh aware OSM programming
On 26-11-20, 19:45, AngeloGioacchino Del Regno wrote: > On new SoCs (SDM845 onwards) the Operating State Manager (OSM) is > being programmed in the bootloader and write-protected by the > hypervisor, leaving to the OS read-only access to some of its > registers (in order to read the Lookup Tables and also some > status registers) and write access to the p-state register, for > for the OS to request a specific performance state to trigger a > DVFS switch on the CPU through the OSM hardware. > > On old SoCs though (MSM8998, SDM630/660 and variants), the > bootloader will *not* initialize the OSM (and the CPRh, as it > is a requirement for it) before booting the OS, making any > request to trigger a performance state change ineffective, as > the hardware doesn't have any Lookup Table, nor is storing any > parameter to trigger a DVFS switch. In this case, basically all > of the OSM registers are *not* write protected for the OS, even > though some are - but write access is granted through SCM calls. > > This commit introduces support for OSM programming, which has to > be done on these old SoCs that were distributed (almost?) always > with a bootloader that does not do any CPRh nor OSM init before > booting the kernel. > In order to program the OSM on these SoCs, it is necessary to > fullfill a "special" requirement: the Core Power Reduction > Hardened (CPRh) hardware block must be initialized, as the OSM > is "talking" to it in order to perform the Voltage part of DVFS; > here, we are calling initialization of this through Linux generic > power domains, specifically by requesting a genpd attach from the > qcom-cpufreq-hw driver, which will give back voltages associated > to each CPU frequency that has been declared in the OPPs, scaled > and interpolated with the previous one, and will also give us > parameters for the Array Power Mux (APM) and mem-acc, in order > for this driver to be then able to generate the Lookup Tables > that will be finally programmed to the OSM hardware. > > After writing the parameters to the OSM and enabling it, all the > programming work will never happen anymore until a OS reboot, so > all of the allocations and "the rest" will be disposed-of: this > is done mainly to leave the code that was referred only to the > new SoCs intact, as to also emphasize on the fact that the OSM > HW is, in the end, the exact same; apart some register offsets > that are slightly different, the entire logic is the same. > > Signed-off-by: AngeloGioacchino Del Regno > > --- > drivers/cpufreq/qcom-cpufreq-hw.c | 914 +- > 1 file changed, 884 insertions(+), 30 deletions(-) This is a lot of code, I need someone from Qcom's team to review it and make sure it doesn't break anything for the existing platforms. -- viresh
[PATCH] mmc: mediatek: fix race condition between msdc_request_timeout and irq
when get request SW timeout, if CMD/DAT xfer done irq coming right now,
then there is race between the msdc_request_timeout work and irq handler,
and the host->cmd and host->data may set to NULL in irq handler. also,
current flow ensure that only one path can go to msdc_request_done(), so
no need check the return value of cancel_delayed_work().
Signed-off-by: Chaotian Jing
---
drivers/mmc/host/mtk-sd.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index de09c6347524..898ed1b023df 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1127,13 +1127,13 @@ static void msdc_track_cmd_data(struct msdc_host *host,
static void msdc_request_done(struct msdc_host *host, struct mmc_request *mrq)
{
unsigned long flags;
- bool ret;
- ret = cancel_delayed_work(>req_timeout);
- if (!ret) {
- /* delay work already running */
- return;
- }
+ /*
+* No need check the return value of cancel_delayed_work, as only ONE
+* path will go here!
+*/
+ cancel_delayed_work(>req_timeout);
+
spin_lock_irqsave(>lock, flags);
host->mrq = NULL;
spin_unlock_irqrestore(>lock, flags);
@@ -1155,7 +1155,7 @@ static bool msdc_cmd_done(struct msdc_host *host, int
events,
bool done = false;
bool sbc_error;
unsigned long flags;
- u32 *rsp = cmd->resp;
+ u32 *rsp;
if (mrq->sbc && cmd == mrq->cmd &&
(events & (MSDC_INT_ACMDRDY | MSDC_INT_ACMDCRCERR
@@ -1176,6 +1176,7 @@ static bool msdc_cmd_done(struct msdc_host *host, int
events,
if (done)
return true;
+ rsp = cmd->resp;
sdr_clr_bits(host->base + MSDC_INTEN, cmd_ints_mask);
@@ -1363,7 +1364,7 @@ static void msdc_data_xfer_next(struct msdc_host *host,
static bool msdc_data_xfer_done(struct msdc_host *host, u32 events,
struct mmc_request *mrq, struct mmc_data *data)
{
- struct mmc_command *stop = data->stop;
+ struct mmc_command *stop;
unsigned long flags;
bool done;
unsigned int check_data = events &
@@ -1379,6 +1380,7 @@ static bool msdc_data_xfer_done(struct msdc_host *host,
u32 events,
if (done)
return true;
+ stop = data->stop;
if (check_data || (stop && stop->error)) {
dev_dbg(host->dev, "DMA status: 0x%8X\n",
--
2.18.0
Re: [PATCH v2 00/48] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
On 17-12-20, 21:05, Dmitry Osipenko wrote: > Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces > power consumption and heating of the Tegra chips. Tegra SoC has multiple > hardware units which belong to a core power domain of the SoC and share > the core voltage. The voltage must be selected in accordance to a minimum > requirement of every core hardware unit. Please submit the OPP changes separately (alone), it will never get merged this way. Send fixes at the top, any features you want later in the series. It is fine for you to base your series of patches which are under review, you just need to mention that in your cover letter for your platform's patchset. -- viresh
Re: [PATCH] ARM: OMAP1: OSK: fix ohci-omap breakage
* Aaro Koskinen [201214 23:01]:
> From: Linus Walleij
>
> Commit 45c5775460f3 ("usb: ohci-omap: Fix descriptor conversion") tried to
> fix all issues related to ohci-omap descriptor conversion, but a wrong
> patch was applied, and one needed change to the OSK board file is still
> missing. Fix that.
Thanks applying into fixes.
Tony
Re: [PATCH v1 4/5] driver core: Handle cycles in device links created by fw_devlink
Hi Saravana,
I love your patch! Perhaps something to improve:
[auto build test WARNING on driver-core/driver-core-testing]
[also build test WARNING on linus/master next-20201217]
[cannot apply to linux/master v5.10]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Saravana-Kannan/Enable-fw_devlink-on-by-default/20201218-112111
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
accefff5b547a9a1d959c7e76ad539bf2480e78b
config: riscv-randconfig-r014-20201217 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
cee1e7d14f4628d6174b33640d502bff3b54ae45)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
#
https://github.com/0day-ci/linux/commit/7bdc87ea0400318d827410f454ec7e5fbaf470c3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Saravana-Kannan/Enable-fw_devlink-on-by-default/20201218-112111
git checkout 7bdc87ea0400318d827410f454ec7e5fbaf470c3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
~~ ^
arch/riscv/include/asm/mmio.h:87:48: note: expanded from macro 'readb_cpu'
#define readb_cpu(c)({ u8 __r = __raw_readb(c); __r; })
^
In file included from drivers/base/core.c:27:
In file included from include/linux/netdevice.h:37:
In file included from include/net/net_namespace.h:39:
In file included from include/linux/skbuff.h:31:
In file included from include/linux/dma-mapping.h:10:
In file included from include/linux/scatterlist.h:9:
In file included from arch/riscv/include/asm/io.h:149:
include/asm-generic/io.h:564:9: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
return inw(addr);
^
arch/riscv/include/asm/io.h:56:76: note: expanded from macro 'inw'
#define inw(c) ({ u16 __v; __io_pbr(); __v =
readw_cpu((void*)(PCI_IOBASE + (c))); __io_par(__v); __v; })
~~ ^
arch/riscv/include/asm/mmio.h:88:76: note: expanded from macro 'readw_cpu'
#define readw_cpu(c)({ u16 __r = le16_to_cpu((__force
__le16)__raw_readw(c)); __r; })
^
include/uapi/linux/byteorder/little_endian.h:36:51: note: expanded from
macro '__le16_to_cpu'
#define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
^
In file included from drivers/base/core.c:27:
In file included from include/linux/netdevice.h:37:
In file included from include/net/net_namespace.h:39:
In file included from include/linux/skbuff.h:31:
In file included from include/linux/dma-mapping.h:10:
In file included from include/linux/scatterlist.h:9:
In file included from arch/riscv/include/asm/io.h:149:
include/asm-generic/io.h:572:9: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
return inl(addr);
^
arch/riscv/include/asm/io.h:57:76: note: expanded from macro 'inl'
#define inl(c) ({ u32 __v; __io_pbr(); __v =
readl_cpu((void*)(PCI_IOBASE + (c))); __io_par(__v); __v; })
~~ ^
arch/riscv/include/asm/mmio.h:89:76: note: expanded from macro 'readl_cpu'
#define readl_cpu(c)({ u32 __r = le32_to_cpu((__force
__le32)__raw_readl(c)); __r; })
^
include/uapi/linux/byteorder/little_endian.h:34:51: note: expanded from
macro '__le32_to_cpu'
#define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
^
In file included from drivers/base/core.c:27:
In file included from include/linux/netdevice.h:37:
In file included from include/net/net_namespace.h:39:
In file included from include/linux/skbuff.h:31:
In file included from include/linux/dma-mapping.h:10:
In file included from i
Re: [PATCH] DTS: ARM: gta04: remove legacy spi-cs-high to make display work again
* H. Nikolaus Schaller [201212 11:59]:
> This reverts
>
> commit f1f028ff89cb ("DTS: ARM: gta04: introduce legacy spi-cs-high to make
> display work again")
>
> which had to be intruduced after
>
> commit 6953c57ab172 ("gpio: of: Handle SPI chipselect legacy bindings")
>
> broke the GTA04 display. This contradicted the data sheet but was the only
> way to get it as an spi client operational again.
>
> The panel data sheet defines the chip-select to be active low.
>
> Now, with the arrival of
>
> commit 766c6b63aa04 ("spi: fix client driver breakages when using GPIO
> descriptors")
>
> the logic of interaction between spi-cs-high and the gpio descriptor flags
> has been changed a second time, making the display broken again. So we have
> to remove the original fix which in retrospect was a workaround of a bug in
> the spi subsystem and not a feature of the panel or bug in the device tree.
>
> With this fix the device tree is back in sync with the data sheet and
> spi subsystem code.
Thanks applying into fixes.
Tony
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Thu, Dec 17, 2020 at 10:19:37PM +0100, Alexandre Belloni wrote: > Hello, > > On 05/12/2020 16:51:36+0100, Greg KH wrote: > > > To me, the documentation was written, and reviewed, more from the > > > perspective of "why not open code a custom bus instead". So I can see > > > after the fact how that is a bit too much theory and justification and > > > not enough practical application. Before the fact though this was a > > > bold mechanism to propose and it was not clear that everyone was > > > grokking the "why" and the tradeoffs. > > > > Understood, I guess I read this from the "of course you should do this, > > now how do I use it?" point of view. Which still needs to be addressed > > I feel. > > > > > I also think it was a bit early to identify consistent design patterns > > > across the implementations and codify those. I expect this to evolve > > > convenience macros just like other parts of the driver-core gained > > > over time. Now that it is in though, another pass through the > > > documentation to pull in more examples seems warranted. > > > > A real, working, example would be great to have, so that people can know > > how to use this. Trying to dig through the sound or IB patches to view > > how it is being used is not a trivial thing to do, which is why > > reviewing this took so much work. Having a simple example test module, > > that creates a number of devices on a bus, ideally tied into the ktest > > framework, would be great. I'll attach below a .c file that I used for > > some basic local testing to verify some of this working, but it does not > > implement a aux bus driver, which needs to be also tested. > > > > There is something I don't get from the documentation and it is what is > this introducing that couldn't already be done using platform drivers > and platform devices? Because platform drivers and devices should ONLY be for actual platform devices. Do NOT use that interface to fake up a non-platform device (i.e. something that is NOT connected to a cpu through a memory-mapped or direct-firmware interface). Do not abuse the platform code anymore than it currently is, it's bad enough what has been done to it over time, let's not make it any worse. thanks, greg k-h
Re: [PATCH] dt-bindings: Fix JSON pointers
On 17-12-20, 16:34, Rob Herring wrote: > The correct syntax for JSON pointers begins with a '/' after the '#'. > Without a '/', the string should be interpretted as a subschema > identifier. The jsonschema module currently doesn't handle subschema > identifiers and incorrectly allows JSON pointers to begin without a '/'. > Let's fix this before it becomes a problem when jsonschema module is > fixed. > > Converted with: > perl -p -i -e 's/yaml#definitions/yaml#\/definitions/g' `find > Documentation/devicetree/bindings/ -name "*.yaml"` > .../devicetree/bindings/dma/dma-common.yaml | 4 +- > .../devicetree/bindings/dma/dma-router.yaml | 2 +- > .../devicetree/bindings/dma/ingenic,dma.yaml | 2 +- > .../bindings/dma/snps,dma-spear1340.yaml | 10 ++--- Acked-By: Vinod Koul -- ~Vinod
[PATCH v5 3/3] scsi: ufs: Revert "Make sure clk scaling happens only when HBA is runtime ACTIVE"
Commit 73cc291c27024 ("Make sure clk scaling happens only when HBA is
runtime ACTIVE") is no longer needed since commit f7a42540928a8 ("scsi:
ufs: Protect some contexts from unexpected clock scaling") is a more
mature fix to protect UFS LLD stability from clock scaling invoked through
sysfs nodes by users.
Reviewed-by: Stanley Chu
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 80f82cb..052479a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1300,15 +1300,8 @@ static int ufshcd_devfreq_target(struct device *dev,
}
spin_unlock_irqrestore(hba->host->host_lock, irq_flags);
- pm_runtime_get_noresume(hba->dev);
- if (!pm_runtime_active(hba->dev)) {
- pm_runtime_put_noidle(hba->dev);
- ret = -EAGAIN;
- goto out;
- }
start = ktime_get();
ret = ufshcd_devfreq_scale(hba, scale_up);
- pm_runtime_put(hba->dev);
trace_ufshcd_profile_clk_scaling(dev_name(hba->dev),
(scale_up ? "up" : "down"),
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
[PATCH v5 2/3] scsi: ufs: Clean up ufshcd_exit_clk_scaling/gating()
ufshcd_hba_exit() is always called after ufshcd_exit_clk_scaling() and
ufshcd_exit_clk_gating(), so move ufshcd_exit_clk_scaling/gating() to
ufshcd_hba_exit().
Reviewed-by: Stanley Chu
Reviewed-by: Bean Huo
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 32 +++-
drivers/scsi/ufs/ufshcd.h | 4
2 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 4ccdd2b..80f82cb 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1857,11 +1857,14 @@ static void ufshcd_init_clk_scaling(struct ufs_hba *hba)
snprintf(wq_name, sizeof(wq_name), "ufs_clkscaling_%d",
hba->host->host_no);
hba->clk_scaling.workq = create_singlethread_workqueue(wq_name);
+
+ hba->clk_scaling.is_initialized = true;
}
static void ufshcd_exit_clk_scaling(struct ufs_hba *hba)
{
- if (!ufshcd_is_clkscaling_supported(hba))
+ if (!ufshcd_is_clkscaling_supported(hba) ||
+ !hba->clk_scaling.is_initialized)
return;
if (hba->devfreq)
@@ -1905,12 +1908,16 @@ static void ufshcd_init_clk_gating(struct ufs_hba *hba)
hba->clk_gating.enable_attr.attr.mode = 0644;
if (device_create_file(hba->dev, >clk_gating.enable_attr))
dev_err(hba->dev, "Failed to create sysfs for
clkgate_enable\n");
+
+ hba->clk_gating.is_initialized = true;
}
static void ufshcd_exit_clk_gating(struct ufs_hba *hba)
{
- if (!ufshcd_is_clkgating_allowed(hba))
+ if (!ufshcd_is_clkgating_allowed(hba) ||
+ !hba->clk_gating.is_initialized)
return;
+
device_remove_file(hba->dev, >clk_gating.delay_attr);
device_remove_file(hba->dev, >clk_gating.enable_attr);
cancel_work_sync(>clk_gating.ungate_work);
@@ -7775,7 +7782,6 @@ static void ufshcd_async_scan(void *data, async_cookie_t
cookie)
*/
if (ret) {
pm_runtime_put_sync(hba->dev);
- ufshcd_exit_clk_scaling(hba);
ufshcd_hba_exit(hba);
}
}
@@ -8212,12 +8218,12 @@ static int ufshcd_hba_init(struct ufs_hba *hba)
static void ufshcd_hba_exit(struct ufs_hba *hba)
{
if (hba->is_powered) {
+ ufshcd_exit_clk_scaling(hba);
+ ufshcd_exit_clk_gating(hba);
+ if (hba->eh_wq)
+ destroy_workqueue(hba->eh_wq);
ufshcd_variant_hba_exit(hba);
ufshcd_setup_vreg(hba, false);
- ufshcd_suspend_clkscaling(hba);
- if (ufshcd_is_clkscaling_supported(hba))
- if (hba->devfreq)
- ufshcd_suspend_clkscaling(hba);
ufshcd_setup_clocks(hba, false);
ufshcd_setup_hba_vreg(hba, false);
hba->is_powered = false;
@@ -8966,13 +8972,9 @@ void ufshcd_remove(struct ufs_hba *hba)
blk_mq_free_tag_set(>tmf_tag_set);
blk_cleanup_queue(hba->cmd_queue);
scsi_remove_host(hba->host);
- destroy_workqueue(hba->eh_wq);
/* disable interrupts */
ufshcd_disable_intr(hba, hba->intr_mask);
ufshcd_hba_stop(hba);
-
- ufshcd_exit_clk_scaling(hba);
- ufshcd_exit_clk_gating(hba);
ufshcd_hba_exit(hba);
}
EXPORT_SYMBOL_GPL(ufshcd_remove);
@@ -9171,7 +9173,7 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem
*mmio_base, unsigned int irq)
err = devm_request_irq(dev, irq, ufshcd_intr, IRQF_SHARED, UFSHCD, hba);
if (err) {
dev_err(hba->dev, "request irq failed\n");
- goto exit_gating;
+ goto out_disable;
} else {
hba->is_irq_enabled = true;
}
@@ -9179,7 +9181,7 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem
*mmio_base, unsigned int irq)
err = scsi_add_host(host, hba->dev);
if (err) {
dev_err(hba->dev, "scsi_add_host failed\n");
- goto exit_gating;
+ goto out_disable;
}
hba->cmd_queue = blk_mq_init_queue(>host->tag_set);
@@ -9262,10 +9264,6 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem
*mmio_base, unsigned int irq)
blk_cleanup_queue(hba->cmd_queue);
out_remove_scsi_host:
scsi_remove_host(hba->host);
-exit_gating:
- ufshcd_exit_clk_scaling(hba);
- ufshcd_exit_clk_gating(hba);
- destroy_workqueue(hba->eh_wq);
out_disable:
hba->is_irq_enabled = false;
ufshcd_hba_exit(hba);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 5737679..cb9075d 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -347,6 +347,7 @@ enum clk_gating_state {
* @delay_attr: sysfs attribute to control delay_attr
* @enable_attr: sysfs attribute to enable/disable clock gating
* @is_enabled: Indicates the current status of clock gating
+ * @is_initialized: Indicates
[PATCH v5 1/3] scsi: ufs: Protect some contexts from unexpected clock scaling
In contexts like suspend, shutdown and error handling, we need to suspend
devfreq to make sure these contexts won't be disturbed by clock scaling.
However, suspending devfreq is not enough since users can still trigger a
clock scaling by manipulating the sysfs node clkscale_enable and devfreq
sysfs nodes like min/max_freq and governor. Add one more flag in struct
clk_scaling such that these contexts can prevent clock scaling from being
invoked through above sysfs nodes.
Reviewed-by: Stanley Chu
Reviewed-by: Bean Huo
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 83 +++
drivers/scsi/ufs/ufshcd.h | 6 +++-
2 files changed, 60 insertions(+), 29 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 0c148fc..4ccdd2b 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1147,12 +1147,22 @@ static int ufshcd_clock_scaling_prepare(struct ufs_hba
*hba)
*/
ufshcd_scsi_block_requests(hba);
down_write(>clk_scaling_lock);
- if (ufshcd_wait_for_doorbell_clr(hba, DOORBELL_CLR_TOUT_US)) {
+
+ if (!hba->clk_scaling.is_allowed)
+ ret = -EAGAIN;
+ else if (ufshcd_wait_for_doorbell_clr(hba, DOORBELL_CLR_TOUT_US))
ret = -EBUSY;
+
+ if (ret) {
up_write(>clk_scaling_lock);
ufshcd_scsi_unblock_requests(hba);
+ goto out;
}
+ /* let's not get into low power until clock scaling is completed */
+ ufshcd_hold(hba, false);
+
+out:
return ret;
}
@@ -1160,6 +1170,7 @@ static void ufshcd_clock_scaling_unprepare(struct ufs_hba
*hba)
{
up_write(>clk_scaling_lock);
ufshcd_scsi_unblock_requests(hba);
+ ufshcd_release(hba);
}
/**
@@ -1175,12 +1186,9 @@ static int ufshcd_devfreq_scale(struct ufs_hba *hba,
bool scale_up)
{
int ret = 0;
- /* let's not get into low power until clock scaling is completed */
- ufshcd_hold(hba, false);
-
ret = ufshcd_clock_scaling_prepare(hba);
if (ret)
- goto out;
+ return ret;
/* scale down the gear before scaling down clocks */
if (!scale_up) {
@@ -1212,8 +1220,6 @@ static int ufshcd_devfreq_scale(struct ufs_hba *hba, bool
scale_up)
out_unprepare:
ufshcd_clock_scaling_unprepare(hba);
-out:
- ufshcd_release(hba);
return ret;
}
@@ -1487,7 +1493,7 @@ static ssize_t ufshcd_clkscale_enable_show(struct device
*dev,
{
struct ufs_hba *hba = dev_get_drvdata(dev);
- return snprintf(buf, PAGE_SIZE, "%d\n", hba->clk_scaling.is_allowed);
+ return snprintf(buf, PAGE_SIZE, "%d\n", hba->clk_scaling.is_enabled);
}
static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
@@ -1496,12 +1502,20 @@ static ssize_t ufshcd_clkscale_enable_store(struct
device *dev,
struct ufs_hba *hba = dev_get_drvdata(dev);
u32 value;
int err;
+ unsigned long flags;
+ bool update = true;
if (kstrtou32(buf, 0, ))
return -EINVAL;
value = !!value;
- if (value == hba->clk_scaling.is_allowed)
+ spin_lock_irqsave(hba->host->host_lock, flags);
+ if (value == hba->clk_scaling.is_enabled)
+ update = false;
+ else
+ hba->clk_scaling.is_enabled = value;
+ spin_unlock_irqrestore(hba->host->host_lock, flags);
+ if (!update)
goto out;
pm_runtime_get_sync(hba->dev);
@@ -1510,8 +1524,6 @@ static ssize_t ufshcd_clkscale_enable_store(struct device
*dev,
cancel_work_sync(>clk_scaling.suspend_work);
cancel_work_sync(>clk_scaling.resume_work);
- hba->clk_scaling.is_allowed = value;
-
if (value) {
ufshcd_resume_clkscaling(hba);
} else {
@@ -1845,8 +1857,6 @@ static void ufshcd_init_clk_scaling(struct ufs_hba *hba)
snprintf(wq_name, sizeof(wq_name), "ufs_clkscaling_%d",
hba->host->host_no);
hba->clk_scaling.workq = create_singlethread_workqueue(wq_name);
-
- ufshcd_clkscaling_init_sysfs(hba);
}
static void ufshcd_exit_clk_scaling(struct ufs_hba *hba)
@@ -1854,6 +1864,8 @@ static void ufshcd_exit_clk_scaling(struct ufs_hba *hba)
if (!ufshcd_is_clkscaling_supported(hba))
return;
+ if (hba->devfreq)
+ device_remove_file(hba->dev, >clk_scaling.enable_attr);
destroy_workqueue(hba->clk_scaling.workq);
ufshcd_devfreq_remove(hba);
}
@@ -1918,7 +1930,7 @@ static void ufshcd_clk_scaling_start_busy(struct ufs_hba
*hba)
if (!hba->clk_scaling.active_reqs++)
queue_resume_work = true;
- if (!hba->clk_scaling.is_allowed || hba->pm_op_in_progress)
+ if (!hba->clk_scaling.is_enabled || hba->pm_op_in_progress)
return;
if (queue_resume_work)
@@ -4987,7 +4999,8 @@ static
Re: [PATCH v2] cgroup-v1: add disabled controller check in cgroup1_parse_param()
On 2020/12/18 14:17, Chen Zhou wrote:
> When mounting a cgroup hierarchy with disabled controller in cgroup v1,
> all available controllers will be attached.
>
> Add disabled controller check in cgroup1_parse_param() and return directly
> if the specified controller is disabled.
>
> Signed-off-by: Chen Zhou
> ---
> Changes in v2:
> - Fix line over 80 characters warning.
> ---
> kernel/cgroup/cgroup-v1.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
> index 191c329e482a..5190c42fea8b 100644
> --- a/kernel/cgroup/cgroup-v1.c
> +++ b/kernel/cgroup/cgroup-v1.c
> @@ -915,6 +915,9 @@ int cgroup1_parse_param(struct fs_context *fc, struct
> fs_parameter *param)
> for_each_subsys(ss, i) {
> if (strcmp(param->key, ss->legacy_name))
> continue;
> + if (!cgroup_ssid_enabled(i) || cgroup1_ssid_disabled(i))
> + return invalfc(fc, "Disabled controller '%s'",
> +param->key);
> ctx->subsys_mask |= (1 << i);
> return 0;
> }
Reviewed-by: Zefan Li
[PATCH v2] powerpc/32s: Only build hash code when CONFIG_PPC_BOOK3S_604 is selected
It is now possible to only build book3s/32 kernel for CPUs without hash table. Opt out hash related code when CONFIG_PPC_BOOK3S_604 is not selected. Signed-off-by: Christophe Leroy --- v2: Rebased --- arch/powerpc/kernel/head_book3s_32.S | 12 arch/powerpc/mm/book3s32/Makefile| 4 +++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/head_book3s_32.S b/arch/powerpc/kernel/head_book3s_32.S index 349bf3f0c3af..c02024bce544 100644 --- a/arch/powerpc/kernel/head_book3s_32.S +++ b/arch/powerpc/kernel/head_book3s_32.S @@ -286,6 +286,7 @@ MachineCheck: DO_KVM 0x300 DataAccess: #ifdef CONFIG_VMAP_STACK +#ifdef CONFIG_PPC_BOOK3S_604 BEGIN_MMU_FTR_SECTION mtspr SPRN_SPRG_SCRATCH2,r10 mfspr r10, SPRN_SPRG_THREAD @@ -302,12 +303,14 @@ BEGIN_MMU_FTR_SECTION MMU_FTR_SECTION_ELSE b 1f ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_HPTE_TABLE) +#endif 1: EXCEPTION_PROLOG_0 handle_dar_dsisr=1 EXCEPTION_PROLOG_1 b handle_page_fault_tramp_1 #else /* CONFIG_VMAP_STACK */ EXCEPTION_PROLOG handle_dar_dsisr=1 get_and_save_dar_dsisr_on_stack r4, r5, r11 +#ifdef CONFIG_PPC_BOOK3S_604 BEGIN_MMU_FTR_SECTION andis. r0, r5, (DSISR_BAD_FAULT_32S | DSISR_DABRMATCH)@h bne handle_page_fault_tramp_2 /* if not, try to put a PTE */ @@ -315,8 +318,11 @@ BEGIN_MMU_FTR_SECTION bl hash_page b handle_page_fault_tramp_1 MMU_FTR_SECTION_ELSE +#endif b handle_page_fault_tramp_2 +#ifdef CONFIG_PPC_BOOK3S_604 ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_HPTE_TABLE) +#endif #endif /* CONFIG_VMAP_STACK */ /* Instruction access exception. */ @@ -332,12 +338,14 @@ InstructionAccess: mfspr r11, SPRN_SRR1 /* check whether user or kernel */ stw r11, SRR1(r10) mfcrr10 +#ifdef CONFIG_PPC_BOOK3S_604 BEGIN_MMU_FTR_SECTION andis. r11, r11, SRR1_ISI_NOPT@h /* no pte found? */ bne hash_page_isi .Lhash_page_isi_cont: mfspr r11, SPRN_SRR1 /* check whether user or kernel */ END_MMU_FTR_SECTION_IFSET(MMU_FTR_HPTE_TABLE) +#endif andi. r11, r11, MSR_PR EXCEPTION_PROLOG_1 @@ -348,9 +356,11 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_HPTE_TABLE) beq 1f /* if so, try to put a PTE */ li r3,0/* into the hash table */ mr r4,r12 /* SRR0 is fault address */ +#ifdef CONFIG_PPC_BOOK3S_604 BEGIN_MMU_FTR_SECTION bl hash_page END_MMU_FTR_SECTION_IFSET(MMU_FTR_HPTE_TABLE) +#endif #endif /* CONFIG_VMAP_STACK */ 1: mr r4,r12 andis. r5,r9,DSISR_SRR1_MATCH_32S@h /* Filter relevant SRR1 bits */ @@ -683,6 +693,7 @@ handle_page_fault_tramp_2: EXC_XFER_LITE(0x300, handle_page_fault) #ifdef CONFIG_VMAP_STACK +#ifdef CONFIG_PPC_BOOK3S_604 .macro save_regs_threadthread stw r0, THR0(\thread) stw r3, THR3(\thread) @@ -754,6 +765,7 @@ fast_hash_page_return: mfspr r11, SPRN_SPRG_SCRATCH1 mfspr r10, SPRN_SPRG_SCRATCH0 rfi +#endif /* CONFIG_PPC_BOOK3S_604 */ stack_overflow: vmap_stack_overflow_exception diff --git a/arch/powerpc/mm/book3s32/Makefile b/arch/powerpc/mm/book3s32/Makefile index 3f972db17761..446d9de88ce4 100644 --- a/arch/powerpc/mm/book3s32/Makefile +++ b/arch/powerpc/mm/book3s32/Makefile @@ -6,4 +6,6 @@ ifdef CONFIG_KASAN CFLAGS_mmu.o += -DDISABLE_BRANCH_PROFILING endif -obj-y += mmu.o hash_low.o mmu_context.o tlb.o nohash_low.o +obj-y += mmu.o mmu_context.o +obj-$(CONFIG_PPC_BOOK3S_603) += nohash_low.o +obj-$(CONFIG_PPC_BOOK3S_604) += hash_low.o tlb.o -- 2.25.0
Re: [PATCH] Input: gtco - remove driver
Hi Jiri,
On Thu, Dec 17, 2020 at 12:22:17PM +0100, Jiri Kosina wrote:
> On Sat, 5 Dec 2020, Dmitry Torokhov wrote:
>
> > The driver has its own HID descriptor parsing code, that had and still
> > has several issues discovered by syzbot and other tools. Ideally we
> > should move the driver over to the HID subsystem, so that it uses proven
> > parsing code. However the devices in question are EOL, and GTCO is not
> > willing to extend resources for that, so let's simply remove the driver.
>
> Acked-by: Jiri Kosina
>
> >
> > Note that our HID support has greatly improved over the last 10 years,
> > we may also consider reverting 6f8d9e26e7de ("hid-core.c: Adds all GTCO
> > CalComp Digitizers and InterWrite School Products to blacklist") and see
> > if GTCO devices actually work with normal HID drivers.
>
> Sounds like a good plan to me. Perhaps you can do that in a series
> together, and stage that for 5.12?
Sorry, I already zapped the driver in 5.11.
Unfortunately I do not have this hardware, so while we could remove
these devices from the blacklist we will have to do that blindly. Please
let me know if you still want to do that.
Thank you.
--
Dmitry
Re: 5.10.1: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:1
Hi,
[adding linux-mm]
On 12/16/20 1:54 AM, Toralf Förster wrote:
> Hi,
>
> I got this recently at this hardened Gentoo Linux server:
>
> Linux mr-fox 5.10.1 #1 SMP Tue Dec 15 22:09:42 CET 2020 x86_64 Intel(R)
> Xeon(R) CPU E5-1650 v3 @ 3.50GHz GenuineIntel GNU/Linux
>
>
> Dec 15 23:31:51 mr-fox kernel: [ 1974.206972]
>
> Dec 15 23:31:51 mr-fox kernel: [ 1974.206977] UBSAN: shift-out-of-bounds
> in ./include/linux/log2.h:57:13
> Dec 15 23:31:51 mr-fox kernel: [ 1974.206980] shift exponent 64 is too
> large for 64-bit type 'long unsigned int'
> Dec 15 23:31:51 mr-fox kernel: [ 1974.206982] CPU: 11 PID: 21051 Comm:
> cc1 Tainted: G T 5.10.1 #1
> Dec 15 23:31:51 mr-fox kernel: [ 1974.206984] Hardware name: ASUSTeK
> COMPUTER INC. Z10PA-U8 Series/Z10PA-U8 Series, BIOS 3703 08/02/2018
> Dec 15 23:31:51 mr-fox kernel: [ 1974.206985] Call Trace:
> Dec 15 23:31:51 mr-fox kernel: [ 1974.206993] dump_stack+0x57/0x6a
> Dec 15 23:31:51 mr-fox kernel: [ 1974.206996] ubsan_epilogue+0x5/0x40
> Dec 15 23:31:51 mr-fox kernel: [ 1974.206999]
> __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207002]
> ondemand_readahead.cold+0x16/0x21
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207007]
> generic_file_buffered_read+0x452/0x890
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207011] new_sync_read+0x156/0x200
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207014] vfs_read+0xf8/0x190
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207016] ksys_read+0x65/0xe0
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207018] do_syscall_64+0x33/0x40
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207021]
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207024] RIP: 0033:0x7f01b2df198e
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207026] Code: c0 e9 b6 fe ff ff 50
> 48 8d 3d 66 c3 09 00 e8 59 e2 01 00 66 0f 1f 84 00 00 00 00 00 64 8b 04
> 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f
> 84 00 00 00 00 00 48 83 ec 28
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207028] RSP: 002b:7fff2167e998
> EFLAGS: 0246 ORIG_RAX:
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207030] RAX: ffda RBX:
> RCX: 7f01b2df198e
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207032] RDX: RSI:
> 054dcc50 RDI: 0004
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207033] RBP: 054dcc50 R08:
> 054dcc50 R09:
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207034] R10: R11:
> 0246 R12: 054dc3b0
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207035] R13: 8000 R14:
> 054c9800 R15:
> Dec 15 23:31:51 mr-fox kernel: [ 1974.207037]
>
>
>
> Known issue ?
Not that I have heard about, but that's not conclusive.
Looks to me like this is in mm/readahead.c:
static unsigned long get_init_ra_size(unsigned long size, unsigned long max)
{
unsigned long newsize = roundup_pow_of_two(size);
What filesystem? What workload?
thanks.
--
~Randy
[PATCH] Input: da7280 - protect OF match table with CONFIG_OF
The OF match table is only used when OF is enabled.
Fixes: cd3f609823a5 ("Input: new da7280 haptic driver")
Reported-by: kernel test robot
Signed-off-by: Dmitry Torokhov
---
drivers/input/misc/da7280.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c
index 2f698a8c1d65..b08610d6e575 100644
--- a/drivers/input/misc/da7280.c
+++ b/drivers/input/misc/da7280.c
@@ -1300,11 +1300,13 @@ static int __maybe_unused da7280_resume(struct device
*dev)
return retval;
}
+#ifdef CONFIG_OF
static const struct of_device_id da7280_of_match[] = {
{ .compatible = "dlg,da7280", },
{ }
};
MODULE_DEVICE_TABLE(of, da7280_of_match);
+#endif
static const struct i2c_device_id da7280_i2c_id[] = {
{ "da7280", },
--
2.29.2.729.g45daf8777d-goog
--
Dmitry
Re: [PATCH v2] xen/xenbus: make xs_talkv() interruptible
On 17.12.20 19:25, Andrew Cooper wrote:
On 16/12/2020 08:21, Jürgen Groß wrote:
On 15.12.20 21:59, Andrew Cooper wrote:
On 15/12/2020 11:10, Juergen Gross wrote:
In case a process waits for any Xenstore action in the xenbus driver
it should be interruptible by signals.
Signed-off-by: Juergen Gross
---
V2:
- don't special case SIGKILL as libxenstore is handling -EINTR fine
---
drivers/xen/xenbus/xenbus_xs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_xs.c
b/drivers/xen/xenbus/xenbus_xs.c
index 3a06eb699f33..17c8f8a155fd 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -205,8 +205,15 @@ static bool test_reply(struct xb_req_data *req)
static void *read_reply(struct xb_req_data *req)
{
+ int ret;
+
do {
- wait_event(req->wq, test_reply(req));
+ ret = wait_event_interruptible(req->wq, test_reply(req));
+
+ if (ret == -ERESTARTSYS && signal_pending(current)) {
+ req->msg.type = XS_ERROR;
+ return ERR_PTR(-EINTR);
+ }
So now I can talk fully about the situations which lead to this, I think
there is a bit more complexity.
It turns out there are a number of issues related to running a Xen
system with no xenstored.
1) If a xenstore-write occurs during startup before init-xenstore-domain
runs, the former blocks on /dev/xen/xenbus waiting for xenstored to
reply, while the latter blocks on /dev/xen/xenbus_backend when trying to
tell the dom0 kernel that xenstored is in dom1. This effectively
deadlocks the system.
This should be easy to solve: any request to /dev/xen/xenbus should
block upfront in case xenstored isn't up yet (could e.g. wait
interruptible until xenstored_ready is non-zero).
I'm not sure that that would fix the problem. The problem is that
setting the ring details via /dev/xen/xenbus_backend blocks, which
prevents us launching the xenstored stubdomain, which prevents the
earlier xenbus write being completed.
But _why_ is it blocking? Digging through the code I think it blocks
is xs_suspend() due to the normal xenstore request being pending. If
that request doesn't reach the state to cause blocking in xs_suspend()
all is fine.
So long as /dev/xen/xenbus_backend doesn't block, there's no problem
with other /dev/xen/xenbus activity being pending briefly.
Looking at the current logic, I'm not completely convinced. Even
finding a filled-in evtchn/gfn doesn't mean that xenstored is actually
ready.
No, but the deadlock is not going to happen anymore (famous last
words).
There are 3 possible cases.
1) PV guest, and details in start_info
2) HVM guest, and details in HVM_PARAMs
3) No details (expected for dom0). Something in userspace must provide
details at a later point.
So the setup phases go from nothing, to having ring details, to finding
the ring working.
I think it would be prudent to try reading a key between having details
and declaring the xenstored_ready. Any activity, even XS_ERROR,
indicates that the other end of the ring is listening.
Yes. But I really think the xs_suspend() is the problematic case. And
this will be called _before_ xenstored_ready is being set.
2) If xenstore-watch is running when xenstored dies, it spins at 100%
cpu usage making no system calls at all. This is caused by bad error
handling from xs_watch(), and attempting to debug found:
Can you expand on "bad error handling from xs_watch()", please?
do_watch() has
for ( ... ) { // defaults to an infinite loop
vec = xs_read_watch();
if (vec == NULL)
continue;
...
}
My next plan was to experiment with break instead of continue, which
I'll get to at some point.
I'd rather put a sleep() in. Otherwise you might break some use cases.
3) (this issue). If anyone starts xenstore-watch with no xenstored
running at all, it blocks in D in the kernel.
Should be handled with solution for 1).
The cause is the special handling for watch/unwatch commands which,
instead of just queuing up the data for xenstore, explicitly waits for
an OK for registering the watch. This causes a write() system call to
block waiting for a non-existent entity to reply.
So while this patch does resolve the major usability issue I found (I
can't even SIGINT and get my terminal back), I think there are issues.
The reason why XS_WATCH/XS_UNWATCH are special cased is because they do
require special handling. The main kernel thread for processing
incoming data from xenstored does need to know how to associate each
async XS_WATCH_EVENT to the caller who watched the path.
Therefore, depending on when this cancellation hits, we might be in any
of the following states:
1) the watch is queued in the kernel, but not even sent to xenstored yet
2) the watch is queued in the xenstored ring, but not acted upon
3) the watch is queued in the xenstored ring, and the xenstored has seen
it but not replied yet
Re: [PATCH v1 4/5] driver core: Handle cycles in device links created by fw_devlink
Hi Saravana,
I love your patch! Perhaps something to improve:
[auto build test WARNING on driver-core/driver-core-testing]
[also build test WARNING on linus/master next-20201217]
[cannot apply to linux/master v5.10]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Saravana-Kannan/Enable-fw_devlink-on-by-default/20201218-112111
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
accefff5b547a9a1d959c7e76ad539bf2480e78b
config: mips-randconfig-r016-20201217 (attached as .config)
compiler: mips64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/7bdc87ea0400318d827410f454ec7e5fbaf470c3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Saravana-Kannan/Enable-fw_devlink-on-by-default/20201218-112111
git checkout 7bdc87ea0400318d827410f454ec7e5fbaf470c3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/base/core.c:1522:5: warning: no previous prototype for
>> 'fw_devlink_relax_cycle' [-Wmissing-prototypes]
1522 | int fw_devlink_relax_cycle(struct device *con, void *sup)
| ^~
vim +/fw_devlink_relax_cycle +1522 drivers/base/core.c
1507
1508 /**
1509 * fw_devlink_relax_cycle - Convert cyclic links to SYNC_STATE_ONLY
links
1510 * @con: Device to check dependencies for.
1511 * @sup: Device to check against.
1512 *
1513 * Check if @sup depends on @con or any device dependent on it (its
child or
1514 * its consumer etc). When such a cyclic dependency is found, convert
all
1515 * device links created solely by fw_devlink into SYNC_STATE_ONLY
device links.
1516 * This is the equivalent of doing fw_devlink=permissive just between
the
1517 * devices in the cycle. We need to do this because, at this point,
fw_devlink
1518 * can't tell which of these dependencies is not a real dependency.
1519 *
1520 * Return 1 if a cycle is found. Otherwise, return 0.
1521 */
> 1522 int fw_devlink_relax_cycle(struct device *con, void *sup)
1523 {
1524 struct device_link *link;
1525 int ret;
1526
1527 if (con == sup)
1528 return 1;
1529
1530 ret = device_for_each_child(con, sup, fw_devlink_relax_cycle);
1531 if (ret)
1532 return ret;
1533
1534 list_for_each_entry(link, >links.consumers, s_node) {
1535 if ((link->flags & ~DL_FLAG_INFERRED) ==
1536 (DL_FLAG_SYNC_STATE_ONLY | DL_FLAG_MANAGED))
1537 continue;
1538
1539 if (!fw_devlink_relax_cycle(link->consumer, sup))
1540 continue;
1541
1542 ret = 1;
1543
1544 if (!(link->flags & DL_FLAG_INFERRED))
1545 continue;
1546
1547 pm_runtime_drop_link(link);
1548 link->flags = DL_FLAG_MANAGED |
FW_DEVLINK_FLAGS_PERMISSIVE;
1549 dev_dbg(link->consumer, "Relaxing link with %s\n",
1550 dev_name(link->supplier));
1551 }
1552 return ret;
1553 }
1554
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] block/rnbd: Adding name to the Contributors List
Hi Jens, On Thu, Dec 17, 2020 at 6:44 PM swapnil ingle wrote: > > Adding linux-r...@vger.kernel.org > > On Fri, Nov 27, 2020 at 1:54 PM Danil Kipnis > wrote: >> >> On Fri, Nov 27, 2020 at 1:31 PM Swapnil Ingle wrote: >> > >> > Adding name to the Contributors List >> > >> > Signed-off-by: Swapnil Ingle >> >> Acked-by: Danil Kipnis Can you pick up this patch, or do you need a resend from me or Swapnil? Thanks! Jack >> >> > --- >> > drivers/block/rnbd/README | 1 + >> > 1 file changed, 1 insertion(+) >> > >> > diff --git a/drivers/block/rnbd/README b/drivers/block/rnbd/README >> > index 1773c0a..080f58a 100644 >> > --- a/drivers/block/rnbd/README >> > +++ b/drivers/block/rnbd/README >> > @@ -90,3 +90,4 @@ Kleber Souza >> > Lutz Pogrell >> > Milind Dumbare >> > Roman Penyaev >> > +Swapnil Ingle >> > -- >> > 1.8.3.1 >> >
Re: [PATCH v1 4/5] driver core: Handle cycles in device links created by fw_devlink
Hi Saravana, I love your patch! Perhaps something to improve: [auto build test WARNING on driver-core/driver-core-testing] [also build test WARNING on linus/master next-20201217] [cannot apply to linux/master v5.10] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Saravana-Kannan/Enable-fw_devlink-on-by-default/20201218-112111 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git accefff5b547a9a1d959c7e76ad539bf2480e78b config: i386-randconfig-s001-20201217 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.3-184-g1b896707-dirty # https://github.com/0day-ci/linux/commit/7bdc87ea0400318d827410f454ec7e5fbaf470c3 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Saravana-Kannan/Enable-fw_devlink-on-by-default/20201218-112111 git checkout 7bdc87ea0400318d827410f454ec7e5fbaf470c3 # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" >> drivers/base/core.c:1522:5: sparse: sparse: symbol 'fw_devlink_relax_cycle' >> was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[RFC PATCH] driver core: fw_devlink_relax_cycle() can be static
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 4cc0303611650c..4e15193aafad6a 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1519,7 +1519,7 @@ static void fw_devlink_parse_fwtree(struct fwnode_handle
*fwnode)
*
* Return 1 if a cycle is found. Otherwise, return 0.
*/
-int fw_devlink_relax_cycle(struct device *con, void *sup)
+static int fw_devlink_relax_cycle(struct device *con, void *sup)
{
struct device_link *link;
int ret;
Re: [PATCH v2 0/4] scsi: ufs: Cleanup and refactor clock scaling
On 2020-12-18 14:24, Stanley Chu wrote: Hi Can, On Fri, 2020-12-18 at 14:20 +0800, Can Guo wrote: On 2020-12-16 21:16, Stanley Chu wrote: > Hi, > This series cleans up and refactors clk-scaling feature, and shall not > change any functionality. > > This series is based on Can's series "Three changes related with UFS > clock scaling" in 5.10/scsi-fixes branch in Martin's tree. > Hi Stanley, Thanks for noticing my changes, will you review them? I see customers manipulte UFS scaling related sysfs nodes more often than before, so we may want to fix it asap. I have gave my review tag in all patches in this series : ) Thanks, Stanley Chu Hi Stanley, oops, just saw it - I opened the wrong series. I will push a new version which incorporates your comments soon. Since the new changes would only be some words in ufshcd.h, so you won't need to rebase. Thanks, Can Guo. Regards, Can Guo. > However this series may not be required to be merged to 5.10. The > choice of base branch is simply making these patches easy to be > reviewed because this series is based on clk-scaling fixes by Can. If > this series is decided not being merged to 5.10, then I would rebase > it to 5.11/scsi-queue. > > Changes since v1: > - Refactor ufshcd_clk_scaling_suspend() in patch [3/4] > - Change function name from ufshcd_clk_scaling_pm() to > ufshcd_clk_scaling_suspend() in patch [3/4] > - Refine patch titles > > Stanley Chu (4): > scsi: ufs: Refactor cancelling clkscaling works > scsi: ufs: Remove redundant null checking of devfreq instance > scsi: ufs: Cleanup and refactor clk-scaling feature > scsi: ufs: Fix build warning by incorrect function description > > drivers/scsi/ufs/ufshcd.c | 90 +++ > 1 file changed, 43 insertions(+), 47 deletions(-)
Re: drivers/tty/vt/keyboard.c:2037:13: sparse: sparse: incorrect type in initializer (different address spaces)
On 16. 12. 20, 13:07, kernel test robot wrote: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d01e7f10dae29eba0f9ada82b65d24e035d5b2f9 commit: 07edff9265204e15c9fc8d07cc69e38c4c484e15 vt: keyboard, reorder user buffer handling in vt_do_kdgkb_ioctl date: 6 weeks ago config: sh-randconfig-s032-20201216 (attached as .config) compiler: sh4-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-184-g1b896707-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=07edff9265204e15c9fc8d07cc69e38c4c484e15 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 07edff9265204e15c9fc8d07cc69e38c4c484e15 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sh If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" drivers/tty/vt/keyboard.c:1745:21: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected unsigned int const *__gu_addr @@ got unsigned int [noderef] __user * @@ drivers/tty/vt/keyboard.c:1745:21: sparse: expected unsigned int const *__gu_addr drivers/tty/vt/keyboard.c:1745:21: sparse: got unsigned int [noderef] __user * drivers/tty/vt/keyboard.c:1745:21: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ Guys, any idea why __gu_addr in superH's __get_user_check is not marked as __user? thanks, -- js suse labs
Re: [PATCH v4 1/3] scsi: ufs: Protect some contexts from unexpected clock scaling
On 2020-12-15 13:43, Stanley Chu wrote:
Hi Can,
On Sun, 2020-12-13 at 08:31 -0800, Can Guo wrote:
In contexts like suspend, shutdown and error handling, we need to
suspend
devfreq to make sure these contexts won't be disturbed by clock
scaling.
However, suspending devfreq is not enough since users can still
trigger a
clock scaling by manipulating the sysfs node clkscale_enable and
devfreq
sysfs nodes like min/max_freq and governor. Add one more flag in
struct
clk_scaling such that these contexts can prevent clock scaling from
being
invoked through above sysfs nodes.
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 83
+++
drivers/scsi/ufs/ufshcd.h | 2 ++
2 files changed, 57 insertions(+), 28 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 0c148fc..4ccdd2b 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1147,12 +1147,22 @@ static int ufshcd_clock_scaling_prepare(struct
ufs_hba *hba)
*/
ufshcd_scsi_block_requests(hba);
down_write(>clk_scaling_lock);
- if (ufshcd_wait_for_doorbell_clr(hba, DOORBELL_CLR_TOUT_US)) {
+
+ if (!hba->clk_scaling.is_allowed)
+ ret = -EAGAIN;
+ else if (ufshcd_wait_for_doorbell_clr(hba, DOORBELL_CLR_TOUT_US))
ret = -EBUSY;
+
+ if (ret) {
up_write(>clk_scaling_lock);
ufshcd_scsi_unblock_requests(hba);
+ goto out;
}
+ /* let's not get into low power until clock scaling is completed */
+ ufshcd_hold(hba, false);
+
+out:
return ret;
}
@@ -1160,6 +1170,7 @@ static void
ufshcd_clock_scaling_unprepare(struct ufs_hba *hba)
{
up_write(>clk_scaling_lock);
ufshcd_scsi_unblock_requests(hba);
+ ufshcd_release(hba);
}
/**
@@ -1175,12 +1186,9 @@ static int ufshcd_devfreq_scale(struct ufs_hba
*hba, bool scale_up)
{
int ret = 0;
- /* let's not get into low power until clock scaling is completed */
- ufshcd_hold(hba, false);
-
ret = ufshcd_clock_scaling_prepare(hba);
if (ret)
- goto out;
+ return ret;
/* scale down the gear before scaling down clocks */
if (!scale_up) {
@@ -1212,8 +1220,6 @@ static int ufshcd_devfreq_scale(struct ufs_hba
*hba, bool scale_up)
out_unprepare:
ufshcd_clock_scaling_unprepare(hba);
-out:
- ufshcd_release(hba);
return ret;
}
@@ -1487,7 +1493,7 @@ static ssize_t
ufshcd_clkscale_enable_show(struct device *dev,
{
struct ufs_hba *hba = dev_get_drvdata(dev);
- return snprintf(buf, PAGE_SIZE, "%d\n",
hba->clk_scaling.is_allowed);
+ return snprintf(buf, PAGE_SIZE, "%d\n",
hba->clk_scaling.is_enabled);
}
static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
@@ -1496,12 +1502,20 @@ static ssize_t
ufshcd_clkscale_enable_store(struct device *dev,
struct ufs_hba *hba = dev_get_drvdata(dev);
u32 value;
int err;
+ unsigned long flags;
+ bool update = true;
if (kstrtou32(buf, 0, ))
return -EINVAL;
value = !!value;
- if (value == hba->clk_scaling.is_allowed)
+ spin_lock_irqsave(hba->host->host_lock, flags);
+ if (value == hba->clk_scaling.is_enabled)
+ update = false;
+ else
+ hba->clk_scaling.is_enabled = value;
+ spin_unlock_irqrestore(hba->host->host_lock, flags);
+ if (!update)
goto out;
pm_runtime_get_sync(hba->dev);
@@ -1510,8 +1524,6 @@ static ssize_t
ufshcd_clkscale_enable_store(struct device *dev,
cancel_work_sync(>clk_scaling.suspend_work);
cancel_work_sync(>clk_scaling.resume_work);
- hba->clk_scaling.is_allowed = value;
-
if (value) {
ufshcd_resume_clkscaling(hba);
} else {
@@ -1845,8 +1857,6 @@ static void ufshcd_init_clk_scaling(struct
ufs_hba *hba)
snprintf(wq_name, sizeof(wq_name), "ufs_clkscaling_%d",
hba->host->host_no);
hba->clk_scaling.workq = create_singlethread_workqueue(wq_name);
-
- ufshcd_clkscaling_init_sysfs(hba);
}
static void ufshcd_exit_clk_scaling(struct ufs_hba *hba)
@@ -1854,6 +1864,8 @@ static void ufshcd_exit_clk_scaling(struct
ufs_hba *hba)
if (!ufshcd_is_clkscaling_supported(hba))
return;
+ if (hba->devfreq)
+ device_remove_file(hba->dev, >clk_scaling.enable_attr);
destroy_workqueue(hba->clk_scaling.workq);
ufshcd_devfreq_remove(hba);
}
@@ -1918,7 +1930,7 @@ static void ufshcd_clk_scaling_start_busy(struct
ufs_hba *hba)
if (!hba->clk_scaling.active_reqs++)
queue_resume_work = true;
- if (!hba->clk_scaling.is_allowed || hba->pm_op_in_progress)
+ if (!hba->clk_scaling.is_enabled || hba->pm_op_in_progress)
return;
if
Re: [PATCH v2 0/4] scsi: ufs: Cleanup and refactor clock scaling
Hi Can, On Fri, 2020-12-18 at 14:20 +0800, Can Guo wrote: > On 2020-12-16 21:16, Stanley Chu wrote: > > Hi, > > This series cleans up and refactors clk-scaling feature, and shall not > > change any functionality. > > > > This series is based on Can's series "Three changes related with UFS > > clock scaling" in 5.10/scsi-fixes branch in Martin's tree. > > > > Hi Stanley, > > Thanks for noticing my changes, will you review them? > I see customers manipulte UFS scaling related sysfs > nodes more often than before, so we may want to fix it asap. I have gave my review tag in all patches in this series : ) Thanks, Stanley Chu > > Regards, > > Can Guo. > > > However this series may not be required to be merged to 5.10. The > > choice of base branch is simply making these patches easy to be > > reviewed because this series is based on clk-scaling fixes by Can. If > > this series is decided not being merged to 5.10, then I would rebase > > it to 5.11/scsi-queue. > > > > Changes since v1: > > - Refactor ufshcd_clk_scaling_suspend() in patch [3/4] > > - Change function name from ufshcd_clk_scaling_pm() to > > ufshcd_clk_scaling_suspend() in patch [3/4] > > - Refine patch titles > > > > Stanley Chu (4): > > scsi: ufs: Refactor cancelling clkscaling works > > scsi: ufs: Remove redundant null checking of devfreq instance > > scsi: ufs: Cleanup and refactor clk-scaling feature > > scsi: ufs: Fix build warning by incorrect function description > > > > drivers/scsi/ufs/ufshcd.c | 90 +++ > > 1 file changed, 43 insertions(+), 47 deletions(-)
Re: [PATCH v12 2/4] powerpc: Move arch independent ima kexec functions to drivers/of/kexec.c
On 12/17/20 2:01 PM, Rob Herring wrote: [...] +#ifdef CONFIG_IMA_KEXEC +/** + * arch_ima_add_kexec_buffer - do arch-specific steps to add the IMA buffer + * + * @image: kimage struct to set IMA buffer data + * @load_addr: Starting address where IMA buffer is loaded at + * @size: Number of bytes in the IMA buffer + * + * Architectures should use this function to pass on the IMA buffer + * information to the next kernel. + * + * Return: 0 on success, negative errno on error. + */ +int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr, + size_t size) This should be a static inline in asm/kexec.h. arch_ima_add_kexec_buffer() is identical for powerpc and arm64. Would it be better to "static inline" this function in "of.h" instead of duplicating it in "asm/kexec.h" for powerpc and arm64? No, think about what it is specific to and place it there. It has nothing to do with DT really. All it is is a wrapper to access the struct members in kimage_arch. So it belongs where they are declared. Now perhaps ima_buffer_addr and ima_buffer_size shouldn't be arch specific, but that's a separate issue. Since "struct kimage" definition is not available in "asm/kexec.h", defining arch_ima_add_kexec_buffer() in this header file results in the following build error: ./arch/powerpc/include/asm/kexec.h: In function 'arch_ima_add_kexec_buffer': ./arch/powerpc/include/asm/kexec.h:139:7: error: 'struct kimage' has no member named 'arch' 139 | image->arch.ima_buffer_addr = load_addr; I think it would be appropriate to make arch_ima_add_kexec_buffer() a static inline function in "security/integrity/ima/ima_kexec.c" - the only file where this function is used. This will also enable sharing this function for powerpc and arm64 architectures. thanks, -lakshmi
[PATCH] lib/logic_pio: Fix overlap check for pio registery
Since the [start, end) is a half-open interval, a range with the end equal
to the start of another range should not be considered as overlapped.
Signed-off-by: Jiahui Cen
---
lib/logic_pio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/logic_pio.c b/lib/logic_pio.c
index f32fe481b492..445d611f1dc1 100644
--- a/lib/logic_pio.c
+++ b/lib/logic_pio.c
@@ -57,7 +57,7 @@ int logic_pio_register_range(struct logic_pio_hwaddr
*new_range)
new_range->flags == LOGIC_PIO_CPU_MMIO) {
/* for MMIO ranges we need to check for overlap */
if (start >= range->hw_start + range->size ||
- end < range->hw_start) {
+ end <= range->hw_start) {
mmio_end = range->io_start + range->size;
} else {
ret = -EFAULT;
--
2.28.0
[PATCH] powerpc/mm: Limit allocation of SWIOTLB on server machines
On server-class POWER machines, we don't need the SWIOTLB unless we're a
secure VM. Nevertheless, if CONFIG_SWIOTLB is enabled we unconditionally
allocate it.
In most cases this is harmless, but on a few machine configurations (e.g.,
POWER9 powernv systems with 4 GB area reserved for crashdump kernel) it can
happen that memblock can't find a 64 MB chunk of memory for the SWIOTLB and
fails with a scary-looking WARN_ONCE:
[ cut here ]
memblock: bottom-up allocation failed, memory hotremove may be affected
WARNING: CPU: 0 PID: 0 at mm/memblock.c:332
memblock_find_in_range_node+0x328/0x340
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0-rc2-orig+ #6
NIP: c0442f38 LR: c0442f34 CTR: c01e0080
REGS: c1def900 TRAP: 0700 Not tainted (5.10.0-rc2-orig+)
MSR: 92021033 CR: 2802 XER: 2004
CFAR: c014b7b4 IRQMASK: 1
GPR00: c0442f34 c1defba0 c1deff00 0047
GPR04: 7fff c1def828 c1def820
GPR08: 001ffc3e c1b75478 c1b75478 0001
GPR12: 2000 c203
GPR16: 0203
GPR20: 0001 0001 c1defc10
GPR24: c1defc08 c1c91868 c1defc18 c1c91890
GPR28: 0400
NIP [c0442f38] memblock_find_in_range_node+0x328/0x340
LR [c0442f34] memblock_find_in_range_node+0x324/0x340
Call Trace:
[c1defba0] [c0442f34] memblock_find_in_range_node+0x324/0x340
(unreliable)
[c1defc90] [c15ac088] memblock_alloc_range_nid+0xec/0x1b0
[c1defd40] [c15ac1f8] memblock_alloc_internal+0xac/0x110
[c1defda0] [c15ac4d0] memblock_alloc_try_nid+0x94/0xcc
[c1defe30] [c159c3c8] swiotlb_init+0x78/0x104
[c1defea0] [c158378c] mem_init+0x4c/0x98
[c1defec0] [c157457c] start_kernel+0x714/0xac8
[c1deff90] [c000d244] start_here_common+0x1c/0x58
Instruction dump:
2c23 4182ffd4 ea610088 ea810090 4bfffe84 3921 3d42fff4 3c62ff60
3863c560 992a8bfc 4bd0881d 6000 <0fe0> ea610088 4bfffd94 6000
random: get_random_bytes called from __warn+0x128/0x184 with crng_init=0
---[ end trace ]---
software IO TLB: Cannot allocate buffer
Unless this is a secure VM the message can actually be ignored, because the
SWIOTLB isn't needed. Therefore, let's avoid the SWIOTLB in those cases.
Fixes: eae9eec476d1 ("powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in
memory")
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/mm/mem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index afab328d0887..3af991844145 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -300,7 +300,8 @@ void __init mem_init(void)
memblock_set_bottom_up(true);
if (is_secure_guest())
svm_swiotlb_init();
- else
+ /* Server machines don't need SWIOTLB if they're not secure guests. */
+ else if (!machine_is(pseries) && !machine_is(powernv))
swiotlb_init(0);
#endif
Re: [PATCH v2 0/4] scsi: ufs: Cleanup and refactor clock scaling
On 2020-12-16 21:16, Stanley Chu wrote: Hi, This series cleans up and refactors clk-scaling feature, and shall not change any functionality. This series is based on Can's series "Three changes related with UFS clock scaling" in 5.10/scsi-fixes branch in Martin's tree. Hi Stanley, Thanks for noticing my changes, will you review them? I see customers manipulte UFS scaling related sysfs nodes more often than before, so we may want to fix it asap. Regards, Can Guo. However this series may not be required to be merged to 5.10. The choice of base branch is simply making these patches easy to be reviewed because this series is based on clk-scaling fixes by Can. If this series is decided not being merged to 5.10, then I would rebase it to 5.11/scsi-queue. Changes since v1: - Refactor ufshcd_clk_scaling_suspend() in patch [3/4] - Change function name from ufshcd_clk_scaling_pm() to ufshcd_clk_scaling_suspend() in patch [3/4] - Refine patch titles Stanley Chu (4): scsi: ufs: Refactor cancelling clkscaling works scsi: ufs: Remove redundant null checking of devfreq instance scsi: ufs: Cleanup and refactor clk-scaling feature scsi: ufs: Fix build warning by incorrect function description drivers/scsi/ufs/ufshcd.c | 90 +++ 1 file changed, 43 insertions(+), 47 deletions(-)
Re: [PATCH v2 4/4] scsi: ufs: Fix build warning by incorrect function description
On 2020-12-16 21:16, Stanley Chu wrote: Fix build warnings as below due to incorrect function description of ufshcd_try_to_abort_task(). ufshcd.c:6651: warning: Function parameter or member 'hba' not described in 'ufshcd_try_to_abort_task' ufshcd.c:6651: warning: Function parameter or member 'tag' not described in 'ufshcd_try_to_abort_task' ufshcd.c:6651: warning: Excess function parameter 'cmd' description in 'ufshcd_try_to_abort_task' Signed-off-by: Stanley Chu --- drivers/scsi/ufs/ufshcd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index ce0528f2e2ed..79287fdd049b 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -6652,7 +6652,8 @@ static void ufshcd_set_req_abort_skip(struct ufs_hba *hba, unsigned long bitmap) /** * ufshcd_try_to_abort_task - abort a specific task - * @cmd: SCSI command pointer + * @hba: per adapter instance + * @tag: position of the bit to be aborted * * Abort the pending command in device by sending UFS_ABORT_TASK task management * command, and in host controller by clearing the door-bell register. There can Thanks for the fix. Reviewed-by: Can Guo
Re: [PATCH v2 3/4] scsi: ufs: Cleanup and refactor clk-scaling feature
On 2020-12-16 21:16, Stanley Chu wrote:
Manipulate clock scaling related stuff only if the host capability
supports clock scaling feature to avoid redundant code execution.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd.c | 64 ---
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 9cc16598136d..ce0528f2e2ed 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1448,9 +1448,6 @@ static void ufshcd_suspend_clkscaling(struct
ufs_hba *hba)
unsigned long flags;
bool suspend = false;
- if (!ufshcd_is_clkscaling_supported(hba))
- return;
-
cancel_work_sync(>clk_scaling.suspend_work);
cancel_work_sync(>clk_scaling.resume_work);
@@ -1470,9 +1467,6 @@ static void ufshcd_resume_clkscaling(struct
ufs_hba *hba)
unsigned long flags;
bool resume = false;
- if (!ufshcd_is_clkscaling_supported(hba))
- return;
-
spin_lock_irqsave(hba->host->host_lock, flags);
if (hba->clk_scaling.is_suspended) {
resume = true;
@@ -5642,6 +5636,26 @@ static inline void
ufshcd_schedule_eh_work(struct ufs_hba *hba)
}
}
+static void ufshcd_clk_scaling_allow(struct ufs_hba *hba, bool allow)
+{
+ down_write(>clk_scaling_lock);
+ hba->clk_scaling.is_allowed = allow;
+ up_write(>clk_scaling_lock);
+}
+
+static void ufshcd_clk_scaling_suspend(struct ufs_hba *hba, bool
suspend)
+{
+ if (suspend) {
+ if (hba->clk_scaling.is_enabled)
+ ufshcd_suspend_clkscaling(hba);
+ ufshcd_clk_scaling_allow(hba, false);
+ } else {
+ ufshcd_clk_scaling_allow(hba, true);
+ if (hba->clk_scaling.is_enabled)
+ ufshcd_resume_clkscaling(hba);
+ }
+}
+
static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
{
pm_runtime_get_sync(hba->dev);
@@ -5663,23 +5677,20 @@ static void ufshcd_err_handling_prepare(struct
ufs_hba *hba)
ufshcd_vops_resume(hba, UFS_RUNTIME_PM);
} else {
ufshcd_hold(hba, false);
- if (hba->clk_scaling.is_enabled)
+ if (ufshcd_is_clkscaling_supported(hba) &&
+ hba->clk_scaling.is_enabled)
ufshcd_suspend_clkscaling(hba);
}
- down_write(>clk_scaling_lock);
- hba->clk_scaling.is_allowed = false;
- up_write(>clk_scaling_lock);
+ ufshcd_clk_scaling_allow(hba, false);
}
static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
{
ufshcd_release(hba);
- down_write(>clk_scaling_lock);
- hba->clk_scaling.is_allowed = true;
- up_write(>clk_scaling_lock);
- if (hba->clk_scaling.is_enabled)
- ufshcd_resume_clkscaling(hba);
+ if (ufshcd_is_clkscaling_supported(hba))
+ ufshcd_clk_scaling_suspend(hba, false);
+
pm_runtime_put(hba->dev);
}
@@ -8507,12 +8518,8 @@ static int ufshcd_suspend(struct ufs_hba *hba,
enum ufs_pm_op pm_op)
ufshcd_hold(hba, false);
hba->clk_gating.is_suspended = true;
- if (hba->clk_scaling.is_enabled)
- ufshcd_suspend_clkscaling(hba);
-
- down_write(>clk_scaling_lock);
- hba->clk_scaling.is_allowed = false;
- up_write(>clk_scaling_lock);
+ if (ufshcd_is_clkscaling_supported(hba))
+ ufshcd_clk_scaling_suspend(hba, true);
if (req_dev_pwr_mode == UFS_ACTIVE_PWR_MODE &&
req_link_state == UIC_LINK_ACTIVE_STATE) {
@@ -8618,11 +8625,9 @@ static int ufshcd_suspend(struct ufs_hba *hba,
enum ufs_pm_op pm_op)
if (!ufshcd_set_dev_pwr_mode(hba, UFS_ACTIVE_PWR_MODE))
ufshcd_disable_auto_bkops(hba);
enable_gating:
- down_write(>clk_scaling_lock);
- hba->clk_scaling.is_allowed = true;
- up_write(>clk_scaling_lock);
- if (hba->clk_scaling.is_enabled)
- ufshcd_resume_clkscaling(hba);
+ if (ufshcd_is_clkscaling_supported(hba))
+ ufshcd_clk_scaling_suspend(hba, false);
+
hba->clk_gating.is_suspended = false;
hba->dev_info.b_rpm_dev_flush_capable = false;
ufshcd_release(hba);
@@ -8719,11 +8724,8 @@ static int ufshcd_resume(struct ufs_hba *hba,
enum ufs_pm_op pm_op)
hba->clk_gating.is_suspended = false;
- down_write(>clk_scaling_lock);
- hba->clk_scaling.is_allowed = true;
- up_write(>clk_scaling_lock);
- if (hba->clk_scaling.is_enabled)
- ufshcd_resume_clkscaling(hba);
+ if (ufshcd_is_clkscaling_supported(hba))
+ ufshcd_clk_scaling_suspend(hba, false);
/* Enable Auto-Hibernate if configured */
ufshcd_auto_hibern8_enable(hba);
Thanks for the cleanup
Reviewed-by: Can Guo
Re: [net-next PATCH v2 10/14] device property: Introduce fwnode_get_id()
On Tue, Dec 15, 2020 at 07:45:16PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson
> wrote:
> >
> > Using fwnode_get_id(), get the reg property value for DT node
> > and get the _ADR object value for ACPI node.
>
> and -> or
>
> ...
>
> > +/**
> > + * fwnode_get_id - Get the id of a fwnode.
> > + * @fwnode: firmware node
> > + * @id: id of the fwnode
> > + *
> > + * Returns 0 on success or a negative errno.
> > + */
> > +int fwnode_get_id(struct fwnode_handle *fwnode, u32 *id)
> > +{
> > + unsigned long long adr;
> > + acpi_status status;
> > +
> > + if (is_of_node(fwnode)) {
> > + return of_property_read_u32(to_of_node(fwnode), "reg", id);
>
> ACPI nodes can hold reg property as well. I would rather think about
>
> ret = fwnode_property_read_u32(fwnode, "reg", id)
> if (!(ret && is_acpi_node(fwnode)))
> return ret;
>
Got it. Will rework on it.
> > + } else if (is_acpi_node(fwnode)) {
>
> Redundant 'else'
>
> > + status = acpi_evaluate_integer(ACPI_HANDLE_FWNODE(fwnode),
> > + METHOD_NAME__ADR, NULL,
> > );
> > + if (ACPI_FAILURE(status))
> > + return -ENODATA;
>
> I'm wondering if it compiles when CONFIG_ACPI=n.
Correct. It doesn't compile for non-ACPI case. Will resolve it.
Thanks
Calvin
[PATCH v2] cgroup-v1: add disabled controller check in cgroup1_parse_param()
When mounting a cgroup hierarchy with disabled controller in cgroup v1,
all available controllers will be attached.
Add disabled controller check in cgroup1_parse_param() and return directly
if the specified controller is disabled.
Signed-off-by: Chen Zhou
---
Changes in v2:
- Fix line over 80 characters warning.
---
kernel/cgroup/cgroup-v1.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index 191c329e482a..5190c42fea8b 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -915,6 +915,9 @@ int cgroup1_parse_param(struct fs_context *fc, struct
fs_parameter *param)
for_each_subsys(ss, i) {
if (strcmp(param->key, ss->legacy_name))
continue;
+ if (!cgroup_ssid_enabled(i) || cgroup1_ssid_disabled(i))
+ return invalfc(fc, "Disabled controller '%s'",
+ param->key);
ctx->subsys_mask |= (1 << i);
return 0;
}
--
2.20.1
Re: [net-next PATCH v2 10/14] device property: Introduce fwnode_get_id()
Hi Laurent,
Thanks for reviewing.
On Tue, Dec 15, 2020 at 07:00:28PM +0200, Laurent Pinchart wrote:
> Hi Calvin,
>
> Thank you for the patch.
>
> On Tue, Dec 15, 2020 at 10:13:11PM +0530, Calvin Johnson wrote:
> > Using fwnode_get_id(), get the reg property value for DT node
> > and get the _ADR object value for ACPI node.
> >
> > Signed-off-by: Calvin Johnson
> > ---
> >
> > Changes in v2: None
> >
> > drivers/base/property.c | 26 ++
> > include/linux/property.h | 1 +
> > 2 files changed, 27 insertions(+)
> >
> > diff --git a/drivers/base/property.c b/drivers/base/property.c
> > index 4c43d30145c6..1c50e17ae879 100644
> > --- a/drivers/base/property.c
> > +++ b/drivers/base/property.c
> > @@ -580,6 +580,32 @@ const char *fwnode_get_name_prefix(const struct
> > fwnode_handle *fwnode)
> > return fwnode_call_ptr_op(fwnode, get_name_prefix);
> > }
> >
> > +/**
> > + * fwnode_get_id - Get the id of a fwnode.
> > + * @fwnode: firmware node
> > + * @id: id of the fwnode
> > + *
>
> Is the concept of fwnode ID documented clearly somewhere ? I think this
> function should otherwise have more documentation, at least to explain
> what the ID is.
Agree. Will add more info here.
>
> > + * Returns 0 on success or a negative errno.
> > + */
> > +int fwnode_get_id(struct fwnode_handle *fwnode, u32 *id)
> > +{
> > + unsigned long long adr;
> > + acpi_status status;
> > +
> > + if (is_of_node(fwnode)) {
> > + return of_property_read_u32(to_of_node(fwnode), "reg", id);
> > + } else if (is_acpi_node(fwnode)) {
> > + status = acpi_evaluate_integer(ACPI_HANDLE_FWNODE(fwnode),
> > + METHOD_NAME__ADR, NULL, );
> > + if (ACPI_FAILURE(status))
> > + return -ENODATA;
>
> Would it make sense to standardize error codes ? of_property_read_u32()
> can return -EINVAL, -ENODATA or -EOVERFLOW. I don't think the caller of
> this function would be very interested to tell those three cases apart.
> Maybe we should return -EINVAL in all error cases ? Or maybe different
> error codes to mean "the backend doesn't support the concept of IDs",
> and "the device doesn't have an ID" ?
I think it make sense to return just -EINVAL. Will take care in v3.
Thanks
Calvin
Re: [PATCH v2 2/4] scsi: ufs: Remove redundant null checking of devfreq instance
On 2020-12-16 21:16, Stanley Chu wrote:
hba->devfreq is zero-initialized thus it is not required
to check its existence in ufshcd_add_lus() function which
is invoked during initialization only.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a91b73a1fc48..9cc16598136d 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7636,15 +7636,13 @@ static int ufshcd_add_lus(struct ufs_hba *hba)
>pwr_info,
sizeof(struct ufs_pa_layer_attr));
hba->clk_scaling.saved_pwr_info.is_valid = true;
- if (!hba->devfreq) {
- hba->clk_scaling.is_allowed = true;
- ret = ufshcd_devfreq_init(hba);
- if (ret)
- goto out;
+ hba->clk_scaling.is_allowed = true;
+ ret = ufshcd_devfreq_init(hba);
+ if (ret)
+ goto out;
- hba->clk_scaling.is_enabled = true;
- ufshcd_clkscaling_init_sysfs(hba);
- }
+ hba->clk_scaling.is_enabled = true;
+ ufshcd_clkscaling_init_sysfs(hba);
}
ufs_bsg_probe(hba);
Reviewed-by: Can Guo
Re: [PATCH 1/1] device-dax: avoid an unnecessary check in alloc_dev_dax_range()
On 2020/11/20 17:22, Zhen Lei wrote:
> Swap the calling sequence of krealloc() and __request_region(), call the
> latter first. In this way, the value of dev_dax->nr_range does not need to
> be considered when __request_region() failed.
>
> Signed-off-by: Zhen Lei
> ---
> drivers/dax/bus.c | 29 -
> 1 file changed, 12 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index 27513d311242..1efae11d947a 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -763,23 +763,15 @@ static int alloc_dev_dax_range(struct dev_dax *dev_dax,
> u64 start,
> return 0;
> }
>
> - ranges = krealloc(dev_dax->ranges, sizeof(*ranges)
> - * (dev_dax->nr_range + 1), GFP_KERNEL);
> - if (!ranges)
> - return -ENOMEM;
> -
> alloc = __request_region(res, start, size, dev_name(dev), 0);
> - if (!alloc) {
> - /*
> - * If this was an empty set of ranges nothing else
> - * will release @ranges, so do it now.
> - */
> - if (!dev_dax->nr_range) {
> - kfree(ranges);
> - ranges = NULL;
> - }
> - dev_dax->ranges = ranges;
> + if (!alloc)
> return -ENOMEM;
> +
> + ranges = krealloc(dev_dax->ranges, sizeof(*ranges)
> + * (dev_dax->nr_range + 1), GFP_KERNEL);
> + if (!ranges) {
> + rc = -ENOMEM;
> + goto err;
Hi, Dan Williams:
In fact, after adding the new helper dev_dax_trim_range(), we can
directly call __release_region() and return error code at here. Replace goto.
> }
>
> for (i = 0; i < dev_dax->nr_range; i++)
> @@ -808,11 +800,14 @@ static int alloc_dev_dax_range(struct dev_dax *dev_dax,
> u64 start,
> dev_dbg(dev, "delete range[%d]: %pa:%pa\n", dev_dax->nr_range -
> 1,
> >start, >end);
> dev_dax->nr_range--;
> - __release_region(res, alloc->start, resource_size(alloc));
> - return rc;
> + goto err;
> }
>
> return 0;
> +
> +err:
> + __release_region(res, alloc->start, resource_size(alloc));
> + return rc;
> }
>
> static int adjust_dev_dax_range(struct dev_dax *dev_dax, struct resource
> *res, resource_size_t size)
>
Re: [PATCH v2 1/4] scsi: ufs: Refactor cancelling clkscaling works
On 2020-12-16 21:16, Stanley Chu wrote:
Cancelling suspend_work and resume_work is only required while
suspending clk-scaling. Thus moving these two invokes into
ufshcd_suspend_clkscaling() function.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 052479a56a6f..a91b73a1fc48 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1451,6 +1451,9 @@ static void ufshcd_suspend_clkscaling(struct
ufs_hba *hba)
if (!ufshcd_is_clkscaling_supported(hba))
return;
+ cancel_work_sync(>clk_scaling.suspend_work);
+ cancel_work_sync(>clk_scaling.resume_work);
+
spin_lock_irqsave(hba->host->host_lock, flags);
if (!hba->clk_scaling.is_suspended) {
suspend = true;
@@ -1514,9 +1517,6 @@ static ssize_t
ufshcd_clkscale_enable_store(struct device *dev,
pm_runtime_get_sync(hba->dev);
ufshcd_hold(hba, false);
- cancel_work_sync(>clk_scaling.suspend_work);
- cancel_work_sync(>clk_scaling.resume_work);
-
if (value) {
ufshcd_resume_clkscaling(hba);
} else {
@@ -5663,11 +5663,8 @@ static void ufshcd_err_handling_prepare(struct
ufs_hba *hba)
ufshcd_vops_resume(hba, UFS_RUNTIME_PM);
} else {
ufshcd_hold(hba, false);
- if (hba->clk_scaling.is_enabled) {
- cancel_work_sync(>clk_scaling.suspend_work);
- cancel_work_sync(>clk_scaling.resume_work);
+ if (hba->clk_scaling.is_enabled)
ufshcd_suspend_clkscaling(hba);
- }
}
down_write(>clk_scaling_lock);
hba->clk_scaling.is_allowed = false;
@@ -8512,11 +8509,9 @@ static int ufshcd_suspend(struct ufs_hba *hba,
enum ufs_pm_op pm_op)
ufshcd_hold(hba, false);
hba->clk_gating.is_suspended = true;
- if (hba->clk_scaling.is_enabled) {
- cancel_work_sync(>clk_scaling.suspend_work);
- cancel_work_sync(>clk_scaling.resume_work);
+ if (hba->clk_scaling.is_enabled)
ufshcd_suspend_clkscaling(hba);
- }
+
down_write(>clk_scaling_lock);
hba->clk_scaling.is_allowed = false;
up_write(>clk_scaling_lock);
Reviewed-by: Can Guo
Re: linux-next: Signed-off-by missing for commit in the cifs tree
I have now amended the patches to have the correct author and repushed
On Thu, Dec 17, 2020 at 11:57 PM Stephen Rothwell wrote:
>
> Hi all,
>
> Commits
>
> ee04fe87f4d0 ("cifs: Re-indent cifs_swn_reconnect()")
> 2c6dd2f9742d ("cifs: Unlock on errors in cifs_swn_reconnect()")
> fb2356b3739b ("cifs: Delete a stray unlock in cifs_swn_reconnect()")
>
> are missing a Signed-off-by from their author.
>
> This is the problem with the mailing list again :-( The
> author has been recorded as
>
> "Dan Carpenter via samba-technical "
>
> --
> Cheers,
> Stephen Rothwell
--
Thanks,
Steve
Re: [PATCH 1/1] device-dax: avoid an unnecessary check in alloc_dev_dax_range()
On 2020/12/18 11:10, Dan Williams wrote:
> On Fri, Nov 20, 2020 at 1:23 AM Zhen Lei wrote:
>>
>> Swap the calling sequence of krealloc() and __request_region(), call the
>> latter first. In this way, the value of dev_dax->nr_range does not need to
>> be considered when __request_region() failed.
>
> This looks ok, but I think I want to see another cleanup go in first
> before this to add a helper for trimming the last range off the set of
> ranges:
>
> static void dev_dax_trim_range(struct dev_dax *dev_dax)
> {
> int i = dev_dax->nr_range - 1;
> struct range *range = _dax->ranges[i].range;
> struct dax_region *dax_region = dev_dax->region;
>
> dev_dbg(dev, "delete range[%d]: %#llx:%#llx\n", i,
> (unsigned long long)range->start,
> (unsigned long long)range->end);
>
> __release_region(_region->res, range->start, range_len(range));
> if (--dev_dax->nr_range == 0) {
> kfree(dev_dax->ranges);
> dev_dax->ranges = NULL;
> }
> }
>
> Care to do a lead in patch with that cleanup, then do this one?
I don't mind! You can add above helper first. After that, I'll update
and send this patch again.
>
> I think that might also cleanup a memory leak report from Jane in
> addition to not needing the "goto" as well.
>
> http://lore.kernel.org/r/c8a8a260-34c6-dbfc-1f19-25c23d01c...@oracle.com
>
> .
>
[PATCH] genirq/msi: Initialize msi_alloc_info to zero for msi_prepare API
Since commit 5fe71d271df8 ("irqchip/gic-v3-its: Tag ITS device as shared if
allocating for a proxy device"), some of the devices are wrongly marked as
"shared" by the ITS driver on systems equipped with the ITS(es). The
problem is that the @info->flags may not be initialized anywhere and we end
up looking at random bits on the stack. That's obviously not good.
The straightforward fix is to properly initialize msi_alloc_info inside the
.prepare callback of affected MSI domains (its-pci-msi, its-platform-msi,
etc). We can also perform the initialization in IRQ core layer for
msi_domain_prepare_irqs() API and it looks much neater to me.
Signed-off-by: Zenghui Yu
---
This was noticed when I was playing with the assigned devices on arm64 and
VFIO failed to enable MSI-X vectors for almost all VFs (CCed kvm list in
case others will hit the same issue). It turned out that these VFs are
marked as "shared" by mistake and have trouble with the following sequence:
pci_alloc_irq_vectors(pdev, 1, 1, flag);
pci_free_irq_vectors(pdev);
pci_alloc_irq_vectors(pdev, 1, 2, flag); --> we can only get
*one* vector
But besides VFIO, I guess there are already some devices get into trouble
at probe time and can't work properly.
kernel/irq/msi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 2c0c4d6d0f83..dc0e2d7fbdfd 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -402,7 +402,7 @@ int __msi_domain_alloc_irqs(struct irq_domain *domain,
struct device *dev,
struct msi_domain_ops *ops = info->ops;
struct irq_data *irq_data;
struct msi_desc *desc;
- msi_alloc_info_t arg;
+ msi_alloc_info_t arg = { };
int i, ret, virq;
bool can_reserve;
--
2.19.1
Re: [PATCH v2 2/4] scsi: ufs: Remove redundant null checking of devfreq instance
On 2020-12-16 21:16, Stanley Chu wrote:
hba->devfreq is zero-initialized thus it is not required
to check its existence in ufshcd_add_lus() function which
is invoked during initialization only.
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a91b73a1fc48..9cc16598136d 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7636,15 +7636,13 @@ static int ufshcd_add_lus(struct ufs_hba *hba)
>pwr_info,
sizeof(struct ufs_pa_layer_attr));
hba->clk_scaling.saved_pwr_info.is_valid = true;
- if (!hba->devfreq) {
Just FYI, checking this was due to consideration for supporting UFS
cards
which can do hot-plug. But UFS cards seems out of the picture for a long
time.
Anyways, if someday UFS cards come back in future, let's add these
checks back again.
Thanks,
Can Guo.
- hba->clk_scaling.is_allowed = true;
- ret = ufshcd_devfreq_init(hba);
- if (ret)
- goto out;
+ hba->clk_scaling.is_allowed = true;
+ ret = ufshcd_devfreq_init(hba);
+ if (ret)
+ goto out;
- hba->clk_scaling.is_enabled = true;
- ufshcd_clkscaling_init_sysfs(hba);
- }
+ hba->clk_scaling.is_enabled = true;
+ ufshcd_clkscaling_init_sysfs(hba);
}
ufs_bsg_probe(hba);
linux-next: Signed-off-by missing for commit in the cifs tree
Hi all,
Commits
ee04fe87f4d0 ("cifs: Re-indent cifs_swn_reconnect()")
2c6dd2f9742d ("cifs: Unlock on errors in cifs_swn_reconnect()")
fb2356b3739b ("cifs: Delete a stray unlock in cifs_swn_reconnect()")
are missing a Signed-off-by from their author.
This is the problem with the mailing list again :-( The
author has been recorded as
"Dan Carpenter via samba-technical "
--
Cheers,
Stephen Rothwell
pgpGK4EriNRQm.pgp
Description: OpenPGP digital signature
Re: Question for AMD patches
On Fri, Dec 18, 2020 at 05:18:16AM +0800, Young Hsieh wrote: > Hi Greg, > > Thanks. I am looking for the Essential, RAS & Perf patches for AMD Milan as > follows: > I don't see anything here :( > I am not familiar the rules for stable kernel patches, can you help to > elaborate ? Thanks for your assistance! :) Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for what stable kernels are all about. thanks, greg k-h
Re: [net-next PATCH v2 09/14] net/fsl: Use fwnode_mdiobus_register()
On Tue, Dec 15, 2020 at 07:55:01PM +0200, Andy Shevchenko wrote: > On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson > wrote: > > > > fwnode_mdiobus_register() internally takes care of both DT > > and ACPI cases to register mdiobus. Replace existing > > of_mdiobus_register() with fwnode_mdiobus_register(). > > > > Note: For both ACPI and DT cases, endianness of MDIO controller > > need to be specified using "little-endian" property. > > ... > > > @@ -2,6 +2,7 @@ > > * QorIQ 10G MDIO Controller > > * > > * Copyright 2012 Freescale Semiconductor, Inc. > > + * Copyright 2020 NXP > > * > > * Authors: Andy Fleming > > * Timur Tabi > > @@ -11,6 +12,7 @@ > > I guess this... > > > priv->is_little_endian = device_property_read_bool(>dev, > >"little-endian"); > > - > > priv->has_a011043 = device_property_read_bool(>dev, > > > > "fsl,erratum-a011043"); > > ...this... > > > - > > ...and this changes can go to a separate patch. I think I'll remove the unnecessary cleanup. Regards Calvin
Re: [PATCH V2 1/1] scsi: ufs: Fix a possible NULL pointer issue
On 2020-12-14 22:32, Bean Huo wrote:
On Sun, 2020-12-13 at 19:41 -0800, Can Guo wrote:
Fixes: 88a92d6ae4fe ("scsi: ufs: Serialize eh_work with system PM
events and async scan")
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufshcd.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c1c401b..ef155a9 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8883,8 +8883,11 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
int ret = 0;
ktime_t start = ktime_get();
+ if (!hba)
+ return 0;
+
down(>eh_sem);
- if (!hba || !hba->is_powered)
+ if (!hba->is_powered)
return 0;
Can,
why not moving down(>eh_sem) after "return 0;"?
In your way, if hba is not powered, ufshcd_system_suspend() returns
0, which is a successful suspend. When ufshcd_system_resume() is called,
if hba is not powered, it goes to out and does up(>eh_sem), which
shall cause unbalance to eh_sem.
Thanks,
Can Guo.
Re: [net-next PATCH v2 08/14] net: mdiobus: Introduce fwnode_mdiobus_register()
On Tue, Dec 15, 2020 at 07:53:26PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson
> wrote:
> >
> > Introduce fwnode_mdiobus_register() to register PHYs on the mdiobus.
> > If the fwnode is DT node, then call of_mdiobus_register().
> > If it is an ACPI node, then:
> > - disable auto probing of mdiobus
> > - register mdiobus
> > - save fwnode to mdio structure
> > - loop over child nodes & register a phy_device for each PHY
>
> ...
>
> > +/**
> > + * fwnode_mdiobus_register - Register mii_bus and create PHYs from fwnode
> > + * @mdio: pointer to mii_bus structure
> > + * @fwnode: pointer to fwnode of MDIO bus.
> > + *
> > + * This function registers the mii_bus structure and registers a phy_device
> > + * for each child node of @fwnode.
> > + */
> > +int fwnode_mdiobus_register(struct mii_bus *mdio, struct fwnode_handle
> > *fwnode)
> > +{
> > + struct fwnode_handle *child;
> > + unsigned long long addr;
> > + acpi_status status;
> > + int ret;
> > +
> > + if (is_of_node(fwnode)) {
> > + return of_mdiobus_register(mdio, to_of_node(fwnode));
> > + } else if (is_acpi_node(fwnode)) {
>
> I would rather see this as simple as
>
> if (is_of_node(fwnode))
>return of_mdiobus_register(mdio, to_of_node(fwnode));
> if (is_acpi_node(fwnode))
>return acpi_mdiobus_register(mdio, fwnode);
>
> where the latter one is defined somewhere in drivers/acpi/.
Makes sense. I'll do it. But I think it will be better to place
acpi_mdiobus_register() here itself in the network subsystem, maybe
/drivers/net/mdio/acpi_mdio.c.
>
> > + /* Mask out all PHYs from auto probing. */
> > + mdio->phy_mask = ~0;
> > + ret = mdiobus_register(mdio);
> > + if (ret)
> > + return ret;
> > +
> > + mdio->dev.fwnode = fwnode;
> > + /* Loop over the child nodes and register a phy_device for each PHY
> > */
> > + fwnode_for_each_child_node(fwnode, child) {
>
> > + status =
> > acpi_evaluate_integer(ACPI_HANDLE_FWNODE(child),
> > + "_ADR", NULL, );
> > + if (ACPI_FAILURE(status)) {
>
> Isn't it fwnode_get_id() now?
Yes. Will change it.
>
> > + pr_debug("_ADR returned %d\n", status);
> > + continue;
> > + }
>
> > + if (addr < 0 || addr >= PHY_MAX_ADDR)
> > + continue;
>
> addr can't be less than 0.
Yes. will update in v3.
>
> > + ret = fwnode_mdiobus_register_phy(mdio, child,
> > addr);
> > + if (ret == -ENODEV)
> > + dev_err(>dev,
> > + "MDIO device at address %lld is
> > missing.\n",
> > + addr);
> > + }
> > + return 0;
> > + }
> > + return -EINVAL;
> > +}
>
> --
> With Best Regards,
> Andy Shevchenko
Re: [PATCH v4 3/4] pinctrl: qcom: Don't clear pending interrupts when enabling
On 12/12/2020 3:45 AM, Douglas Anderson wrote:
In Linux, if a driver does disable_irq() and later does enable_irq()
on its interrupt, I believe it's expecting these properties:
* If an interrupt was pending when the driver disabled then it will
still be pending after the driver re-enables.
* If an edge-triggered interrupt comes in while an interrupt is
disabled it should assert when the interrupt is re-enabled.
If you think that the above sounds a lot like the disable_irq() and
enable_irq() are supposed to be masking/unmasking the interrupt
instead of disabling/enabling it then you've made an astute
observation. Specifically when talking about interrupts, "mask"
usually means to stop posting interrupts but keep tracking them and
"disable" means to fully shut off interrupt detection. It's
unfortunate that this is so confusing, but presumably this is all the
way it is for historical reasons.
Perhaps more confusing than the above is that, even though clients of
IRQs themselves don't have a way to request mask/unmask
vs. disable/enable calls, IRQ chips themselves can implement both.
...and yet more confusing is that if an IRQ chip implements
disable/enable then they will be called when a client driver calls
disable_irq() / enable_irq().
It does feel like some of the above could be cleared up. However,
without any other core interrupt changes it should be clear that when
an IRQ chip gets a request to "disable" an IRQ that it has to treat it
like a mask of that IRQ.
In any case, after that long interlude you can see that the "unmask
and clear" can break things. Maulik tried to fix it so that we no
longer did "unmask and clear" in commit 71266d9d3936 ("pinctrl: qcom:
Move clearing pending IRQ to .irq_request_resources callback"), but it
only handled the PDC case (it also had problems, but that's the
subject of another patch). Let's fix this for the non-PDC case.
From my understanding the source of the phantom interrupt in the
non-PDC case was the one that could have been introduced in
msm_gpio_irq_set_type(). Let's handle that one and then get rid of
the clear.
Fixes: 4b7618fdc7e6 ("pinctrl: qcom: Add irq_enable callback for msm gpio")
Signed-off-by: Douglas Anderson
---
I don't have lots of good test cases here, so hopefully someone from
Qualcomm can confirm that this works well for them and there isn't
some other phantom interrupt source that I'm not aware of.
I currently don;t have access to any non-PDC hardware, so could not really do
any real tests, but the changes seem sane, so
Reviewed-by: Rajendra Nayak
Changes in v4:
- ("pinctrl: qcom: Don't clear pending interrupts when enabling") split for v4.
drivers/pinctrl/qcom/pinctrl-msm.c | 32 +-
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
b/drivers/pinctrl/qcom/pinctrl-msm.c
index 588df91274e2..f785646d1df7 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -774,7 +774,7 @@ static void msm_gpio_irq_mask(struct irq_data *d)
raw_spin_unlock_irqrestore(>lock, flags);
}
-static void msm_gpio_irq_clear_unmask(struct irq_data *d, bool status_clear)
+static void msm_gpio_irq_unmask(struct irq_data *d)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
struct msm_pinctrl *pctrl = gpiochip_get_data(gc);
@@ -792,17 +792,6 @@ static void msm_gpio_irq_clear_unmask(struct irq_data *d,
bool status_clear)
raw_spin_lock_irqsave(>lock, flags);
- if (status_clear) {
- /*
-* clear the interrupt status bit before unmask to avoid
-* any erroneous interrupts that would have got latched
-* when the interrupt is not in use.
-*/
- val = msm_readl_intr_status(pctrl, g);
- val &= ~BIT(g->intr_status_bit);
- msm_writel_intr_status(val, pctrl, g);
- }
-
val = msm_readl_intr_cfg(pctrl, g);
val |= BIT(g->intr_raw_status_bit);
val |= BIT(g->intr_enable_bit);
@@ -822,7 +811,7 @@ static void msm_gpio_irq_enable(struct irq_data *d)
irq_chip_enable_parent(d);
if (!test_bit(d->hwirq, pctrl->skip_wake_irqs))
- msm_gpio_irq_clear_unmask(d, true);
+ msm_gpio_irq_unmask(d);
}
static void msm_gpio_irq_disable(struct irq_data *d)
@@ -837,11 +826,6 @@ static void msm_gpio_irq_disable(struct irq_data *d)
msm_gpio_irq_mask(d);
}
-static void msm_gpio_irq_unmask(struct irq_data *d)
-{
- msm_gpio_irq_clear_unmask(d, false);
-}
-
/**
* msm_gpio_update_dual_edge_parent() - Prime next edge for IRQs handled by
parent.
* @d: The irq dta.
@@ -936,6 +920,7 @@ static int msm_gpio_irq_set_type(struct irq_data *d,
unsigned int type)
struct msm_pinctrl *pctrl = gpiochip_get_data(gc);
const struct msm_pingroup *g;
unsigned long flags;
+ bool
Re: [net-next PATCH v2 06/14] net: mdiobus: Introduce fwnode_mdiobus_register_phy()
On Tue, Dec 15, 2020 at 07:33:40PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson
> wrote:
> >
> > Introduce fwnode_mdiobus_register_phy() to register PHYs on the
> > mdiobus. From the compatible string, identify whether the PHY is
> > c45 and based on this create a PHY device instance which is
> > registered on the mdiobus.
>
> ...
>
> > +int fwnode_mdiobus_register_phy(struct mii_bus *bus,
> > + struct fwnode_handle *child, u32 addr)
> > +{
> > + struct mii_timestamper *mii_ts;
> > + struct phy_device *phy;
> > + const char *cp;
> > + bool is_c45;
> > + u32 phy_id;
> > + int rc;
>
> > + if (is_of_node(child)) {
> > + mii_ts = of_find_mii_timestamper(to_of_node(child));
> > + if (IS_ERR(mii_ts))
> > + return PTR_ERR(mii_ts);
> > + }
>
> Perhaps
>
>mii_ts = of_find_mii_timestamper(to_of_node(child));
>
> > +
> > + rc = fwnode_property_read_string(child, "compatible", );
> > + is_c45 = !(rc || strcmp(cp, "ethernet-phy-ieee802.3-c45"));
> > +
> > + if (is_c45 || fwnode_get_phy_id(child, _id))
> > + phy = get_phy_device(bus, addr, is_c45);
> > + else
> > + phy = phy_device_create(bus, addr, phy_id, 0, NULL);
> > + if (IS_ERR(phy)) {
>
> > + if (mii_ts && is_of_node(child))
> > + unregister_mii_timestamper(mii_ts);
>
> if (!IS_ERR_OR_NULL(mii_ts))
> ...
>
> However it points to the question why unregister() doesn't handle the
> above cases.
> I would expect unconditional call to unregister() here.
This is following the logic defined in of_mdiobus_register_phy().
https://elixir.bootlin.com/linux/latest/source/drivers/net/mdio/of_mdio.c#L107
mii_ts = of_find_mii_timestamper(child);
if (IS_ERR(mii_ts))
return PTR_ERR(mii_ts);
I think the logic above is correct because this function returns only if
of_find_mii_timestamper() returns error. On NULL return, it proceeds further.
>
> > + return PTR_ERR(phy);
> > + }
> > +
> > + if (is_acpi_node(child)) {
> > + phy->irq = bus->irq[addr];
> > +
> > + /* Associate the fwnode with the device structure so it
> > +* can be looked up later.
> > +*/
> > + phy->mdio.dev.fwnode = child;
> > +
> > + /* All data is now stored in the phy struct, so register it
> > */
> > + rc = phy_device_register(phy);
> > + if (rc) {
> > + phy_device_free(phy);
> > + fwnode_handle_put(phy->mdio.dev.fwnode);
> > + return rc;
> > + }
> > +
> > + dev_dbg(>dev, "registered phy at address %i\n", addr);
> > + } else if (is_of_node(child)) {
> > + rc = of_mdiobus_phy_device_register(bus, phy,
> > to_of_node(child), addr);
> > + if (rc) {
>
> > + if (mii_ts)
> > + unregister_mii_timestamper(mii_ts);
>
> Ditto.
>
> > + phy_device_free(phy);
> > + return rc;
> > + }
> > +
> > + /* phy->mii_ts may already be defined by the PHY driver. A
> > +* mii_timestamper probed via the device tree will still
> > have
> > +* precedence.
> > +*/
>
> > + if (mii_ts)
> > + phy->mii_ts = mii_ts;
>
> How is that defined? Do you need to do something with an old pointer?
As the comment says, I think PHY drivers which got invoked before calling
of_mdiobus_register_phy() may have defined phy->mii_ts.
>
> > + }
> > + return 0;
> > +}
>
> --
> With Best Regards,
> Andy Shevchenko
linux-next: Tree for Dec 18
Hi all, News: there will be no linux-next releases between Dec 24 and Jan 3 inclusive. Please do not add any v5.12 destined code to your linux-next included branches until after v5.11-rc1 has been released. Changes since 20201217: The ext4 tree gained a conflict against Linus' tree. The watchdog tree lost its build failure. The kvm tree gained a conflict against the arm64-fixes tree. Non-merge commits (relative to Linus' tree): 2068 2029 files changed, 69916 insertions(+), 28793 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 327 trees (counting Linus' and 85 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (6daa90439e91 Merge tag 'dmaengine-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine) Merging fixes/fixes (9223e74f9960 Merge tag 'io_uring-5.10-2020-11-27' of git://git.kernel.dk/linux-block) Merging kbuild-current/fixes (7d32358be8ac kbuild: avoid split lines in .mod files) Merging arc-current/for-curr (3a71e423133a ARC: build: use $(READELF) instead of hard-coded readelf) Merging arm-current/fixes (e64ab473ddda ARM: 9034/1: __div64_32(): straighten up inline asm constraints) Merging arm64-fixes/for-next/fixes (9fd339a45be5 arm64: Work around broken GCC 4.9 handling of "S" constraint) Merging arm-soc-fixes/arm/fixes (43ffe817bfe3 arm64: dts: bitmain: Use generic "ngpios" rather than "snps,nr-gpios") Merging drivers-memory-fixes/fixes (3650b228f83a Linux 5.10-rc1) Merging m68k-current/for-linus (2ae92e8b9b7e MAINTAINERS: Update m68k Mac entry) Merging powerpc-fixes/fixes (5eedf9fe8db2 powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed()) Merging s390-fixes/fixes (586592478b1f Merge tag 's390-5.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption not used on new files) Merging net/master (44d4775ca518 net/sched: sch_taprio: reset child qdiscs before freeing them) Merging bpf/master (1a3449c19407 selftests/bpf: Clarify build error if no vmlinux) Merging ipsec/master (7f376f1917d7 Merge tag 'mtd/fixes-for-5.10-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux) Merging netfilter/master (3db1a3fa9880 Merge tag 'staging-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging) Merging ipvs/master (3db1a3fa9880 Merge tag 'staging-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging) Merging wireless-drivers/master (4dfde294b979 rtlwifi: rise completion at the last step of firmware callback) Merging mac80211/master (2c85ebc57b3e Linux 5.10) Merging rdma-fixes/for-rc (340b940ea0ed RDMA/cm: Fix an attempt to use non-valid pointer when cleaning timewait) Merging sound-current/for-linus (725124d10d00 ALSA: usb-audio: Add VID to support native DSD reproduction on FiiO devices) Merging sound-asoc-fixes/for-linus (20b7445d8aa1 Merge remote-tracking branch 'asoc/for-5.11' into asoc-linus) Merging regmap-fixes/for-linus (e6e9354b5830 regmap: Remove duplicate `type` field from regmap `regcache_sync` trace event) Merging regulator-fixes/for-linus (87a96de608de
Re: [PATCH -next] vdpa: Mark macaddr_buf with static keyword
On 2020/12/18 上午9:51, Zou Wei wrote: Fix the following sparse warning: drivers/vdpa/vdpa_sim/vdpa_sim_net.c:36:4: warning: symbol 'macaddr_buf' was not declared. Should it be static? Reported-by: Hulk Robot Signed-off-by: Zou Wei --- drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c index c10b698..f048242 100644 --- a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c +++ b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c @@ -33,7 +33,7 @@ static char *macaddr; module_param(macaddr, charp, 0); MODULE_PARM_DESC(macaddr, "Ethernet MAC address"); -u8 macaddr_buf[ETH_ALEN]; +static u8 macaddr_buf[ETH_ALEN]; static struct vdpasim *vdpasim_net_dev; Acked-by: Jason Wang
[PATCH] JFS: more checks for invalid superblock
syzbot is feeding invalid superblock data to JFS for mount testing.
JFS does not check several of the fields -- just assumes that they
are good since the JFS_MAGIC and version fields are good.
In this case (syzbot reproducer), we have s_l2bsize == 0xda0c,
pad == 0xf045, and s_state == 0x50, all of which are invalid IMO.
Having s_l2bsize == 0xda0c causes this UBSAN warning:
UBSAN: shift-out-of-bounds in fs/jfs/jfs_mount.c:373:25
shift exponent -9716 is negative
s_l2bsize can be tested for correctness. pad can be tested for non-0
and punted. s_state can be tested for its valid values and punted.
Do those 3 tests and if any of them fails, report the superblock as
invalid/corrupt and let fsck handle it.
With this patch, chkSuper() says this when JFS_DEBUG is enabled:
jfs_mount: Mount Failure: superblock is corrupt!
Mount JFS Failure: -22
jfs_mount failed w/return code = -22
The obvious problem with this method is that next week there could
be another syzbot test that uses different fields for invalid values,
this making this like a game of whack-a-mole.
syzkaller link: https://syzkaller.appspot.com/bug?extid=36315852ece4132ec193
Reported-by: syzbot+36315852ece4132ec...@syzkaller.appspotmail.com
Signed-off-by: Randy Dunlap
Cc: Dave Kleikamp
Cc: jfs-discuss...@lists.sourceforge.net
---
fs/jfs/jfs_filsys.h |1 +
fs/jfs/jfs_mount.c | 10 ++
2 files changed, 11 insertions(+)
--- lnx-510.orig/fs/jfs/jfs_mount.c
+++ lnx-510/fs/jfs/jfs_mount.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "jfs_incore.h"
#include "jfs_filsys.h"
@@ -366,6 +367,15 @@ static int chkSuper(struct super_block *
sbi->bsize = bsize;
sbi->l2bsize = le16_to_cpu(j_sb->s_l2bsize);
+ /* check some fields for possible corruption */
+ if (sbi->l2bsize != ilog2((u32)bsize) ||
+ j_sb->pad != 0 ||
+ j_sb->s_state > FM_STATE_MAX) {
+ rc = -EINVAL;
+ jfs_err("jfs_mount: Mount Failure: superblock is corrupt!");
+ goto out;
+ }
+
/*
* For now, ignore s_pbsize, l2bfactor. All I/O going through buffer
* cache.
--- lnx-510.orig/fs/jfs/jfs_filsys.h
+++ lnx-510/fs/jfs/jfs_filsys.h
@@ -268,5 +268,6 @@
* fsck() must be run to repair
*/
#defineFM_EXTENDFS 0x0008 /* file system extendfs() in progress */
+#defineFM_STATE_MAX 0x000f /* max value of s_state */
#endif /* _H_JFS_FILSYS */
Re: [PATCH 3/5] irqchip/bcm2836: Make IPIs use handle_percpu_devid_irq()
On 12/15/20 7:46 AM, Marc Zyngier wrote: > On 2020-12-15 15:39, Guenter Roeck wrote: >> On 12/15/20 7:26 AM, Marc Zyngier wrote: >>> On 2020-12-15 15:21, Guenter Roeck wrote: Hi Marc, On 12/15/20 2:19 AM, Marc Zyngier wrote: > Hi Gunter, > > On 2020-12-15 00:21, Guenter Roeck wrote: >> On Mon, Nov 09, 2020 at 09:41:19AM +, Valentin Schneider wrote: >>> As done for the Arm GIC irqchips, move IPIs to >>> handle_percpu_devid_irq() as >>> handle_percpu_devid_fasteoi_ipi() isn't actually required. >>> >>> Signed-off-by: Valentin Schneider >> >> This patch results in boot failures (silent stall) for the qemu >> raspi2 emulation. Unfortunately it can not be reverted because >> handle_percpu_devid_fasteoi_ipi no longer exists in next-20201214, >> so I don't know if it is the only problem. > > This is odd. This works just fine for me on both the RPi2 and 3 > emulation, running a full Debian userspace. Could this be caused > by the version of QEMU you are using? Here's what I have: > > $ qemu-system-arm --version > QEMU emulator version 5.1.0 (Debian 1:5.1+dfsg-4+b1) > I used qemu 5.0 which - up to now - worked fine. Let me try with 5.1 and 5.2. Sorry, I should have tried first before bothering you. >>> >>> No bother at all. If this works for you on more recent versions of >>> QEMU, that'd be an interesting data point. I'm also interested in >>> the result of the patch either way. >>> >> >> It doesn't work for me with qemu 5.1, nor with qemu 5.2. My userspace >> is generated with buildroot, busybox-based, and very basic. > > OK, so something is definitely different between our setups. > Mind pointing me to your config and your QEMU invocation? > >> >> Your patch fixes the problem for me, though, so feel free to add >> >> Tested-by: Guenter Roeck >> >> if/when you submit it. > > Thanks for that. > Any news on this? I now see the problem in mainline. Thanks, Guenter
Re: [PATCH v2] ALSA: hda: Continue to probe when codec probe fails
[+Cc Bjorn, Alan and linux-pci]
On Thu, Dec 17, 2020 at 12:57 AM Takashi Iwai wrote:
>
> On Wed, 16 Dec 2020 17:22:17 +0100,
> Takashi Iwai wrote:
> >
> > On Wed, 16 Dec 2020 17:07:45 +0100,
> > Kai-Heng Feng wrote:
> > >
> > > On Wed, Dec 16, 2020 at 11:58 PM Takashi Iwai wrote:
> > > >
> > > > On Wed, 16 Dec 2020 16:50:20 +0100,
> > > > Kai-Heng Feng wrote:
> > > > >
> > > > > On Wed, Dec 16, 2020 at 11:41 PM Takashi Iwai wrote:
> > > > > >
> > > > > > On Wed, 16 Dec 2020 13:47:24 +0100,
> > > > > > Kai-Heng Feng wrote:
> > > > > > >
> > > > > > > Similar to commit 9479e75fca37 ("ALSA: hda: Keep the controller
> > > > > > > initialization even if no codecs found"), when codec probe fails,
> > > > > > > it
> > > > > > > doesn't enable runtime suspend, and can prevent graphics card from
> > > > > > > getting powered down:
> > > > > > > [4.280991] snd_hda_intel :01:00.1: no codecs initialized
> > > > > > >
> > > > > > > $ cat /sys/bus/pci/devices/:01:00.1/power/runtime_status
> > > > > > > active
> > > > > > >
> > > > > > > So mark there's no codec and continue probing to let runtime PM
> > > > > > > to work.
> > > > > > >
> > > > > > > BugLink: https://bugs.launchpad.net/bugs/1907212
> > > > > > > Signed-off-by: Kai-Heng Feng
> > > > > >
> > > > > > Hm, but if the probe fails, doesn't it mean something really wrong?
> > > > > > IOW, how does this situation happen?
> > > > >
> > > > > The HDA controller is forcely created by quirk_nvidia_hda(). So
> > > > > probably there's really not an HDA controller.
> > > >
> > > > I still don't understand how non-zero codec_mask is passed.
> > > > The non-zero codec_mask means that BIOS or whatever believes that
> > > > HD-audio codecs are present and let HD-audio controller reporting the
> > > > presence. What error did you get at probing?
> > >
> > > [4.280991] snd_hda_intel :01:00.1: no codecs initialized
> > > Full dmesg here:
> > > https://launchpadlibrarian.net/510351476/dmesg.log
> >
> > The actual problems are shown before that line.
> >
> > [4.178848] pci :01:00.1: can't change power state from D3cold to D0
> > (config space inaccessible)
> > [4.179502] snd_hda_intel :01:00.1: can't change power state from
> > D3cold to D0 (config space inaccessible)
> > [4.179511] snd_hda_intel :01:00.1: can't change power state from
> > D3hot to D0 (config space inaccessible)
> >
> > [4.280571] hdaudio hdaudioC1D0: no AFG or MFG node found
> > [4.280633] hdaudio hdaudioC1D1: no AFG or MFG node found
> > [4.280685] hdaudio hdaudioC1D2: no AFG or MFG node found
> > [4.280736] hdaudio hdaudioC1D3: no AFG or MFG node found
> > [4.280788] hdaudio hdaudioC1D4: no AFG or MFG node found
> > [4.280839] hdaudio hdaudioC1D5: no AFG or MFG node found
> > [4.280892] hdaudio hdaudioC1D6: no AFG or MFG node found
> > [4.280943] hdaudio hdaudioC1D7: no AFG or MFG node found
> >
> > Could you check the codec_mask value read in
> > sound/hda/hdac_controller.c? I guess it reads 0xff.
> >
> > If that's the case, it can be corrected by the patch below.
> > But, we should check the cause of the first error (inaccessible config
> > space) in anyway; this must be the primary reason of the whole chain
> > of errors.
>
> Now I took a deeper look at the code. So we hit errors after errors:
> - The first problem is that quirk_nvidia_hda() enabled HD-audio even
> if it's non-functional by some reason. We may need additional
> checks there.
Quite possibly the system doesn't power up HDA controller when there's
no external monitor.
So when it's connected to external monitor, it's still needed for HDMI audio.
Let me ask the user to confirm this.
>
> - The second problem is that pci_enable_device() ignores the error
> returned from pci_set_power_state() if it's -EIO. And the
> inaccessible access error returns -EIO, although it's rather a fatal
> problem. So the driver believes as the PCI device gets enabled
> properly.
This was introduced in 2005, by Alan's 11f3859b1e85 ("[PATCH] PCI: Fix
regression in pci_enable_device_bars") to fix UHCI controller.
>
> - The third problem is that HD-audio driver blindly believes the
> codec_mask read from the register even if it's a read failure as I
> already showed.
This approach has least regression risk.
Kai-Heng
> Ideally we should address in the first place.
>
>
> Takashi
Re: [PATCH] arm64: Kconfig: Add SYS_SUPPORTS_APM_EMULATION
Hi Catalin, Thanks for your explanation. > > so there is two points > > 1. out-of-tree function can't be approved > > I totally agree with this :) so we may have a driver upstream in the > > future. > > It may not be upstreamable if it relies on the old APM interface ;). > > > 2. APM not make sense on arm64 > > Could you please let me konw the reason why APM on ARM64 doesn't make sense? > > It's a very old interface, even on x86 it is disabled in the distro > kernels. There are more modern alternatives and you should update your > driver and user space to use them (e.g. /sys/power/). Got it! I will disscuss with our internal team to update their drivers. thanks a lot! BRs, Lecopzer
[RFC PATCH v2] pinctrl: add helper to expose pinctrl state in debugfs
BeagleBoard.org [0] currently uses an out-of-tree driver called
bone-pinmux-helper [1] developed by Pantelis Antoniou [2] back in 2013.
The driver assists users of our BeagleBone and PocketBeagle boards in
rapid prototyping by allowing them to change at run-time between defined
set of pinctrl states [3] for each pin on the expansion connectors [4].
This is achieved by exposing a 'state' file in sysfs for each pin which
is used by our 'config-pin' utility [5].
Our goal is to eliminate all out-of-tree drivers for BeagleBoard.org
boards and thus I have been working to replace bone-pinmux-helper with a
new driver that could be acceptable upstream. My understanding is that
debugfs, unlike sysfs, could be the appropriate mechanism to expose such
functionality.
Here is an example of how pin P9.14 on the BeagleBone Black expansion
connector [6] would be represented in device tree:
_pinmux {
/* P9_14 (ZCZ ball U14) gpio1_18 */
P9_14_default_pin: pinmux_P9_14_default_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT_PULLDOWN | INPUT_EN |
MUX_MODE7) >; };
P9_14_gpio_pin: pinmux_P9_14_gpio_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT | INPUT_EN | MUX_MODE7) >; };
P9_14_gpio_pu_pin: pinmux_P9_14_gpio_pu_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE7)
>; };
P9_14_gpio_pd_pin: pinmux_P9_14_gpio_pd_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT_PULLDOWN | INPUT_EN |
MUX_MODE7) >; };
P9_14_gpio_input_pin: pinmux_P9_14_gpio_input_pin { pinctrl-single,pins
= <
AM33XX_IOPAD(0x0848, PIN_INPUT | MUX_MODE7) >; };
P9_14_pwm_pin: pinmux_P9_14_pwm_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT_PULLDOWN | INPUT_EN |
MUX_MODE6) >; };
};
{
/* P9_14 (ZCZ ball U14) */
P9_14_pinmux {
compatible = "pinctrl,state-helper";
status = "okay";
pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd",
"gpio_input", "pwm";
pinctrl-0 = <_14_default_pin>;
pinctrl-1 = <_14_gpio_pin>;
pinctrl-2 = <_14_gpio_pu_pin>;
pinctrl-3 = <_14_gpio_pd_pin>;
pinctrl-4 = <_14_gpio_input_pin>;
pinctrl-5 = <_14_pwm_pin>;
};
};
I used the compatible string "pinctrl,state-helper" but would appreciate
advice on how to best name this. Should I create a new vendor prefix?
The P9_14_pinmux entry would cause pinctrl-state-helper to be probed.
The driver would create the corresponding pinctrl state file in debugfs
for the pin. Here is an example of how the state can be read and
written from userspace:
root@beaglebone:~# cat
/sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
default
root@beaglebone:~# echo pwm >
/sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
root@beaglebone:~# cat
/sys/kernel/debug/pinctrl/pinctrl_state/ocp:P9_14_pinmux/state
pwm
I would very much appreciate feedback on both this general concept, and
also specific areas in which the code should be changed to be acceptable
upstream.
Thank you!
Drew
[0] http://beagleboard.org/latest-images
[1]
https://github.com/beagleboard/linux/blob/5.4/drivers/misc/cape/beaglebone/bone-pinmux-helper.c
[2]
https://github.com/RobertCNelson/linux-dev/blob/master/patches/drivers/ti/gpio/0001-BeagleBone-pinmux-helper.patch
[3]
https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v5.4.x-ti-overlays/src/arm/am335x-bone-common-univ.dtsi#L2084
[4]
https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual#section-7-1
[5]
https://github.com/beagleboard/bb.org-overlays/blob/master/tools/beaglebone-universal-io/config-pin
[6] https://beagleboard.org/Support/bone101/#headers
Cc: Pantelis Antoniou
Cc: Pantelis Antoniou
Cc: Pantelis Antoniou
Cc: Jason Kridner
Cc: Robert Nelson
Cc: Linus Walleij
Cc: Tony Lindgren
Cc: Andy Shevchenko
Signed-off-by: Drew Fustini
---
v2 changes:
- add RFC: comments in places where I would appreciate feedback
- remove pa...@antoniou-consulting.com as it is bouncing
- add alternative email addresses for Pantelis
- update pinctrl_state_read() to use kasprintf() based on Andy's advice
- update pinctrl_state_write() to use memdup_user_nul()
- call debugfs_lookup() to use existing "pinctrl" dir as parent
- create subdir "pinctrl_state" to be parent of per-pin directories
- add pinctrl_state_helper_init() and pinctrl_state_helper_exit() to
handle creating and cleaning up debugfs_root ("pinctrl_state")
drivers/pinctrl/Kconfig| 10 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-state-helper.c | 241 +
3 files changed, 252 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-state-helper.c
diff --git a/drivers/pinctrl/Kconfig
Re: [PATCH bpf-next 1/2] bpf: Add a bpf_kallsyms_lookup helper
On 12/17/20 7:20 PM, Alexei Starovoitov wrote:
On Thu, Dec 17, 2020 at 09:26:09AM -0800, Yonghong Song wrote:
On 12/17/20 7:31 AM, Florent Revest wrote:
On Mon, Dec 14, 2020 at 7:47 AM Yonghong Song wrote:
On 12/11/20 6:40 AM, Florent Revest wrote:
On Wed, Dec 2, 2020 at 10:18 PM Alexei Starovoitov
wrote:
I still think that adopting printk/vsnprintf for this instead of
reinventing the wheel
is more flexible and easier to maintain long term.
Almost the same layout can be done with vsnprintf
with exception of \0 char.
More meaningful names, etc.
See Documentation/core-api/printk-formats.rst
I agree this would be nice. I finally got a bit of time to experiment
with this and I noticed a few things:
First of all, because helpers only have 5 arguments, if we use two for
the output buffer and its size and two for the format string and its
size, we are only left with one argument for a modifier. This is still
enough for our usecase (where we'd only use "%ps" for example) but it
does not strictly-speaking allow for the same layout that Andrii
proposed.
See helper bpf_seq_printf. It packs all arguments for format string and
puts them into an array. bpf_seq_printf will unpack them as it parsed
through the format string. So it should be doable to have more than
"%ps" in format string.
This could be a nice trick, thank you for the suggestion Yonghong :)
My understanding is that this would also require two extra args (one
for the array of arguments and one for the size of this array) so it
would still not fit the 5 arguments limit I described in my previous
email.
eg: this would not be possible:
long bpf_snprintf(const char *out, u32 out_size,
const char *fmt, u32 fmt_size,
const void *data, u32 data_len)
Right. bpf allows only up to 5 parameters.
Would you then suggest that we also put the format string and its
length in the first and second cells of this array and have something
along the line of:
long bpf_snprintf(const char *out, u32 out_size,
const void *args, u32 args_len) ?
This seems like a fairly opaque signature to me and harder to verify.
One way is to define an explicit type for args, something like
struct bpf_fmt_str_data {
char *fmt;
u64 fmt_len;
u64 data[];
};
that feels a bit convoluted.
The reason I feel unease with the helper as was originally proposed
and with Andrii's proposal is all the extra strlen and strcpy that
needs to be done. In the helper we have to call kallsyms_lookup()
which is ok interface for what it was desinged to do,
but it's awkward to use to construct new string ("%s [%s]", sym, modname)
or to send two strings into a ring buffer.
Andrii's zero separator idea will simplify bpf prog, but user space
would need to do strlen anyway if it needs to pretty print.
If we take pain on converting addr to sym+modname let's figure out
how to make it easy for the bpf prog to do and easy for user space to consume.
That's why I proposed snprintf.
As far as 6 arg issue:
long bpf_snprintf(const char *out, u32 out_size,
const char *fmt, u32 fmt_size,
const void *data, u32 data_len);
Yeah. It won't work as-is, but fmt_size is unnecessary nowadays.
The verifier understands read-only data.
Hence the helper can be:
long bpf_snprintf(const char *out, u32 out_size,
const char *fmt,
const void *data, u32 data_len);
The 3rd arg cannot be ARG_PTR_TO_MEM.
Instead we can introduce ARG_PTR_TO_CONST_STR in the verifier.
This should work except if fmt string is on the stack. Maybe this is
an okay tradeoff.
See check_mem_access() where it's doing bpf_map_direct_read().
That 'fmt' string will be accessed through the same bpf_map_direct_read().
The verifier would need to check that it's NUL-terminated valid string.
It should probably do % specifier checks at the same time.
At the end bpf_snprintf() will have 5 args and when wrapped with
BPF_SNPRINTF() macro it will accept arbitrary number of arguments to print.
It also will be generally useful to do all other kinds of pretty printing.
Re: [PATCH V3 1/3] arm64: topology: Avoid the have_policy check
On 17-12-20, 10:55, Catalin Marinas wrote: > Hi Viresh, > > On Thu, Dec 17, 2020 at 01:27:32PM +0530, Viresh Kumar wrote: > > On 15-12-20, 11:04, Viresh Kumar wrote: > > > Every time I have stumbled upon this routine, I get confused with the > > > way 'have_policy' is used and I have to dig in to understand why is it > > > so. Here is an attempt to make it easier to understand, and hopefully it > > > is an improvement. > > > > > > The 'have_policy' check was just an optimization to avoid writing > > > to amu_fie_cpus in case we don't have to, but that optimization itself > > > is creating more confusion than the real work. Lets just do that if all > > > the CPUs support AMUs. It is much cleaner that way. > > > > > > Reviewed-by: Ionela Voinescu > > > Signed-off-by: Viresh Kumar > > > --- > > > V3: > > > - Added Reviewed by tag. > > > > Catalin, please pick the first two patches for 5.11. I will send the > > last one separately later on. > > I haven't figured out whether these are fixes (a cover letter would > help ;)). They look like generic improvements to me Right they are and since the merge window just opened I thought these don't really need to wait for another full cycle to get in. > and given that we > are already in the 5.11 merging window, they would probably need to wait > until 5.12. Whatever you decide :) -- viresh
[PATCH] net: neighbor: fix a crash caused by mod zero
pneigh_enqueue() tries to obtain a random delay by mod
NEIGH_VAR(p, PROXY_DELAY). However, NEIGH_VAR(p, PROXY_DELAY)
migth be zero at that point because someone could write zero
to /proc/sys/net/ipv4/neigh/[device]/proxy_delay after the
callers check it.
This patch double-checks NEIGH_VAR(p, PROXY_DELAY) in
pneigh_enqueue() to ensure not to take zero as modulus.
Signed-off-by: weichenchen
---
net/core/neighbour.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 9500d28a43b0..eb5d015c53d3 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1570,9 +1570,14 @@ void pneigh_enqueue(struct neigh_table *tbl, struct
neigh_parms *p,
struct sk_buff *skb)
{
unsigned long now = jiffies;
+ unsigned long sched_next;
- unsigned long sched_next = now + (prandom_u32() %
- NEIGH_VAR(p, PROXY_DELAY));
+ int delay = NEIGH_VAR(p, PROXY_DELAY);
+
+ if (delay <= 0)
+ sched_next = now;
+ else
+ sched_next = now + (prandom_u32() % delay);
if (tbl->proxy_queue.qlen > NEIGH_VAR(p, PROXY_QLEN)) {
kfree_skb(skb);
--
2.20.1 (Apple Git-117)
Re: [PATCH] mm/filemap: Fix warning: no previous prototype
On Thu, Dec 17, 2020 at 7:53 AM Matthew Wilcox wrote:
>
> On Thu, Dec 17, 2020 at 10:03:11AM +0800, Xiangyang Yu wrote:
> > Fixed the warning when building with warnings enabled (W=1),
> > This function is only used in filemap.c, so mark this function
> > with 'static'.
>
> Good grief, no. Look at the git history before proposing a patch.
revert "mm/filemap: add static for function __add_to_page_cache_locked"
Revert commit 3351b16af494 ("mm/filemap: add static for function
__add_to_page_cache_locked") due to incompatibility with
ALLOW_ERROR_INJECTION which result in build errors.
>
Re: [NEEDS-REVIEW] [PATCH V3 04/10] x86/pks: Preserve the PKRS MSR on context switch
On Thu, Dec 17, 2020 at 12:41:50PM -0800, Dave Hansen wrote: > On 11/6/20 3:29 PM, ira.we...@intel.com wrote: > > void disable_TSC(void) > > @@ -644,6 +668,8 @@ void __switch_to_xtra(struct task_struct *prev_p, > > struct task_struct *next_p) > > > > if ((tifp ^ tifn) & _TIF_SLD) > > switch_to_sld(tifn); > > + > > + pks_sched_in(); > > } > > Does the selftest for this ever actually schedule()? At this point I'm not sure. This code has been in since the beginning. So its seen a lot of soak time. > > I see it talking about context switching, but I don't immediately see > how it would. We were trying to force parent and child to run on the same CPU. I suspect something is wrong in the timing of that test. Ira
[PATCH] ACPI: scan: Fix a Hyper-V Linux VM panic caused by buffer overflow
Linux VM on Hyper-V crashes with the latest mainline:
[4.069624] detected buffer overflow in strcpy
[4.077733] kernel BUG at lib/string.c:1149!
..
[4.085819] RIP: 0010:fortify_panic+0xf/0x11
...
[4.085819] Call Trace:
[4.085819] acpi_device_add.cold.15+0xf2/0xfb
[4.085819] acpi_add_single_object+0x2a6/0x690
[4.085819] acpi_bus_check_add+0xc6/0x280
[4.085819] acpi_ns_walk_namespace+0xda/0x1aa
[4.085819] acpi_walk_namespace+0x9a/0xc2
[4.085819] acpi_bus_scan+0x78/0x90
[4.085819] acpi_scan_init+0xfa/0x248
[4.085819] acpi_init+0x2c1/0x321
[4.085819] do_one_initcall+0x44/0x1d0
[4.085819] kernel_init_freeable+0x1ab/0x1f4
This is because of the recent buffer overflow detection in the
commit 6a39e62abbaf ("lib: string.h: detect intra-object overflow in fortified
string functions")
Here acpi_device_bus_id->bus_id can only hold 14 characters, while the
the acpi_device_hid(device) returns a 22-char string
"HYPER_V_GEN_COUNTER_V1".
Per ACPI Spec v6.2, Section 6.1.5 _HID (Hardware ID), if the ID is a
string, it must be of the form AAA or , i.e. 7 chars or 8
chars.
The field bus_id in struct acpi_device_bus_id was originally defined as
char bus_id[9], and later was enlarged to char bus_id[15] in 2007 in the
commit bb0958544f3c ("ACPI: use more understandable bus_id for ACPI devices")
It looks like so far an ID string of >=15 chars is only seen in the guest
BIOS/firmware by Hyper-V, and AFAIK the ID string "HYPER_V_GEN_COUNTER_V1"
is never used by Linux VM on Hyper-V, so let's just truncate the string to
fix the panic.
Signed-off-by: Dexuan Cui
---
drivers/acpi/scan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index a1b226eb2ce2..b801442b6b1b 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -674,7 +674,8 @@ int acpi_device_add(struct acpi_device *device,
}
if (!found) {
acpi_device_bus_id = new_bus_id;
- strcpy(acpi_device_bus_id->bus_id, acpi_device_hid(device));
+ strlcpy(acpi_device_bus_id->bus_id, acpi_device_hid(device),
+ sizeof(acpi_device_bus_id->bus_id));
acpi_device_bus_id->instance_no = 0;
list_add_tail(_device_bus_id->node, _bus_id_list);
}
--
2.19.1
Re: [PATCH V3 04/10] x86/pks: Preserve the PKRS MSR on context switch
On Thu, Dec 17, 2020 at 03:50:55PM +0100, Thomas Gleixner wrote:
> On Fri, Nov 06 2020 at 15:29, ira weiny wrote:
> > --- a/arch/x86/kernel/process.c
> > +++ b/arch/x86/kernel/process.c
> > @@ -43,6 +43,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "process.h"
> >
> > @@ -187,6 +188,27 @@ int copy_thread(unsigned long clone_flags, unsigned
> > long sp, unsigned long arg,
> > return ret;
> > }
> >
> > +#ifdef CONFIG_ARCH_HAS_SUPERVISOR_PKEYS
> > +DECLARE_PER_CPU(u32, pkrs_cache);
> > +static inline void pks_init_task(struct task_struct *tsk)
>
> First of all. I asked several times now not to glue stuff onto a
> function without a newline inbetween. It's unreadable.
Fixed.
>
> But what's worse is that the declaration of pkrs_cache which is global
> is in a C file and not in a header. And pkrs_cache is not even used in
> this file. So what?
OK, this was just a complete rebase/refactor mess up on my part. The
global'ness is not required until we need a global update of the pkrs which was
not part of this series.
I've removed it from this patch. And cleaned it up in patch 6/10 as well. And
cleaned it up in the global pkrs patch which you found in my git tree.
>
> > +{
> > + /* New tasks get the most restrictive PKRS value */
> > + tsk->thread.saved_pkrs = INIT_PKRS_VALUE;
> > +}
> > +static inline void pks_sched_in(void)
>
> Newline between functions. It's fine for stubs, but not for a real
> implementation.
Again my apologies.
Fixed.
>
> > diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c
> > index d1dfe743e79f..76a62419c446 100644
> > --- a/arch/x86/mm/pkeys.c
> > +++ b/arch/x86/mm/pkeys.c
> > @@ -231,3 +231,34 @@ u32 update_pkey_val(u32 pk_reg, int pkey, unsigned int
> > flags)
> >
> > return pk_reg;
> > }
> > +
> > +DEFINE_PER_CPU(u32, pkrs_cache);
>
> Again, why is this global?
In this patch it does not need to be. I've changed it to static.
>
> > +void write_pkrs(u32 new_pkrs)
> > +{
> > + u32 *pkrs;
> > +
> > + if (!static_cpu_has(X86_FEATURE_PKS))
> > + return;
> > +
> > + pkrs = get_cpu_ptr(_cache);
>
> So this is called from various places including schedule and also from
> the low level entry/exit code. Why do we need to have an extra
> preempt_disable/enable() there via get/put_cpu_ptr()?
>
> Just because performance in those code paths does not matter?
Honestly I don't recall the full history at this point. The
preempt_disable/enable() is required when this is called from
pks_update_protection() AKA when a user is trying to update the protections of
their key. What I do remember is that this was originally not preempt safe and
we
had a comment to that effect in the early patches.[1]
Somewhere along the line the preempt discussion lead us to make write_pkrs()
'self contained' with the preemption protection here. I just did not think
about any performance issues. It is safe to call preempt_disable() from a
preempt disabled region, correct? I seem to recall asking that and the answer
was 'yes'.
I will audit the calls again and adjust the preemption disable as needed.
[1] https://lore.kernel.org/lkml/20200717072056.73134-5-ira.we...@intel.com/#t
>
> > + if (*pkrs != new_pkrs) {
> > + *pkrs = new_pkrs;
> > + wrmsrl(MSR_IA32_PKRS, new_pkrs);
> > + }
> > + put_cpu_ptr(pkrs);
>
> Now back to the context switch:
>
> > @@ -644,6 +668,8 @@ void __switch_to_xtra(struct task_struct *prev_p,
> > struct task_struct *next_p)
> >
> > if ((tifp ^ tifn) & _TIF_SLD)
> > switch_to_sld(tifn);
> > +
> > + pks_sched_in();
> > }
>
> How is this supposed to work?
>
> switch_to() {
>
>switch_to_extra() {
>
> if (unlikely(next_tif & _TIF_WORK_CTXSW_NEXT ||
> prev_tif & _TIF_WORK_CTXSW_PREV))
> __switch_to_xtra(prev, next);
>
> I.e. __switch_to_xtra() is only invoked when the above condition is
> true, which is not guaranteed at all.
I did not know that. I completely missunderstood what __switch_to_xtra()
meant. I thought it was arch specific 'extra' stuff so it seemed reasonable to
me.
Also, our test seemed to work. I'm still investigating what may be wrong.
>
> While I have to admit that I dropped the ball on the update for the
> entry patch, I'm not too sorry about it anymore when looking at this.
>
> Are you still sure that this is ready for merging?
Nope...
Thanks for the review,
Ira
>
> Thanks,
>
> tglx
Re: [PATCH V3 10/10] x86/pks: Add PKS test code
On Thu, Dec 17, 2020 at 12:55:39PM -0800, Dave Hansen wrote: > On 11/6/20 3:29 PM, ira.we...@intel.com wrote: > > + /* Arm for context switch test */ > > + write(fd, "1", 1); > > + > > + /* Context switch out... */ > > + sleep(4); > > + > > + /* Check msr restored */ > > + write(fd, "2", 1); > > These are always tricky. What you ideally want here is: > > 1. Switch away from this task to a non-PKS task, or > 2. Switch from this task to a PKS-using task, but one which has a >different PKS value Or both... > > then, switch back to this task and make sure PKS maintained its value. > > *But*, there's no absolute guarantee that another task will run. It > would not be totally unreasonable to have the kernel just sit in a loop > without context switching here if no other tasks can run. > > The only way you *know* there is a context switch is by having two tasks > bound to the same logical CPU and make sure they run one after another. Ah... We do that. ... + CPU_ZERO(); + CPU_SET(0, ); + /* Two processes run on CPU 0 so that they go through context switch. */ + sched_setaffinity(getpid(), sizeof(cpu_set_t), ); ... I think this should be ensuring that both the parent and the child are running on CPU 0. At least according to the man page they should be. A child created via fork(2) inherits its parent's CPU affinity mask. Perhaps a better method would be to synchronize the 2 threads more to ensure that we are really running at the 'same time' and forcing the context switch. > This just gets itself into a state where it *CAN* context switch and > prays that one will happen. Not sure what you mean by 'This'? Do you mean that running on the same CPU will sometimes not force a context switch? Or do you mean that the sleeps could be badly timed and the 2 threads could run 1 after the other on the same CPU? The latter is AFAICT the most likely case. > > You can also run a bunch of these in parallel bound to a single CPU. > That would also give you higher levels of assurance that *some* context > switch happens at sleep(). I think more cycles is a good idea for sure. But I'm more comfortable with forcing the test to be more synchronized so that it is actually running in the order we think/want it to be. > > One critical thing with these tests is to sabotage the kernel and then > run them and make *sure* they fail. Basically, if you screw up, do they > actually work to catch it? I'll try and come up with a more stressful test. Ira
RE: [EXT] Re: [PATCH 1/2] mmc: Support kmsg dumper based on pstore/blk
>-Original Message- >From: Ulf Hansson >Sent: Thursday, December 17, 2020 10:42 PM >To: Bhaskara Budiredla >Cc: Kees Cook ; Colin Cross >; Tony Luck ; Sunil Kovvuri >Goutham ; linux-...@vger.kernel.org; Linux >Kernel Mailing List ; Christoph Hellwig > >Subject: Re: [EXT] Re: [PATCH 1/2] mmc: Support kmsg dumper based on >pstore/blk > >On Thu, 17 Dec 2020 at 12:36, Bhaskara Budiredla >wrote: >> >> >> [...] >> >> >> >> An extra check can be added to see if host was runtime suspended >> >> >> ahead of panic write attempt. >> >> > >> >> >What if that is the case, should we just return an error? >> >> > >> >> Yes. >> >> >> >> >Moreover, even the device belonging to the mmc card can be runtime >> >> >suspended too. So if that is the case, we should return an error too? >> >> > >> >> >> >> Yes, same here. >> >> >> >> Please comment if returning error is sufficient here or can there be >> an attempt to wake the device through either of the atomic activation calls: >> pm_runtime_get(), pm_request_resume()? > >Hmm, I would start with playing with the below. mmc_claim_host supports >also nested claims. > >mmc_claim_host(host) - this will call pm_runtime_get_sync(host) >mmc_get_card(card, NULL) - this will call can >pm_runtime_get_sync(card)) and also try to claim the host > As you suggested I am creating a parallel path that avoids wait queue to claim the host. The *_sync()* routines could sleep, I can't use them as part of panic write. >Kind regards >Uffe Thanks, Bhaskara
[PATCH v6 6/6] ARM: dts: rainier: Add eMMC clock phase compensation
Determined by scope measurements at speed.
Signed-off-by: Andrew Jeffery
Reviewed-by: Joel Stanley
---
arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
index 21ae880c7530..ab8d37d49f30 100644
--- a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
@@ -186,6 +186,7 @@ _emmc_default {
{
status = "okay";
+ clk-phase-mmc-hs200 = <180>, <180>;
};
{
--
2.27.0
[PATCH v6 5/6] MAINTAINERS: Add entry for the ASPEED SD/MMC driver
Add myself as the maintainer. Signed-off-by: Andrew Jeffery --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index e451dcce054f..eae4322aae67 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2826,6 +2826,15 @@ F: Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2xxx-scu-ic. F: drivers/irqchip/irq-aspeed-scu-ic.c F: include/dt-bindings/interrupt-controller/aspeed-scu-ic.h +ASPEED SD/MMC DRIVER +M: Andrew Jeffery +L: linux-asp...@lists.ozlabs.org (moderated for non-subscribers) +L: open...@lists.ozlabs.org (moderated for non-subscribers) +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml +F: drivers/mmc/host/sdhci-of-aspeed* + ASPEED VIDEO ENGINE DRIVER M: Eddie James L: linux-me...@vger.kernel.org -- 2.27.0
[PATCH v6 1/6] mmc: core: Add helper for parsing clock phase properties
Drivers for MMC hosts that accept phase corrections can take advantage
of the helper by embedding an instance of struct mmc_clk_phase_map in
their private data and invoking mmc_of_parse_clk_phase() to extract
phase parameters. It is the responsibility of the host driver to
translate and apply the extracted values to hardware as required.
Signed-off-by: Andrew Jeffery
---
drivers/mmc/core/host.c | 44
include/linux/mmc/host.h | 13
2 files changed, 57 insertions(+)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 96b2ca1f1b06..74e853bb6948 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -163,6 +163,50 @@ static void mmc_retune_timer(struct timer_list *t)
mmc_retune_needed(host);
}
+static void mmc_of_parse_timing_phase(struct device *dev, const char *prop,
+ struct mmc_clk_phase *phase)
+{
+ int degrees[2] = {0};
+ int rc;
+
+ rc = device_property_read_u32_array(dev, prop, degrees, 2);
+ phase->valid = !rc;
+ if (phase->valid) {
+ phase->in_deg = degrees[0];
+ phase->out_deg = degrees[1];
+ }
+}
+
+void
+mmc_of_parse_clk_phase(struct mmc_host *host, struct mmc_clk_phase_map *map)
+{
+ struct device *dev = host->parent;
+
+ mmc_of_parse_timing_phase(dev, "clk-phase-legacy",
+ >phase[MMC_TIMING_LEGACY]);
+ mmc_of_parse_timing_phase(dev, "clk-phase-mmc-hs",
+ >phase[MMC_TIMING_MMC_HS]);
+ mmc_of_parse_timing_phase(dev, "clk-phase-sd-hs",
+ >phase[MMC_TIMING_SD_HS]);
+ mmc_of_parse_timing_phase(dev, "clk-phase-uhs-sdr12",
+ >phase[MMC_TIMING_UHS_SDR12]);
+ mmc_of_parse_timing_phase(dev, "clk-phase-uhs-sdr25",
+ >phase[MMC_TIMING_UHS_SDR25]);
+ mmc_of_parse_timing_phase(dev, "clk-phase-uhs-sdr50",
+ >phase[MMC_TIMING_UHS_SDR50]);
+ mmc_of_parse_timing_phase(dev, "clk-phase-uhs-sdr104",
+ >phase[MMC_TIMING_UHS_SDR104]);
+ mmc_of_parse_timing_phase(dev, "clk-phase-uhs-ddr50",
+ >phase[MMC_TIMING_UHS_DDR50]);
+ mmc_of_parse_timing_phase(dev, "clk-phase-mmc-ddr52",
+ >phase[MMC_TIMING_MMC_DDR52]);
+ mmc_of_parse_timing_phase(dev, "clk-phase-mmc-hs200",
+ >phase[MMC_TIMING_MMC_HS200]);
+ mmc_of_parse_timing_phase(dev, "clk-phase-mmc-hs400",
+ >phase[MMC_TIMING_MMC_HS400]);
+}
+EXPORT_SYMBOL(mmc_of_parse_clk_phase);
+
/**
* mmc_of_parse() - parse host's device-tree node
* @host: host whose node should be parsed.
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 01bba36545c5..8cf686d98a68 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -79,6 +79,17 @@ struct mmc_ios {
bool enhanced_strobe; /* hs400es selection */
};
+struct mmc_clk_phase {
+ bool valid;
+ u16 in_deg;
+ u16 out_deg;
+};
+
+#define MMC_NUM_CLK_PHASES (MMC_TIMING_MMC_HS400 + 1)
+struct mmc_clk_phase_map {
+ struct mmc_clk_phase phase[MMC_NUM_CLK_PHASES];
+};
+
struct mmc_host;
struct mmc_host_ops {
@@ -490,6 +501,8 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *);
int mmc_add_host(struct mmc_host *);
void mmc_remove_host(struct mmc_host *);
void mmc_free_host(struct mmc_host *);
+void mmc_of_parse_clk_phase(struct mmc_host *host,
+ struct mmc_clk_phase_map *map);
int mmc_of_parse(struct mmc_host *host);
int mmc_of_parse_voltage(struct device_node *np, u32 *mask);
--
2.27.0
[PATCH v6 2/6] mmc: sdhci-of-aspeed: Expose clock phase controls
The Aspeed SD/eMMC controllers expose configurable clock phase
correction by inserting delays of up to 15 logic elements in length into
the bus clock path. The hardware supports independent configuration for
both bus directions on a per-slot basis.
The timing delay per element encoded in the driver was experimentally
determined by scope measurements.
The phase controls for both slots are grouped together in a single
register of the global register block of the SD/MMC controller(s), which
drives the use of a locking scheme between the SDHCIs and the global
register set.
Signed-off-by: Andrew Jeffery
---
drivers/mmc/host/sdhci-of-aspeed.c | 216 +++--
1 file changed, 208 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c
b/drivers/mmc/host/sdhci-of-aspeed.c
index 4f008ba3280e..b1a14e7dda82 100644
--- a/drivers/mmc/host/sdhci-of-aspeed.c
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -16,9 +17,19 @@
#include "sdhci-pltfm.h"
-#define ASPEED_SDC_INFO0x00
-#define ASPEED_SDC_S1MMC8BIT(25)
-#define ASPEED_SDC_S0MMC8BIT(24)
+#define ASPEED_SDC_INFO0x00
+#define ASPEED_SDC_S1_MMC8 BIT(25)
+#define ASPEED_SDC_S0_MMC8 BIT(24)
+#define ASPEED_SDC_PHASE 0xf4
+#define ASPEED_SDC_S1_PHASE_IN GENMASK(25, 21)
+#define ASPEED_SDC_S0_PHASE_IN GENMASK(20, 16)
+#define ASPEED_SDC_S1_PHASE_OUT GENMASK(15, 11)
+#define ASPEED_SDC_S1_PHASE_IN_ENBIT(10)
+#define ASPEED_SDC_S1_PHASE_OUT_EN GENMASK(9, 8)
+#define ASPEED_SDC_S0_PHASE_OUT GENMASK(7, 3)
+#define ASPEED_SDC_S0_PHASE_IN_ENBIT(2)
+#define ASPEED_SDC_S0_PHASE_OUT_EN GENMASK(1, 0)
+#define ASPEED_SDC_PHASE_MAX 31
struct aspeed_sdc {
struct clk *clk;
@@ -28,9 +39,36 @@ struct aspeed_sdc {
void __iomem *regs;
};
+struct aspeed_sdhci_tap_param {
+ bool valid;
+
+#define ASPEED_SDHCI_TAP_PARAM_INVERT_CLK BIT(4)
+ u8 in;
+ u8 out;
+};
+
+struct aspeed_sdhci_tap_desc {
+ u32 tap_mask;
+ u32 enable_mask;
+ u8 enable_value;
+};
+
+struct aspeed_sdhci_phase_desc {
+ struct aspeed_sdhci_tap_desc in;
+ struct aspeed_sdhci_tap_desc out;
+};
+
+struct aspeed_sdhci_pdata {
+ const struct aspeed_sdhci_phase_desc *phase_desc;
+ size_t nr_phase_descs;
+};
+
struct aspeed_sdhci {
+ const struct aspeed_sdhci_pdata *pdata;
struct aspeed_sdc *parent;
u32 width_mask;
+ struct mmc_clk_phase_map phase_map;
+ const struct aspeed_sdhci_phase_desc *phase_desc;
};
static void aspeed_sdc_configure_8bit_mode(struct aspeed_sdc *sdc,
@@ -50,10 +88,118 @@ static void aspeed_sdc_configure_8bit_mode(struct
aspeed_sdc *sdc,
spin_unlock(>lock);
}
+static u32
+aspeed_sdc_set_phase_tap(const struct aspeed_sdhci_tap_desc *desc,
+u8 tap, bool enable, u32 reg)
+{
+ reg &= ~(desc->enable_mask | desc->tap_mask);
+ if (enable) {
+ reg |= tap << __ffs(desc->tap_mask);
+ reg |= desc->enable_value << __ffs(desc->enable_mask);
+ }
+
+ return reg;
+}
+
+static void
+aspeed_sdc_set_phase_taps(struct aspeed_sdc *sdc,
+ const struct aspeed_sdhci_phase_desc *desc,
+ const struct aspeed_sdhci_tap_param *taps)
+{
+ u32 reg;
+
+ spin_lock(>lock);
+ reg = readl(sdc->regs + ASPEED_SDC_PHASE);
+
+ reg = aspeed_sdc_set_phase_tap(>in, taps->in, taps->valid, reg);
+ reg = aspeed_sdc_set_phase_tap(>out, taps->out, taps->valid, reg);
+
+ writel(reg, sdc->regs + ASPEED_SDC_PHASE);
+ spin_unlock(>lock);
+}
+
+#define PICOSECONDS_PER_SECOND 1ULL
+#define ASPEED_SDHCI_NR_TAPS 15
+/* Measured value with *handwave* environmentals and static loading */
+#define ASPEED_SDHCI_MAX_TAP_DELAY_PS 1253
+static int aspeed_sdhci_phase_to_tap(struct device *dev, unsigned long rate_hz,
+int phase_deg)
+{
+ u64 phase_period_ps;
+ u64 prop_delay_ps;
+ u64 clk_period_ps;
+ unsigned int tap;
+ u8 inverted;
+
+ phase_deg %= 360;
+
+ if (phase_deg >= 180) {
+ inverted = ASPEED_SDHCI_TAP_PARAM_INVERT_CLK;
+ phase_deg -= 180;
+ dev_dbg(dev,
+ "Inverting clock to reduce phase correction from %d to
%d degrees\n",
+ phase_deg + 180, phase_deg);
+ } else {
+ inverted = 0;
+ }
+
+ prop_delay_ps = ASPEED_SDHCI_MAX_TAP_DELAY_PS / ASPEED_SDHCI_NR_TAPS;
+ clk_period_ps = div_u64(PICOSECONDS_PER_SECOND, (u64)rate_hz);
+ phase_period_ps = div_u64((u64)phase_deg * clk_period_ps, 360ULL);
+
+ tap = div_u64(phase_period_ps, prop_delay_ps);
[PATCH v6 3/6] mmc: sdhci-of-aspeed: Add AST2600 bus clock support
The AST2600 can achieve HS200 speeds with a change to the bus clock
divisor behaviour. The divisor can also be more accurate with respect
to the requested clock rate, but keep the one-hot behaviour for
backwards compatibility with the AST2400 and AST2500.
Signed-off-by: Andrew Jeffery
---
drivers/mmc/host/sdhci-of-aspeed.c | 37 ++
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c
b/drivers/mmc/host/sdhci-of-aspeed.c
index b1a14e7dda82..4b30f6a1178e 100644
--- a/drivers/mmc/host/sdhci-of-aspeed.c
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -59,6 +59,7 @@ struct aspeed_sdhci_phase_desc {
};
struct aspeed_sdhci_pdata {
+ unsigned int clk_div_start;
const struct aspeed_sdhci_phase_desc *phase_desc;
size_t nr_phase_descs;
};
@@ -200,10 +201,13 @@ static void aspeed_sdhci_set_clock(struct sdhci_host
*host, unsigned int clock)
{
struct sdhci_pltfm_host *pltfm_host;
unsigned long parent, bus;
+ struct aspeed_sdhci *sdhci;
int div;
u16 clk;
pltfm_host = sdhci_priv(host);
+ sdhci = sdhci_pltfm_priv(pltfm_host);
+
parent = clk_get_rate(pltfm_host->clk);
sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
@@ -214,7 +218,23 @@ static void aspeed_sdhci_set_clock(struct sdhci_host
*host, unsigned int clock)
if (WARN_ON(clock > host->max_clk))
clock = host->max_clk;
- for (div = 2; div < 256; div *= 2) {
+ /*
+* Regarding the AST2600:
+*
+* If (EMMC12C[7:6], EMMC12C[15:8] == 0) then
+* period of SDCLK = period of SDMCLK.
+*
+* If (EMMC12C[7:6], EMMC12C[15:8] != 0) then
+* period of SDCLK = period of SDMCLK * 2 * (EMMC12C[7:6], EMMC[15:8])
+*
+* If you keep EMMC12C[7:6] = 0 and EMMC12C[15:8] as one-hot,
+* 0x1/0x2/0x4/etc, you will find it is compatible to AST2400 or AST2500
+*
+* Keep the one-hot behaviour for backwards compatibility except for
+* supporting the value 0 in (EMMC12C[7:6], EMMC12C[15:8]), and capture
+* the 0-value capability in clk_div_start.
+*/
+ for (div = sdhci->pdata->clk_div_start; div < 256; div *= 2) {
bus = parent / div;
if (bus <= clock)
break;
@@ -316,6 +336,10 @@ static int aspeed_sdhci_probe(struct platform_device *pdev)
int ret;
aspeed_pdata = of_device_get_match_data(>dev);
+ if (!aspeed_pdata) {
+ dev_err(>dev, "Missing platform configuration data\n");
+ return -EINVAL;
+ }
host = sdhci_pltfm_init(pdev, _sdhci_pdata, sizeof(*dev));
if (IS_ERR(host))
@@ -334,7 +358,7 @@ static int aspeed_sdhci_probe(struct platform_device *pdev)
else if (slot >= 2)
return -EINVAL;
- if (dev->pdata && slot < dev->pdata->nr_phase_descs) {
+ if (slot < dev->pdata->nr_phase_descs) {
dev->phase_desc = >pdata->phase_desc[slot];
} else {
dev_info(>dev,
@@ -396,6 +420,10 @@ static int aspeed_sdhci_remove(struct platform_device
*pdev)
return 0;
}
+static const struct aspeed_sdhci_pdata ast2400_sdhci_pdata = {
+ .clk_div_start = 2,
+};
+
static const struct aspeed_sdhci_phase_desc ast2600_sdhci_phase[] = {
/* SDHCI/Slot 0 */
[0] = {
@@ -426,13 +454,14 @@ static const struct aspeed_sdhci_phase_desc
ast2600_sdhci_phase[] = {
};
static const struct aspeed_sdhci_pdata ast2600_sdhci_pdata = {
+ .clk_div_start = 1,
.phase_desc = ast2600_sdhci_phase,
.nr_phase_descs = ARRAY_SIZE(ast2600_sdhci_phase),
};
static const struct of_device_id aspeed_sdhci_of_match[] = {
- { .compatible = "aspeed,ast2400-sdhci", },
- { .compatible = "aspeed,ast2500-sdhci", },
+ { .compatible = "aspeed,ast2400-sdhci", .data = _sdhci_pdata, },
+ { .compatible = "aspeed,ast2500-sdhci", .data = _sdhci_pdata, },
{ .compatible = "aspeed,ast2600-sdhci", .data = _sdhci_pdata, },
{ }
};
--
2.27.0
[PATCH v6 4/6] mmc: sdhci-of-aspeed: Add KUnit tests for phase calculations
Converting degrees of phase to logic delays is irritating to test on
hardware, so lets exercise the function using KUnit.
Signed-off-by: Andrew Jeffery
---
drivers/mmc/host/Kconfig| 14
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-of-aspeed-test.c | 100
3 files changed, 115 insertions(+)
create mode 100644 drivers/mmc/host/sdhci-of-aspeed-test.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 596f32637315..d6f00d1d6251 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -168,6 +168,20 @@ config MMC_SDHCI_OF_ASPEED
If unsure, say N.
+config MMC_SDHCI_OF_ASPEED_TEST
+ bool "Tests for the ASPEED SDHCI driver"
+ depends on MMC_SDHCI_OF_ASPEED && KUNIT=y
+ help
+ Enable KUnit tests for the ASPEED SDHCI driver. Select this
+ option only if you will boot the kernel for the purpose of running
+ unit tests (e.g. under UML or qemu).
+
+ The KUnit tests generally exercise parts of the driver that do not
+ directly touch the hardware, for example, the phase correction
+ calculations.
+
+ If unsure, say N.
+
config MMC_SDHCI_OF_AT91
tristate "SDHCI OF support for the Atmel SDMMC controller"
depends on MMC_SDHCI_PLTFM
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 451c25fc2c69..3ee59d5802cf 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -90,6 +90,7 @@ obj-$(CONFIG_MMC_SDHCI_DOVE) += sdhci-dove.o
obj-$(CONFIG_MMC_SDHCI_TEGRA) += sdhci-tegra.o
obj-$(CONFIG_MMC_SDHCI_OF_ARASAN) += sdhci-of-arasan.o
obj-$(CONFIG_MMC_SDHCI_OF_ASPEED) += sdhci-of-aspeed.o
+obj-$(CONFIG_MMC_SDHCI_OF_ASPEED_TEST) += sdhci-of-aspeed-test.o
obj-$(CONFIG_MMC_SDHCI_OF_AT91)+= sdhci-of-at91.o
obj-$(CONFIG_MMC_SDHCI_OF_ESDHC) += sdhci-of-esdhc.o
obj-$(CONFIG_MMC_SDHCI_OF_HLWD)+= sdhci-of-hlwd.o
diff --git a/drivers/mmc/host/sdhci-of-aspeed-test.c
b/drivers/mmc/host/sdhci-of-aspeed-test.c
new file mode 100644
index ..fb79b278fb81
--- /dev/null
+++ b/drivers/mmc/host/sdhci-of-aspeed-test.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* Copyright (C) 2020 IBM Corp. */
+
+#include
+
+#include "sdhci-of-aspeed.c"
+
+static void aspeed_sdhci_phase_ddr52(struct kunit *test)
+{
+ int rate = 5200;
+
+ KUNIT_EXPECT_EQ(test, 0,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 0));
+ KUNIT_EXPECT_EQ(test, 0,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 1));
+ KUNIT_EXPECT_EQ(test, 1,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 2));
+ KUNIT_EXPECT_EQ(test, 1,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 3));
+ KUNIT_EXPECT_EQ(test, 2,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 4));
+ KUNIT_EXPECT_EQ(test, 3,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 5));
+ KUNIT_EXPECT_EQ(test, 14,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 23));
+ KUNIT_EXPECT_EQ(test, 15,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 24));
+ KUNIT_EXPECT_EQ(test, 15,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 25));
+
+ KUNIT_EXPECT_EQ(test, (int)ASPEED_SDHCI_TAP_PARAM_INVERT_CLK | 0,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 180));
+ KUNIT_EXPECT_EQ(test, (int)ASPEED_SDHCI_TAP_PARAM_INVERT_CLK | 0,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 181));
+ KUNIT_EXPECT_EQ(test, (int)ASPEED_SDHCI_TAP_PARAM_INVERT_CLK | 1,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 182));
+ KUNIT_EXPECT_EQ(test, (int)ASPEED_SDHCI_TAP_PARAM_INVERT_CLK | 1,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 183));
+ KUNIT_EXPECT_EQ(test, (int)ASPEED_SDHCI_TAP_PARAM_INVERT_CLK | 2,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 184));
+ KUNIT_EXPECT_EQ(test, (int)ASPEED_SDHCI_TAP_PARAM_INVERT_CLK | 3,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 185));
+ KUNIT_EXPECT_EQ(test, (int)ASPEED_SDHCI_TAP_PARAM_INVERT_CLK | 14,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 203));
+ KUNIT_EXPECT_EQ(test, (int)ASPEED_SDHCI_TAP_PARAM_INVERT_CLK | 15,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 204));
+ KUNIT_EXPECT_EQ(test, (int)ASPEED_SDHCI_TAP_PARAM_INVERT_CLK | 15,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 205));
+}
+
+static void aspeed_sdhci_phase_hs200(struct kunit *test)
+{
+ int rate = 2;
+
+ KUNIT_EXPECT_EQ(test, 0,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 0));
+ KUNIT_EXPECT_EQ(test, 0,
+ aspeed_sdhci_phase_to_tap(NULL, rate, 5));
+
[PATCH v6 0/6] mmc: sdhci-of-aspeed: Expose phase delay tuning
Hello, This series implements support for the MMC core clk-phase-* devicetree bindings in the Aspeed SD/eMMC driver. The relevant register was exposed on the AST2600 and is present for both the SD/MMC controller and the dedicated eMMC controller. v6 simply removes the typedef from v5 in favour of a struct containing the phase array. I've just done a quick build test of v6 given the small change and more extensive testing done with v5. v5 can be found here: https://lore.kernel.org/linux-mmc/20201208012615.2717412-1-and...@aj.id.au/ Please review! Cheers, Andrew Andrew Jeffery (6): mmc: core: Add helper for parsing clock phase properties mmc: sdhci-of-aspeed: Expose clock phase controls mmc: sdhci-of-aspeed: Add AST2600 bus clock support mmc: sdhci-of-aspeed: Add KUnit tests for phase calculations MAINTAINERS: Add entry for the ASPEED SD/MMC driver ARM: dts: rainier: Add eMMC clock phase compensation MAINTAINERS | 9 + arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts | 1 + drivers/mmc/core/host.c | 44 drivers/mmc/host/Kconfig | 14 ++ drivers/mmc/host/Makefile| 1 + drivers/mmc/host/sdhci-of-aspeed-test.c | 100 drivers/mmc/host/sdhci-of-aspeed.c | 251 ++- include/linux/mmc/host.h | 13 + 8 files changed, 422 insertions(+), 11 deletions(-) create mode 100644 drivers/mmc/host/sdhci-of-aspeed-test.c -- 2.27.0
Re: [RFC PATCH v3 0/9] fsdax: introduce fs query to support reflink
On Fri, Dec 18, 2020 at 10:44:26AM +0800, Ruan Shiyang wrote: > > > On 2020/12/17 上午4:55, Jane Chu wrote: > > Hi, Shiyang, > > > > On 12/15/2020 4:14 AM, Shiyang Ruan wrote: > > > The call trace is like this: > > > memory_failure() > > > pgmap->ops->memory_failure() => pmem_pgmap_memory_failure() > > > gendisk->fops->corrupted_range() => - pmem_corrupted_range() > > > - md_blk_corrupted_range() > > > sb->s_ops->currupted_range() => xfs_fs_corrupted_range() > > > xfs_rmap_query_range() > > > xfs_currupt_helper() > > > * corrupted on metadata > > > try to recover data, call xfs_force_shutdown() > > > * corrupted on file data > > > try to recover data, call mf_dax_mapping_kill_procs() > > > > > > The fsdax & reflink support for XFS is not contained in this patchset. > > > > > > (Rebased on v5.10) > > > > So I tried the patchset with pmem error injection, the SIGBUS payload > > does not look right - > > > > ** SIGBUS(7): ** > > ** si_addr(0x(nil)), si_lsb(0xC), si_code(0x4, BUS_MCEERR_AR) ** > > > > I expect the payload looks like > > > > ** si_addr(0x7f3672e0), si_lsb(0x15), si_code(0x4, BUS_MCEERR_AR) ** > > Thanks for testing. I test the SIGBUS by writing a program which calls > madvise(... ,MADV_HWPOISON) to inject memory-failure. It just shows that > the program is killed by SIGBUS. I cannot get any detail from it. So, > could you please show me the right way(test tools) to test it? I'm assuming that Jane is using a program that calls sigaction to install a SIGBUS handler, and dumps the entire siginfo_t structure whenever it receives one... --D > > -- > Thanks, > Ruan Shiyang. > > > > > thanks, > > -jane > > > > > > > > > > > > > >
Re: [PATCH net v3] net: mvpp2: disable force link UP during port init procedure
Hi Stefan,
czw., 17 gru 2020 o 15:54 napisał(a):
>
> From: Stefan Chulski
>
> Force link UP can be enabled by bootloader during tftpboot
> and breaks NFS support.
> Force link UP disabled during port init procedure.
>
> Fixes: f84bf386f395 ("net: mvpp2: initialize the GoP")
> Signed-off-by: Stefan Chulski
> ---
>
> Changes in v3:
> - Added Fixes tag.
> Changes in v2:
> - No changes.
>
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index d2b0506..0ad3177 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -5479,7 +5479,7 @@ static int mvpp2_port_init(struct mvpp2_port *port)
> struct mvpp2 *priv = port->priv;
> struct mvpp2_txq_pcpu *txq_pcpu;
> unsigned int thread;
> - int queue, err;
> + int queue, err, val;
>
> /* Checks for hardware constraints */
> if (port->first_rxq + port->nrxqs >
> @@ -5493,6 +5493,18 @@ static int mvpp2_port_init(struct mvpp2_port *port)
> mvpp2_egress_disable(port);
> mvpp2_port_disable(port);
>
> + if (mvpp2_is_xlg(port->phy_interface)) {
> + val = readl(port->base + MVPP22_XLG_CTRL0_REG);
> + val &= ~MVPP22_XLG_CTRL0_FORCE_LINK_PASS;
> + val |= MVPP22_XLG_CTRL0_FORCE_LINK_DOWN;
> + writel(val, port->base + MVPP22_XLG_CTRL0_REG);
> + } else {
> + val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
> + val &= ~MVPP2_GMAC_FORCE_LINK_PASS;
> + val |= MVPP2_GMAC_FORCE_LINK_DOWN;
> + writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
> + }
> +
> port->tx_time_coal = MVPP2_TXDONE_COAL_USEC;
>
> port->txqs = devm_kcalloc(dev, port->ntxqs, sizeof(*port->txqs),
> --
I confirm the patch fixes issue - tested on CN913x-DB and RGMII port.
Other boards there I see no regression.
Acked-by: Marcin Wojtas
Thanks,
Marcin
[PATCH v5 6/6] MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver
Add myself as the maintainer of the i.MX8qxp DPU DRM driver. Signed-off-by: Liu Ying --- v4->v5: * No change. v3->v4: * No change. v2->v3: * No change. v1->v2: * No change. MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 17b92e6..96e05cd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5846,6 +5846,15 @@ F: Documentation/devicetree/bindings/display/imx/ F: drivers/gpu/drm/imx/ F: drivers/gpu/ipu-v3/ +DRM DRIVERS FOR FREESCALE i.MX8QXP +M: Liu Ying +L: dri-de...@lists.freedesktop.org +S: Maintained +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml +F: Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml +F: drivers/gpu/drm/imx/dpu/ + DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets) M: Patrik Jakobsson L: dri-de...@lists.freedesktop.org -- 2.7.4
Re: [PATCH net v3] net: mvpp2: Fix GoP port 3 Networking Complex Control configurations
Hi Stefan,
czw., 17 gru 2020 o 13:40 napisał(a):
>
> From: Stefan Chulski
>
> During GoP port 2 Networking Complex Control mode of operation configurations,
> also GoP port 3 mode of operation was wrongly set.
> Patch removes these configurations.
> GENCONF_CTRL0_PORTX naming also fixed.
>
> Cc: sta...@vger.kernel.org
> Fixes: f84bf386f395 ("net: mvpp2: initialize the GoP")
> Signed-off-by: Stefan Chulski
> ---
>
> Changes in v3:
> - Added cc sta...@vger.kernel.org
> Changes in v2:
> - Added Fixes tag.
>
> drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 6 +++---
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 8
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> index 6bd7e40..39c4e5c 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> @@ -651,9 +651,9 @@
> #define GENCONF_PORT_CTRL1_EN(p) BIT(p)
> #define GENCONF_PORT_CTRL1_RESET(p)(BIT(p) << 28)
> #define GENCONF_CTRL0 0x1120
> -#define GENCONF_CTRL0_PORT0_RGMII BIT(0)
> -#define GENCONF_CTRL0_PORT1_RGMII_MII BIT(1)
> -#define GENCONF_CTRL0_PORT1_RGMII BIT(2)
> +#define GENCONF_CTRL0_PORT2_RGMII BIT(0)
> +#define GENCONF_CTRL0_PORT3_RGMII_MII BIT(1)
> +#define GENCONF_CTRL0_PORT3_RGMII BIT(2)
>
> /* Various constants */
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index d64dc12..d2b0506 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -1231,9 +1231,9 @@ static void mvpp22_gop_init_rgmii(struct mvpp2_port
> *port)
>
> regmap_read(priv->sysctrl_base, GENCONF_CTRL0, );
> if (port->gop_id == 2)
> - val |= GENCONF_CTRL0_PORT0_RGMII | GENCONF_CTRL0_PORT1_RGMII;
> + val |= GENCONF_CTRL0_PORT2_RGMII;
> else if (port->gop_id == 3)
> - val |= GENCONF_CTRL0_PORT1_RGMII_MII;
> + val |= GENCONF_CTRL0_PORT3_RGMII_MII;
> regmap_write(priv->sysctrl_base, GENCONF_CTRL0, val);
> }
>
> @@ -1250,9 +1250,9 @@ static void mvpp22_gop_init_sgmii(struct mvpp2_port
> *port)
> if (port->gop_id > 1) {
> regmap_read(priv->sysctrl_base, GENCONF_CTRL0, );
> if (port->gop_id == 2)
> - val &= ~GENCONF_CTRL0_PORT0_RGMII;
> + val &= ~GENCONF_CTRL0_PORT2_RGMII;
> else if (port->gop_id == 3)
> - val &= ~GENCONF_CTRL0_PORT1_RGMII_MII;
> + val &= ~GENCONF_CTRL0_PORT3_RGMII_MII;
> regmap_write(priv->sysctrl_base, GENCONF_CTRL0, val);
> }
> }
> --
I tested the patch and LGTM.
Acked-by: Marcin Wojtas
Thanks,
Marcin
[PATCH v5 4/6] drm/atomic: Avoid unused-but-set-variable warning on for_each_old_plane_in_state
Artifically use 'plane' and 'old_plane_state' to avoid 'not used' warning. The precedent has already been set by other macros in the same file. Acked-by: Daniel Vetter Signed-off-by: Liu Ying --- v4->v5: * No change. v3->v4: * Add Daniel's A-b tag. v2->v3: * Add a missing blank line. v1->v2: * No change. include/drm/drm_atomic.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index ce7023e..6ade7a1 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -908,7 +908,10 @@ void drm_state_dump(struct drm_device *dev, struct drm_printer *p); (__i)++) \ for_each_if ((__state)->planes[__i].ptr && \ ((plane) = (__state)->planes[__i].ptr, \ - (old_plane_state) = (__state)->planes[__i].old_state, 1)) + (void)(plane) /* Only to avoid unused-but-set-variable warning */, \ + (old_plane_state) = (__state)->planes[__i].old_state, \ + (void)(old_plane_state) /* Only to avoid unused-but-set-variable warning */, 1)) + /** * for_each_new_plane_in_state - iterate over all planes in an atomic update * @__state: drm_atomic_state pointer -- 2.7.4
[PATCH v5 3/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
Note that this depends on the 'two cell binding' clock patch set which has
already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h
won't be found.
v4->v5:
* No change.
v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.
v2->v3:
* No change.
v1->v2:
* Use new dt binding way to add clocks in the example.
.../bindings/display/imx/fsl,imx8qxp-dprc.yaml | 87 ++
1 file changed, 87 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
diff --git
a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
new file mode 100644
index ..9e05c83
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dprc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Channel
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The i.MX8qm/qxp Display Prefetch Resolve Channel(DPRC) is an engine which
+ fetches display data before the display pipeline needs the data to drive
+ pixels in the active display region. This data is transformed, or resolved,
+ from a variety of tiled buffer formats into linear format, if needed.
+ The DPR works with a double bank memory structure. This memory structure is
+ implemented in the Resolve Tile Memory(RTRAM) and the banks are referred to
+ as A and B. Each bank is either 4 or 8 lines high depending on the source
+ frame buffer format.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qxp-dpr-channel
+ - fsl,imx8qm-dpr-channel
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: apb clock
+ - description: b clock
+ - description: rtram clock
+
+ clock-names:
+items:
+ - const: apb
+ - const: b
+ - const: rtram
+
+ fsl,sc-resource:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: The SCU resource ID associated with this DPRC instance.
+
+ fsl,prgs:
+$ref: /schemas/types.yaml#/definitions/phandle-array
+description: |
+ List of phandle which points to Prefetch Resolve Gaskets(PRGs)
+ associated with this DPRC instance.
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - fsl,sc-resource
+ - fsl,prgs
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+dpr-channel@5610 {
+compatible = "fsl,imx8qxp-dpr-channel";
+reg = <0x5610 0x1>;
+interrupts = ;
+clocks = <_dpr1_lpcg IMX_LPCG_CLK_4>,
+ <_dpr1_lpcg IMX_LPCG_CLK_5>,
+ <_rtram1_lpcg IMX_LPCG_CLK_0>;
+clock-names = "apb", "b", "rtram";
+fsl,sc-resource = ;
+fsl,prgs = <_prg4>, <_prg5>;
+power-domains = < IMX_SC_R_DC_0>;
+};
--
2.7.4
[PATCH v5 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding
This patch adds bindings for i.MX8qxp/qm Display Processing Unit. Reviewed-by: Rob Herring Signed-off-by: Liu Ying --- Note that this depends on the 'two cell binding' clock patch set which has already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h won't be found. v4->v5: * No change. v3->v4: * Improve compatible property by using enum instead of oneOf+const. (Rob) * Add Rob's R-b tag. v2->v3: * No change. v1->v2: * Fix yamllint warnings. * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm, as the display controller subsystem spec does say that they exist. * Use new dt binding way to add clocks in the example. * Trivial tweaks for the example. .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 416 + 1 file changed, 416 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml new file mode 100644 index ..817c7f3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml @@ -0,0 +1,416 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8qm/qxp Display Processing Unit + +maintainers: + - Liu Ying + +description: | + The Freescale i.MX8qm/qxp Display Processing Unit(DPU) is comprised of two + main components that include a blit engine for 2D graphics accelerations + and a display controller for display output processing, as well as a command + sequencer. + +properties: + compatible: +enum: + - fsl,imx8qxp-dpu + - fsl,imx8qm-dpu + + reg: +maxItems: 1 + + interrupts: +items: + - description: | + store9 shadow load interrupt(blit engine) + - description: | + store9 frame complete interrupt(blit engine) + - description: | + store9 sequence complete interrupt(blit engine) + - description: | + extdst0 shadow load interrupt + (display controller, content stream 0) + - description: | + extdst0 frame complete interrupt + (display controller, content stream 0) + - description: | + extdst0 sequence complete interrupt + (display controller, content stream 0) + - description: | + extdst4 shadow load interrupt + (display controller, safety stream 0) + - description: | + extdst4 frame complete interrupt + (display controller, safety stream 0) + - description: | + extdst4 sequence complete interrupt + (display controller, safety stream 0) + - description: | + extdst1 shadow load interrupt + (display controller, content stream 1) + - description: | + extdst1 frame complete interrupt + (display controller, content stream 1) + - description: | + extdst1 sequence complete interrupt + (display controller, content stream 1) + - description: | + extdst5 shadow load interrupt + (display controller, safety stream 1) + - description: | + extdst5 frame complete interrupt + (display controller, safety stream 1) + - description: | + extdst5 sequence complete interrupt + (display controller, safety stream 1) + - description: | + disengcfg0 shadow load interrupt + (display controller, display stream 0) + - description: | + disengcfg0 frame complete interrupt + (display controller, display stream 0) + - description: | + disengcfg0 sequence complete interrupt + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt0 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt1 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt2 + (display controller, display stream 0) + - description: | + framegen0 programmable interrupt3 + (display controller, display stream 0) + - description: | + signature0 shadow load interrupt + (display controller, display stream 0) + - description: | + signature0 measurement valid interrupt + (display controller, display stream 0) + - description: | + signature0 error condition interrupt + (display controller, display stream 0) + - description: | + disengcfg1 shadow load interrupt + (display controller, display stream 1) + - description: | + disengcfg1 frame complete interrupt + (display controller, display stream 1) +
[PATCH v5 2/6] dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding
This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.
Reviewed-by: Rob Herring
Signed-off-by: Liu Ying
---
Note that this depends on the 'two cell binding' clock patch set which has
already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h
won't be found.
v4->v5:
* No change.
v3->v4:
* Improve compatible property by using enum instead of oneOf+const. (Rob)
* Add Rob's R-b tag.
v2->v3:
* No change.
v1->v2:
* Use new dt binding way to add clocks in the example.
.../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60 ++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
new file mode 100644
index ..3ff46e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-prg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Prefetch Resolve Gasket
+
+maintainers:
+ - Liu Ying
+
+description: |
+ The i.MX8qm/qxp Prefetch Resolve Gasket (PRG) is a gasket interface between
+ RTRAM controller and Display Controller. The main function is to convert
+ the AXI interface to the RTRAM interface, which includes re-mapping the
+ ARADDR to a RTRAM address.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8qxp-prg
+ - fsl,imx8qm-prg
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: rtram clock
+ - description: apb clock
+
+ clock-names:
+items:
+ - const: rtram
+ - const: apb
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+prg@5604 {
+compatible = "fsl,imx8qxp-prg";
+reg = <0x5604 0x1>;
+clocks = <_prg0_lpcg IMX_LPCG_CLK_0>,
+ <_prg0_lpcg IMX_LPCG_CLK_4>;
+clock-names = "rtram", "apb";
+power-domains = < IMX_SC_R_DC_0>;
+};
--
2.7.4
Re: extcon: add EXTCON_JACK_UNSUPPORTED for external headset jack
On 12/18/20 11:51 AM, me...@codeaurora.org wrote:
>
>
>
>
> From dac7b15dbdd4c327083fff97f22cf0c6ddfcf31a Mon Sep 17 00:00:00 2001
>
> From: Meng Wang
>
> Date: Wed, 9 Dec 2020 12:35:54 +0800
>
> Subject: [PATCH] extcon: add EXTCON_JACK_UNSUPPORTED for external headset jack
>
>
>
> This patch adds the new extcon type EXTCON_JACK_UNSUPPORTED. This
>
> type would be used when Euro headset is inserted into US jack and
>
> vice versa. When EU headset is inserted into US jack and there's
>
> no switch to switch the MIC_GND, EXTCON_JACK_UNSUPPORTED
>
> would be reported to usespace.
Actually, I don't understand why this definition is needed.
Until now, I had not been heard like this name for external connector.
We have to use the correct connector name.
Instead of defining new type, you can use EXTCON_MECHANICAL
type in order to notify something to user-space
when unsupported external connector is inserted or vice-versa.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1205.0/00538.html
>
>
>
> Signed-off-by: Meng Wang
>
> ---
>
> drivers/extcon/extcon.c | 5 +
>
> include/linux/extcon.h | 1 +
>
> 2 files changed, 6 insertions(+)
>
>
>
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
>
> index 0a6438c..cfe2404 100644
>
> --- a/drivers/extcon/extcon.c
>
> +++ b/drivers/extcon/extcon.c
>
> @@ -135,6 +135,11 @@ static const struct __extcon_info {
>
> .id = EXTCON_JACK_SPDIF_OUT,
>
> .name = "SPDIF-OUT",
>
> },
>
> + [EXTCON_JACK_UNSUPPORTED] = {
>
> + .type = EXTCON_TYPE_JACK,
>
> + .id = EXTCON_JACK_UNSUPPORTED,
>
> + .name = "UNSUPPORTED",
>
> + },
>
> /* Display external connector */
>
> [EXTCON_DISP_HDMI] = {
>
> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
>
> index fd183fb..5b47dae 100644
>
> --- a/include/linux/extcon.h
>
> +++ b/include/linux/extcon.h
>
> @@ -68,6 +68,7 @@
>
> #define EXTCON_JACK_VIDEO_OUT 25
>
> #define EXTCON_JACK_SPDIF_IN 26 /* Sony Philips Digital
> InterFace */
>
> #define EXTCON_JACK_SPDIF_OUT 27
>
> +#define EXTCON_JACK_UNSUPPORTED 28
>
> /* Display external connector */
>
> #define EXTCON_DISP_HDMI 40 /* High-Definition Multimedia
> Interface */
>
> --
>
> 2.7.4
>
>
>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[PATCH v5 0/6] drm/imx: Introduce i.MX8qm/qxp DPU DRM
Hi, This patch set introduces i.MX8qm/qxp Display Processing Unit(DPU) DRM support. DPU is comprised of a blit engine for 2D graphics, a display controller and a command sequencer. Outside of DPU, optional prefetch engines can fetch data from memory prior to some DPU fetchunits of blit engine and display controller. The pre-fetchers support linear formats and Vivante GPU tile formats. Reference manual can be found at: https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM This patch set adds kernel modesetting support for the display controller part. It supports two CRTCs per display controller, several planes, prefetch engines and some properties of CRTC and plane. Currently, the registers of the controller is accessed without command sequencer involved, instead just by using CPU. DRM connectors would be created from the DPU KMS driver. If people want to try this series with i.MX8qxp, clock patches can be found at: https://www.spinics.net/lists/arm-kernel/msg859763.html and, power domain patches have already landed in Shawn's i.MX for-next git branch. Version2 dropped the device tree patches because we'll use new dt binding way to support i.MX8qm/qxp clocks. It depends on the below series to do basic conversions for the platforms which has not landed yet: https://www.spinics.net/lists/linux-mmc/msg61965.html I've sent the below series to add downstream bridges(embedded in i.MX8qm/qxp) to support LVDS displays: https://www.spinics.net/lists/linux-media/msg183650.html Patch 1 ~ 3 add dt-bindings for DPU and prefetch engines. Patch 4 is a minor improvement of a macro to suppress warning as the KMS driver uses it. Patch 5 introduces the DPU DRM support. Patch 6 updates MAINTAINERS. Welcome comments, thanks. v4->v5: * Rebase up onto the latest drm-misc-next branch and remove the hook to drm_atomic_helper_legacy_gamma_set() from patch 5/6, because it was dropped by the newly landed commit 'drm: automatic legacy gamma support'. * Remove a redundant blank line from dpu_plane_atomic_update() in patch 5/6. v3->v4: * Improve compatible properties in DPU and prefetch engines' dt bindings by using enum instead of oneOf+const. * Add Rob's R-b tags on dt binding patches(patch 1/6, 2/6 and 3/6). * Add Daniel's A-b tag on patch 4/6. v2->v3: * Fix DPU DRM driver build warnings which are Reported-by: kernel test robot . * Drop DPU DRM driver build dependency on IMX_SCU, as dummy SCU functions have been added in header files by the patch 'firmware: imx: add dummy functions' which has landed in linux-next/master branch. * Add a missing blank line in include/drm/drm_atomic.h. v1->v2: * Test this patch set also with i.MX8qm LVDS displays. * Drop the device tree patches because we'll use new dt binding way to support i.MX8qm/qxp clocks. This depends on a not-yet-landed patch set to do basic conversions for the platforms. * Fix dt binding yamllint warnings. * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm in DPU's dt binding documentation. * Use new dt binding way to add clocks in the dt binding examples. * Address several comments from Laurentiu on the DPU DRM patch. Liu Ying (6): dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding drm/atomic: Avoid unused-but-set-variable warning on for_each_old_plane_in_state drm/imx: Introduce i.MX8qm/qxp DPU DRM MAINTAINERS: add maintainer for i.MX8qxp DPU DRM driver .../bindings/display/imx/fsl,imx8qxp-dprc.yaml | 87 ++ .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 416 + .../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60 ++ MAINTAINERS| 9 + drivers/gpu/drm/imx/Kconfig| 1 + drivers/gpu/drm/imx/Makefile | 1 + drivers/gpu/drm/imx/dpu/Kconfig| 10 + drivers/gpu/drm/imx/dpu/Makefile | 10 + drivers/gpu/drm/imx/dpu/dpu-constframe.c | 170 drivers/gpu/drm/imx/dpu/dpu-core.c | 881 drivers/gpu/drm/imx/dpu/dpu-crtc.c | 925 + drivers/gpu/drm/imx/dpu/dpu-crtc.h | 62 ++ drivers/gpu/drm/imx/dpu/dpu-disengcfg.c| 114 +++ drivers/gpu/drm/imx/dpu/dpu-dprc.c | 721 drivers/gpu/drm/imx/dpu/dpu-dprc.h | 40 + drivers/gpu/drm/imx/dpu/dpu-drv.c | 297 +++ drivers/gpu/drm/imx/dpu/dpu-drv.h | 28 + drivers/gpu/drm/imx/dpu/dpu-extdst.c | 296 +++ drivers/gpu/drm/imx/dpu/dpu-fetchdecode.c | 291 +++ drivers/gpu/drm/imx/dpu/dpu-fetcheco.c | 221 + drivers/gpu/drm/imx/dpu/dpu-fetchlayer.c | 151 drivers/gpu/drm/imx/dpu/dpu-fetchunit.c| 609 ++
Re: [RFC PATCH v2 2/2] blk-mq: Lockout tagset iter when freeing rqs
On Thu, Dec 17, 2020 at 07:07:53PM +0800, John Garry wrote:
> References to old IO sched requests are currently cleared from the
> tagset when freeing those requests; switching elevator or changing
> request queue depth is such a scenario in which this occurs.
>
> However, this does not stop the potentially racy behaviour of freeing
> and clearing a request reference between a tagset iterator getting a
> reference to a request and actually dereferencing that request.
>
> Such a use-after-free can be triggered, as follows:
>
> ==
> BUG: KASAN: use-after-free in bt_iter+0xa0/0x120
> Read of size 8 at addr 00108d589300 by task fio/3052
>
> CPU: 32 PID: 3052 Comm: fio Tainted: GW
> 5.10.0-rc4-64839-g2dcf1ee5054f #693
> Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon
> D05 IT21 Nemo 2.0 RC0 04/18/2018
> Call trace:
> dump_backtrace+0x0/0x2d0
> show_stack+0x18/0x68
> dump_stack+0x100/0x16c
> print_address_description.constprop.12+0x6c/0x4e8
> kasan_report+0x130/0x200
> __asan_load8+0x9c/0xd8
> bt_iter+0xa0/0x120
> blk_mq_queue_tag_busy_iter+0x2d8/0x540
> blk_mq_in_flight+0x80/0xb8
> part_stat_show+0xd8/0x238
> dev_attr_show+0x44/0x90
> sysfs_kf_seq_show+0x128/0x1c8
> kernfs_seq_show+0xa0/0xb8
> seq_read_iter+0x1ec/0x6a0
> seq_read+0x1d0/0x250
> kernfs_fop_read+0x70/0x330
> vfs_read+0xe4/0x250
> ksys_read+0xc8/0x178
> __arm64_sys_read+0x44/0x58
> el0_svc_common.constprop.2+0xc4/0x1e8
> do_el0_svc+0x90/0xa0
> el0_sync_handler+0x128/0x178
> el0_sync+0x158/0x180
>
> This is found experimentally by running fio on 2x SCSI disks - 1x disk
> holds the root partition. Userspace is constantly triggering the tagset
> iter from reading the root (gen)disk partition info. And so if the IO
> sched is constantly changed on the other disk, eventually the UAF occurs,
> as described above.
>
> For experiments sake, a mdelay() is added to trigger the UAF within a
> sane timeframe, as follows:
>
> +++ b/block/blk-mq-tag.c
> @@ -215,8 +215,11 @@ static bool bt_iter(struct sbitmap *bitmap, unsigned int
> bitnr, void *data)
> * We can hit rq == NULL here, because the tagging functions
> * test and set the bit before assigning ->rqs[].
> */
> - if (rq && rq->q == hctx->queue && rq->mq_hctx == hctx)
> - return iter_data->fn(hctx, rq, iter_data->data, reserved);
> + if (rq) {
> + mdelay(50);
> + if (rq->q == hctx->queue && rq->mq_hctx == hctx)
> + return iter_data->fn(hctx, rq, iter_data->data,
> reserved);
> + }
> return true;
> }
>
> This delay increases the window for the iter in between getting the
> request reference and actually dereferencing it.
>
> To solve this problem, lockout the per-hw queue tagset iterators while
> freeing IO sched tags.
>
> Signed-off-by: John Garry
> ---
> block/blk-mq-tag.c | 20 ++--
> block/blk-mq-tag.h | 3 +++
> block/blk-mq.c | 2 ++
> 3 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
> index a6df2d5df88a..853ed5b889aa 100644
> --- a/block/blk-mq-tag.c
> +++ b/block/blk-mq-tag.c
> @@ -358,10 +358,19 @@ void blk_mq_tagset_busy_iter(struct blk_mq_tag_set
> *tagset,
> {
> int i;
>
> for (i = 0; i < tagset->nr_hw_queues; i++) {
> - if (tagset->tags && tagset->tags[i])
> - __blk_mq_all_tag_iter(tagset->tags[i], fn, priv,
> + if (tagset->tags && tagset->tags[i]) {
> + struct blk_mq_tags *tags = tagset->tags[i];
> +
> + if (!atomic_inc_not_zero(>iter_usage_counter))
> + continue;
When 'continue' is run, blk_mq_tagset_busy_iter()'s semantic may be
broken.
> +
> + __blk_mq_all_tag_iter(tags, fn, priv,
> BT_TAG_ITER_STARTED);
> +
> + atomic_dec(>iter_usage_counter);
> + }
> }
> }
> EXPORT_SYMBOL(blk_mq_tagset_busy_iter);
> @@ -435,9 +444,14 @@ void blk_mq_queue_tag_busy_iter(struct request_queue *q,
> busy_iter_fn *fn,
> if (!blk_mq_hw_queue_mapped(hctx))
> continue;
>
> + if (!atomic_inc_not_zero(>iter_usage_counter))
> + continue;
Same with above comment.
> +
> if (tags->nr_reserved_tags)
> bt_for_each(hctx, tags->breserved_tags, fn, priv, true);
> bt_for_each(hctx, tags->bitmap_tags, fn, priv, false);
> +
> + atomic_dec(>iter_usage_counter);
> }
> blk_queue_exit(q);
> }
> @@ -461,6 +475,8 @@ static int blk_mq_init_bitmap_tags(struct blk_mq_tags
> *tags,
>round_robin, node))
> goto free_bitmap_tags;
>
> + atomic_set(>iter_usage_counter, 1);
> +
> tags->bitmap_tags = >__bitmap_tags;
>
Re: Linux kernel in-tree Rust support
On Thu, Dec 17, 2020 at 10:45 PM Pavel Machek wrote: > > Well.. not everyone has 32 cores in their notebook. It is true that complex Rust, like complex C++, does have high compilation times. But it all depends on how much one relies on certain language features. Straightforward Rust code is quick to compile. For reference, some quick stats :-) On a given machine, building v5.10 with a minimal config under -j3 takes 3 minutes. With Rust support enabled and 4 trivial Rust modules, it takes 50 seconds more. "A big increase!", you may indeed claim, but those 50 seconds are basically all spent on the shared Rust support. The actual Rust modules compile very quickly afterwards. For example, touching either `drivers/char/mem.c` or one of the trivial Rust modules takes the same time in that machine: 10 seconds. This is for a minimal config -- when you start dealing with `allmodconfig` builds, or when you start having a hundred Rust modules instead of 4, the upfront cost becomes very small per Rust module. > Okay. I did some refactoring recently and I really wished kernel was > in Rust (and not in C)... so lets see what happens. Indeed, I think it is definitely worth it. Cheers, Miguel
[PATCH] scsi: ufs: fix livelock of ufshcd_clear_ua_wluns
When gate_work/ungate_work gets an error during hibern8_enter or exit,
ufshcd_err_handler()
ufshcd_scsi_block_requests()
ufshcd_reset_and_restore()
ufshcd_clear_ua_wluns() -> stuck
ufshcd_scsi_unblock_requests()
In order to avoid it, ufshcd_clear_ua_wluns() can be called per recovery flows
such as suspend/resume, link_recovery, and error_handler.
Signed-off-by: Jaegeuk Kim
---
drivers/scsi/ufs/ufshcd.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e221add25a7e..e711def829cd 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3963,6 +3963,8 @@ int ufshcd_link_recovery(struct ufs_hba *hba)
if (ret)
dev_err(hba->dev, "%s: link recovery failed, err %d",
__func__, ret);
+ else
+ ufshcd_clear_ua_wluns(hba);
return ret;
}
@@ -5968,6 +5970,8 @@ static void ufshcd_err_handler(struct work_struct *work)
ufshcd_scsi_unblock_requests(hba);
ufshcd_err_handling_unprepare(hba);
up(>eh_sem);
+
+ ufshcd_clear_ua_wluns(hba);
}
/**
@@ -6908,14 +6912,11 @@ static int ufshcd_host_reset_and_restore(struct ufs_hba
*hba)
ufshcd_set_clk_freq(hba, true);
err = ufshcd_hba_enable(hba);
- if (err)
- goto out;
/* Establish the link again and restore the device */
- err = ufshcd_probe_hba(hba, false);
if (!err)
- ufshcd_clear_ua_wluns(hba);
-out:
+ err = ufshcd_probe_hba(hba, false);
+
if (err)
dev_err(hba->dev, "%s: Host init failed %d\n", __func__, err);
ufshcd_update_evt_hist(hba, UFS_EVT_HOST_RESET, (u32)err);
@@ -8745,6 +8746,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum
ufs_pm_op pm_op)
ufshcd_resume_clkscaling(hba);
hba->clk_gating.is_suspended = false;
hba->dev_info.b_rpm_dev_flush_capable = false;
+ ufshcd_clear_ua_wluns(hba);
ufshcd_release(hba);
out:
if (hba->dev_info.b_rpm_dev_flush_capable) {
@@ -8855,6 +8857,8 @@ static int ufshcd_resume(struct ufs_hba *hba, enum
ufs_pm_op pm_op)
cancel_delayed_work(>rpm_dev_flush_recheck_work);
}
+ ufshcd_clear_ua_wluns(hba);
+
/* Schedule clock gating in case of no access to UFS device yet */
ufshcd_release(hba);
--
2.29.2.729.g45daf8777d-goog
Re: [RFC PATCH] badblocks: Improvement badblocks_set() for handling multiple ranges
[ add Neil, original gooodguy who wrote badblocks ] On Thu, Dec 3, 2020 at 9:16 AM Coly Li wrote: > > Recently I received a bug report that current badblocks code does not > properly handle multiple ranges. For example, > badblocks_set(bb, 32, 1, true); > badblocks_set(bb, 34, 1, true); > badblocks_set(bb, 36, 1, true); > badblocks_set(bb, 32, 12, true); > Then indeed badblocks_show() reports, > 32 3 > 36 1 > But the expected bad blocks table should be, > 32 12 > Obviously only the first 2 ranges are merged and badblocks_set() returns > and ignores the rest setting range. > > This behavior is improper, if the caller of badblocks_set() wants to set > a range of blocks into bad blocks table, all of the blocks in the range > should be handled even the previous part encountering failure. > > The desired way to set bad blocks range by badblocks_set() is, > - Set as many as blocks in the setting range into bad blocks table. > - Merge the bad blocks ranges and occupy as less as slots in the bad > blocks table. > - Fast. > > Indeed the above proposal is complicated, especially with the following > restrictions, > - The setting bad blocks range can be ackknowledged or not acknowledged. s/ackknowledged/acknowledged/ I'd run checkpatch --codespell for future versions... > - The bad blocks table size is limited. > - Memory allocation should be avoided. > > This patch is an initial effort to improve badblocks_set() for setting > bad blocks range when it covers multiple already set bad ranges in the > bad blocks table, and to do it as fast as possible. > > The basic idea of the patch is to categorize all possible bad blocks > range setting combinationsinto to much less simplified and more less > special conditions. Inside badblocks_set() there is an implicit loop > composed by jumping between labels 're_insert' and 'update_sectors'. No > matter how large the setting bad blocks range is, in every loop just a > minimized range from the head is handled by a pre-defined behavior from > one of the categorized conditions. The logic is simple and code flow is > manageable. > > This patch is unfinished yet, it only improves badblocks_set() and not > touch badblocks_clear() and badblocks_show() yet. I post it earlier > because this patch will be large (more then 1000 lines of change), I > want more people to give me comments earlier before I go too far away. > I wonder if this isn't indication that the base data structure should be replaced... but I have not had a chance to devote deeper thought to this. > The code logic is tested as user space programmer, this patch passes > compiling but not tested in kernel mode yet. Right now it is only for > RFC purpose. I will post tested patch in further versions. > > Thank you in advance for any review or comments on this patch. > > Signed-off-by: Coly Li > --- > block/badblocks.c | 1041 ++--- > include/linux/badblocks.h | 33 ++ > 2 files changed, 881 insertions(+), 193 deletions(-) > > diff --git a/block/badblocks.c b/block/badblocks.c > index d39056630d9c..04ccae95777d 100644 > --- a/block/badblocks.c > +++ b/block/badblocks.c > @@ -5,6 +5,8 @@ > * - Heavily based on MD badblocks code from Neil Brown > * > * Copyright (c) 2015, Intel Corporation. > + * > + * Improvement for handling multiple ranges by Coly Li > */ > > #include > @@ -16,114 +18,612 @@ > #include > #include > > -/** > - * badblocks_check() - check a given range for bad sectors > - * @bb:the badblocks structure that holds all badblock > information > - * @s: sector (start) at which to check for badblocks > - * @sectors: number of sectors to check for badblocks > - * @first_bad: pointer to store location of the first badblock > - * @bad_sectors: pointer to store number of badblocks after @first_bad > +/* > + * The purpose of badblocks set/clear is to manage bad blocks ranges which > are > + * identified by LBA addresses. > * > - * We can record which blocks on each device are 'bad' and so just > - * fail those blocks, or that stripe, rather than the whole device. > - * Entries in the bad-block table are 64bits wide. This comprises: > - * Length of bad-range, in sectors: 0-511 for lengths 1-512 > - * Start of bad-range, sector offset, 54 bits (allows 8 exbibytes) > - * A 'shift' can be set so that larger blocks are tracked and > - * consequently larger devices can be covered. > - * 'Acknowledged' flag - 1 bit. - the most significant bit. > + * When the caller of badblocks_set() wants to set a range of bad blocks, the > + * setting range can be acked or unacked. And the setting range may merge, > + * overwrite, skip the overlaypped already set range, depends on who they are > + * overlapped or adjacent, and the acknowledgment type of the ranges. It can > be > + * more complicated when the setting range covers multiple already set bad > block > + * ranges, with
Re: KASAN: use-after-free Read in service_outstanding_interrupt
syzbot has found a reproducer for the following issue on: HEAD commit:5e60366d Merge tag 'fallthrough-fixes-clang-5.11-rc1' of g.. git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing console output: https://syzkaller.appspot.com/x/log.txt?x=12c5b62350 kernel config: https://syzkaller.appspot.com/x/.config?x=5cea7506b7139727 dashboard link: https://syzkaller.appspot.com/bug?extid=9e04e2df4a32fb661daf compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=175adf0750 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1672680f50 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+9e04e2df4a32fb661...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in usb_submit_urb+0x1210/0x1560 drivers/usb/core/urb.c:383 Read of size 4 at addr 888101d21018 by task syz-executor166/4405 CPU: 0 PID: 4405 Comm: syz-executor166 Not tainted 5.10.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0xae/0x4c8 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562 usb_submit_urb+0x1210/0x1560 drivers/usb/core/urb.c:383 service_outstanding_interrupt.part.0+0x5f/0xa0 drivers/usb/class/cdc-wdm.c:470 service_outstanding_interrupt drivers/usb/class/cdc-wdm.c:465 [inline] wdm_read+0x9a0/0xbd0 drivers/usb/class/cdc-wdm.c:583 vfs_read+0x1b5/0x570 fs/read_write.c:494 ksys_read+0x12d/0x250 fs/read_write.c:634 do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x44b529 Code: e8 bc b4 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 8b cb fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f2dfcb6ed98 EFLAGS: 0246 ORIG_RAX: RAX: ffda RBX: 006dcc38 RCX: 0044b529 RDX: 1000 RSI: 20001000 RDI: 0004 RBP: 006dcc30 R08: R09: R10: R11: 0246 R12: 006dcc3c R13: 0142006002090100 R14: 04010040a4157d25 R15: 40020112 Allocated by task 2632: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:461 kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:682 [inline] usb_alloc_dev+0x51/0xef0 drivers/usb/core/usb.c:582 hub_port_connect drivers/usb/core/hub.c:5129 [inline] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline] port_event drivers/usb/core/hub.c:5509 [inline] hub_event+0x1def/0x42d0 drivers/usb/core/hub.c:5591 process_one_work+0x98d/0x15c0 kernel/workqueue.c:2275 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 kthread+0x38c/0x460 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Freed by task 2181: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48 kasan_set_track+0x1c/0x30 mm/kasan/common.c:56 kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:352 __kasan_slab_free+0x102/0x140 mm/kasan/common.c:422 slab_free_hook mm/slub.c:1544 [inline] slab_free_freelist_hook+0x5d/0x150 mm/slub.c:1577 slab_free mm/slub.c:3140 [inline] kfree+0xdb/0x3a0 mm/slub.c:4122 device_release+0x9f/0x240 drivers/base/core.c:1962 kobject_cleanup lib/kobject.c:705 [inline] kobject_release lib/kobject.c:736 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:753 put_device+0x1b/0x30 drivers/base/core.c:3190 hub_port_connect drivers/usb/core/hub.c:5074 [inline] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline] port_event drivers/usb/core/hub.c:5509 [inline] hub_event+0x1c8a/0x42d0 drivers/usb/core/hub.c:5591 process_one_work+0x98d/0x15c0 kernel/workqueue.c:2275 worker_thread+0x64c/0x1120 kernel/workqueue.c:2421 kthread+0x38c/0x460 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 The buggy address belongs to the object at 888101d21000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 24 bytes inside of 2048-byte region [888101d21000, 888101d21800) The buggy address belongs to the page: page:19761127 refcount:1 mapcount:0 mapping: index:0x0 pfn:0x101d20 head:19761127 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x2010200(slab|head) raw: 02010200 dead0100 dead0122 888100042000 raw: 80080008 0001 page dumped because: kasan: bad access detected Memory
Re: [PATCH bpf-next 1/2] bpf: Add a bpf_kallsyms_lookup helper
On Thu, Dec 17, 2020 at 09:26:09AM -0800, Yonghong Song wrote:
>
>
> On 12/17/20 7:31 AM, Florent Revest wrote:
> > On Mon, Dec 14, 2020 at 7:47 AM Yonghong Song wrote:
> > > On 12/11/20 6:40 AM, Florent Revest wrote:
> > > > On Wed, Dec 2, 2020 at 10:18 PM Alexei Starovoitov
> > > > wrote:
> > > > > I still think that adopting printk/vsnprintf for this instead of
> > > > > reinventing the wheel
> > > > > is more flexible and easier to maintain long term.
> > > > > Almost the same layout can be done with vsnprintf
> > > > > with exception of \0 char.
> > > > > More meaningful names, etc.
> > > > > See Documentation/core-api/printk-formats.rst
> > > >
> > > > I agree this would be nice. I finally got a bit of time to experiment
> > > > with this and I noticed a few things:
> > > >
> > > > First of all, because helpers only have 5 arguments, if we use two for
> > > > the output buffer and its size and two for the format string and its
> > > > size, we are only left with one argument for a modifier. This is still
> > > > enough for our usecase (where we'd only use "%ps" for example) but it
> > > > does not strictly-speaking allow for the same layout that Andrii
> > > > proposed.
> > >
> > > See helper bpf_seq_printf. It packs all arguments for format string and
> > > puts them into an array. bpf_seq_printf will unpack them as it parsed
> > > through the format string. So it should be doable to have more than
> > > "%ps" in format string.
> >
> > This could be a nice trick, thank you for the suggestion Yonghong :)
> >
> > My understanding is that this would also require two extra args (one
> > for the array of arguments and one for the size of this array) so it
> > would still not fit the 5 arguments limit I described in my previous
> > email.
> > eg: this would not be possible:
> > long bpf_snprintf(const char *out, u32 out_size,
> >const char *fmt, u32 fmt_size,
> > const void *data, u32 data_len)
>
> Right. bpf allows only up to 5 parameters.
> >
> > Would you then suggest that we also put the format string and its
> > length in the first and second cells of this array and have something
> > along the line of:
> > long bpf_snprintf(const char *out, u32 out_size,
> >const void *args, u32 args_len) ?
> > This seems like a fairly opaque signature to me and harder to verify.
>
> One way is to define an explicit type for args, something like
>struct bpf_fmt_str_data {
> char *fmt;
> u64 fmt_len;
> u64 data[];
>};
that feels a bit convoluted.
The reason I feel unease with the helper as was originally proposed
and with Andrii's proposal is all the extra strlen and strcpy that
needs to be done. In the helper we have to call kallsyms_lookup()
which is ok interface for what it was desinged to do,
but it's awkward to use to construct new string ("%s [%s]", sym, modname)
or to send two strings into a ring buffer.
Andrii's zero separator idea will simplify bpf prog, but user space
would need to do strlen anyway if it needs to pretty print.
If we take pain on converting addr to sym+modname let's figure out
how to make it easy for the bpf prog to do and easy for user space to consume.
That's why I proposed snprintf.
As far as 6 arg issue:
long bpf_snprintf(const char *out, u32 out_size,
const char *fmt, u32 fmt_size,
const void *data, u32 data_len);
Yeah. It won't work as-is, but fmt_size is unnecessary nowadays.
The verifier understands read-only data.
Hence the helper can be:
long bpf_snprintf(const char *out, u32 out_size,
const char *fmt,
const void *data, u32 data_len);
The 3rd arg cannot be ARG_PTR_TO_MEM.
Instead we can introduce ARG_PTR_TO_CONST_STR in the verifier.
See check_mem_access() where it's doing bpf_map_direct_read().
That 'fmt' string will be accessed through the same bpf_map_direct_read().
The verifier would need to check that it's NUL-terminated valid string.
It should probably do % specifier checks at the same time.
At the end bpf_snprintf() will have 5 args and when wrapped with
BPF_SNPRINTF() macro it will accept arbitrary number of arguments to print.
It also will be generally useful to do all other kinds of pretty printing.
[PATCH v1 4/5] driver core: Handle cycles in device links created by fw_devlink
Sometimes, firmware can have cyclic dependencies between devices. But
one or more of those dependencies in the cycle are false dependencies
that don't affect the probing of the device.
fw_devlink can detect some of these false dependencies using logic. But
when it can't, we don't want to block probing of the devices in this
cyclic dependency.
So, instead of using normal device links for the devices in this cycle,
we need to switch to SYNC_STATE_ONLY device links between these devices.
This is so that sync_state() callback correctness is still maintained
while we allow these device to probe.
This is functionally similar to switching to fw_devlink=permissive just
for the devices in the cycle.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c | 58 -
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 1107d03aa6b3..4cc030361165 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1505,6 +1505,53 @@ static void fw_devlink_parse_fwtree(struct fwnode_handle
*fwnode)
fw_devlink_parse_fwtree(child);
}
+/**
+ * fw_devlink_relax_cycle - Convert cyclic links to SYNC_STATE_ONLY links
+ * @con: Device to check dependencies for.
+ * @sup: Device to check against.
+ *
+ * Check if @sup depends on @con or any device dependent on it (its child or
+ * its consumer etc). When such a cyclic dependency is found, convert all
+ * device links created solely by fw_devlink into SYNC_STATE_ONLY device links.
+ * This is the equivalent of doing fw_devlink=permissive just between the
+ * devices in the cycle. We need to do this because, at this point, fw_devlink
+ * can't tell which of these dependencies is not a real dependency.
+ *
+ * Return 1 if a cycle is found. Otherwise, return 0.
+ */
+int fw_devlink_relax_cycle(struct device *con, void *sup)
+{
+ struct device_link *link;
+ int ret;
+
+ if (con == sup)
+ return 1;
+
+ ret = device_for_each_child(con, sup, fw_devlink_relax_cycle);
+ if (ret)
+ return ret;
+
+ list_for_each_entry(link, >links.consumers, s_node) {
+ if ((link->flags & ~DL_FLAG_INFERRED) ==
+ (DL_FLAG_SYNC_STATE_ONLY | DL_FLAG_MANAGED))
+ continue;
+
+ if (!fw_devlink_relax_cycle(link->consumer, sup))
+ continue;
+
+ ret = 1;
+
+ if (!(link->flags & DL_FLAG_INFERRED))
+ continue;
+
+ pm_runtime_drop_link(link);
+ link->flags = DL_FLAG_MANAGED | FW_DEVLINK_FLAGS_PERMISSIVE;
+ dev_dbg(link->consumer, "Relaxing link with %s\n",
+ dev_name(link->supplier));
+ }
+ return ret;
+}
+
/**
* fw_devlink_create_devlink - Create a device link from a consumer to fwnode
* @con - Consumer device for the device link
@@ -1536,8 +1583,17 @@ static int fw_devlink_create_devlink(struct device *con,
* If this fails, it is due to cycles in device links. Just
* give up on this link and treat it as invalid.
*/
- if (!device_link_add(con, sup_dev, flags))
+ if (!device_link_add(con, sup_dev, flags) &&
+ !(flags & DL_FLAG_SYNC_STATE_ONLY)) {
+ dev_info(con, "Fixing up cyclic dependency with %s\n",
+dev_name(sup_dev));
+ device_links_write_lock();
+ fw_devlink_relax_cycle(con, sup_dev);
+ device_links_write_unlock();
+ device_link_add(con, sup_dev,
+ FW_DEVLINK_FLAGS_PERMISSIVE);
ret = -EINVAL;
+ }
goto out;
}
--
2.29.2.684.gfbc64c5ab5-goog
[PATCH v1 5/5] driver core: Set fw_devlink=on by default
Cyclic dependencies in some firmware was one of the last remaining
reasons fw_devlink=on couldn't be set by default. Now that cyclic
dependencies don't block probing, set fw_devlink=on by default.
Setting fw_devlink=on by default brings a bunch of benefits (currently,
only for systems with device tree firmware):
* Significantly cuts down deferred probes.
* Device probe is effectively attempted in graph order.
* Makes it much easier to load drivers as modules without having to
worry about functional dependencies between modules (depmod is still
needed for symbol dependencies).
If this patch prevents some devices from probing, it's very likely due
to the system having one or more device drivers that "probe"/set up a
device (DT node with compatible property) without creating a struct
device for it. If we hit such cases, the device drivers need to be
fixed so that they populate struct devices and probe them like normal
device drivers so that the driver core is aware of the devices and their
status. See [1] for an example of such a case.
[1] -
https://lore.kernel.org/lkml/CAGETcx9PiX==mlxb9po8myyk6u2vhpvwtmsa5nkd-ywh5xh...@mail.gmail.com/
Signed-off-by: Saravana Kannan
---
drivers/base/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 4cc030361165..803bfa6eb823 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1457,7 +1457,7 @@ static void device_links_purge(struct device *dev)
#define FW_DEVLINK_FLAGS_RPM (FW_DEVLINK_FLAGS_ON | \
DL_FLAG_PM_RUNTIME)
-static u32 fw_devlink_flags = FW_DEVLINK_FLAGS_PERMISSIVE;
+static u32 fw_devlink_flags = FW_DEVLINK_FLAGS_ON;
static int __init fw_devlink_setup(char *arg)
{
if (!arg)
--
2.29.2.684.gfbc64c5ab5-goog
[PATCH v1 3/5] driver core: Have fw_devlink use DL_FLAG_INFERRED
This will be useful in identifying device links created only due to
fw_devlink when we need to break cyclic dependencies due to fw_devlink.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 5827dbff7f21..1107d03aa6b3 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1450,7 +1450,14 @@ static void device_links_purge(struct device *dev)
device_links_write_unlock();
}
-static u32 fw_devlink_flags = DL_FLAG_SYNC_STATE_ONLY;
+#define FW_DEVLINK_FLAGS_PERMISSIVE(DL_FLAG_INFERRED | \
+DL_FLAG_SYNC_STATE_ONLY)
+#define FW_DEVLINK_FLAGS_ON(DL_FLAG_INFERRED | \
+DL_FLAG_AUTOPROBE_CONSUMER)
+#define FW_DEVLINK_FLAGS_RPM (FW_DEVLINK_FLAGS_ON | \
+DL_FLAG_PM_RUNTIME)
+
+static u32 fw_devlink_flags = FW_DEVLINK_FLAGS_PERMISSIVE;
static int __init fw_devlink_setup(char *arg)
{
if (!arg)
@@ -1459,12 +1466,11 @@ static int __init fw_devlink_setup(char *arg)
if (strcmp(arg, "off") == 0) {
fw_devlink_flags = 0;
} else if (strcmp(arg, "permissive") == 0) {
- fw_devlink_flags = DL_FLAG_SYNC_STATE_ONLY;
+ fw_devlink_flags = FW_DEVLINK_FLAGS_PERMISSIVE;
} else if (strcmp(arg, "on") == 0) {
- fw_devlink_flags = DL_FLAG_AUTOPROBE_CONSUMER;
+ fw_devlink_flags = FW_DEVLINK_FLAGS_ON;
} else if (strcmp(arg, "rpm") == 0) {
- fw_devlink_flags = DL_FLAG_AUTOPROBE_CONSUMER |
- DL_FLAG_PM_RUNTIME;
+ fw_devlink_flags = FW_DEVLINK_FLAGS_RPM;
}
return 0;
}
@@ -1477,7 +1483,7 @@ u32 fw_devlink_get_flags(void)
static bool fw_devlink_is_permissive(void)
{
- return fw_devlink_flags == DL_FLAG_SYNC_STATE_ONLY;
+ return fw_devlink_flags == FW_DEVLINK_FLAGS_PERMISSIVE;
}
static void fw_devlink_parse_fwnode(struct fwnode_handle *fwnode)
@@ -1624,7 +1630,7 @@ static void __fw_devlink_link_to_consumers(struct device
*dev)
con_dev = NULL;
} else {
own_link = false;
- dl_flags = DL_FLAG_SYNC_STATE_ONLY;
+ dl_flags = FW_DEVLINK_FLAGS_PERMISSIVE;
}
}
@@ -1679,7 +1685,7 @@ static void __fw_devlink_link_to_suppliers(struct device
*dev,
if (own_link)
dl_flags = fw_devlink_get_flags();
else
- dl_flags = DL_FLAG_SYNC_STATE_ONLY;
+ dl_flags = FW_DEVLINK_FLAGS_PERMISSIVE;
list_for_each_entry_safe(link, tmp, >suppliers, c_hook) {
int ret;
--
2.29.2.684.gfbc64c5ab5-goog
[PATCH v1 2/5] driver core: Add device link support for INFERRED flag
This flag can never be added to a device link that already exists and
doesn't have the flag set. It can only be added when a device link is
created for the first time or it can be maintained if the device link
already has the it set.
This flag will be used for marking device links created ONLY by
inferring dependencies from data and NOT from explicit action by device
drivers/frameworks. This will be useful in the future when we need to
deal with cycles in dependencies inferred from firmware.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 15 +++
include/linux/device.h | 2 ++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index fe8601197b84..5827dbff7f21 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -229,7 +229,8 @@ int device_is_dependent(struct device *dev, void *target)
return ret;
list_for_each_entry(link, >links.consumers, s_node) {
- if (link->flags == (DL_FLAG_SYNC_STATE_ONLY | DL_FLAG_MANAGED))
+ if ((link->flags & ~DL_FLAG_INFERRED) ==
+ (DL_FLAG_SYNC_STATE_ONLY | DL_FLAG_MANAGED))
continue;
if (link->consumer == target)
@@ -302,7 +303,8 @@ static int device_reorder_to_tail(struct device *dev, void
*not_used)
device_for_each_child(dev, NULL, device_reorder_to_tail);
list_for_each_entry(link, >links.consumers, s_node) {
- if (link->flags == (DL_FLAG_SYNC_STATE_ONLY | DL_FLAG_MANAGED))
+ if ((link->flags & ~DL_FLAG_INFERRED) ==
+ (DL_FLAG_SYNC_STATE_ONLY | DL_FLAG_MANAGED))
continue;
device_reorder_to_tail(link->consumer, NULL);
}
@@ -546,7 +548,8 @@ postcore_initcall(devlink_class_init);
#define DL_MANAGED_LINK_FLAGS (DL_FLAG_AUTOREMOVE_CONSUMER | \
DL_FLAG_AUTOREMOVE_SUPPLIER | \
DL_FLAG_AUTOPROBE_CONSUMER | \
- DL_FLAG_SYNC_STATE_ONLY)
+ DL_FLAG_SYNC_STATE_ONLY | \
+ DL_FLAG_INFERRED)
#define DL_ADD_VALID_FLAGS (DL_MANAGED_LINK_FLAGS | DL_FLAG_STATELESS | \
DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE)
@@ -615,7 +618,7 @@ struct device_link *device_link_add(struct device *consumer,
if (!consumer || !supplier || flags & ~DL_ADD_VALID_FLAGS ||
(flags & DL_FLAG_STATELESS && flags & DL_MANAGED_LINK_FLAGS) ||
(flags & DL_FLAG_SYNC_STATE_ONLY &&
-flags != DL_FLAG_SYNC_STATE_ONLY) ||
+(flags & ~DL_FLAG_INFERRED) != DL_FLAG_SYNC_STATE_ONLY) ||
(flags & DL_FLAG_AUTOPROBE_CONSUMER &&
flags & (DL_FLAG_AUTOREMOVE_CONSUMER |
DL_FLAG_AUTOREMOVE_SUPPLIER)))
@@ -671,6 +674,10 @@ struct device_link *device_link_add(struct device
*consumer,
if (link->consumer != consumer)
continue;
+ if (link->flags & DL_FLAG_INFERRED &&
+ !(flags & DL_FLAG_INFERRED))
+ link->flags &= ~DL_FLAG_INFERRED;
+
if (flags & DL_FLAG_PM_RUNTIME) {
if (!(link->flags & DL_FLAG_PM_RUNTIME)) {
pm_runtime_new_link(consumer);
diff --git a/include/linux/device.h b/include/linux/device.h
index 89bb8b84173e..cb5eb2e58c25 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -323,6 +323,7 @@ enum device_link_state {
* AUTOPROBE_CONSUMER: Probe consumer driver automatically after supplier
binds.
* MANAGED: The core tracks presence of supplier/consumer drivers (internal).
* SYNC_STATE_ONLY: Link only affects sync_state() behavior.
+ * INFERRED: Inferred from data (eg: firmware) and not from driver actions.
*/
#define DL_FLAG_STATELESS BIT(0)
#define DL_FLAG_AUTOREMOVE_CONSUMERBIT(1)
@@ -332,6 +333,7 @@ enum device_link_state {
#define DL_FLAG_AUTOPROBE_CONSUMER BIT(5)
#define DL_FLAG_MANAGEDBIT(6)
#define DL_FLAG_SYNC_STATE_ONLYBIT(7)
+#define DL_FLAG_INFERRED BIT(8)
/**
* enum dl_dev_state - Device driver presence tracking information.
--
2.29.2.684.gfbc64c5ab5-goog
[PATCH v1 1/5] driver core: Add debug logs for device link related probe deferrals
There's insufficient logging when device links or fw_devlink (waiting to
create device links) cause probe deferrals. This makes it hard to debug
devices not getting probed. So, add debug logs to make it easy to debug.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 25e08e5f40bd..fe8601197b84 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -929,6 +929,10 @@ int device_links_check_suppliers(struct device *dev)
mutex_lock(_link_lock);
if (dev->fwnode && !list_empty(>fwnode->suppliers) &&
!fw_devlink_is_permissive()) {
+ dev_dbg(dev, "probe deferral - wait for supplier %pfwP\n",
+ list_first_entry(>fwnode->suppliers,
+ struct fwnode_link,
+ c_hook)->supplier);
mutex_unlock(_link_lock);
return -EPROBE_DEFER;
}
@@ -943,6 +947,8 @@ int device_links_check_suppliers(struct device *dev)
if (link->status != DL_STATE_AVAILABLE &&
!(link->flags & DL_FLAG_SYNC_STATE_ONLY)) {
device_links_missing_supplier(dev);
+ dev_dbg(dev, "probe deferral - supplier %s not ready\n",
+ dev_name(link->supplier));
ret = -EPROBE_DEFER;
break;
}
--
2.29.2.684.gfbc64c5ab5-goog
