August 2024 - Linux-stable-mirror

[PATCH v3] scsi: sd: retry command SYNC CACHE if format in progress

by Yihang Li

If formatting a suspended disk (such as formatting with different DIF type), the disk will be resuming first, and then the format command will submit to the disk through SG_IO ioctl. When the disk is processing the format command, the system does not submit other commands to the disk. Therefore, the system attempts to suspend the disk again and sends the SYNC CACHE command. However, the SYNC CACHE command will fail because the disk is in the formatting process, which will cause the runtime_status of the disk to error and it is difficult for user to recover it. Error info like: [ 669.925325] sd 6:0:6:0: [sdg] Synchronizing SCSI cache [ 670.202371] sd 6:0:6:0: [sdg] Synchronize Cache(10) failed: Result: hostbyte=0x00 driverbyte=DRIVER_OK [ 670.216300] sd 6:0:6:0: [sdg] Sense Key : 0x2 [current] [ 670.221860] sd 6:0:6:0: [sdg] ASC=0x4 ASCQ=0x4 To solve the issue, retry the command until format command is finished. Signed-off-by: Yihang Li <liyihang9(a)huawei.com> Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> --- drivers/scsi/sd.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index adeaa8ab9951..5cd88a8eea73 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -1823,6 +1823,11 @@ static int sd_sync_cache(struct scsi_disk *sdkp) (sshdr.asc == 0x74 && sshdr.ascq == 0x71)) /* drive is password locked */ /* this is no error here */ return 0; + + /* retry if format in progress */ + if (sshdr.asc == 0x4 && sshdr.ascq == 0x4) + return -EBUSY; + /* * This drive doesn't support sync and there's not much * we can do because this is called during shutdown -- 2.33.0

1 year, 4 months

3
2
0 0

[PATCH V2] pmdomain: imx: wait SSAR when i.MX93 power domain on

by Peng Fan (OSS)

From: Peng Fan <peng.fan(a)nxp.com> With "quiet" set in bootargs, there is power domain failure: "imx93_power_domain 44462400.power-domain: pd_off timeout: name: 44462400.power-domain, stat: 4" The current power on opertation takes ISO state as power on finished flag, but it is wrong. Before powering on operation really finishes, powering off comes and powering off will never finish because the last powering on still not finishes, so the following powering off actually not trigger hardware state machine to run. SSAR is the last step when powering on a domain, so need to wait SSAR done when powering on. Since EdgeLock Enclave(ELE) handshake is involved in the flow, enlarge the waiting time to 10ms for both on and off to avoid timeout. Cc: <Stable(a)vger.kernel.org> Fixes: 0a0f7cc25d4a ("soc: imx: add i.MX93 SRC power domain driver") Reviewed-by: Jacky Bai <ping.bai(a)nxp.com> Signed-off-by: Peng Fan <peng.fan(a)nxp.com> --- V2: Add Fixes tag and Cc stable (Per Ulf's comment) drivers/pmdomain/imx/imx93-pd.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/pmdomain/imx/imx93-pd.c b/drivers/pmdomain/imx/imx93-pd.c index 1e94b499c19b..d750a7dc58d2 100644 --- a/drivers/pmdomain/imx/imx93-pd.c +++ b/drivers/pmdomain/imx/imx93-pd.c @@ -20,6 +20,7 @@ #define FUNC_STAT_PSW_STAT_MASK BIT(0) #define FUNC_STAT_RST_STAT_MASK BIT(2) #define FUNC_STAT_ISO_STAT_MASK BIT(4) +#define FUNC_STAT_SSAR_STAT_MASK BIT(8) struct imx93_power_domain { struct generic_pm_domain genpd; @@ -50,7 +51,7 @@ static int imx93_pd_on(struct generic_pm_domain *genpd) writel(val, addr + MIX_SLICE_SW_CTRL_OFF); ret = readl_poll_timeout(addr + MIX_FUNC_STAT_OFF, val, - !(val & FUNC_STAT_ISO_STAT_MASK), 1, 10000); + !(val & FUNC_STAT_SSAR_STAT_MASK), 1, 10000); if (ret) { dev_err(domain->dev, "pd_on timeout: name: %s, stat: %x\n", genpd->name, val); return ret; @@ -72,7 +73,7 @@ static int imx93_pd_off(struct generic_pm_domain *genpd) writel(val, addr + MIX_SLICE_SW_CTRL_OFF); ret = readl_poll_timeout(addr + MIX_FUNC_STAT_OFF, val, - val & FUNC_STAT_PSW_STAT_MASK, 1, 1000); + val & FUNC_STAT_PSW_STAT_MASK, 1, 10000); if (ret) { dev_err(domain->dev, "pd_off timeout: name: %s, stat: %x\n", genpd->name, val); return ret; -- 2.37.1

1 year, 4 months

2
1
0 0

Re: [PATCH 6.6.y 00/12] Backport "make svc_stat per-net instead of global"

by Petr Vorel

Hi Calum, > Hi Petr, > There are two sets of changes here, for NFS client, and NFS server. > The NFS client changes have already been backported from v6.9 all the way to v5.4. > Here, Chuck is discussing the NFS server changes (and others), which were not backported from v6.9 (actually, a few were, but only to v6.8). Thanks for info! Now I'll see the patchset "Make nfsd stats visible in network ns" [1]. kernelnewbies [2] starts with d98416cc2154 ("nfsd: rename NFSD_NET_* to NFSD_STATS_*"), the others are probably some preparation commits. Anyway, I'll update the patch with NFS server patchset. Kind regards, Petr [1] https://lore.kernel.org/linux-nfs/cover.1706283433.git.josef@toxicpanda.com/ [2] https://kernelnewbies.org/Linux_6.9#File_systems > Thanks, > Calum. > Sent from Outlook for Android<https://aka.ms/AAb9ysg> > ________________________________ > From: Petr Vorel <pvorel(a)suse.cz> > Sent: Wednesday, August 14, 2024 8:45:59 AM > To: cel(a)kernel.org <cel(a)kernel.org> > Cc: stable(a)vger.kernel.org <stable(a)vger.kernel.org>; linux-nfs(a)vger.kernel.org <linux-nfs(a)vger.kernel.org>; Sherry Yang <sherry.yang(a)oracle.com>; Calum Mackay <calum.mackay(a)oracle.com>; kernel-team(a)fb.com <kernel-team(a)fb.com>; Chuck Lever III <chuck.lever(a)oracle.com>; Cyril Hrubis <chrubis(a)suse.cz>; ltp(a)lists.linux.it <ltp(a)lists.linux.it> > Subject: Re: [PATCH 6.6.y 00/12] Backport "make svc_stat per-net instead of global" > Hi Chuck, > > Following up on: > > https://lore.kernel.org/linux-nfs/d4b235df-4ee5-4824-9d48-e3b3c1f1f4d1@orac… > > Here is a backport series targeting origin/linux-6.6.y that closes > > the information leak described in the above thread. It passes basic > > NFSD regression testing. > Thank you for handling this! The link above mentions that it was already > backported to 5.4 and indeed I see at least d47151b79e322 ("nfs: expose > /proc/net/sunrpc/nfs in net namespaces") is backported in 5.4, 5.10, 5.15, 6.1. > And you're now preparing 6.6. Thus we can expect the behavior changed from > 5.4 kernels. > I wonder if we consider this as a fix, thus expect any kernel newer than 5.4 > should backport all these 12 patches. > Or, whether we should relax and just check if version is higher than the one > which got it in stable/LTS (e.g. >= 5.4.276 || >= 5.10.217 ...). The question is > also if enterprise distros will take this patchset. > BTW We have in LTP functionality which points as a hint to kernel fixes. But > it's usually a single commit. I might need to list all. > Kind regards, > Petr > > Review comments welcome. > > Chuck Lever (2): > > NFSD: Rewrite synopsis of nfsd_percpu_counters_init() > > NFSD: Fix frame size warning in svc_export_parse() > > Josef Bacik (10): > > sunrpc: don't change ->sv_stats if it doesn't exist > > nfsd: stop setting ->pg_stats for unused stats > > sunrpc: pass in the sv_stats struct through svc_create_pooled > > sunrpc: remove ->pg_stats from svc_program > > sunrpc: use the struct net as the svc proc private > > nfsd: rename NFSD_NET_* to NFSD_STATS_* > > nfsd: expose /proc/net/sunrpc/nfsd in net namespaces > > nfsd: make all of the nfsd stats per-network namespace > > nfsd: remove nfsd_stats, make th_cnt a global counter > > nfsd: make svc_stat per-network namespace instead of global > > fs/lockd/svc.c | 3 -- > > fs/nfs/callback.c | 3 -- > > fs/nfsd/cache.h | 2 - > > fs/nfsd/export.c | 32 ++++++++++---- > > fs/nfsd/export.h | 4 +- > > fs/nfsd/netns.h | 25 +++++++++-- > > fs/nfsd/nfs4proc.c | 6 +-- > > fs/nfsd/nfs4state.c | 3 +- > > fs/nfsd/nfscache.c | 40 ++++------------- > > fs/nfsd/nfsctl.c | 16 +++---- > > fs/nfsd/nfsd.h | 1 + > > fs/nfsd/nfsfh.c | 3 +- > > fs/nfsd/nfssvc.c | 14 +++--- > > fs/nfsd/stats.c | 54 ++++++++++------------- > > fs/nfsd/stats.h | 88 ++++++++++++++------------------------ > > fs/nfsd/vfs.c | 6 ++- > > include/linux/sunrpc/svc.h | 5 ++- > > net/sunrpc/stats.c | 2 +- > > net/sunrpc/svc.c | 39 +++++++++++------ > > 19 files changed, 163 insertions(+), 183 deletions(-)

1 year, 4 months

2
1
0 0

Re: [PATCHv3 0/3] cpuidle: teo: Fixing utilization and intercept logic

by Christian Loehle

On 6/28/24 20:06, Rafael J. Wysocki wrote: > On Fri, Jun 28, 2024 at 12:02 PM Christian Loehle > <christian.loehle(a)arm.com> wrote: >> >> Hi all, >> so my investigation into teo lead to the following fixes. >> >> 1/3: >> As discussed the utilization threshold is too high while >> there are benefits in certain workloads, there are quite a few >> regressions, too. Revert the Util-awareness patch. >> This in itself leads to regressions, but part of it can be offset >> by the later patches. >> See >> https://lore.kernel.org/lkml/CAKfTPtA6ZzRR-zMN7sodOW+N_P+GqwNv4tGR+aMB5VXRT… >> 2/3: >> Remove the 'recent' intercept logic, see my findings in: >> https://lore.kernel.org/lkml/0ce2d536-1125-4df8-9a5b-0d5e389cd8af@arm.com/ >> I haven't found a way to salvage this properly, so I removed it. >> The regular intercept seems to decay fast enough to not need this, but >> we could change it if that turns out that we need this to be faster in >> ramp-up and decaying. >> 3/3: >> The rest of the intercept logic had issues, too. >> See the commit. >> >> Happy for anyone to take a look and test as well. >> >> Some numbers for context, comparing: >> - IO workload (intercept heavy). >> - Timer workload very low utilization (check for deepest state) >> - hackbench (high utilization) >> - Geekbench 5 on Pixel6 (high utilization) >> Tests 1 to 3 are on RK3399 with CONFIG_HZ=100. >> target_residencies: 1, 900, 2000 >> >> 1. IO workload, 5 runs, results sorted, in read IOPS. >> fio --minimal --time_based --name=fiotest --filename=/dev/nvme0n1 --runtime=30 --rw=randread --bs=4k --ioengine=psync --iodepth=1 --direct=1 | cut -d \; -f 8; >> >> teo fixed v2: >> /dev/nvme0n1 >> [4599, 4658, 4692, 4694, 4720] >> /dev/mmcblk2 >> [5700, 5730, 5735, 5747, 5977] >> /dev/mmcblk1 >> [2052, 2054, 2066, 2067, 2073] >> >> teo mainline: >> /dev/nvme0n1 >> [3793, 3825, 3846, 3865, 3964] >> /dev/mmcblk2 >> [3831, 4110, 4154, 4203, 4228] >> /dev/mmcblk1 >> [1559, 1564, 1596, 1611, 1618] >> >> menu: >> /dev/nvme0n1 >> [2571, 2630, 2804, 2813, 2917] >> /dev/mmcblk2 >> [4181, 4260, 5062, 5260, 5329] >> /dev/mmcblk1 >> [1567, 1581, 1585, 1603, 1769] >> >> >> 2. Timer workload (through IO for my convenience 😉 ) >> Results in read IOPS, fio same as above. >> echo "0 2097152 zero" | dmsetup create dm-zeros >> echo "0 2097152 delay /dev/mapper/dm-zeros 0 50" | dmsetup create dm-slow >> (Each IO is delayed by timer of 50ms, should be mostly in state2, for 5s total) >> >> teo fixed v2: >> idle_state time >> 2.0 4.807025 >> -1.0 0.219766 >> 0.0 0.072007 >> 1.0 0.169570 >> >> 3199 cpu_idle total >> 38 cpu_idle_miss >> 31 cpu_idle_miss above >> 7 cpu_idle_miss below >> >> teo mainline: >> idle_state time >> 1.0 4.897942 >> -1.0 0.095375 >> 0.0 0.253581 >> >> 3221 cpu_idle total >> 1269 cpu_idle_miss >> 22 cpu_idle_miss above >> 1247 cpu_idle_miss below >> >> menu: >> idle_state time >> 2.0 4.295546 >> -1.0 0.234164 >> 1.0 0.356344 >> 0.0 0.401507 >> >> 3421 cpu_idle total >> 129 cpu_idle_miss >> 52 cpu_idle_miss above >> 77 cpu_idle_miss below >> >> Residencies: >> teo mainline isn't in state2 at all, teo fixed is more in state2 than menu, but >> both are in state2 the vast majority of the time as expected. >> >> tldr: overall teo fixed spends more time in state2 while having >> fewer idle_miss than menu. >> teo mainline was just way too aggressive at selecting shallow states. >> >> 3. Hackbench, 5 runs >> for i in $(seq 0 4); do hackbench -l 100 -g 100 ; sleep 1; done >> >> teo fixed v2: >> Time: 4.937 >> Time: 4.898 >> Time: 4.871 >> Time: 4.833 >> Time: 4.898 >> >> teo mainline: >> Time: 4.945 >> Time: 5.021 >> Time: 4.927 >> Time: 4.923 >> Time: 5.137 >> >> menu: >> Time: 4.964 >> Time: 4.847 >> Time: 4.914 >> Time: 4.841 >> Time: 4.800 >> >> tldr: all comparable, teo mainline slightly worse >> >> 4. Geekbench 5 (multi-core) on Pixel6 >> (Device is cooled for each iteration separately) >> teo mainline: >> 3113, 3068, 3079 >> mean 3086.66 >> >> teo revert util-awareness: >> 2947, 2941, 2952 >> mean 2946.66 (-4.54%) >> >> teo fixed v2: >> 3032, 3066, 3019 >> mean 3039 (-1.54%) >> >> >> Changes since v2: >> - Reworded commits according to Dietmar's comments >> - Dropped the KTIME_MAX as hit part from 3/3 according to Dietmar's >> remark. >> >> Changes since v1: >> - Removed all non-fixes. >> - Do a full revert of Util-awareness instead of increasing thresholds. >> - Address Dietmar's comments. >> https://lore.kernel.org/linux-kernel/20240606090050.327614-2-christian.loeh… >> >> Kind Regards, >> Christian >> >> Christian Loehle (3): >> Revert: "cpuidle: teo: Introduce util-awareness" >> cpuidle: teo: Remove recent intercepts metric >> cpuidle: teo: Don't count non-existent intercepts >> >> drivers/cpuidle/governors/teo.c | 189 +++++--------------------------- >> 1 file changed, 27 insertions(+), 162 deletions(-) >> >> -- > > Patches [1-2/3] have been applied as 6.11 material. > > Patch [3/3] looks like it may be improved slightly, see my reply to that patch. > > Thanks! Hi Rafael, are you fine with this being backported to stable? @stable 4b20b07ce72f cpuidle: teo: Don't count non-existent intercepts 449914398083 cpuidle: teo: Remove recent intercepts metric 0a2998fa48f0 Revert: "cpuidle: teo: Introduce util-awareness" apply as-is to linux-6.10.y linux-6.6.y for linux-6.1.y only 449914398083 ("cpuidle: teo: Remove recent intercepts metric") is relevant, I'll reply with a backport.

1 year, 4 months

2
4
0 0

[PATCH] soc: imx: imx8m-blk-ctrl: Fix NULL pointer dereference

by Ma Ke

Check bc->bus_power_dev = dev_pm_domain_attach_by_name() return value using IS_ERR_OR_NULL() instead of plain IS_ERR(), and fail if bc->bus_power_dev is either error or NULL. In case a power domain attached by dev_pm_domain_attach_by_name() is not described in DT, dev_pm_domain_attach_by_name() returns NULL, which is then used, which leads to NULL pointer dereference. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 1a1da28544fd ("soc: imx: imx8m-blk-ctrl: Defer probe if 'bus' genpd is not yet ready") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/pmdomain/imx/imx8m-blk-ctrl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pmdomain/imx/imx8m-blk-ctrl.c b/drivers/pmdomain/imx/imx8m-blk-ctrl.c index ca942d7929c2..d46fb5387148 100644 --- a/drivers/pmdomain/imx/imx8m-blk-ctrl.c +++ b/drivers/pmdomain/imx/imx8m-blk-ctrl.c @@ -212,7 +212,7 @@ static int imx8m_blk_ctrl_probe(struct platform_device *pdev) return -ENOMEM; bc->bus_power_dev = dev_pm_domain_attach_by_name(dev, "bus"); - if (IS_ERR(bc->bus_power_dev)) { + if (IS_ERR_OR_NULL(bc->bus_power_dev)) { if (PTR_ERR(bc->bus_power_dev) == -ENODEV) return dev_err_probe(dev, -EPROBE_DEFER, "failed to attach power domain \"bus\"\n"); -- 2.25.1

1 year, 4 months

4
7
0 0

[PATCH] tty: serial: Add a NULL check for of_node

by Ma Ke

The pdev->dev.of_node can be NULL if the "serial" node is absent. Add a NULL check for np to return an error in such cases. Found by code review. Compile tested only. Cc: stable(a)vger.kernel.org Fixes: 09864c1cdf5c ("tty: serial: Add linflexuart driver for S32V234") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/tty/serial/fsl_linflexuart.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/tty/serial/fsl_linflexuart.c b/drivers/tty/serial/fsl_linflexuart.c index e972df4b188d..f46f3c21ee1b 100644 --- a/drivers/tty/serial/fsl_linflexuart.c +++ b/drivers/tty/serial/fsl_linflexuart.c @@ -811,6 +811,9 @@ static int linflex_probe(struct platform_device *pdev) struct resource *res; int ret; + if (!np) + return -ENODEV; + sport = devm_kzalloc(&pdev->dev, sizeof(*sport), GFP_KERNEL); if (!sport) return -ENOMEM; -- 2.25.1

1 year, 4 months

2
1
0 0

Re: [PATCH v2] media: qcom: camss: fix error path on configuration of power domains

by Bryan O'Donoghue

On 13/08/2024 22:03, Vladimir Zapolskiy wrote: > There is a chance to meet runtime issues during configuration of CAMSS > power domains, because on the error path dev_pm_domain_detach() is > unexpectedly called with NULL or error pointer. > > One of the simplest ways to reproduce the problem is to probe CAMSS > driver before registration of CAMSS power domains, for instance if > a platform CAMCC driver is simply not built. > > Warning backtrace example: > > Unable to handle kernel NULL pointer dereference at virtual address 00000000000001a2 > > <snip> > > pc : dev_pm_domain_detach+0x8/0x48 > lr : camss_probe+0x374/0x9c0 > > <snip> > > Call trace: > dev_pm_domain_detach+0x8/0x48 > platform_probe+0x70/0xf0 > really_probe+0xc4/0x2a8 > __driver_probe_device+0x80/0x140 > driver_probe_device+0x48/0x170 > __device_attach_driver+0xc0/0x148 > bus_for_each_drv+0x88/0xf0 > __device_attach+0xb0/0x1c0 > device_initial_probe+0x1c/0x30 > bus_probe_device+0xb4/0xc0 > deferred_probe_work_func+0x90/0xd0 > process_one_work+0x164/0x3e0 > worker_thread+0x310/0x420 > kthread+0x120/0x130 > ret_from_fork+0x10/0x20 > > Fixes: 23aa4f0cd327 ("media: qcom: camss: Move VFE power-domain specifics into vfe.c") > Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy(a)linaro.org> > --- > The first version of the patch and discussion is found over here: > > https://lore.kernel.org/all/20240806221204.1560258-1-vladimir.zapolskiy@lin… > > Changes from v1 to v2: > * added an encountered runtime warning to the commit message per ask from Bryan. > > I tested this fix in both cases of set and unset "power-domain-names" > property in camss device tree node, and I didn't find any negative side > effects of the fix. > > drivers/media/platform/qcom/camss/camss.c | 19 ++++++++----------- > 1 file changed, 8 insertions(+), 11 deletions(-) > > diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c > index 51b1d3550421..aa894be1461d 100644 > --- a/drivers/media/platform/qcom/camss/camss.c > +++ b/drivers/media/platform/qcom/camss/camss.c + stable(a)vger.kernel.org Reviewed-by: Bryan O'Donoghue <bryan.odonoghue(a)linaro.org>

1 year, 4 months

1
0
0 0

[git:media_stage/fixes] media: atomisp: Fix streaming no longer working on BYT / ISP2400 devices

by Hans Verkuil

This is an automatic generated email to let you know that the following patch were queued: Subject: media: atomisp: Fix streaming no longer working on BYT / ISP2400 devices Author: Hans de Goede <hdegoede(a)redhat.com> Date: Sun Jul 21 17:38:40 2024 +0200 Commit a0821ca14bb8 ("media: atomisp: Remove test pattern generator (TPG) support") broke BYT support because it removed a seemingly unused field from struct sh_css_sp_config and a seemingly unused value from enum ia_css_input_mode. But these are part of the ABI between the kernel and firmware on ISP2400 and this part of the TPG support removal changes broke ISP2400 support. ISP2401 support was not affected because on ISP2401 only a part of struct sh_css_sp_config is used. Restore the removed field and enum value to fix this. Fixes: a0821ca14bb8 ("media: atomisp: Remove test pattern generator (TPG) support") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> .../staging/media/atomisp/pci/ia_css_stream_public.h | 8 ++++++-- drivers/staging/media/atomisp/pci/sh_css_internal.h | 19 ++++++++++++++++--- 2 files changed, 22 insertions(+), 5 deletions(-) --- diff --git a/drivers/staging/media/atomisp/pci/ia_css_stream_public.h b/drivers/staging/media/atomisp/pci/ia_css_stream_public.h index 961c61288083..aad860e54d3a 100644 --- a/drivers/staging/media/atomisp/pci/ia_css_stream_public.h +++ b/drivers/staging/media/atomisp/pci/ia_css_stream_public.h @@ -27,12 +27,16 @@ #include "ia_css_prbs.h" #include "ia_css_input_port.h" -/* Input modes, these enumerate all supported input modes. - * Note that not all ISP modes support all input modes. +/* + * Input modes, these enumerate all supported input modes. + * This enum is part of the atomisp firmware ABI and must + * NOT be changed! + * Note that not all ISP modes support all input modes. */ enum ia_css_input_mode { IA_CSS_INPUT_MODE_SENSOR, /** data from sensor */ IA_CSS_INPUT_MODE_FIFO, /** data from input-fifo */ + IA_CSS_INPUT_MODE_TPG, /** data from test-pattern generator */ IA_CSS_INPUT_MODE_PRBS, /** data from pseudo-random bit stream */ IA_CSS_INPUT_MODE_MEMORY, /** data from a frame in memory */ IA_CSS_INPUT_MODE_BUFFERED_SENSOR /** data is sent through mipi buffer */ diff --git a/drivers/staging/media/atomisp/pci/sh_css_internal.h b/drivers/staging/media/atomisp/pci/sh_css_internal.h index a2d972ea3fa0..959e7f549641 100644 --- a/drivers/staging/media/atomisp/pci/sh_css_internal.h +++ b/drivers/staging/media/atomisp/pci/sh_css_internal.h @@ -344,7 +344,14 @@ struct sh_css_sp_input_formatter_set { #define IA_CSS_MIPI_SIZE_CHECK_MAX_NOF_ENTRIES_PER_PORT (3) -/* SP configuration information */ +/* + * SP configuration information + * + * This struct is part of the atomisp firmware ABI and is directly copied + * to ISP DRAM by sh_css_store_sp_group_to_ddr() + * + * Do NOT change this struct's layout or remove seemingly unused fields! + */ struct sh_css_sp_config { u8 no_isp_sync; /* Signal host immediately after start */ u8 enable_raw_pool_locking; /** Enable Raw Buffer Locking for HALv3 Support */ @@ -354,6 +361,10 @@ struct sh_css_sp_config { host (true) or when they are passed to the preview/video pipe (false). */ + /* + * Note the fields below are only used on the ISP2400 not on the ISP2401, + * sh_css_store_sp_group_to_ddr() skip copying these when run on the ISP2401. + */ struct { u8 a_changed; u8 b_changed; @@ -363,11 +374,13 @@ struct sh_css_sp_config { } input_formatter; sync_generator_cfg_t sync_gen; + tpg_cfg_t tpg; prbs_cfg_t prbs; input_system_cfg_t input_circuit; u8 input_circuit_cfg_changed; - u32 mipi_sizes_for_check[N_CSI_PORTS][IA_CSS_MIPI_SIZE_CHECK_MAX_NOF_ENTRIES_PER_PORT]; - u8 enable_isys_event_queue; + u32 mipi_sizes_for_check[N_CSI_PORTS][IA_CSS_MIPI_SIZE_CHECK_MAX_NOF_ENTRIES_PER_PORT]; + /* These last 2 fields are used on both the ISP2400 and the ISP2401 */ + u8 enable_isys_event_queue; u8 disable_cont_vf; };

1 year, 4 months

1
0
0 0

[PATCH] usb: dwc3: Fix latency of DSTS while receiving wakeup event

by Prashanth K

When operating in High-Speed, it is observed that DSTS[USBLNKST] doesn't update link state immediately after receiving the wakeup interrupt. Since wakeup event handler calls the resume callbacks, there is a chance that function drivers can perform an ep queue. Which in turn tries to perform remote wakeup from send_gadget_ep_cmd(), this happens because DSTS[[21:18] wasn't updated to U0 yet. It is observed that the latency of DSTS can be in order of milli-seconds. Hence update the dwc->link_state from evtinfo, and use this variable to prevent calling remote wakup unnecessarily. Fixes: ecba9bc9946b ("usb: dwc3: gadget: Check for L1/L2/U3 for Start Transfer") Cc: <stable(a)vger.kernel.org> Signed-off-by: Prashanth K <quic_prashk(a)quicinc.com> --- drivers/usb/dwc3/gadget.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 89fc690fdf34..3b55285118b0 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -328,7 +328,8 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd, } if (DWC3_DEPCMD_CMD(cmd) == DWC3_DEPCMD_STARTTRANSFER) { - int link_state; + int link_state; + bool remote_wakeup = false; /* * Initiate remote wakeup if the link state is in U3 when @@ -339,15 +340,26 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd, link_state = dwc3_gadget_get_link_state(dwc); switch (link_state) { case DWC3_LINK_STATE_U2: - if (dwc->gadget->speed >= USB_SPEED_SUPER) + if (dwc->gadget->speed < USB_SPEED_SUPER) + remote_wakeup = true; + break; + case DWC3_LINK_STATE_U3: + /* + * In HS, DSTS can take few milliseconds to update linkstate bits, + * so rely on dwc->link_state to identify whether gadget woke up. + * Don't issue remote wakuep again if link is already in U0. + */ + if (dwc->link_state == DWC3_LINK_STATE_U0) break; - fallthrough; - case DWC3_LINK_STATE_U3: + remote_wakeup = true; + break; + } + + if (remote_wakeup) { ret = __dwc3_gadget_wakeup(dwc, false); dev_WARN_ONCE(dwc->dev, ret, "wakeup failed --> %d\n", ret); - break; } } @@ -4214,6 +4226,7 @@ static void dwc3_gadget_conndone_interrupt(struct dwc3 *dwc) static void dwc3_gadget_wakeup_interrupt(struct dwc3 *dwc, unsigned int evtinfo) { dwc->suspended = false; + dwc->link_state = evtinfo & DWC3_LINK_STATE_MASK; /* * TODO take core out of low power mode when that's @@ -4225,8 +4238,6 @@ static void dwc3_gadget_wakeup_interrupt(struct dwc3 *dwc, unsigned int evtinfo) dwc->gadget_driver->resume(dwc->gadget); spin_lock(&dwc->lock); } - - dwc->link_state = evtinfo & DWC3_LINK_STATE_MASK; } static void dwc3_gadget_linksts_change_interrupt(struct dwc3 *dwc, -- 2.25.1

1 year, 4 months

2
6
0 0

[PATCH v2 0/2] userfaultfd: fix races around pmd_trans_huge() check

by Jann Horn

The pmd_trans_huge() code in mfill_atomic() is wrong in three different ways depending on kernel version: 1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case). 2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr(). 3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong. I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to kernels affected by bugs 1+2. Signed-off-by: Jann Horn <jannh(a)google.com> --- Changes in v2: - in patch 1/2: - change title - get rid of redundant early pmd_trans_huge() check - also check for swap PMDs and devmap PMDs (Qi Zheng) - Link to v1: https://lore.kernel.org/r/20240812-uffd-thp-flip-fix-v1-0-4fc1db7ccdd0@goog… --- Jann Horn (2): userfaultfd: Fix checks for huge PMDs userfaultfd: Don't BUG_ON() if khugepaged yanks our page table mm/userfaultfd.c | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-) --- base-commit: d4560686726f7a357922f300fc81f5964be8df04 change-id: 20240812-uffd-thp-flip-fix-20f91f1151b9 -- Jann Horn <jannh(a)google.com>

1 year, 4 months

3
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2024