Re: [PATCH] pinctrl: renesas: Constify sh73a0_vccq_mc0_ops
On Mon, Nov 9, 2020 at 11:10 PM Rikard Falkeborn
wrote:
> The only usage of sh73a0_vccq_mc0_ops is to assign its address to the
> ops field in the regulator_desc struct, which is a const pointer. Make
> it const to allow the compiler to put it in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-pinctrl-for-v5.11.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[rcu:dev.2020.11.06a 15/22] kernel/taskstats.c:350: undefined reference to `cpulist_parse'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2020.11.06a
head: 5cec02881428f10c4a1632c3aebb666b12888958
commit: 015465e505581b068dba346e6e73caeb673e8753 [15/22] cpumask: un-inline
cpulist_parse; prepare for ascii helpers
config: h8300-randconfig-r013-20201109 (attached as .config)
compiler: h8300-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://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?id=015465e505581b068dba346e6e73caeb673e8753
git remote add rcu
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
git fetch --no-tags rcu dev.2020.11.06a
git checkout 015465e505581b068dba346e6e73caeb673e8753
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=h8300
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
h8300-linux-ld: arch/h8300/kernel/entry.o: in function `resume_kernel':
arch/h8300/kernel/entry.S:324: undefined reference to `TI_PRE_COUNT'
h8300-linux-ld: kernel/taskstats.o: in function `parse':
>> kernel/taskstats.c:350: undefined reference to `cpulist_parse'
vim +350 kernel/taskstats.c
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 332
41c7bb9588904eb Rusty Russell 2009-01-01 333 static int parse(struct nlattr
*na, struct cpumask *mask)
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 334 {
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 335 char *data;
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 336 int len;
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 337 int ret;
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 338
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 339 if (na == NULL)
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 340 return 1;
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 341 len = nla_len(na);
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 342 if (len >
TASKSTATS_CPUMASK_MAXLEN)
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 343 return -E2BIG;
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 344 if (len < 1)
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 345 return -EINVAL;
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 346 data = kmalloc(len,
GFP_KERNEL);
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 347 if (!data)
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 348 return -ENOMEM;
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 349 nla_strlcpy(data, na,
len);
29c0177e6a4ac09 Rusty Russell 2008-12-13 @350 ret =
cpulist_parse(data, mask);
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 351 kfree(data);
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 352 return ret;
f9fd8914c1acca0 Shailabh Nagar 2006-07-14 353 }
ad4ecbcba72855a Shailabh Nagar 2006-07-14 354
:: The code at line 350 was first introduced by commit
:: 29c0177e6a4ac094302bed54a1d4bbb6b740a9ef cpumask: change
cpumask_scnprintf, cpumask_parse_user, cpulist_parse, and cpulist_scnprintf to
take pointers.
:: TO: Rusty Russell
:: CC: Rusty Russell
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH V2] sched/rt, powerpc: Prepare for PREEMPT_RT
PREEMPT_RT is a separate preemption model, CONFIG_PRTTMPT will
be disabled when CONFIG_PREEMPT_RT is enabled, so you need
to add CONFIG_PREEMPT_RT judgments to __die().
Signed-off-by: Wang Qing
Changes in v2:
- Modify as Christophe suggested.
---
arch/powerpc/kernel/traps.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 5006dcb..dec7b81
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -262,10 +262,11 @@ static int __die(const char *str, struct pt_regs *regs,
long err)
{
printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
- printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
+ printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",
IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
PAGE_SIZE / 1024, get_mmu_str(),
IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
+ IS_ENABLED(CONFIG_PREEMPT_RT) ? " PREEMPT_RT" : "",
IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
--
2.7.4
[PATCH] amd/display/amdgpu_dm: delete same check in if condition
In function amdgpu_dm_connector_get_modes, drm_edid_is_valid
will check weather (!edid), no need to check again in the if
branch.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e93e18c06c0e..0a283d07fe10 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6352,7 +6352,7 @@ static int amdgpu_dm_connector_get_modes(struct
drm_connector *connector)
encoder = amdgpu_dm_connector_to_encoder(connector);
- if (!edid || !drm_edid_is_valid(edid)) {
+ if (!drm_edid_is_valid(edid)) {
amdgpu_dm_connector->num_modes =
drm_add_modes_noedid(connector, 640, 480);
} else {
--
2.29.0
[PATCH 1/1] mfd: stmfx: fix dev_err_probe call in stmfx_chip_init
ret may be 0 so, dev_err_probe should be called only when ret is an error
code.
Fixes: 41c9c06c491a ("mfd: stmfx: Simplify with dev_err_probe()")
Signed-off-by: Amelie Delaunay
---
drivers/mfd/stmfx.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/stmfx.c b/drivers/mfd/stmfx.c
index 5e680bfdf5c9..360fb4646688 100644
--- a/drivers/mfd/stmfx.c
+++ b/drivers/mfd/stmfx.c
@@ -329,12 +329,11 @@ static int stmfx_chip_init(struct i2c_client *client)
stmfx->vdd = devm_regulator_get_optional(>dev, "vdd");
ret = PTR_ERR_OR_ZERO(stmfx->vdd);
- if (ret == -ENODEV) {
+ if (ret == -ENODEV)
stmfx->vdd = NULL;
- } else {
+ else if (ret)
return dev_err_probe(>dev, ret,
"Failed to get VDD regulator\n");
- }
if (stmfx->vdd) {
ret = regulator_enable(stmfx->vdd);
--
2.17.1
[PATCH] ALSA: usb-audio: disable 96khz support for HUAWEI USB-C HEADSET
The HUAWEI USB-C headset (VID:0x12d1, PID:0x3a07) reported it supports 96khz. However there will be some random issue under 96khz. Not sure if there is any alternate setting could be applied. Hence 48khz is suggested to be applied at this moment. Signed-off-by: Macpaul Lin Signed-off-by: Eddie Hung --- sound/usb/format.c |5 + 1 file changed, 5 insertions(+) diff --git a/sound/usb/format.c b/sound/usb/format.c index 1b28d01..6f6e79b 100644 --- a/sound/usb/format.c +++ b/sound/usb/format.c @@ -217,6 +217,11 @@ static int parse_audio_format_rates_v1(struct snd_usb_audio *chip, struct audiof (chip->usb_id == USB_ID(0x041e, 0x4064) || chip->usb_id == USB_ID(0x041e, 0x4068))) rate = 8000; + /* Huawei headset can't support 96kHz fully */ + if (rate == 96000 && + chip->usb_id == USB_ID(0x12d1, 0x3a07) && + le16_to_cpu(udev->descriptor.bcdDevice) == 0x49) + continue; fp->rate_table[fp->nr_rates] = rate; if (!fp->rate_min || rate < fp->rate_min) -- 1.7.9.5
Re: binder: add transaction latency tracer
On Tue, 2020-11-10 at 08:53 +0100, Greg Kroah-Hartman wrote: > On Tue, Nov 10, 2020 at 08:52:09AM +0100, Greg Kroah-Hartman wrote: > > On Tue, Nov 10, 2020 at 03:33:00PM +0800, Frankie Chang wrote: > > > On Mon, 2020-11-09 at 18:46 +0100, Greg Kroah-Hartman wrote: > > > > On Fri, Oct 30, 2020 at 12:08:54AM +0800, Frankie Chang wrote: > > > > > Change from v11: > > > > > - rebase. > > > > > > > > This whole patch set is sent with DOS line-ends, which makes git really > > > > unhappy when it tries to apply it, as rightfully, it doesn't know how to > > > > convert things. > > > > > > > Hmm.., actually I can use 'git apply' PATCH v11 from the message > > > directly. > > > > Ok, let me see if I can figure this out on my end, let me try using `b4` > > on this to see if that helps... > > Nope, there's still some merge conflicts here. b4 fixed the line-end > issues, but can you please rebase on top of my char-misc-next branch in > the char.git tree on git.kernel.org and resend? I think some changes by > others are conflicting with this patchset somehow. > Thanks for helping the line-end issues, I will rebase and verify locally then resend the patch set again. Many thanks Frankie Chang
Re: [linux-safety] [PATCH] taskstats: remove unneeded dead assignment
On Fri, Nov 06, 2020 at 12:04:53PM +, Sudip Mukherjee wrote: > Hi Lukas, > > On 06/11/2020 10:31, Lukas Bulwahn wrote: > > > > > > On Fri, 6 Nov 2020, Sudip Mukherjee wrote: > > > >> Hi Lukas, > >> > > > > > > > I did not try but I bet (a beverage of your choice) that the object code > > remains the same also for your suggested patch. Try to disprove my claim > > and possibly earn yourself a beverage when we meet... > > Lets decide which beverage.. ;-) > > Using gcc-7.2.0 for MIPS: > > original:- ab81d3305d578c2568fbc73aad2f9e61 kernel/taskstats.o > After your change:- ab81d3305d578c2568fbc73aad2f9e61 kernel/taskstats.o > After my change:- 0acae2c8d72abd3e15bf805fccdca711 kernel/taskstats.o I'm surprised the line numbers from the printks aren't affecting it... I personally prefer Lukas's patch. "rc" should be function scope... regards, dan carpenter
Re: [PATCH V2] sched/rt, powerpc: Prepare for PREEMPT_RT
Le 10/11/2020 à 09:02, Wang Qing a écrit :
PREEMPT_RT is a separate preemption model, CONFIG_PRTTMPT will
s/CONFIG_PRTTMPT/CONFIG_PREEMPT
be disabled when CONFIG_PREEMPT_RT is enabled, so you need
to add CONFIG_PREEMPT_RT judgments to __die().
Signed-off-by: Wang Qing
Otherwise
Reviewed-by: Christophe Leroy
Changes in v2:
- Modify as Christophe suggested.
---
arch/powerpc/kernel/traps.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 5006dcb..dec7b81
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -262,10 +262,11 @@ static int __die(const char *str, struct pt_regs *regs,
long err)
{
printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
- printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
+ printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",
IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
PAGE_SIZE / 1024, get_mmu_str(),
IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
+ IS_ENABLED(CONFIG_PREEMPT_RT) ? " PREEMPT_RT" : "",
IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
Re: [PATCH] ALSA: firewire: fix comparison to bool warning
On Sat, 07 Nov 2020 17:13:31 +0100,
xiakaixu1...@gmail.com wrote:
>
> From: Kaixu Xia
>
> Fix the following coccicheck warning:
>
> ./sound/firewire/amdtp-stream.h:273:6-19: WARNING: Comparison to bool
>
> Reported-by: Tosk Robot
> Signed-off-by: Kaixu Xia
Thanks, applied.
Takashi
> ---
> sound/firewire/amdtp-stream.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/firewire/amdtp-stream.h b/sound/firewire/amdtp-stream.h
> index 2ceb57d1d58e..a3daa1f2c1c4 100644
> --- a/sound/firewire/amdtp-stream.h
> +++ b/sound/firewire/amdtp-stream.h
> @@ -270,7 +270,7 @@ static inline bool amdtp_stream_wait_callback(struct
> amdtp_stream *s,
> unsigned int timeout)
> {
> return wait_event_timeout(s->callback_wait,
> - s->callbacked == true,
> + s->callbacked,
> msecs_to_jiffies(timeout)) > 0;
> }
>
> --
> 2.20.0
>
Re: [PATCH 03/24] perf: Add build id data in mmap2 event
On Mon, Nov 09, 2020 at 10:53:54PM +0100, Jiri Olsa wrote:
> Adding support to carry build id data in mmap2 event.
>
> The build id data replaces maj/min/ino/ino_generation
> fields, whichc are also used to identify map's binary,
> so it's ok to replace them with build id data:
>
> union {
> struct {
> u32 maj;
> u32 min;
> u64 ino;
> u64 ino_generation;
> };
> struct {
> u8build_id[20];
> u8build_id_size;
What's the purpose of a size field for a fixed size array? Also, I'd
flip the order of these fields, first have the size and then the array.
> u8__reserved_1;
> u16 __reserved_2;
> };
> };
>
> Replaced maj/min/ino/ino_generation fields give us size
> of 24 bytes. We use 20 bytes for build id data, 1 byte
> for size and rest is unused.
Re: [PATCH V2] sched/rt, powerpc: Prepare for PREEMPT_RT
On Tue, Nov 10, 2020 at 04:02:47PM +0800, Wang Qing wrote: > PREEMPT_RT is a separate preemption model, CONFIG_PRTTMPT will Minor typo on this line with your config option :(
[Resend][PATCH] drm/msm: delete conversion from bool value to bool variable
Remove the conversion from bool value to bool variable.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index f7f5c258b553..e99a543da243 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1362,7 +1362,7 @@ void dpu_encoder_register_frame_event_callback(struct
drm_encoder *drm_enc,
unsigned long lock_flags;
bool enable;
- enable = frame_event_cb ? true : false;
+ enable = (frame_event_cb != NULL);
if (!drm_enc) {
DPU_ERROR("invalid encoder\n");
--
2.29.0
[Resend][PATCH] drivers/thermal: fix potential memleak in error branch
Function __thermal_cooling_device_register, when device_register
failed, cdev is not free after error value return, this may
bring in potential memleak.
Signed-off-by: Bernard Zhao
---
drivers/thermal/thermal_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 3d1e0033bf3e..e4bee15dfa1f 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1125,6 +1125,7 @@ __thermal_cooling_device_register(struct device_node *np,
if (result) {
ida_simple_remove(_cdev_ida, cdev->id);
put_device(>device);
+ kfree(cdev);
return ERR_PTR(result);
}
--
2.29.0
[Resend][PATCH] drm/msm: delete conversion from bool value to bool return
Delete the conversion from bool value to bool function return.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 8493d68ad841..411222f4cd6f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -37,7 +37,7 @@
static bool dpu_encoder_phys_cmd_is_master(struct dpu_encoder_phys *phys_enc)
{
- return (phys_enc->split_role != ENC_ROLE_SLAVE) ? true : false;
+ return (phys_enc->split_role != ENC_ROLE_SLAVE);
}
static bool dpu_encoder_phys_cmd_mode_fixup(
--
2.29.0
[Resend][PATCH] drivers/thermal: cleanup coding style a bit
Function thermal_add_hwmon_sysfs, hwmon will be NULL when new_hwmon_device = 0, so there is no need to check, kfree will handle NULL point. Signed-off-by: Bernard Zhao --- drivers/thermal/thermal_hwmon.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c index 8b92e00ff236..ad03262cca56 100644 --- a/drivers/thermal/thermal_hwmon.c +++ b/drivers/thermal/thermal_hwmon.c @@ -206,8 +206,7 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz) if (new_hwmon_device) hwmon_device_unregister(hwmon->device); free_mem: - if (new_hwmon_device) - kfree(hwmon); + kfree(hwmon); return result; } -- 2.29.0
[PATCH] f2fs-tools: skipped to end on error syntax error
When error were found, we won't need to do any initialization but
just quit.
Signed-off-by: Robin Hsu
---
fsck/main.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/fsck/main.c b/fsck/main.c
index 32559f1..e70048b 100644
--- a/fsck/main.c
+++ b/fsck/main.c
@@ -597,20 +597,22 @@ void f2fs_parse_options(int argc, char *argv[])
}
}
- add_default_options();
+ if (err == NOERROR) {
+ add_default_options();
- if (optind >= argc) {
- MSG(0, "\tError: Device not specified\n");
- error_out(prog);
- }
+ if (optind >= argc) {
+ MSG(0, "\tError: Device not specified\n");
+ error_out(prog);
+ }
- c.devices[0].path = strdup(argv[optind]);
- if (argc > (optind + 1)) {
- c.dbg_lv = 0;
- err = EUNKNOWN_ARG;
+ c.devices[0].path = strdup(argv[optind]);
+ if (argc > (optind + 1)) {
+ c.dbg_lv = 0;
+ err = EUNKNOWN_ARG;
+ }
+ if (err == NOERROR)
+ return;
}
- if (err == NOERROR)
- return;
/* print out error */
switch (err) {
--
2.29.2.222.g5d2a92d10f8-goog
Re: [PATCH] ALSA: firewire: fix comparison to bool warning
On Tue, Nov 10, 2020 at 09:06:29AM +0100, Takashi Iwai wrote:
> On Sat, 07 Nov 2020 17:13:31 +0100,
> xiakaixu1...@gmail.com wrote:
> >
> > From: Kaixu Xia
> >
> > Fix the following coccicheck warning:
> >
> > ./sound/firewire/amdtp-stream.h:273:6-19: WARNING: Comparison to bool
> >
> > Reported-by: Tosk Robot
> > Signed-off-by: Kaixu Xia
The message seems not to reach my mailbox. Anyway:
Acked-by: Takashi Sakamoto
> Thanks, applied.
>
>
> Takashi
>
> > ---
> > sound/firewire/amdtp-stream.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/sound/firewire/amdtp-stream.h b/sound/firewire/amdtp-stream.h
> > index 2ceb57d1d58e..a3daa1f2c1c4 100644
> > --- a/sound/firewire/amdtp-stream.h
> > +++ b/sound/firewire/amdtp-stream.h
> > @@ -270,7 +270,7 @@ static inline bool amdtp_stream_wait_callback(struct
> > amdtp_stream *s,
> > unsigned int timeout)
> > {
> > return wait_event_timeout(s->callback_wait,
> > - s->callbacked == true,
> > + s->callbacked,
> > msecs_to_jiffies(timeout)) > 0;
> > }
> >
> > --
> > 2.20.0
Regards
Takashi Sakamoto
Re: [PATCH] ALSA: usb-audio: disable 96khz support for HUAWEI USB-C HEADSET
On Tue, 10 Nov 2020 09:04:03 +0100, Macpaul Lin wrote: > > The HUAWEI USB-C headset (VID:0x12d1, PID:0x3a07) reported it supports > 96khz. However there will be some random issue under 96khz. > Not sure if there is any alternate setting could be applied. > Hence 48khz is suggested to be applied at this moment. > > Signed-off-by: Macpaul Lin > Signed-off-by: Eddie Hung > --- > sound/usb/format.c |5 + > 1 file changed, 5 insertions(+) > > diff --git a/sound/usb/format.c b/sound/usb/format.c > index 1b28d01..6f6e79b 100644 > --- a/sound/usb/format.c > +++ b/sound/usb/format.c > @@ -217,6 +217,11 @@ static int parse_audio_format_rates_v1(struct > snd_usb_audio *chip, struct audiof > (chip->usb_id == USB_ID(0x041e, 0x4064) || >chip->usb_id == USB_ID(0x041e, 0x4068))) > rate = 8000; > + /* Huawei headset can't support 96kHz fully */ > + if (rate == 96000 && > + chip->usb_id == USB_ID(0x12d1, 0x3a07) && > + le16_to_cpu(udev->descriptor.bcdDevice) == 0x49) This causes the compile error due to the unknown udev. Is this bcdDevice check mandatory? thanks, Takashi
Re: [PATCH] Replace a set of atomic_add()
Yejune Deng writes: > a set of atomic_inc() looks more readable > > Signed-off-by: Yejune Deng > --- > drivers/net/wireless/st/cw1200/bh.c | 10 +- > drivers/net/wireless/st/cw1200/wsm.c | 8 > 2 files changed, 9 insertions(+), 9 deletions(-) The subject prefix should be "cw1200:", but I can fix that. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v23 00/12] Landlock LSM
On 10/11/2020 07:47, James Morris wrote: > On Tue, 3 Nov 2020, Mickaël Salaün wrote: > >> Hi, >> >> Can you please consider to merge this into the tree? >> > > I've added this to my tree: > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git > landlock_lsm > > and merged into next-testing (which is pulled into linux-next). > > > Please make any further changes against the branch in my tree. Great, thanks!
Re: [PATCH] ALSA: usb-audio: disable 96khz support for HUAWEI USB-C HEADSET
On Tue, 2020-11-10 at 09:12 +0100, Takashi Iwai wrote: > On Tue, 10 Nov 2020 09:04:03 +0100, > Macpaul Lin wrote: > > > > The HUAWEI USB-C headset (VID:0x12d1, PID:0x3a07) reported it supports > > 96khz. However there will be some random issue under 96khz. > > Not sure if there is any alternate setting could be applied. > > Hence 48khz is suggested to be applied at this moment. > > > > Signed-off-by: Macpaul Lin > > Signed-off-by: Eddie Hung > > --- > > sound/usb/format.c |5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/sound/usb/format.c b/sound/usb/format.c > > index 1b28d01..6f6e79b 100644 > > --- a/sound/usb/format.c > > +++ b/sound/usb/format.c > > @@ -217,6 +217,11 @@ static int parse_audio_format_rates_v1(struct > > snd_usb_audio *chip, struct audiof > > (chip->usb_id == USB_ID(0x041e, 0x4064) || > > chip->usb_id == USB_ID(0x041e, 0x4068))) > > rate = 8000; > > + /* Huawei headset can't support 96kHz fully */ > > + if (rate == 96000 && > > + chip->usb_id == USB_ID(0x12d1, 0x3a07) && > > + le16_to_cpu(udev->descriptor.bcdDevice) == 0x49) > > This causes the compile error due to the unknown udev. > Is this bcdDevice check mandatory? This means firmware version of the headset as far as I know.. Sorry I'll check the compile error and resend later. > > thanks, > > Takashi Thanks Macpaul Lin
[RFC PATCH 0/3] regulator: bd718x7: support voltage scaling
RFC for adding a support for typical voltage scaling connection In few occasions there has been a need to scale the voltage output from bucks on BD71837. Usually this is done when buck8 is used to power specific GPU which can utilize voltages down to 0.7V. As lowest the buck8 on BD71837 can go is 0.8V, and external connection is used to scale the voltages. The BD71837, BD71847 and BD71850 bucks can be adjusted by pulling up the feedback pin using suitable voltage/resistors. |---| | buck 8 |---+->Vout | | | |---| | || || +---+--R2+ | R1 | V FB-pull-up This will scale the voltage as follows: - Vout_o = Vo - (Vpu - Vo)*R2/R1 - Linear_step = step_orig*(R1+R2)/R1 where: Vout_o is adjusted voltage output at vsel reg value 0 Vo is original voltage output at vsel reg value 0 Vpu is the pull-up voltage V FB-pull-up in the picture R1 and R2 are resistor values. >From HW point of view this does not need to be limited to buck 8. This connection can be used to adjust output from any of the bucks on BD71837/47/50. As this seems to be a 'de-facto' way to scale the voltages on BD71837 it might be a good idea to support computing the new voltage ranges for bucks based on the V-pull-up and resistor R1/R2 values given from device-tree. This allows describing the external HW connection using DT to correctly scale the voltages. This RFC uses "rohm,feedback-pull-up-r1-ohms" and "rohm,feedback-pull-up-r2-ohms" to provide the resistor values - but these names (without the picture) might not be too descriptive. I am grateful for all suggestions as better and more descriptive names. This patch series is an RFC because this connection feels somewhat "hacky". OTOH - when hack becomes widely used, it is less of an hack and more of a standard - and occasionally supporting HW hacks using SW may benefit us all, right? :) The other thing some projects do is allowing the change of BD71837 buck8 voltages when buck8 is enabled. This however will introduce voltage spikes as buck8 was not originally designed for this. The specific HW platform must be evaluated to be able to tolerate these spikes. Thus this patch series does not support buck8 voltage changes when buck8 is enabled. I wonder if this should be allowed per some config option(?) I don't want to help people frying their boards... Opinions? Is there suggested way of allowing this type of features at own risk? Config or even Some #ifdef which is not listed in Kconfig? Device-tree property? If you have (good) suggestions I could add the optional (non default) DVS support for non DVS bucks on BD71837. Matti Vaittinen (3): dt-bindings: regulator: BD71837 support commonly used feedback connection dt-bindings: regulator: BD71847 support commonly used feedback connection regulator: bd718x7: Support external connection to scale voltages .../regulator/rohm,bd71837-regulator.yaml | 48 + .../regulator/rohm,bd71847-regulator.yaml | 49 ++ drivers/regulator/bd718x7-regulator.c | 164 +- 3 files changed, 254 insertions(+), 7 deletions(-) base-commit: 3cea11cd5e3b00d91caf0b4730194039b45c5891 -- 2.21.3 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
[RFC PATCH 1/3] dt-bindings: regulator: BD71837 support commonly used feedback connection
The BD71837 buck output voltages are in a few cases scaled using external connection which adds a pull-up to regulator feedback pin. This connection will adjust output voltage from regulator in a deterministic way. Add support for describing this HW connection so that driver can adjust voltage ranges accordingly. Signed-off-by: Matti Vaittinen --- .../regulator/rohm,bd71837-regulator.yaml | 48 +++ 1 file changed, 48 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml index f5e31196a646..1941b36cf1ef 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml @@ -105,6 +105,54 @@ patternProperties: PMIC hardware state machine. type: boolean + # Setups where regulator (especially the buck8) output voltage is scaled + # by adding external connection where some other regulator output is + # connected to feedback-pin (over suitable resistors) is getting popular + # amongst users of BD71837. (This allows for example scaling down the + # buck8 voltages to suit lover GPU voltages for projects where buck8 is + # (ab)used to supply power for GPU. + # + # So we allow describing this external connection from DT and scale the + # voltages accordingly. This is what the connection should look like: + # + # |---| + # | buck 8 |---+->Vout + # | | | + # |---| | + #|| + #|| + #+---+--R2+ + #| + #R1 + #| + #V FB-pull-up + # + # Here the buck output is sifted according to formula: + # + # Vout_o = Vo - (Vpu - Vo)*R2/R1 + # Linear_step = step_orig*(R1+R2)/R1 + # + # where: + # Vout_o is adjusted voltage output at vsel reg value 0 + # Vo is original voltage output at vsel reg value 0 + # Vpu is the pull-up voltage V FB-pull-up in the picture + # R1 and R2 are resistor values. + + rohm,fb-pull-up-microvolt: +description: + Feedback-pin has pull-up connection to adjust voltage range. This is + the used pull-up voltage before R1. + + rohm,feedback-pull-up-r1-ohms: +description: + Feedback-pin has pull-up connection to adjust voltage range. This is + the used R1 resistor. + + rohm,feedback-pull-up-r2-ohms: +description: + Feedback-pin has pull-up connection to adjust voltage range. This is + the used R2 resistor. + required: - regulator-name -- 2.21.3 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
Re: [PATCH v2] Bluetooth: btusb: Add support for 13d3:3560 MediaTek MT7615E device
Hi Chris, > The ASUS X532EQ laptop contains AzureWave AW-CB434NF WiFi/BT combo > module with an associated MT7615E BT chip using a USB ID of 13d3:3560. > > T: Bus=03 Lev=01 Prnt=01 Port=09 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 > D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=13d3 ProdID=3560 Rev= 1.00 > S: Manufacturer=MediaTek Inc. > S: Product=Wireless_Device > S: SerialNumber=0 > C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA > A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 > I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us > E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms > I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms > I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms > I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms > I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms > I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms > I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms > > Signed-off-by: Chris Chiu > --- > > v2: > - Add comment for the MT7615E BT device. > > drivers/bluetooth/btusb.c | 3 +++ > 1 file changed, 3 insertions(+) patch has been applied to bluetooth-next tree. Regards Marcel
[RFC PATCH 3/3] regulator: bd718x7: Support external connection to scale voltages
Setups where regulator (especially the buck8) output voltage is scaled
by adding external connection where some other regulator output is
connected to feedback-pin (over suitable resistors) is getting popular
amongst users of BD71837. This allows for example scaling down the
buck8 voltages to suit lover GPU voltages for projects where buck8 is
(ab)used to supply power for GPU. As a note - some setups do allow DVS
for buck8. This do produce voltage spikes and the HW must be evaluated
to be able to survive them. Thus this commit still keep the DVS disabled
for non DVS bucks by default. Let's not help you burn your proto board.
Allow describing this external connection from DT and scale the
voltages accordingly. This is what the connection should look like:
||
|buck 8 |---+->Vout
|| |
|| |
| FB pin|
| |
+---+--R2---+
|
R1
|
V FB-pull-up
Here the buck output is sifted according to formula:
Vout_o = Vo - (Vpu - Vo)*R2/R1
Linear_step = step_orig*(R1+R2)/R1
where:
Vout_o is adjusted voltage output at vsel reg value 0
Vo is original voltage output at vsel reg value 0
Vpu is the pull-up voltage V FB-pull-up in the picture
R1 and R2 are resistor values.
Bring support for specifying the Vpu, R1 and R2 from device tree and
scale voltages if they are given.
Signed-off-by: Matti Vaittinen
---
drivers/regulator/bd718x7-regulator.c | 164 --
1 file changed, 157 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/bd718x7-regulator.c
b/drivers/regulator/bd718x7-regulator.c
index 0774467994fb..e6d5d98c3cea 100644
--- a/drivers/regulator/bd718x7-regulator.c
+++ b/drivers/regulator/bd718x7-regulator.c
@@ -1323,13 +1323,142 @@ static void mark_hw_controlled(struct device *dev,
struct device_node *np,
dev_warn(dev, "Bad regulator node\n");
}
-static int get_hw_controlled_regulators(struct device *dev,
- struct bd718xx_regulator_data *reg_data,
- unsigned int num_reg_data, int *info)
+/*
+ * Setups where regulator (especially the buck8) output voltage is scaled
+ * by adding external connection where some other regulator output is connected
+ * to feedback-pin (over suitable resistors) is getting popular amongst users
+ * of BD71837. (This allows for example scaling down the buck8 voltages to suit
+ * lover GPU voltages for projects where buck8 is (ab)used to supply power
+ * for GPU. Additionally some setups do allow DVS for buck8 but as this do
+ * produce voltage spikes the HW must be evaluated to be able to survive this
+ * - hence I keep the DVS disabled for non DVS bucks by default. I don't want
+ * to help you burn your proto board)
+ *
+ * So we allow describing this external connection from DT and scale the
+ * voltages accordingly. This is what the connection should look like:
+ *
+ * ||
+ * | buck 8 |---+->Vout
+ * | | |
+ * || |
+ * | FB pin|
+ * | |
+ * +---+--R2---+
+ * |
+ * R1
+ * |
+ * V FB-pull-up
+ *
+ * Here the buck output is sifted according to formula:
+ *
+ * Vout_o = Vo - (Vpu - Vo)*R2/R1
+ * Linear_step = step_orig*(R1+R2)/R1
+ *
+ * where:
+ * Vout_o is adjusted voltage output at vsel reg value 0
+ * Vo is original voltage output at vsel reg value 0
+ * Vpu is the pull-up voltage V FB-pull-up in the picture
+ * R1 and R2 are resistor values.
+ *
+ * As a real world example for buck8 and a specific GPU:
+ * VLDO = 1.6V (used as FB-pull-up)
+ * R1 = 1000ohms
+ * R2 = 150ohms
+ * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V
+ * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV
+ */
+static int setup_feedback_loop(struct device *dev, struct device_node *np,
+ struct bd718xx_regulator_data *reg_data,
+ unsigned int num_reg_data, int fb_uv)
{
+ int i, r1, r2, ret;
+
+ /*
+* We do adjust the values in the global desc based on DT settings.
+* This may not be best approach as it can cause problems if more than
+* one PMIC is controlled from same processor. I don't see such use-case
+* for BD718x7 now - so we spare some bits.
+*
+* If this will point out to be a problem - then we can allocate new
+* bd718xx_regulator_data array at probe and just use the global
+* array as a template where we copy initial values. Then we can
+* use allocated descs for regultor registration and do IC specific
+* modifications to this copy while leaving other PMICs untouched. But
+* that means allocating new array for each PMIC - and currently I see
+* no need for that.
+*/
+
+ for (i = 0; i < num_reg_data; i++) {
+ struct
[RFC PATCH 2/3] dt-bindings: regulator: BD71847 support commonly used feedback connection
The BD71847 buck output voltages are in a few cases scaled using external connection which adds a pull-up to regulator feedback pin. This connection will adjust output voltage from regulator in a deterministic way. Add support for describing this HW connection so that driver can adjust voltage ranges accordingly. Signed-off-by: Matti Vaittinen --- .../regulator/rohm,bd71847-regulator.yaml | 49 +++ 1 file changed, 49 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml index eeac32cd15d6..a1b806373853 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml @@ -99,6 +99,55 @@ patternProperties: Enable/Disable control of this regulator must be left to the PMIC hardware state machine. type: boolean + + # Setups where regulator (especially the buck8) output voltage is scaled + # by adding external connection where some other regulator output is + # connected to feedback-pin (over suitable resistors) is getting popular + # amongst users of BD71837. (This allows for example scaling down the + # buck8 voltages to suit lover GPU voltages for projects where buck8 is + # (ab)used to supply power for GPU. + # + # So we allow describing this external connection from DT and scale the + # voltages accordingly. This is what the connection should look like: + # + # |---| + # | buck 8 |---+->Vout + # | | | + # |---| | + #|| + #|| + #+---+--R2+ + #| + #R1 + #| + #V FB-pull-up + # + # Here the buck output is sifted according to formula: + # + # Vout_o = Vo - (Vpu - Vo)*R2/R1 + # Linear_step = step_orig*(R1+R2)/R1 + # + # where: + # Vout_o is adjusted voltage output at vsel reg value 0 + # Vo is original voltage output at vsel reg value 0 + # Vpu is the pull-up voltage V FB-pull-up in the picture + # R1 and R2 are resistor values. + + rohm,fb-pull-up-microvolt: +description: + Feedback-pin has pull-up connection to adjust voltage range. This is + the used pull-up voltage before R1. + + rohm,feedback-pull-up-r1-ohms: +description: + Feedback-pin has pull-up connection to adjust voltage range. This is + the used R1 resistor. + + rohm,feedback-pull-up-r2-ohms: +description: + Feedback-pin has pull-up connection to adjust voltage range. This is + the used R2 resistor. + required: - regulator-name -- 2.21.3 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
Re: [PATCH] Bluetooth: btusb: btrtl: Add support for RTL8852A
Hi Max, > Add the support for RTL8852A BT controller on USB interface. > The necessary firmware will be submitted to linux-firmware project. > > The device info from /sys/kernel/debug/usb/devices as below. > > T: Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 10 Spd=12 MxCh= 0 > D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=0bda ProdID=c852 Rev= 0.00 > S: Manufacturer=Realtek > S: Product=Bluetooth Radio > S: SerialNumber=00e04c01 > C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA > I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms > E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms > I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms > E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms > I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms > E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms > I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms > E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms > I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms > E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms > I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms > E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms > > Signed-off-by: Max Chou > --- > drivers/bluetooth/btrtl.c | 12 > drivers/bluetooth/btusb.c | 4 > 2 files changed, 16 insertions(+) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH] ALSA: usb-audio: disable 96khz support for HUAWEI USB-C HEADSET
On Tue, 10 Nov 2020 09:17:46 +0100, Macpaul Lin wrote: > > On Tue, 2020-11-10 at 09:12 +0100, Takashi Iwai wrote: > > On Tue, 10 Nov 2020 09:04:03 +0100, > > Macpaul Lin wrote: > > > > > > The HUAWEI USB-C headset (VID:0x12d1, PID:0x3a07) reported it supports > > > 96khz. However there will be some random issue under 96khz. > > > Not sure if there is any alternate setting could be applied. > > > Hence 48khz is suggested to be applied at this moment. > > > > > > Signed-off-by: Macpaul Lin > > > Signed-off-by: Eddie Hung > > > --- > > > sound/usb/format.c |5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/sound/usb/format.c b/sound/usb/format.c > > > index 1b28d01..6f6e79b 100644 > > > --- a/sound/usb/format.c > > > +++ b/sound/usb/format.c > > > @@ -217,6 +217,11 @@ static int parse_audio_format_rates_v1(struct > > > snd_usb_audio *chip, struct audiof > > > (chip->usb_id == USB_ID(0x041e, 0x4064) || > > >chip->usb_id == USB_ID(0x041e, 0x4068))) > > > rate = 8000; > > > + /* Huawei headset can't support 96kHz fully */ > > > + if (rate == 96000 && > > > + chip->usb_id == USB_ID(0x12d1, 0x3a07) && > > > + le16_to_cpu(udev->descriptor.bcdDevice) == 0x49) > > > > This causes the compile error due to the unknown udev. > > Is this bcdDevice check mandatory? > > This means firmware version of the headset as far as I know.. OK, then it's useful. > Sorry I'll check the compile error and resend later. I guess the only needed change is to replace udev with chip->dev. thanks, Takashi > > > > > thanks, > > > > Takashi > > Thanks > Macpaul Lin >
Re: [PATCH 3/3] ARM: dts: imx50-kobo-aura: Enable eKTF2132 touchscreen
On Tue, Nov 10, 2020 at 11:12:52AM +0800, Shawn Guo wrote:
> On Fri, Nov 06, 2020 at 12:24:12PM +0100, Jonathan Neuschäfer wrote:
...
> > - /* TODO: ektf2132 touch controller at 0x15 */
> > + touchscreen@15 {
> > + reg = <0x15>;
> > + compatible = "elan,ektf2132";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_ts>;
> > + power-gpios = < 9 GPIO_ACTIVE_HIGH>;
> > + interrupts-extended = < 13 IRQ_TYPE_EDGE_FALLING>;
>
> It needs include of .
>
> DTC arch/arm/boot/dts/imx50-kobo-aura.dtb
> Error: ../arch/arm/boot/dts/imx50-kobo-aura.dts:128.36-37 syntax error
> FATAL ERROR: Unable to parse input tree
> scripts/Makefile.lib:326: recipe for target
> 'arch/arm/boot/dts/imx50-kobo-aura.dtb' failed
> make[2]: *** [arch/arm/boot/dts/imx50-kobo-aura.dtb] Error 1
Ooops, indeed.
> Patch dropped.
I'll send a version 2.
Thanks,
Jonathan Neuschäfer
signature.asc
Description: PGP signature
Re: [PATCH v3 4/4] pinctrl: amd: remove debounce filter setting in IRQ type setting
On Mon, Nov 09, 2020 at 02:52:17PM +0100, Hans de Goede wrote: Hi, On 11/6/20 12:19 AM, Coiby Xu wrote: Debounce filter setting should be independent from IRQ type setting because according to the ACPI specs, there are separate arguments for specifying debounce timeout and IRQ type in GpioIo() and GpioInt(). This will fix broken touchpads for laptops whose BIOS set the debounce timeout to a relatively large value. For example, the BIOS of Lenovo Legion-5 AMD gaming laptops including 15ARH05 (R7000) and R7000P set the debounce timeout to 124.8ms. This led to the kernel receiving only ~7 HID reports per second from the Synaptics touchpad (MSFT0001:00 06CB:7F28). Existing touchpads like [1][2] are not troubled by this bug because the debounce timeout has been set to 0 by the BIOS before enabling the debounce filter in setting IRQ type. [1] https://github.com/Syniurge/i2c-amd-mp2/issues/11#issuecomment-721331582 [2] https://forum.manjaro.org/t/random-short-touchpad-freezes/30832/28 Cc: Hans de Goede Cc: Andy Shevchenko Cc: Benjamin Tissoires Cc: sta...@vger.kernel.org Reviewed-by: Andy Shevchenko BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887190 Link: https://lore.kernel.org/linux-gpio/CAHp75VcwiGREBUJ0A06EEw-SyabqYsp%2Bdqs2DpSrhaY-2GVdAA%40mail.gmail.com/ Signed-off-by: Coiby Xu I'm not entirely sure about this patch. This is consistent with how we already stopped touching the debounce timeout setting during init, so that speaks in favor of this change. Still I'm worried a bit that this might have undesirable side effects. Now I can only confirm this patch won't affect the mentioned touchpads. I'll see if other distributions like Manjaro are willing to test it through the unstable channel. I guess this should be landed together with Andy's series to apply the debounce setting from the ACPI GPIO resources. Thank you for the reminding! You are right, Andy's patch "gpiolib: acpi: Take into account debounce settings" is needed to fix this kind of touchpad issues. Since that patch hasn't been merged, is there a way to refer to it in the commit message? Regards, Hans --- drivers/pinctrl/pinctrl-amd.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c index e9b761c2b77a..2d4acf21117c 100644 --- a/drivers/pinctrl/pinctrl-amd.c +++ b/drivers/pinctrl/pinctrl-amd.c @@ -468,7 +468,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, unsigned int type) pin_reg &= ~BIT(LEVEL_TRIG_OFF); pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); pin_reg |= ACTIVE_HIGH << ACTIVE_LEVEL_OFF; - pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF; irq_set_handler_locked(d, handle_edge_irq); break; @@ -476,7 +475,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, unsigned int type) pin_reg &= ~BIT(LEVEL_TRIG_OFF); pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); pin_reg |= ACTIVE_LOW << ACTIVE_LEVEL_OFF; - pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF; irq_set_handler_locked(d, handle_edge_irq); break; @@ -484,7 +482,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, unsigned int type) pin_reg &= ~BIT(LEVEL_TRIG_OFF); pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); pin_reg |= BOTH_EADGE << ACTIVE_LEVEL_OFF; - pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF; irq_set_handler_locked(d, handle_edge_irq); break; @@ -492,8 +489,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, unsigned int type) pin_reg |= LEVEL_TRIGGER << LEVEL_TRIG_OFF; pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); pin_reg |= ACTIVE_HIGH << ACTIVE_LEVEL_OFF; - pin_reg &= ~(DB_CNTRl_MASK << DB_CNTRL_OFF); - pin_reg |= DB_TYPE_PRESERVE_LOW_GLITCH << DB_CNTRL_OFF; irq_set_handler_locked(d, handle_level_irq); break; @@ -501,8 +496,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, unsigned int type) pin_reg |= LEVEL_TRIGGER << LEVEL_TRIG_OFF; pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); pin_reg |= ACTIVE_LOW << ACTIVE_LEVEL_OFF; - pin_reg &= ~(DB_CNTRl_MASK << DB_CNTRL_OFF); - pin_reg |= DB_TYPE_PRESERVE_HIGH_GLITCH << DB_CNTRL_OFF; irq_set_handler_locked(d, handle_level_irq); break; -- Best regards, Coiby
Re: [PATCH 03/24] perf: Add build id data in mmap2 event
On Mon, Nov 09, 2020 at 10:53:54PM +0100, Jiri Olsa wrote: > There's new misc bit for mmap2 to signal there's build > id data in it: > > #define PERF_RECORD_MISC_BUILD_ID (1 << 14) PERF_RECORD_MISC_MMAP_BUILD_ID would be consistent with the existing PERF_RECORD_MISC_MMAP_DATA naming. Also, AFAICT there's still a bunch of unused bits in misc. 012 CDEF |||- Where: 0-2 CPUMODE_MASK C PROC_MAP_PARSE_TIMEOUT D MMAP_DATA / COMM_EXEC / FORK_EXEC / SWITCH_OUT E EXACT_IP / SCHED_OUT_PREEMPT F (reserved) Maybe we should put in a comment to keep track of the hole ? Also, perhaps it is time to use F to indicate that @size is in 8 instead of 1 ? That would increase our max entry size to 512K, people seem to hit his 64K limit (insane as it is).
Re: [PATCH v3 4/4] pinctrl: amd: remove debounce filter setting in IRQ type setting
Hi, On 11/10/20 9:26 AM, Coiby Xu wrote: > On Mon, Nov 09, 2020 at 02:52:17PM +0100, Hans de Goede wrote: >> Hi, >> >> On 11/6/20 12:19 AM, Coiby Xu wrote: >>> Debounce filter setting should be independent from IRQ type setting >>> because according to the ACPI specs, there are separate arguments for >>> specifying debounce timeout and IRQ type in GpioIo() and GpioInt(). >>> >>> This will fix broken touchpads for laptops whose BIOS set the debounce >>> timeout to a relatively large value. For example, the BIOS of Lenovo >>> Legion-5 AMD gaming laptops including 15ARH05 (R7000) and R7000P set >>> the debounce timeout to 124.8ms. This led to the kernel receiving only >>> ~7 HID reports per second from the Synaptics touchpad >>> (MSFT0001:00 06CB:7F28). Existing touchpads like [1][2] are not troubled >>> by this bug because the debounce timeout has been set to 0 by the BIOS >>> before enabling the debounce filter in setting IRQ type. >>> >>> [1] https://github.com/Syniurge/i2c-amd-mp2/issues/11#issuecomment-721331582 >>> [2] https://forum.manjaro.org/t/random-short-touchpad-freezes/30832/28 >>> >>> Cc: Hans de Goede >>> Cc: Andy Shevchenko >>> Cc: Benjamin Tissoires >>> Cc: sta...@vger.kernel.org >>> Reviewed-by: Andy Shevchenko >>> BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887190 >>> Link: >>> https://lore.kernel.org/linux-gpio/CAHp75VcwiGREBUJ0A06EEw-SyabqYsp%2Bdqs2DpSrhaY-2GVdAA%40mail.gmail.com/ >>> Signed-off-by: Coiby Xu >> >> I'm not entirely sure about this patch. This is consistent with how we >> already stopped touching the debounce timeout setting during init, so >> that speaks in favor of this change. >> >> Still I'm worried a bit that this might have undesirable side effects. >> > Now I can only confirm this patch won't affect the mentioned touchpads. > I'll see if other distributions like Manjaro are willing to test it > through the unstable channel. > >> I guess this should be landed together with Andy's series to apply >> the debounce setting from the ACPI GPIO resources. > > Thank you for the reminding! You are right, Andy's patch > "gpiolib: acpi: Take into account debounce settings" is needed to > fix this kind of touchpad issues. Since that patch hasn't been > merged, is there a way to refer to it in the commit message? You can always refer to it by subject, as you did above. Regards, Hans >>> --- >>> drivers/pinctrl/pinctrl-amd.c | 7 --- >>> 1 file changed, 7 deletions(-) >>> >>> diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c >>> index e9b761c2b77a..2d4acf21117c 100644 >>> --- a/drivers/pinctrl/pinctrl-amd.c >>> +++ b/drivers/pinctrl/pinctrl-amd.c >>> @@ -468,7 +468,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, >>> unsigned int type) >>> pin_reg &= ~BIT(LEVEL_TRIG_OFF); >>> pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); >>> pin_reg |= ACTIVE_HIGH << ACTIVE_LEVEL_OFF; >>> - pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF; >>> irq_set_handler_locked(d, handle_edge_irq); >>> break; >>> >>> @@ -476,7 +475,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, >>> unsigned int type) >>> pin_reg &= ~BIT(LEVEL_TRIG_OFF); >>> pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); >>> pin_reg |= ACTIVE_LOW << ACTIVE_LEVEL_OFF; >>> - pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF; >>> irq_set_handler_locked(d, handle_edge_irq); >>> break; >>> >>> @@ -484,7 +482,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, >>> unsigned int type) >>> pin_reg &= ~BIT(LEVEL_TRIG_OFF); >>> pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); >>> pin_reg |= BOTH_EADGE << ACTIVE_LEVEL_OFF; >>> - pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF; >>> irq_set_handler_locked(d, handle_edge_irq); >>> break; >>> >>> @@ -492,8 +489,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, >>> unsigned int type) >>> pin_reg |= LEVEL_TRIGGER << LEVEL_TRIG_OFF; >>> pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); >>> pin_reg |= ACTIVE_HIGH << ACTIVE_LEVEL_OFF; >>> - pin_reg &= ~(DB_CNTRl_MASK << DB_CNTRL_OFF); >>> - pin_reg |= DB_TYPE_PRESERVE_LOW_GLITCH << DB_CNTRL_OFF; >>> irq_set_handler_locked(d, handle_level_irq); >>> break; >>> >>> @@ -501,8 +496,6 @@ static int amd_gpio_irq_set_type(struct irq_data *d, >>> unsigned int type) >>> pin_reg |= LEVEL_TRIGGER << LEVEL_TRIG_OFF; >>> pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF); >>> pin_reg |= ACTIVE_LOW << ACTIVE_LEVEL_OFF; >>> - pin_reg &= ~(DB_CNTRl_MASK << DB_CNTRL_OFF); >>> - pin_reg |= DB_TYPE_PRESERVE_HIGH_GLITCH << DB_CNTRL_OFF; >>> irq_set_handler_locked(d, handle_level_irq); >>> break; >>> >>> >> > > -- > Best regards, > Coiby >
Re: [PATCH] mtd: rawnand: ingenic: remove redundant get_device() in ingenic_ecc_get()
Hi,
Le sam. 31 oct. 2020 à 18:54, Yu Kuai a écrit :
of_find_device_by_node() already takes a reference to the device, and
ingenic_ecc_release() will drop the reference. So, the get_device() in
ingenic_ecc_get() is redundand.
Fixes: 15de8c6efd0e("mtd: rawnand: ingenic: Separate top-level and
SoC specific code")
Signed-off-by: Yu Kuai
Acked-by: Paul Cercueil
Thanks,
-Paul
---
drivers/mtd/nand/raw/ingenic/ingenic_ecc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/ingenic/ingenic_ecc.c
b/drivers/mtd/nand/raw/ingenic/ingenic_ecc.c
index 8e22cd6ec71f..efe0ffe4f1ab 100644
--- a/drivers/mtd/nand/raw/ingenic/ingenic_ecc.c
+++ b/drivers/mtd/nand/raw/ingenic/ingenic_ecc.c
@@ -71,8 +71,6 @@ static struct ingenic_ecc *ingenic_ecc_get(struct
device_node *np)
if (!pdev || !platform_get_drvdata(pdev))
return ERR_PTR(-EPROBE_DEFER);
- get_device(>dev);
-
ecc = platform_get_drvdata(pdev);
clk_prepare_enable(ecc->clk);
--
2.25.4
[PATCH] fail_function: remove a redundant mutex unlock
Fix a mutex_unlock() issue where before copy_from_user() is
not called mutex_locked.
Fixes: 4b1a29a7f542 ("error-injection: Support fault injection framework")
Reported-by: Hulk Robot
Signed-off-by: Luo Meng
---
kernel/fail_function.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/fail_function.c b/kernel/fail_function.c
index 63b349168da7..b0b1ad93fa95 100644
--- a/kernel/fail_function.c
+++ b/kernel/fail_function.c
@@ -253,7 +253,7 @@ static ssize_t fei_write(struct file *file, const char
__user *buffer,
if (copy_from_user(buf, buffer, count)) {
ret = -EFAULT;
- goto out;
+ goto out_free;
}
buf[count] = '\0';
sym = strstrip(buf);
@@ -307,8 +307,9 @@ static ssize_t fei_write(struct file *file, const char
__user *buffer,
ret = count;
}
out:
- kfree(buf);
mutex_unlock(_lock);
+out_free:
+ kfree(buf);
return ret;
}
--
2.25.4
[PATCH 0/3] Add support for frequency invariance to AMD EPYC Zen2
This series adds support for frequency invariant accounting on AMD EPYC Zen2 (aka "Rome"). The first patch by Nathan lays out the foundation by querying ACPI infrastructure for the max boost frequency of the system. Specifically, this value is available via the CPPC machinery; the previous EPYC generation, namely Zen aka "Naples", doesn't implement that and frequency invariance won't be supported. The second patch sets the estimate for freq_max to be the midpoint between max_boost and max_P, as that works slightly better in practice. A side effect of this series is to provide, with the invariant schedutil governor, a suitable baseline to evaluate a (still work-in-progress) CPPC-based cpufreq driver for the AMD platform (see https://lore.kernel.org/lkml/cover.1562781484.git.janakarajan.natara...@amd.com if/when it will resubmitted. Giovanni Gherdovich (2): x86, sched: Use midpoint of max_boost and max_P for frequency invariance on AMD EPYC x86: Print ratio freq_max/freq_base used in frequency invariance calculations Nathan Fontenot (1): x86, sched: Calculate frequency invariance for AMD systems arch/x86/include/asm/topology.h | 8 arch/x86/kernel/smpboot.c | 79 + drivers/acpi/cppc_acpi.c| 5 +++ 3 files changed, 84 insertions(+), 8 deletions(-) -- 2.26.2
[PATCH 3/3] x86: Print ratio freq_max/freq_base used in frequency invariance calculations
The value freq_max/freq_base is a fundamental component of frequency
invariance calculations. It may come from a variety of sources such as MSRs
or ACPI data, tracking it down when troubleshooting a system could be
non-trivial. It is worth saving it in the kernel logs.
# dmesg | grep 'Estimated ratio of average max'
[ 14.024036] smpboot: Estimated ratio of average max frequency by base
frequency (times 1024): 1289
Signed-off-by: Giovanni Gherdovich
---
arch/x86/kernel/smpboot.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 1e6fed437b0c..ad0647b2d7c3 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -2110,6 +2110,7 @@ static void init_freq_invariance(bool secondary, bool
cppc_ready)
if (ret) {
init_counter_refs(NULL);
static_branch_enable(_scale_freq_key);
+ pr_info("Estimated ratio of average max frequency by base
frequency (times 1024): %llu\n", arch_max_freq_ratio);
} else {
pr_debug("Couldn't determine max cpu frequency, necessary for
scale-invariant accounting.\n");
}
--
2.26.2
[PATCH 2/3] x86, sched: Use midpoint of max_boost and max_P for frequency invariance on AMD EPYC
Frequency invariant accounting calculations need the ratio freq_curr/freq_max, but freq_max is unknown as it depends on dynamic power allocation between cores: AMD EPYC CPUs implement "Core Performance Boost". Three candidates are considered to estimate this value: - maximum non-boost frequency - maximum boost frequency - the mid point between the above two Experimental data on an AMD EPYC Zen2 machine slightly favors the third option, which is applied with this patch. The analysis uses the ondemand cpufreq governor as baseline, and compares it with schedutil in a number of configurations. Using the freq_max value described above offers a moderate advantage in performance and efficiency: sugov-max (freq_max=max_boost) performs the worst on tbench: less throughput and reduced efficiency than the other invariant-schedutil options (see "Data Overview" below). Consider that tbench is generally a problematic case as no schedutil version currently is better than ondemand. sugov-P0 (freq_max=max_P) is the worst on dbench, while the other sugov's can surpass ondemand with less filesystem latency and slightly increased efficiency. 1. DATA OVERVIEW 2. DETAILED PERFORMANCE TABLES 3. POWER CONSUMPTION TABLE 1. DATA OVERVIEW sugov-noinv : non-invariant schedutil governor sugov-max : invariant schedutil, freq_max=max_boost sugov-mid : invariant schedutil, freq_max=midpoint sugov-P0: invariant schedutil, freq_max=max_P perfgov : performance governor driver : acpi_cpufreq machine : AMD EPYC 7742 (Zen2, aka "Rome"), dual socket, 128 cores / 256 threads, SATA SSD storage, 250G of memory, XFS filesystem Benchmarks are described in the next section. Tilde (~) means the value is the same as baseline. - ondemand perfgov sugov-noinv sugov-max sugov-mid sugov-P0 better if - PERFORMANCE RATIOS tbench1.00 1.44 0.90 0.87 0.93 0.93 higher dbench1.00 0.91 0.95 0.94 0.94 1.06 lower kernbench 1.00 0.93 ~ ~ ~ 0.97 lower gitsource 1.00 0.66 0.97 0.96 ~ 0.95 lower - PERFORMANCE-PER-WATT RATIOS tbench1.00 1.16 0.84 0.84 0.88 0.85 higher dbench1.00 1.03 1.02 1.02 1.02 0.93 higher kernbench 1.00 1.05 ~ ~ ~ ~ higher gitsource 1.00 1.46 1.04 1.04 ~ 1.05 higher 2. DETAILED PERFORMANCE TABLES == Benchmark : tbench4 (i.e. dbench4 over the network, actually loopback) Varying parameter : number of clients Unit : MB/sec (higher is better) 5.9.0-ondemand (BASELINE) 5.9.0-perfgov 5.9.0-sugov-noinv - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hmean 1427.19 +- 0.16% () 778.35 +- 0.10% ( 82.20%) 346.92 +- 0.14% ( -18.79%) Hmean 2853.82 +- 0.09% ()1536.23 +- 0.03% ( 79.93%) 694.36 +- 0.05% ( -18.68%) Hmean 4 1657.54 +- 0.12% ()2938.18 +- 0.12% ( 77.26%) 1362.81 +- 0.11% ( -17.78%) Hmean 8 3301.87 +- 0.06% ()5679.10 +- 0.04% ( 72.00%) 2693.35 +- 0.04% ( -18.43%) Hmean 16 6139.65 +- 0.05% ()9498.81 +- 0.04% ( 54.71%) 4889.97 +- 0.17% ( -20.35%) Hmean 32 11170.28 +- 0.09% () 17393.25 +- 0.08% ( 55.71%) 9104.55 +- 0.09% ( -18.49%) Hmean 64 19322.97 +- 0.17% () 31573.91 +- 0.08% ( 63.40%) 18552.52 +- 0.40% ( -3.99%) Hmean 12830383.71 +- 0.11% () 37416.91 +- 0.15% ( 23.15%) 25938.70 +- 0.41% ( -14.63%) Hmean 25631143.96 +- 0.41% () 30908.76 +- 0.88% ( -0.76%) 29754.32 +- 0.24% ( -4.46%) Hmean 51230858.49 +- 0.26% () 38524.60 +- 1.19% ( 24.84%) 42080.39 +- 0.56% ( 36.37%) Hmean 1024 39187.37 +- 0.19% () 36213.86 +- 0.26% ( -7.59%) 39555.98 +- 0.12% ( 0.94%) 5.9.0-sugov-max 5.9.0-sugov-mid 5.9.0-sugov-P0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hmean 1352.59 +- 1.03% ( -17.46%) 352.08 +- 0.75% ( -17.58%) 352.31 +- 1.48% ( -17.53%) Hmean 2697.32 +- 0.08% ( -18.33%) 700.16 +- 0.20% ( -18.00%)
[PATCH 1/3] x86, sched: Calculate frequency invariance for AMD systems
From: Nathan Fontenot
This is the first pass in creating the ability to calculate the
frequency invariance on AMD systems. This approach uses the CPPC
highest performance and nominal performance values that range from
0 - 255 instead of a high and base frquency. This is because we do
not have the ability on AMD to get a highest frequency value.
On AMD systems the highest performance and nominal performance
vaues do correspond to the highest and base frequencies for the system
so using them should produce an appropriate ratio but some tweaking
is likely necessary.
Due to CPPC being initialized later in boot than when the frequency
invariant calculation is currently made, I had to create a callback
from the CPPC init code to do the calculation after we have CPPC
data.
Signed-off-by: Nathan Fontenot
[ ggherdov...@suse.cz: cosmetic changes ]
Signed-off-by: Giovanni Gherdovich
---
arch/x86/include/asm/topology.h | 8
arch/x86/kernel/smpboot.c | 76 +
drivers/acpi/cppc_acpi.c| 5 +++
3 files changed, 81 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index f4234575f3fd..9799d4da282d 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -218,4 +218,12 @@ static inline void arch_set_max_freq_ratio(bool
turbo_disabled)
}
#endif
+#ifdef CONFIG_ACPI
+void init_freq_invariance_cppc(void);
+#else
+static inline void init_freq_invariance_cppc(void)
+{
+}
+#endif
+
#endif /* _ASM_X86_TOPOLOGY_H */
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index de776b2e6046..89016cc96948 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -82,6 +82,10 @@
#include
#include
+#ifdef CONFIG_ACPI
+#include
+#endif
+
/* representing HT siblings of each logical CPU */
DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_map);
EXPORT_PER_CPU_SYMBOL(cpu_sibling_map);
@@ -148,7 +152,7 @@ static inline void smpboot_restore_warm_reset_vector(void)
*((volatile u32 *)phys_to_virt(TRAMPOLINE_PHYS_LOW)) = 0;
}
-static void init_freq_invariance(bool secondary);
+static void init_freq_invariance(bool secondary, bool cppc_ready);
/*
* Report back to the Boot Processor during boot time or to the caller
processor
@@ -186,7 +190,7 @@ static void smp_callin(void)
*/
set_cpu_sibling_map(raw_smp_processor_id());
- init_freq_invariance(true);
+ init_freq_invariance(true, false);
/*
* Get our bogomips.
@@ -1340,7 +1344,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus)
set_sched_topology(x86_topology);
set_cpu_sibling_map(0);
- init_freq_invariance(false);
+ init_freq_invariance(false, false);
smp_sanity_check();
switch (apic_intr_mode) {
@@ -2027,7 +2031,47 @@ static bool intel_set_max_freq_ratio(void)
return true;
}
-static void init_counter_refs(void)
+#ifdef CONFIG_ACPI
+static bool amd_set_max_freq_ratio(void)
+{
+ struct cppc_perf_caps perf_caps;
+ u64 highest_perf, nominal_perf;
+ u64 perf_ratio;
+ int rc;
+
+ rc = cppc_get_perf_caps(0, _caps);
+ if (rc) {
+ pr_debug("Could not retrieve perf counters (%d)\n", rc);
+ return false;
+ }
+
+ highest_perf = perf_caps.highest_perf;
+ nominal_perf = perf_caps.nominal_perf;
+
+ if (!highest_perf || !nominal_perf) {
+ pr_debug("Could not retrieve highest or nominal performance\n");
+ return false;
+ }
+
+ perf_ratio = div_u64(highest_perf * SCHED_CAPACITY_SCALE, nominal_perf);
+ if (!perf_ratio) {
+ pr_debug("Non-zero highest/nominal perf values led to a 0
ratio\n");
+ return false;
+ }
+
+ arch_turbo_freq_ratio = perf_ratio;
+ arch_set_max_freq_ratio(false);
+
+ return true;
+}
+#else
+static bool amd_set_max_freq_ratio(void)
+{
+ return false;
+}
+#endif
+
+static void init_counter_refs(void *arg)
{
u64 aperf, mperf;
@@ -2038,7 +2082,7 @@ static void init_counter_refs(void)
this_cpu_write(arch_prev_mperf, mperf);
}
-static void init_freq_invariance(bool secondary)
+static void init_freq_invariance(bool secondary, bool cppc_ready)
{
bool ret = false;
@@ -2047,22 +2091,38 @@ static void init_freq_invariance(bool secondary)
if (secondary) {
if (static_branch_likely(_scale_freq_key)) {
- init_counter_refs();
+ init_counter_refs(NULL);
}
return;
}
if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
ret = intel_set_max_freq_ratio();
+ else if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+ if (!cppc_ready) {
+ return;
+ }
+ ret =
Re: [PATCH v2 bpf] tools: bpftool: Add missing close before bpftool net attach exit
在 2020/11/10 12:33, John Fastabend 写道:
Wang Hai wrote:
progfd is created by prog_parse_fd(), before 'bpftool net attach' exit,
it should be closed.
Fixes: 04949ccc273e ("tools: bpftool: add net attach command to attach XDP on
interface")
Signed-off-by: Wang Hai
---
v1->v2: use cleanup tag instead of repeated closes
tools/bpf/bpftool/net.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/tools/bpf/bpftool/net.c b/tools/bpf/bpftool/net.c
index 910e7bac6e9e..1ac7228167e6 100644
--- a/tools/bpf/bpftool/net.c
+++ b/tools/bpf/bpftool/net.c
@@ -578,8 +578,8 @@ static int do_attach(int argc, char **argv)
ifindex = net_parse_dev(, );
if (ifindex < 1) {
- close(progfd);
- return -EINVAL;
+ err = -EINVAL;
+ goto cleanup;
}
if (argc) {
@@ -587,8 +587,8 @@ static int do_attach(int argc, char **argv)
overwrite = true;
} else {
p_err("expected 'overwrite', got: '%s'?", *argv);
- close(progfd);
- return -EINVAL;
+ err = -EINVAL;
+ goto cleanup;
}
}
@@ -600,13 +600,15 @@ static int do_attach(int argc, char **argv)
I think now that return value depends on this err it should be 'if (err)'
otherwise we risk retunring non-zero error code from do_attach which
will cause programs to fail.
I agree with you. Thanks.
if (err < 0) {
if (err) {
p_err("interface %s attach failed: %s",
attach_type_strings[attach_type], strerror(-err));
- return err;
+ goto cleanup;
}
if (json_output)
jsonw_null(json_wtr);
- return 0;
Alternatively we could add an 'err = 0' here, but above should never
return a value >0 as far as I can see.
It's true that 'err > 0' doesn't exist currently , but adding 'err = 0'
would make the code clearer. Thanks for your advice.
+cleanup:
+ close(progfd);
+ return err;
}
static int do_detach(int argc, char **argv)
--
2.17.1
Can it be fixed like this?
--- a/tools/bpf/bpftool/net.c
+++ b/tools/bpf/bpftool/net.c
@@ -578,8 +578,8 @@ static int do_attach(int argc, char **argv)
ifindex = net_parse_dev(, );
if (ifindex < 1) {
- close(progfd);
- return -EINVAL;
+ err = -EINVAL;
+ goto cleanup;
}
if (argc) {
@@ -587,8 +587,8 @@ static int do_attach(int argc, char **argv)
overwrite = true;
} else {
p_err("expected 'overwrite', got: '%s'?", *argv);
- close(progfd);
- return -EINVAL;
+ err = -EINVAL;
+ goto cleanup;
}
}
@@ -597,16 +597,19 @@ static int do_attach(int argc, char **argv)
err = do_attach_detach_xdp(progfd, attach_type, ifindex,
overwrite);
- if (err < 0) {
+ if (err) {
p_err("interface %s attach failed: %s",
attach_type_strings[attach_type], strerror(-err));
- return err;
+ goto cleanup;
}
if (json_output)
jsonw_null(json_wtr);
- return 0;
+ ret = 0;
+cleanup:
+ close(progfd);
+ return err;
}
.
Re: [PATCH 00/19] Second step support for A100
On Tue, 10 Nov 2020 at 07:00, Frank Lee wrote: > > It seems that sending too many e-mails at one time will cause some > emails to fail to be sent out. I will try again. Hi, Instead please reduce the address list to relevant people, as pointed out by scripts/get_maintainer.pl. Don't Cc irrelevant developers unless a file is abandoned and you need to get as much audience as possible... but sunxi is not abandoned. Best regards, Krzysztof
Re: linux-next: build warning after merge of the mac80211-next tree
On Mon, 2020-11-09 at 16:43 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mac80211-next tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/driver-api/80211/cfg80211:48: include/net/cfg80211.h:1014:
> WARNING: Unexpected indentation.
> Documentation/driver-api/80211/cfg80211:48: include/net/cfg80211.h:1016:
> WARNING: Block quote ends without a blank line; unexpected unindent.
> Documentation/driver-api/80211/cfg80211:48: include/net/cfg80211.h:1019:
> WARNING: Unexpected indentation.
>
> Introduced by commit
>
> 9f0ffa418483 ("cfg80211: Add support to configure SAE PWE value to drivers")
Thanks Stephen, fixing it now.
johannes
[PATCH v2] dt-bindings: adau1977: convert text binding to yaml format
This change converts the old device-tree binding for ADAU1977 from text
format to the new yaml format.
Signed-off-by: Alexandru Ardelean
---
Changelog v1 -> v2:
* updated libraries to catch newer schema errors/warnings
* fixed examples, added i2c & spi nodes
.../bindings/sound/adi,adau1977.txt | 61
.../bindings/sound/adi,adau1977.yaml | 92 +++
2 files changed, 92 insertions(+), 61 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/adi,adau1977.txt
create mode 100644 Documentation/devicetree/bindings/sound/adi,adau1977.yaml
diff --git a/Documentation/devicetree/bindings/sound/adi,adau1977.txt
b/Documentation/devicetree/bindings/sound/adi,adau1977.txt
deleted file mode 100644
index 37f8aad01203..
--- a/Documentation/devicetree/bindings/sound/adi,adau1977.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-Analog Devices ADAU1977/ADAU1978/ADAU1979
-
-Datasheets:
-https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1977.pdf
-https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1978.pdf
-https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1979.pdf
-
-This driver supports both the I2C and SPI bus.
-
-Required properties:
- - compatible: Should contain one of the following:
- "adi,adau1977"
- "adi,adau1978"
- "adi,adau1979"
-
- - AVDD-supply: analog power supply for the device, please consult
-Documentation/devicetree/bindings/regulator/regulator.txt
-
-Optional properties:
- - reset-gpios: the reset pin for the chip, for more details consult
-Documentation/devicetree/bindings/gpio/gpio.txt
-
- - DVDD-supply: supply voltage for the digital core, please consult
-Documentation/devicetree/bindings/regulator/regulator.txt
-
-- adi,micbias: configures the voltage setting for the MICBIAS pin.
- Select 0/1/2/3/4/5/6/7/8 to specify MICBIAS voltage
- 5V/5.5V/6V/6.5V/7V/7.5V/8V/8.5V/9V
- If not specified the default value will be "7" meaning 8.5
Volts.
- This property is only valid for the ADAU1977
-
-For required properties on SPI, please consult
-Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Required properties on I2C:
-
- - reg: The i2c address. Value depends on the state of ADDR0
-and ADDR1, as wired in hardware.
-
-Examples:
-
- adau1977_spi: adau1977@0 {
- compatible = "adi,adau1977";
- spi-max-frequency = <60>;
-
- AVDD-supply = <>;
- DVDD-supply = <_digital>;
-
- adi,micbias = <3>;
- reset-gpios = < 10 GPIO_ACTIVE_LOW>;
- };
-
- adau1977_i2c: adau1977@11 {
- compatible = "adi,adau1977";
- reg = <0x11>;
-
- AVDD-supply = <>;
- DVDD-supply = <_digital>;
-
- reset-gpios = < 10 GPIO_ACTIVE_LOW>;
- };
diff --git a/Documentation/devicetree/bindings/sound/adi,adau1977.yaml
b/Documentation/devicetree/bindings/sound/adi,adau1977.yaml
new file mode 100644
index ..b80454ad97da
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,adau1977.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/adi,adau1977.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADAU1977/ADAU1978/ADAU1979 Quad ADC with Diagnostics
+
+maintainers:
+ - Lars-Peter Clausen
+ - Bogdan Togorean
+
+description: |
+ Analog Devices ADAU1977 and similar quad ADC with Diagnostics
+
https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1977.pdf
+
https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1978.pdf
+
https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1979.pdf
+
+properties:
+ compatible:
+enum:
+ - adi,adau1977
+ - adi,adau1978
+ - adi,adau1979
+
+ reg:
+maxItems: 1
+
+ "#sound-dai-cells":
+const: 0
+
+ reset-gpios:
+maxItems: 1
+
+ spi-max-frequency: true
+
+ AVDD-supply:
+description: Analog power support for the device.
+
+ DVDD-supply:
+description: Supply voltage for digital core.
+
+ adi,micbias:
+description: |
+ Configures the voltage setting for the MICBIAS pin.
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [0, 1, 2, 3, 4, 5, 6, 7, 8]
+default: 7
+
+required:
+ - reg
+ - compatible
+ - AVDD-supply
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+adau1977_spi: adau1977@0 {
+compatible = "adi,adau1977";
+reg = <0>;
+spi-max-frequency = <60>;
+
+AVDD-supply = <>;
+DVDD-supply = <_digital>;
+
+reset-gpios
[PATCH v2] ALSA: usb-audio: disable 96khz support for HUAWEI USB-C HEADSET
The HUAWEI USB-C headset (VID:0x12d1, PID:0x3a07) reported it supports
96khz. However there will be some random issue under 96khz.
Not sure if there is any alternate setting could be applied.
Hence 48khz is suggested to be applied at this moment.
Signed-off-by: Macpaul Lin
Signed-off-by: Eddie Hung
Cc: sta...@vger.kernel.org
---
Changes for v2:
- Fix build error.
- Add Cc: sta...@vger.kernel.org
sound/usb/format.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/sound/usb/format.c b/sound/usb/format.c
index 1b28d01..7a4837b 100644
--- a/sound/usb/format.c
+++ b/sound/usb/format.c
@@ -202,6 +202,7 @@ static int parse_audio_format_rates_v1(struct snd_usb_audio
*chip, struct audiof
fp->rate_min = fp->rate_max = 0;
for (r = 0, idx = offset + 1; r < nr_rates; r++, idx += 3) {
unsigned int rate = combine_triple([idx]);
+ struct usb_device *udev = chip->dev;
if (!rate)
continue;
/* C-Media CM6501 mislabels its 96 kHz altsetting */
@@ -217,6 +218,11 @@ static int parse_audio_format_rates_v1(struct
snd_usb_audio *chip, struct audiof
(chip->usb_id == USB_ID(0x041e, 0x4064) ||
chip->usb_id == USB_ID(0x041e, 0x4068)))
rate = 8000;
+ /* Huawei headset can't support 96kHz fully */
+ if (rate == 96000 &&
+ chip->usb_id == USB_ID(0x12d1, 0x3a07) &&
+ le16_to_cpu(udev->descriptor.bcdDevice) == 0x49)
+ continue;
fp->rate_table[fp->nr_rates] = rate;
if (!fp->rate_min || rate < fp->rate_min)
--
1.7.9.5
Re: [PATCH v2 1/3] powerpc/64s: Replace RFI by RFI_TO_KERNEL and remove RFI
Excerpts from Christophe Leroy's message of November 9, 2020 2:57 am: > In head_64.S, we have two places using RFI to return to > kernel. Use RFI_TO_KERNEL instead. > > They are the two only places using RFI on book3s/64, so > the RFI macro can go away. Looks good to me. Acked-by: Nicholas Piggin > > Signed-off-by: Christophe Leroy > --- > arch/powerpc/include/asm/ppc_asm.h | 1 - > arch/powerpc/kernel/head_64.S | 9 +++-- > 2 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/arch/powerpc/include/asm/ppc_asm.h > b/arch/powerpc/include/asm/ppc_asm.h > index 511786f0e40d..bedf3eb52ebc 100644 > --- a/arch/powerpc/include/asm/ppc_asm.h > +++ b/arch/powerpc/include/asm/ppc_asm.h > @@ -495,7 +495,6 @@ END_FTR_SECTION_NESTED(CPU_FTR_CELL_TB_BUG, > CPU_FTR_CELL_TB_BUG, 96) > #endif > > #ifdef CONFIG_PPC_BOOK3S_64 > -#define RFI rfid > #define MTMSRD(r)mtmsrd r > #define MTMSR_EERI(reg) mtmsrd reg,1 > #else > diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S > index 1510b2a56669..ecf9a88988ff 100644 > --- a/arch/powerpc/kernel/head_64.S > +++ b/arch/powerpc/kernel/head_64.S > @@ -41,6 +41,11 @@ > #include > #include > #include > +#ifdef CONFIG_PPC_BOOK3S > +#include > +#else > +#include > +#endif > > /* The physical memory is laid out such that the secondary processor > * spin code sits at 0x...0x00ff. On server, the vectors follow > @@ -829,7 +834,7 @@ __secondary_start: > > mtspr SPRN_SRR0,r3 > mtspr SPRN_SRR1,r4 > - RFI > + RFI_TO_KERNEL > b . /* prevent speculative execution */ > > /* > @@ -966,7 +971,7 @@ start_here_multiplatform: > ld r4,PACAKMSR(r13) > mtspr SPRN_SRR0,r3 > mtspr SPRN_SRR1,r4 > - RFI > + RFI_TO_KERNEL > b . /* prevent speculative execution */ > > /* This is where all platforms converge execution */ > -- > 2.25.0 > >
Re: [PATCH] regmap: Properly free allocated name for regmap_config of syscon
On 2020-11-10 01:35, Kefeng Wang wrote: On 2020/11/10 1:23, Mark Brown wrote: On Mon, Nov 09, 2020 at 07:58:16PM +0800, Kefeng Wang wrote: syscon_config.name in of_syscon_register is allocated using kasprintf, which should be freed when it is not used after regmap_set_name, fix the following memory leak. unreferenced object 0xffe07fe8c150 (size 16): comm "swapper/0", pid 1, jiffies 4294892540 (age 68.168s) hex dump (first 16 bytes): 74 65 73 74 40 31 30 30 30 30 30 00 e0 ff ff ff test@10. backtrace: [<23d86736>] create_object+0xe8/0x348 [] kmemleak_alloc+0x20/0x2a Please think hard before including complete backtraces in upstream reports, they are very large and contain almost no useful information relative to their size so often obscure the relevant content in your message. If part of the backtrace is usefully illustrative (it often is for search engines if nothing else) then it's usually better to pull out the relevant sections. 2899872b627e "regmap: debugfs: Fix memory leak in regmap_debugfs_init" add a similar backtrack, but the address of the trace is useless, will be careful next time. @@ -601,6 +601,7 @@ static int regmap_set_name(struct regmap *map, const struct regmap_config *confi if (!name) return -ENOMEM; + kfree_const(config->name); kfree_const(map->name); map->name = name; } Why would we free the passed in name here? The name wes passed in from outside regmap in a const configuration struct, we've no idea within regmap if it was dynamically allocted or not and it seems very surprising that we'd go off and free it. The whole reason we're duplicating it in regmap_set_name() is that we don't know how long it's going to be around so we don't want to reference it after having returned to the caller. If the caller has dynamically allocated it then the caller should deal with freeing it. Yes, after check it again, this patch is wrong. Hi Marc, the regmap debugfs will duplicate a name in regmap_set_name(), and syscon_config.name won't be used in syscon, so your following patch doesn't seem to be necessary, right ? Please correct me if I'm wrong, thanks. It was certainly necessary at the time when I wrote the patch, as it was fixing some obvious memory corruption (use after free). It is very possible that the flow has been reorganised since, as the following commit hints at: commit e15d7f2b81d2e7d93115d46fa931b366c1cdebc2 Author: Suman Anna Date: Mon Jul 27 16:10:08 2020 -0500 mfd: syscon: Use a unique name with regmap_config The DT node full name is currently being used in regmap_config which in turn is used to create the regmap debugfs directories. This name however is not guaranteed to be unique and the regmap debugfs registration can fail in the cases where the syscon nodes have the same unit-address but are present in different DT node hierarchies. Replace this logic using the syscon reg resource address instead (inspired from logic used while creating platform devices) to ensure a unique name is given for each syscon. Signed-off-by: Suman Anna Reviewed-by: Arnd Bergmann Signed-off-by: Lee Jones I suggest you come up with a more complete analysis of the problem and how it came to be. M. -- Jazz is not dead. It just smells funny...
Re: [PATCH RFC PKS/PMEM 05/58] kmap: Introduce k[un]map_thread
On Mon, Nov 09 2020 at 20:59, Ira Weiny wrote: > On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote: > Also, we can convert the new memcpy_*_page() calls to kmap_local() as well. > [For now my patch just uses kmap_atomic().] > > I've not looked at all of the patches in your latest version. Have you > included converting any of the kmap() call sites? I thought you were more > focused on converting the kmap_atomic() to kmap_local()? I did not touch any of those yet, but it's a logical consequence to convert all kmap() instances which are _not_ creating a global mapping over to it. Thanks, tglx
[PATCH] rfkill: Fix use-after-free in rfkill_resume()
If a device is getting removed or reprobed during resume, use-after-free
might happen. For example, h5_btrtl_resume()[drivers/bluetooth/hci_h5.c]
schedules a work queue for device reprobing. During the reprobing, if
rfkill_set_block() in rfkill_resume() is called after the corresponding
*_unregister() and kfree() are called, there will be an use-after-free
in hci_rfkill_set_block()[net/bluetooth/hci_core.c].
BUG: KASAN: use-after-free in hci_rfkill_set_block+0x58/0xc0 [bluetooth]
...
Call trace:
dump_backtrace+0x0/0x154
show_stack+0x20/0x2c
dump_stack+0xbc/0x12c
print_address_description+0x88/0x4b0
__kasan_report+0x144/0x168
kasan_report+0x10/0x18
check_memory_region+0x19c/0x1ac
__kasan_check_write+0x18/0x24
hci_rfkill_set_block+0x58/0xc0 [bluetooth]
rfkill_set_block+0x9c/0x120
rfkill_resume+0x34/0x70
dpm_run_callback+0xf0/0x1f4
device_resume+0x210/0x22c
Fix this by checking rfkill->registered in rfkill_resume().
Since device_del() in rfkill_unregister() requires device_lock() and the
whole rfkill_resume() is also protected by the same lock in
device_resume()[drivers/base/power/main.c], we can make sure either the
rfkill->registered is false before rfkill_resume() starts or the rfkill
device won't be unregistered before rfkill_resume() returns.
Fixes: 8589086f4efd ("Bluetooth: hci_h5: Turn off RTL8723BS on suspend, reprobe
on resume")
Signed-off-by: Claire Chang
---
net/rfkill/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 971c73c7d34c..97101c55763d 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -876,6 +876,9 @@ static int rfkill_resume(struct device *dev)
rfkill->suspended = false;
+ if (!rfkill->registered)
+ return 0;
+
if (!rfkill->persistent) {
cur = !!(rfkill->state & RFKILL_BLOCK_SW);
rfkill_set_block(rfkill, cur);
--
2.29.2.222.g5d2a92d10f8-goog
Re: [PATCH v2] ALSA: usb-audio: disable 96khz support for HUAWEI USB-C HEADSET
On Tue, Nov 10, 2020 at 04:42:54PM +0800, Macpaul Lin wrote:
> The HUAWEI USB-C headset (VID:0x12d1, PID:0x3a07) reported it supports
> 96khz. However there will be some random issue under 96khz.
> Not sure if there is any alternate setting could be applied.
> Hence 48khz is suggested to be applied at this moment.
>
> Signed-off-by: Macpaul Lin
> Signed-off-by: Eddie Hung
> Cc: sta...@vger.kernel.org
> ---
> Changes for v2:
> - Fix build error.
> - Add Cc: sta...@vger.kernel.org
>
> sound/usb/format.c |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/sound/usb/format.c b/sound/usb/format.c
> index 1b28d01..7a4837b 100644
> --- a/sound/usb/format.c
> +++ b/sound/usb/format.c
> @@ -202,6 +202,7 @@ static int parse_audio_format_rates_v1(struct
> snd_usb_audio *chip, struct audiof
> fp->rate_min = fp->rate_max = 0;
> for (r = 0, idx = offset + 1; r < nr_rates; r++, idx += 3) {
> unsigned int rate = combine_triple([idx]);
> + struct usb_device *udev = chip->dev;
> if (!rate)
> continue;
> /* C-Media CM6501 mislabels its 96 kHz altsetting */
Did you run this patch through checkpatch.pl?
[PATCH v2 2/2] Input: ads7846: convert to one message
Convert multiple full duplex transfers in to a single transfer to reduce
CPU load.
Current driver version support following filtering modes:
- ads7846_no_filter() - not filtered
- ads7846_debounce_filter() - driver specific debounce filter
- pdata->filter - platform specific debounce filter (do any platform
provides such filter?)
Without filter this HW is not really usable, since the physic of
resistive touchscreen can provide some bounce effects. With driver internal
filter, we have constant amount of retries + debounce retries if some anomaly
was detected.
High amount of tiny SPI transfers is the primer reason of high CPU load
and interrupt frequency.
This patch create one SPI transfer with all fields and not optional retires. If
bounce anomaly was detected, we will make more transfer if needed.
Without this patch, we will get about 10% CPU load on iMX6S on pen-down event.
For example by holding stylus on the screen.
With this patch, depending in the amount of retries, the CPU load will
be 1% with "ti,debounce-rep = <3>".
One buffer transfer allows us to use PIO FIFO or DMA engine, depending
on the platform.
Signed-off-by: Oleksij Rempel
---
drivers/input/touchscreen/ads7846.c | 375 ++--
1 file changed, 193 insertions(+), 182 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c
index e9a520c9ad69..d6c6a13af4ea 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -64,23 +64,13 @@
struct ads7846_buf {
u8 cmd;
- /* This union is a temporary hack. The driver does an in-place
-* endianness conversion. This will be cleaned up in the next
-* patch.
-*/
- union {
- __be16 data_be16;
- u16 data;
- };
+ __be16 data;
} __attribute__((__packed__));
-
-struct ts_event {
- bool ignore;
- struct ads7846_buf x;
- struct ads7846_buf y;
- struct ads7846_buf z1;
- struct ads7846_buf z2;
+struct ads7846_buf_layout {
+ unsigned int offset;
+ unsigned int count;
+ unsigned int skip;
};
/*
@@ -89,12 +79,18 @@ struct ts_event {
* systems where main memory is not DMA-coherent (most non-x86 boards).
*/
struct ads7846_packet {
- struct ts_event tc;
- struct ads7846_buf read_x_cmd;
- struct ads7846_buf read_y_cmd;
- struct ads7846_buf read_z1_cmd;
- struct ads7846_buf read_z2_cmd;
+ unsigned int count;
+ unsigned int count_skip;
+ unsigned int cmds;
+ unsigned int last_cmd_idx;
+ struct ads7846_buf_layout l[5];
+ struct ads7846_buf *rx;
+ struct ads7846_buf *tx;
+
struct ads7846_buf pwrdown_cmd;
+
+ bool ignore;
+ u16 x, y, z1, z2;
};
struct ads7846 {
@@ -193,7 +189,6 @@ struct ads7846 {
#defineREAD_Y(vref)(READ_12BIT_DFR(y, 1, vref))
#defineREAD_Z1(vref) (READ_12BIT_DFR(z1, 1, vref))
#defineREAD_Z2(vref) (READ_12BIT_DFR(z2, 1, vref))
-
#defineREAD_X(vref)(READ_12BIT_DFR(x, 1, vref))
#definePWRDOWN (READ_12BIT_DFR(y, 0, 0)) /* LAST */
@@ -206,6 +201,21 @@ struct ads7846 {
#defineREF_ON (READ_12BIT_DFR(x, 1, 1))
#defineREF_OFF (READ_12BIT_DFR(y, 0, 0))
+/* Order commands in the most optimal way to reduce Vref switching and
+ * settling time:
+ * Measure: X; Vref: X+, X-; IN: Y+
+ * Measure: Y; Vref: Y+, Y-; IN: X+
+ * Measure: Z1; Vref: Y+, X-; IN: X+
+ * Measure: Z2; Vref: Y+, X-; IN: Y-
+ */
+enum ads7846_cmds {
+ ADS7846_X,
+ ADS7846_Y,
+ ADS7846_Z1,
+ ADS7846_Z2,
+ ADS7846_PWDOWN,
+};
+
static int get_pendown_state(struct ads7846 *ts)
{
if (ts->get_pendown_state)
@@ -696,26 +706,109 @@ static int ads7846_no_filter(void *ads, int data_idx,
int *val)
return ADS7846_FILTER_OK;
}
-static int ads7846_get_value(struct ads7846 *ts, struct spi_message *m)
+static int ads7846_get_value(struct ads7846_buf *buf)
{
int value;
- struct spi_transfer *t =
- list_entry(m->transfers.prev, struct spi_transfer,
transfer_list);
- struct ads7846_buf *buf = t->rx_buf;
- value = be16_to_cpup(>data_be16);
+ value = be16_to_cpup(>data);
/* enforce ADC output is 12 bits width */
return (value >> 3) & 0xfff;
}
-static void ads7846_update_value(struct spi_message *m, int val)
+static void ads7846_set_cmd_val(struct ads7846 *ts, enum ads7846_cmds cmd_idx,
+ u16 val)
+{
+ struct ads7846_packet *packet = ts->packet;
+
+ switch (cmd_idx) {
+ case ADS7846_Y:
+ packet->y = val;
+ break;
+ case ADS7846_X:
+ packet->x = val;
+ break;
+ case ADS7846_Z1:
+ packet->z1 = val;
+ break;
+ case ADS7846_Z2:
+ packet->z2 =
Re: [PATCH] x86/mce: Check for hypervisor before enabling additional error logging
On 10/11/20 07:31, Borislav Petkov wrote: + if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) + return; + Frankly, I'm tired of wagging the dog because the tail can't. If qemu/kvm can't emulate a CPU model fully then it should ignore those unknown MSR accesses by default, i.e., that "ignore_msrs" functionality should be on by default I'd say... We certainly can't be sprinkling this check everytime the kernel tries to do something as basic as read an MSR. You don't have to, also because it's wrong. Fortunately it's much simpler than that: 1) ignore_msrs _cannot_ be on by default. You cannot know in advance that for all non-architectural MSRs it's okay for them to read as zero and eat writes. For some non-architectural MSR which never reads as zero on real hardware, who knows that there isn't some code using the contents of the MSR as a divisor, and causing a division by zero exception with ignore_msrs=1? 2) it's not just KVM. _Any_ hypervisor is bound to have this issue for some non-architectural MSRs. KVM just gets the flak because Linux CI environments (for obvious reasons) use it more than they use Hyper-V or ESXi or VirtualBox. 3) because of (1) and (2), the solution is very simple. If the MSR is architectural, its absence is a KVM bug and we'll fix it in all stable versions. If the MSR is not architectural (and 17Fh isn't; not only it's not mentioned in the SDM, even Google is failing me), never ever assume that the CPUID family/model/stepping implies a given MSR is there, and just use rdmsr_safe/wrmsr_safe. So, for this patch, Nacked-by: Paolo Bonzini Paolo
Re: [PATCH] drm/ingenic: ipu: Search for scaling coefs up to 102% of the screen
Hi, Le sam. 7 nov. 2020 à 20:33, Sam Ravnborg a écrit : Hi Paul. On Thu, Nov 05, 2020 at 08:39:05AM +, Paul Cercueil wrote: Increase the scaled image's theorical width/height until we find a configuration that has valid scaling coefficients, up to 102% of the screen's resolution. This makes sure that we can scale from almost every resolution possible at the cost of a very small distorsion. The CRTC_W / CRTC_H are not modified. This algorithm was already in place but would not try to go above the screen's resolution, and as a result would only work if the CRTC_W / CRTC_H were smaller than the screen resolution. It will now try until it reaches 102% of the screen's resolution. Signed-off-by: Paul Cercueil Looks like the patch does what the descriptions says. So in other words - look OK to me. I am not confident enogh for a r-b but my code reading is enough to warrant an a-b: Acked-by: Sam Ravnborg Note that this algorithm exists mostly as a band-aid for a missing functionality: it is not possible for userspace to request the closest mode that would encapsulate the provided one, because the GEM buffer is created beforehand. If there was a way to let the kernel tweak the mode, I could write a better algorithm that would result in a better looking picture. Cheers, -Paul
[PATCH v2 1/2] Input: ads7846: convert to full duplex
Starting with following patch, the ads7845 was partially converted to
full duplex mode:
3eac5c7e44f3 Input: ads7846 - extend the driver for ads7845 controller support
Since it is not touchscreen controller specific, it is better to make
this conversion consequent for complete driver. This will reduce CPU
load and make driver more readable.
Signed-off-by: Oleksij Rempel
---
drivers/input/touchscreen/ads7846.c | 193 +---
1 file changed, 62 insertions(+), 131 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c
index 393ab337a9c4..e9a520c9ad69 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -62,19 +62,25 @@
/* this driver doesn't aim at the peak continuous sample rate */
#defineSAMPLE_BITS (8 /*cmd*/ + 16 /*sample*/ + 2 /* before, after
*/)
-struct ts_event {
- /*
-* For portability, we can't read 12 bit values using SPI (which
-* would make the controller deliver them as native byte order u16
-* with msbs zeroed). Instead, we read them as two 8-bit values,
-* *** WHICH NEED BYTESWAPPING *** and range adjustment.
+struct ads7846_buf {
+ u8 cmd;
+ /* This union is a temporary hack. The driver does an in-place
+* endianness conversion. This will be cleaned up in the next
+* patch.
*/
- u16 x;
- u16 y;
- u16 z1, z2;
- boolignore;
- u8 x_buf[3];
- u8 y_buf[3];
+ union {
+ __be16 data_be16;
+ u16 data;
+ };
+} __attribute__((__packed__));
+
+
+struct ts_event {
+ bool ignore;
+ struct ads7846_buf x;
+ struct ads7846_buf y;
+ struct ads7846_buf z1;
+ struct ads7846_buf z2;
};
/*
@@ -83,11 +89,12 @@ struct ts_event {
* systems where main memory is not DMA-coherent (most non-x86 boards).
*/
struct ads7846_packet {
- u8 read_x, read_y, read_z1, read_z2, pwrdown;
- u16 dummy; /* for the pwrdown read */
- struct ts_event tc;
- /* for ads7845 with mpc5121 psc spi we use 3-byte buffers */
- u8 read_x_cmd[3], read_y_cmd[3], pwrdown_cmd[3];
+ struct ts_event tc;
+ struct ads7846_buf read_x_cmd;
+ struct ads7846_buf read_y_cmd;
+ struct ads7846_buf read_z1_cmd;
+ struct ads7846_buf read_z2_cmd;
+ struct ads7846_buf pwrdown_cmd;
};
struct ads7846 {
@@ -694,16 +701,9 @@ static int ads7846_get_value(struct ads7846 *ts, struct
spi_message *m)
int value;
struct spi_transfer *t =
list_entry(m->transfers.prev, struct spi_transfer,
transfer_list);
+ struct ads7846_buf *buf = t->rx_buf;
- if (ts->model == 7845) {
- value = be16_to_cpup((__be16 *)&(((char *)t->rx_buf)[1]));
- } else {
- /*
-* adjust: on-wire is a must-ignore bit, a BE12 value, then
-* padding; built from two 8 bit values written msb-first.
-*/
- value = be16_to_cpup((__be16 *)t->rx_buf);
- }
+ value = be16_to_cpup(>data_be16);
/* enforce ADC output is 12 bits width */
return (value >> 3) & 0xfff;
@@ -713,8 +713,9 @@ static void ads7846_update_value(struct spi_message *m, int
val)
{
struct spi_transfer *t =
list_entry(m->transfers.prev, struct spi_transfer,
transfer_list);
+ struct ads7846_buf *buf = t->rx_buf;
- *(u16 *)t->rx_buf = val;
+ buf->data = val;
}
static void ads7846_read_state(struct ads7846 *ts)
@@ -782,16 +783,14 @@ static void ads7846_report_state(struct ads7846 *ts)
* from on-the-wire format as part of debouncing to get stable
* readings.
*/
+ x = packet->tc.x.data;
+ y = packet->tc.y.data;
if (ts->model == 7845) {
- x = *(u16 *)packet->tc.x_buf;
- y = *(u16 *)packet->tc.y_buf;
z1 = 0;
z2 = 0;
} else {
- x = packet->tc.x;
- y = packet->tc.y;
- z1 = packet->tc.z1;
- z2 = packet->tc.z2;
+ z1 = packet->tc.z1.data;
+ z2 = packet->tc.z2.data;
}
/* range filtering */
@@ -1008,26 +1007,11 @@ static void ads7846_setup_spi_msg(struct ads7846 *ts,
spi_message_init(m);
m->context = ts;
- if (ts->model == 7845) {
- packet->read_y_cmd[0] = READ_Y(vref);
- packet->read_y_cmd[1] = 0;
- packet->read_y_cmd[2] = 0;
- x->tx_buf = >read_y_cmd[0];
- x->rx_buf = >tc.y_buf[0];
- x->len = 3;
- spi_message_add_tail(x, m);
- } else {
- /* y- still on; turn on only y+ (and ADC) */
-
Re: [PATCH 00/19] Second step support for A100
On Tue, Nov 10, 2020 at 4:43 PM Krzysztof Kozlowski wrote: > > On Tue, 10 Nov 2020 at 07:00, Frank Lee wrote: > > > > It seems that sending too many e-mails at one time will cause some > > emails to fail to be sent out. I will try again. > > Hi, > > Instead please reduce the address list to relevant people, as pointed > out by scripts/get_maintainer.pl. Don't Cc irrelevant developers > unless a file is abandoned and you need to get as much audience as > possible... but sunxi is not abandoned. Thank you for the reminder. I resend the version in the afternoon, only CC the relevant people. I'm not sure. Should the cover be copied to everyone? Yangtao
[PATCH v1 0/2] Input: ads7846: reduce SPI related CPU load
changes v2: - add back settle_delay_usecs support - execute power down on the end of the main transfer. - make it work with 2.5MHz SPI clock This series is optimizing SPI transfer related CPU load. Oleksij Rempel (2): Input: ads7846: convert to full duplex Input: ads7846: convert to one message drivers/input/touchscreen/ads7846.c | 456 1 file changed, 199 insertions(+), 257 deletions(-) -- 2.28.0
Re: [PATCH] Replace a set of atomic_add()
Yejune Deng writes: > Oh，I was forgetting. thanks. And you should also disable HTML in your emails :) See the wiki link below for more. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH V3] sched/rt, powerpc: Prepare for PREEMPT_RT
PREEMPT_RT is a separate preemption model, CONFIG_PREEMPT will
be disabled when CONFIG_PREEMPT_RT is enabled, so we need
to add CONFIG_PREEMPT_RT output to __die().
Signed-off-by: Wang Qing
Changes in v3:
- Fix typo issue.
Changes in v2:
- Modify as Christophe suggested.
---
arch/powerpc/kernel/traps.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 5006dcb..dec7b81
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -262,10 +262,11 @@ static int __die(const char *str, struct pt_regs *regs,
long err)
{
printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
- printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
+ printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",
IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
PAGE_SIZE / 1024, get_mmu_str(),
IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
+ IS_ENABLED(CONFIG_PREEMPT_RT) ? " PREEMPT_RT" : "",
IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
--
2.7.4
Re: [PATCH v2] ALSA: usb-audio: disable 96khz support for HUAWEI USB-C HEADSET
On Tue, 2020-11-10 at 09:50 +0100, Greg KH wrote:
> On Tue, Nov 10, 2020 at 04:42:54PM +0800, Macpaul Lin wrote:
> > The HUAWEI USB-C headset (VID:0x12d1, PID:0x3a07) reported it supports
> > 96khz. However there will be some random issue under 96khz.
> > Not sure if there is any alternate setting could be applied.
> > Hence 48khz is suggested to be applied at this moment.
> >
> > Signed-off-by: Macpaul Lin
> > Signed-off-by: Eddie Hung
> > Cc: sta...@vger.kernel.org
> > ---
> > Changes for v2:
> > - Fix build error.
> > - Add Cc: sta...@vger.kernel.org
> >
> > sound/usb/format.c |6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/sound/usb/format.c b/sound/usb/format.c
> > index 1b28d01..7a4837b 100644
> > --- a/sound/usb/format.c
> > +++ b/sound/usb/format.c
> > @@ -202,6 +202,7 @@ static int parse_audio_format_rates_v1(struct
> > snd_usb_audio *chip, struct audiof
> > fp->rate_min = fp->rate_max = 0;
> > for (r = 0, idx = offset + 1; r < nr_rates; r++, idx += 3) {
> > unsigned int rate = combine_triple([idx]);
> > + struct usb_device *udev = chip->dev;
> > if (!rate)
> > continue;
> > /* C-Media CM6501 mislabels its 96 kHz altsetting */
>
> Did you run this patch through checkpatch.pl?
>
I've ran checkpatch for this patch v2, and it shown
"total: 0 errors, 0 warnings". We're using 5.9-rc1 internal.
However, I'll send patch v3 according to Takashi's suggestion.
Thanks
Macpaul Lin
Re: [PATCH RESEND 0/2] Add dmaengine bindings for the JZ4775 and the X2000 SoCs.
Hi Zhou, Le sam. 7 nov. 2020 à 20:20, 周琰杰 (Zhou Yanjie) a écrit : Add the dmaengine bindings for the JZ4775 SoC and the X2000 SoC from Ingenic. 周琰杰 (Zhou Yanjie) (2): dt-bindings: dmaengine: Add JZ4775 bindings. dt-bindings: dmaengine: Add X2000 bindings. include/dt-bindings/dma/jz4775-dma.h | 44 + include/dt-bindings/dma/x2000-dma.h | 54 If that's up to me, these macros aren't really needed, and you can put the values directly in the dma cells. This is done already in jz4740.dtsi, jz4725b.dtsi and jz4770.dtsi. Cheers, -Paul 2 files changed, 98 insertions(+) create mode 100644 include/dt-bindings/dma/jz4775-dma.h create mode 100644 include/dt-bindings/dma/x2000-dma.h -- 2.11.0
Re: [PATCH] drm/ingenic: ipu: Search for scaling coefs up to 102% of?? the screen
Hi Paul, On Tue, Nov 10, 2020 at 08:50:22AM +, Paul Cercueil wrote: > Hi, > > Le sam. 7 nov. 2020 à 20:33, Sam Ravnborg a écrit : > > Hi Paul. > > > > On Thu, Nov 05, 2020 at 08:39:05AM +, Paul Cercueil wrote: > > > Increase the scaled image's theorical width/height until we find a > > > configuration that has valid scaling coefficients, up to 102% of the > > > screen's resolution. This makes sure that we can scale from almost > > > every resolution possible at the cost of a very small distorsion. > > > The CRTC_W / CRTC_H are not modified. > > > > > > This algorithm was already in place but would not try to go above > > > the > > > screen's resolution, and as a result would only work if the CRTC_W / > > > CRTC_H were smaller than the screen resolution. It will now try > > > until it > > > reaches 102% of the screen's resolution. > > > > > > Signed-off-by: Paul Cercueil > > > > Looks like the patch does what the descriptions says. > > So in other words - look OK to me. I am not confident enogh for a r-b > > but my code reading is enough to warrant an a-b: > > Acked-by: Sam Ravnborg > > Note that this algorithm exists mostly as a band-aid for a missing > functionality: it is not possible for userspace to request the closest mode > that would encapsulate the provided one, because the GEM buffer is created > beforehand. If there was a way to let the kernel tweak the mode, I could > write a better algorithm that would result in a better looking picture. Could you add this nice explanation to the changelog so when we wonder why this was done in some years we can dig up this from git history. Sam
Re: [PATCH v3 19/35] x86/io_apic: Cleanup trigger/polarity helpers
On Tue, 2020-11-10 at 01:31 -0500, Qian Cai wrote:
> On Sat, 2020-10-24 at 22:35 +0100, David Woodhouse wrote:
> > From: Thomas Gleixner
> >
> > 'trigger' and 'polarity' are used throughout the I/O-APIC code for handling
> > the trigger type (edge/level) and the active low/high configuration. While
> > there are defines for initializing these variables and struct members, they
> > are not used consequently and the meaning of 'trigger' and 'polarity' is
> > opaque and confusing at best.
> >
> > Rename them to 'is_level' and 'active_low' and make them boolean in various
> > structs so it's entirely clear what the meaning is.
> >
> > Signed-off-by: Thomas Gleixner
> > Signed-off-by: David Woodhouse
> > ---
> > arch/x86/include/asm/hw_irq.h | 6 +-
> > arch/x86/kernel/apic/io_apic.c | 244 +---
> > arch/x86/pci/intel_mid_pci.c| 8 +-
> > drivers/iommu/amd/iommu.c | 10 +-
> > drivers/iommu/intel/irq_remapping.c | 9 +-
> > 5 files changed, 130 insertions(+), 147 deletions(-)
>
> Reverting the rest of patchset up to this commit on next-20201109 fixed an
> endless soft-lockups issue booting an AMD server below. I noticed that the
> failed boots always has this IOMMU IO_PAGE_FAULT before those soft-lockups:
Hm, attempting to reproduce this shows something else. Ever since
commit be62dbf554c5 ("iommu/amd: Convert AMD iommu driver to the dma-
iommu api") in 5.5 the following stops working for me:
$ qemu-system-x86_64 -serial mon:stdio -kernel bzImage -machine
q35,accel=kvm,kernel-irqchip=split -m 2G -device amd-iommu,intremap=off -append
"console=ttyS0 apic=verbose debug" -display none
It hasn't got a hard drive but I can watch the SATA interrupts fail as
it probes the CD-ROM:
[7.403327] ata3.00: qc timeout (cmd 0xa1)
[7.405980] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Adding 'iommu=off' to the kernel command line makes it work again, in
that it correctly panics at the lack of a root file system, quickly.
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] drm/ingenic: ipu: Search for scaling coefs up to 102% of?? the screen
Le mar. 10 nov. 2020 à 9:56, Sam Ravnborg a écrit : Hi Paul, On Tue, Nov 10, 2020 at 08:50:22AM +, Paul Cercueil wrote: Hi, Le sam. 7 nov. 2020 à 20:33, Sam Ravnborg a écrit : > Hi Paul. > > On Thu, Nov 05, 2020 at 08:39:05AM +, Paul Cercueil wrote: > > Increase the scaled image's theorical width/height until we find a > > configuration that has valid scaling coefficients, up to 102% of the > > screen's resolution. This makes sure that we can scale from almost > > every resolution possible at the cost of a very small distorsion. > > The CRTC_W / CRTC_H are not modified. > > > > This algorithm was already in place but would not try to go above > > the > > screen's resolution, and as a result would only work if the CRTC_W / > > CRTC_H were smaller than the screen resolution. It will now try > > until it > > reaches 102% of the screen's resolution. > > > > Signed-off-by: Paul Cercueil > > Looks like the patch does what the descriptions says. > So in other words - look OK to me. I am not confident enogh for a r-b > but my code reading is enough to warrant an a-b: > Acked-by: Sam Ravnborg Note that this algorithm exists mostly as a band-aid for a missing functionality: it is not possible for userspace to request the closest mode that would encapsulate the provided one, because the GEM buffer is created beforehand. If there was a way to let the kernel tweak the mode, I could write a better algorithm that would result in a better looking picture. Could you add this nice explanation to the changelog so when we wonder why this was done in some years we can dig up this from git history. Sure! -Paul
[PATCH] drm/fb_helper: Use min_t() to handle size_t and unsigned long
On arm32:
drivers/gpu/drm/drm_fb_helper.c: In function ‘fb_read_screen_base’:
include/linux/minmax.h:18:28: warning: comparison of distinct pointer types
lacks a cast
...
drivers/gpu/drm/drm_fb_helper.c:2041:22: note: in expansion of macro ‘min’
2041 | size_t alloc_size = min(count, PAGE_SIZE);
| ^~~
drivers/gpu/drm/drm_fb_helper.c: In function ‘fb_write_screen_base’:
include/linux/minmax.h:18:28: warning: comparison of distinct pointer types
lacks a cast
...
drivers/gpu/drm/drm_fb_helper.c:2115:22: note: in expansion of macro ‘min’
2115 | size_t alloc_size = min(count, PAGE_SIZE);
| ^~~
Indeed, on 32-bit size_t is "unsigned int", not "unsigned long".
Fixes: 222ec45f4c69dfa8 ("drm/fb_helper: Support framebuffers in I/O memory")
Signed-off-by: Geert Uytterhoeven
---
Interestingly, the commit log claims v7 changed:
use min_t(size_t,) (kernel test robot)
---
drivers/gpu/drm/drm_fb_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 01ba1da285116373..25edf670867c6f79 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2038,7 +2038,7 @@ static ssize_t fb_read_screen_base(struct fb_info *info,
char __user *buf, size_
loff_t pos)
{
const char __iomem *src = info->screen_base + pos;
- size_t alloc_size = min(count, PAGE_SIZE);
+ size_t alloc_size = min_t(size_t, count, PAGE_SIZE);
ssize_t ret = 0;
int err = 0;
char *tmp;
@@ -2112,7 +2112,7 @@ static ssize_t fb_write_screen_base(struct fb_info *info,
const char __user *buf
loff_t pos)
{
char __iomem *dst = info->screen_base + pos;
- size_t alloc_size = min(count, PAGE_SIZE);
+ size_t alloc_size = min_t(size_t, count, PAGE_SIZE);
ssize_t ret = 0;
int err = 0;
u8 *tmp;
--
2.25.1
Re: [PATCH v5 1/4] HID: i2c-hid: Reorganize so ACPI and OF are separate modules
Hi,
On 11/9/20 10:36 PM, Douglas Anderson wrote:
> This patch rejiggers the i2c-hid code so that the OF (Open Firmware
> aka Device Tree) and ACPI support is separated out a bit. The OF and
> ACPI drivers are now separate modules that wrap the core module.
>
> Essentially, what we're doing here:
> * Make "power up" and "power down" a function that can be (optionally)
> implemented by a given user of the i2c-hid core.
> * The OF and ACPI modules are drivers on their own, so they implement
> probe / remove / suspend / resume / shutdown. The core code
> provides implementations that OF and ACPI can call into.
>
> We'll organize this so that we now have 3 modules: the old i2c-hid
> module becomes the "core" module and two new modules will depend on
> it, handling probing the specific device.
>
> As part of this work, we'll remove the i2c-hid "platform data"
> concept since it's not needed.
>
> Signed-off-by: Douglas Anderson
> ---
>
> Changes in v5:
> - Add shutdown_tail op and use it in ACPI.
> - i2chid_subclass_data => i2chid_ops.
> - power_up_device => power_up (same with power_down).
> - subclass => ops.
>
Thanks this looks good to now, 2 small remarks below (since you are
going to do a v6 anyways). Feel free to ignore these remarks if
you prefer to keep things as is.
And feel free to add my reviewed-by to v6 of this patch:
Reviewed-by: Hans de Goede
> diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c
> b/drivers/hid/i2c-hid/i2c-hid-acpi.c
> new file mode 100644
> index ..5f09635d00ce
> --- /dev/null
> +++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
> @@ -0,0 +1,170 @@
> +static const struct i2c_device_id i2c_hid_acpi_id_table[] = {
> + { "hid", 0 },
> + { "hid-over-i2c", 0 },
> + { },
> +};
> +MODULE_DEVICE_TABLE(i2c, i2c_hid_acpi_id_table);
Hmm, I do not think these old-style i2c-ids are necessarry at
all in this driver. I expect all use-cases to use either
of or acpi matches.
This was already present in the code before though, so
please ignore this remark. This is just something which
I noticed and thought was worth while pointing out as
a future cleanup.
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
> b/drivers/hid/i2c-hid/i2c-hid-core.c
> index aeff1ffb0c8b..9551ba96dc49 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -35,12 +35,8 @@
> #include
> #include
> #include
> -#include
> -#include
> #include
I think you can drop this regulator include here now too ?
> diff --git a/drivers/hid/i2c-hid/i2c-hid-of.c
> b/drivers/hid/i2c-hid/i2c-hid-of.c
> new file mode 100644
> index ..15d533be2b24
> --- /dev/null
> +++ b/drivers/hid/i2c-hid/i2c-hid-of.c
> +static const struct dev_pm_ops i2c_hid_of_pm = {
> + SET_SYSTEM_SLEEP_PM_OPS(i2c_hid_core_suspend, i2c_hid_core_resume)
> +};
This dev_pm_ops struct is identical to the one in i2c-hid-acpi.c
and the one which you introduce later in i2c-hid-of-goodix.c
is also identical, so that is 3 copies.
Maybe just put a shared dev_pm_ops struct in the i2c-core
(and don't export the suspend/resume handlers) ?
Regards,
Hans
Re: [PATCH 15/20] drm/radeon/r600d: Move 'rc600_*' prototypes into shared header
Hi Lee, > > the *d.h headers are supposed to just be hardware definitions. I'd > > prefer to keep driver stuff out of them. > > That's fine (I did wonder if that were the case). > > I need an answer from you and Sam whether I can create new headers. > > For me, it is the right thing to do. Please follow the advice of Alex for the radeon driver. Sam
Re: [PATCH AUTOSEL 5.9 53/55] seq_file: add seq_read_iter
Should not be needed in stable in any form.
Re: [PATCH v2 01/10] usb: cdns3: Add support for DRD CDNSP
On 20-11-06 12:42:51, Pawel Laszczak wrote:
> - * Value of the strap pins.
> + * Value of the strap pins for:
> + * CDN3:
%/CDN3/CDNS3
Peter
> * 000 - no default configuration
> * 010 - Controller initiall configured as Host
> * 100 - Controller initially configured as Device
> + * CDNSP:
> + * 000 - No default configuration.
> + * 010 - Controller initiall configured as Host.
> + * 100 - Controller initially configured as Device.
> */
> #define OTGSTS_STRAP(p) (((p) & GENMASK(14, 12)) >> 12)
> #define OTGSTS_STRAP_NO_DEFAULT_CFG 0x00
> #define OTGSTS_STRAP_HOST_OTG0x01
> #define OTGSTS_STRAP_HOST0x02
> #define OTGSTS_STRAP_GADGET 0x04
> +#define OTGSTS_CDNSP_STRAP_HOST 0x01
> +#define OTGSTS_CDNSP_STRAP_GADGET0x02
> +
> /* Host mode is turned on. */
> -#define OTGSTS_XHCI_READYBIT(26)
> +#define OTGSTS_CDNS3_XHCI_READY BIT(26)
> +#define OTGSTS_CDNSP_XHCI_READY BIT(27)
> +
> /* "Device mode is turned on .*/
> -#define OTGSTS_DEV_READY BIT(27)
> +#define OTGSTS_CDNS3_DEV_READY BIT(27)
> +#define OTGSTS_CDNSP_DEV_READY BIT(26)
>
> /* OTGSTATE- bitmasks */
> #define OTGSTATE_DEV_STATE_MASK GENMASK(2, 0)
> @@ -152,6 +194,8 @@ struct cdns3_otg_common_regs {
> #define OVERRIDE_IDPULLUPBIT(0)
> /* Only for CDNS3_CONTROLLER_V0 version */
> #define OVERRIDE_IDPULLUP_V0 BIT(24)
> +/* Vbusvalid/Sesvalid override select. */
> +#define OVERRIDE_SESS_VLD_SELBIT(10)
>
> /* PHYRST_CFG - bitmasks */
> #define PHYRST_CFG_PHYRST_A_ENABLE BIT(0)
> @@ -170,6 +214,5 @@ int cdns3_drd_gadget_on(struct cdns3 *cdns);
> void cdns3_drd_gadget_off(struct cdns3 *cdns);
> int cdns3_drd_host_on(struct cdns3 *cdns);
> void cdns3_drd_host_off(struct cdns3 *cdns);
> -int cdns3_set_mode(struct cdns3 *cdns, enum usb_dr_mode mode);
>
> #endif /* __LINUX_CDNS3_DRD */
> --
> 2.17.1
>
--
Thanks,
Peter Chen
[PATCH v3] ALSA: usb-audio: disable 96khz support for HUAWEI USB-C HEADSET
The HUAWEI USB-C headset (VID:0x12d1, PID:0x3a07) reported it supports 96khz. However there will be some random issue under 96khz. Not sure if there is any alternate setting could be applied. Hence 48khz is suggested to be applied at this moment. Signed-off-by: Macpaul Lin Signed-off-by: Eddie Hung Cc: sta...@vger.kernel.org --- Changes for v2: - Fix build error. - Add Cc: sta...@vger.kernel.org Changes for v3: - Replace "udev" with "chip->dev" according to Takashi's suggestion. Thanks. sound/usb/format.c |5 + 1 file changed, 5 insertions(+) diff --git a/sound/usb/format.c b/sound/usb/format.c index 1b28d01..0aff774 100644 --- a/sound/usb/format.c +++ b/sound/usb/format.c @@ -217,6 +217,11 @@ static int parse_audio_format_rates_v1(struct snd_usb_audio *chip, struct audiof (chip->usb_id == USB_ID(0x041e, 0x4064) || chip->usb_id == USB_ID(0x041e, 0x4068))) rate = 8000; + /* Huawei headset can't support 96kHz fully */ + if (rate == 96000 && + chip->usb_id == USB_ID(0x12d1, 0x3a07) && + le16_to_cpu(chip->dev->descriptor.bcdDevice) == 0x49) + continue; fp->rate_table[fp->nr_rates] = rate; if (!fp->rate_min || rate < fp->rate_min) -- 1.7.9.5
[PATCH] scsi: ufs: Fix a bug in ufshcd_system_resume()
During system resume, ufshcd_system_resume() won't resume UFS host if
runtime suspended. After that, scsi_bus_resume() try to set SCSI host's
RPM status to RPM_ACTIVE, this will fail because UFS host's RPM status
is still RPM_SUSPENDED. So fix it.
scsi host0: scsi_runtime_suspend()
ufshcd_runtime_suspend()
scsi host0: scsi_bus_suspend()
ufshcd_system_suspend()
--
ufshcd_pltfrm_resume()
scsi host0: scsi_bus_resume()
scsi host0: scsi_bus_resume_common()
scsi host0: pm_runtime_set_active(dev)
scsi host0: runtime PM trying to activate child device host0 but parent
(880.ufshc) is not active
Fixes: 57d104c153d3 ("ufs: add UFS power management support")
Signed-off-by: Yang Yang
---
drivers/scsi/ufs/ufshcd.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index b8f573a02713..9e666e1ad58c 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8767,11 +8767,7 @@ int ufshcd_system_resume(struct ufs_hba *hba)
if (!hba)
return -EINVAL;
- if (!hba->is_powered || pm_runtime_suspended(hba->dev))
- /*
-* Let the runtime resume take care of resuming
-* if runtime suspended.
-*/
+ if (!hba->is_powered)
goto out;
else
ret = ufshcd_resume(hba, UFS_SYSTEM_PM);
@@ -8779,8 +8775,15 @@ int ufshcd_system_resume(struct ufs_hba *hba)
trace_ufshcd_system_resume(dev_name(hba->dev), ret,
ktime_to_us(ktime_sub(ktime_get(), start)),
hba->curr_dev_pwr_mode, hba->uic_link_state);
- if (!ret)
+ if (!ret) {
hba->is_sys_suspended = false;
+
+ if (pm_runtime_suspended(hba->dev)) {
+ pm_runtime_disable(hba->dev);
+ pm_runtime_set_active(hba->dev);
+ pm_runtime_enable(hba->dev);
+ }
+ }
return ret;
}
EXPORT_SYMBOL(ufshcd_system_resume);
--
2.17.1
Re: [PATCH v1 23/24] kvm: arm64: Trap host SMCs in protected mode.
On 2020-11-09 11:32, David Brazdil wrote:
While protected nVHE KVM is installed, start trapping all host SMCs.
By default, these are simply forwarded to EL3, but PSCI SMCs are
validated first.
Create new constant HCR_HOST_NVHE_PROTECTED_FLAGS with the new set of
HCR
flags to use while the nVHE vector is installed when the kernel was
booted with the protected flag enabled. Switch back to the default HCR
flags when switching back to the stub vector.
Signed-off-by: David Brazdil
---
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/kernel/image-vars.h | 4
arch/arm64/kvm/arm.c | 35 ++
arch/arm64/kvm/hyp/nvhe/hyp-init.S | 8 +++
arch/arm64/kvm/hyp/nvhe/switch.c | 5 -
5 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_arm.h
b/arch/arm64/include/asm/kvm_arm.h
index 64ce29378467..4e90c2debf70 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -80,6 +80,7 @@
HCR_FMO | HCR_IMO | HCR_PTW )
#define HCR_VIRT_EXCP_MASK (HCR_VSE | HCR_VI | HCR_VF)
#define HCR_HOST_NVHE_FLAGS (HCR_RW | HCR_API | HCR_APK | HCR_ATA)
+#define HCR_HOST_NVHE_PROTECTED_FLAGS (HCR_HOST_NVHE_FLAGS | HCR_TSC)
#define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H)
/* TCR_EL2 Registers bits */
diff --git a/arch/arm64/kernel/image-vars.h
b/arch/arm64/kernel/image-vars.h
index 78a42a7cdb72..75cda51674f4 100644
--- a/arch/arm64/kernel/image-vars.h
+++ b/arch/arm64/kernel/image-vars.h
@@ -62,9 +62,13 @@ __efistub__ctype = _ctype;
*/
/* Alternative callbacks for init-time patching of nVHE hyp code. */
+KVM_NVHE_ALIAS(kvm_patch_hcr_flags);
KVM_NVHE_ALIAS(kvm_patch_vector_branch);
KVM_NVHE_ALIAS(kvm_update_va_mask);
+/* Static key enabled when the user opted into nVHE protected mode. */
+KVM_NVHE_ALIAS(kvm_protected_mode);
+
/* Global kernel state accessed by nVHE hyp code. */
KVM_NVHE_ALIAS(kvm_vgic_global_state);
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 574aa2d026e6..c09b95cfa00a 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1861,6 +1861,41 @@ void kvm_arch_exit(void)
kvm_perf_teardown();
}
+static inline u32 __init __gen_mov_hcr_insn(u64 hcr, u32 rd, int i)
+{
+ int shift = 48 - (i * 16);
+ u16 imm = (hcr >> shift) & GENMASK(16, 0);
I really doubt you want to encode 17 bits.
+
+ return aarch64_insn_gen_movewide(rd, imm, shift,
+AARCH64_INSN_VARIANT_64BIT,
+(i == 0) ? AARCH64_INSN_MOVEWIDE_ZERO
+ : AARCH64_INSN_MOVEWIDE_KEEP);
+}
I've added a generate_mov_q() helper as part of my host EL2 entry
rework.
We can probably share some stuff here.
+
+void __init kvm_patch_hcr_flags(struct alt_instr *alt,
+ __le32 *origptr, __le32 *updptr, int nr_inst)
+{
+ int i;
+ u32 rd;
+
+ BUG_ON(nr_inst != 4);
+
+ /* Skip for VHE and unprotected nVHE modes. */
+ if (!is_kvm_protected_mode())
+ return;
+
+ rd = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RD,
+ le32_to_cpu(origptr[0]));
+
+ for (i = 0; i < nr_inst; i++) {
+ u32 oinsn = __gen_mov_hcr_insn(HCR_HOST_NVHE_FLAGS, rd, i);
+ u32 insn = __gen_mov_hcr_insn(HCR_HOST_NVHE_PROTECTED_FLAGS,
rd, i);
+
+ BUG_ON(oinsn != le32_to_cpu(origptr[i]));
+ updptr[i] = cpu_to_le32(insn);
+ }
+}
+
static int __init early_kvm_protected_cfg(char *buf)
{
bool val;
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index f999a35b2c8c..bbe6c5f558e0 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -88,6 +88,12 @@ SYM_CODE_END(__kvm_hyp_init)
* x0: struct kvm_nvhe_init_params PA
*/
SYM_CODE_START(___kvm_hyp_init)
+alternative_cb kvm_patch_hcr_flags
+ mov_q x1, HCR_HOST_NVHE_FLAGS
You really want to be careful here: the mov_q macro expands to 2, 3 or 4
instructions, depending on the input data...
It is also odd that you have both a static key and a patching
alternative.
Why isn't "protected KVM" a capability that can be evaluated as a a non
patching alternative? In general, I'd like to reserve patching
alternatives
to values that cannot be evaluated at compile time (VM offsets, for
example).
+alternative_cb_end
+ msr hcr_el2, x1
+ isb
+
ldr x1, [x0, #NVHE_INIT_TPIDR_EL2]
msr tpidr_el2, x1
@@ -220,6 +226,8 @@ reset:
bic x5, x5, x6 // Clear SCTL_M and etc
pre_disable_mmu_workaround
msr sctlr_el2, x5
+ mov_q x5, HCR_HOST_NVHE_FLAGS
+ msr hcr_el2, x5
isb
/* Install stub vectors */
diff --git
[PATCH v3 0/4] Firmware loading option
Add option to prevent firmware/configuration loading during each boot. Andrej Valek (4): Input: goodix - add option to disable firmware loading dt-bindings: touchscreen: goodix: add info about disabling FW loading Input: atmel_mxt_ts - add option to disable firmware loading Input: st1232 - add support resolution reading .../bindings/input/touchscreen/goodix.yaml| 1 + drivers/input/touchscreen/atmel_mxt_ts.c | 17 -- drivers/input/touchscreen/goodix.c| 4 +- drivers/input/touchscreen/st1232.c| 52 +-- 4 files changed, 54 insertions(+), 20 deletions(-) -- 2.20.1
[PATCH v3 1/4] Input: goodix - add option to disable firmware loading
Firmware file loadind for GT911 controller takes too much time (~60s).
There is no check that configuration is the same which is already present.
This happens always during boot, which makes touchscreen unusable.
Add there an option to prevent firmware file loading, but keep it enabled
by default.
Signed-off-by: Andrej Valek
---
drivers/input/touchscreen/goodix.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index 02c75ea385e08..52eb2ccb0de9a 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -941,7 +941,9 @@ static int goodix_get_gpio_config(struct goodix_ts_data *ts)
default:
if (ts->gpiod_int && ts->gpiod_rst) {
ts->reset_controller_at_probe = true;
- ts->load_cfg_from_disk = true;
+ /* Prevent cfg loading for each start */
+ ts->load_cfg_from_disk = !device_property_read_bool(dev,
+"goodix,do-not-load-fw");
ts->irq_pin_access_method = IRQ_PIN_ACCESS_GPIO;
}
}
--
2.20.1
[PATCH v3 2/4] dt-bindings: touchscreen: goodix: add info about disabling FW loading
Add information about option how to disable FW loading for each boot. Signed-off-by: Andrej Valek --- Documentation/devicetree/bindings/input/touchscreen/goodix.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml index da5b0d87e16d0..b61e019ff1a0b 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml @@ -53,6 +53,7 @@ properties: touchscreen-size-x: true touchscreen-size-y: true touchscreen-swapped-x-y: true + goodix,do-not-load-fw: false additionalProperties: false -- 2.20.1
[PATCH v3 3/4] Input: atmel_mxt_ts - add option to disable firmware loading
Firmware file loadind for mXT336U controller takes too much time (~60s).
There is no check that configuration is the same which is already present.
This happens always during boot, which makes touchscreen unusable.
Add there an option to prevent firmware file loading, but keep it enabled
by default.
Signed-off-by: Andrej Valek
---
drivers/input/touchscreen/atmel_mxt_ts.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 98f17fa3a8926..491d5088d2826 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -311,6 +311,7 @@ struct mxt_data {
struct mxt_dbg dbg;
struct gpio_desc *reset_gpio;
bool use_retrigen_workaround;
+ bool cfg_loading_disabled;
/* Cached parameters from object table */
u16 T5_address;
@@ -2191,9 +2192,15 @@ static int mxt_initialize(struct mxt_data *data)
if (error)
return error;
- error = request_firmware_nowait(THIS_MODULE, true, MXT_CFG_NAME,
- >dev, GFP_KERNEL, data,
- mxt_config_cb);
+ /* Load firmware if enabled */
+ if (!data->cfg_loading_disabled) {
+ error = request_firmware_nowait(THIS_MODULE, true, MXT_CFG_NAME,
+ >dev, GFP_KERNEL, data,
+ mxt_config_cb);
+ } else {
+ mxt_config_cb(NULL, data);
+ }
+
if (error) {
dev_err(>dev, "Failed to invoke firmware loader: %d\n",
error);
@@ -3158,6 +3165,10 @@ static int mxt_probe(struct i2c_client *client, const
struct i2c_device_id *id)
msleep(MXT_RESET_INVALID_CHG);
}
+ /* prevent firmware flashing for each start */
+ data->cfg_loading_disabled = device_property_read_bool(>dev,
+ "atmel,do-not-load-fw");
+
error = mxt_initialize(data);
if (error)
return error;
--
2.20.1
[PATCH v3 4/4] Input: st1232 - add support resolution reading
Hard-coding resolution for st1633 device was wrong. Some of LCDs like
YTS700TLBC-02-100C has assembled Sitronix st1633 touchcontroller too. But
the resolution is not 320x480 as was hard-coded.
Add new function which reads correct resolution directly from register.
Signed-off-by: Andrej Valek
---
drivers/input/touchscreen/st1232.c | 52 +-
1 file changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/input/touchscreen/st1232.c
b/drivers/input/touchscreen/st1232.c
index 63b29c7279e29..1b4b139c85330 100644
--- a/drivers/input/touchscreen/st1232.c
+++ b/drivers/input/touchscreen/st1232.c
@@ -26,15 +26,14 @@
#define ST1232_TS_NAME "st1232-ts"
#define ST1633_TS_NAME "st1633-ts"
+#define REG_XY_RESOLUTION 0x04
+#define REG_XY_COORDINATES 0x12
#define ST_TS_MAX_FINGERS 10
struct st_chip_info {
boolhave_z;
- u16 max_x;
- u16 max_y;
u16 max_area;
u16 max_fingers;
- u8 start_reg;
};
struct st1232_ts_data {
@@ -48,15 +47,14 @@ struct st1232_ts_data {
u8 *read_buf;
};
-static int st1232_ts_read_data(struct st1232_ts_data *ts)
+static int st1232_ts_read_data(struct st1232_ts_data *ts, u8 reg)
{
struct i2c_client *client = ts->client;
- u8 start_reg = ts->chip_info->start_reg;
struct i2c_msg msg[] = {
{
.addr = client->addr,
- .len= sizeof(start_reg),
- .buf= _reg,
+ .len= sizeof(reg),
+ .buf= ,
},
{
.addr = client->addr,
@@ -74,6 +72,25 @@ static int st1232_ts_read_data(struct st1232_ts_data *ts)
return 0;
}
+static int st1232_ts_read_resolution(struct st1232_ts_data *ts, u16 *max_x,
+u16 *max_y)
+{
+ u8 *buf;
+ int error;
+
+ /* select resolution register */
+ error = st1232_ts_read_data(ts, REG_XY_RESOLUTION);
+ if (error)
+ return error;
+
+ buf = ts->read_buf;
+
+ *max_x = ((buf[0] & 0x0070) << 4) | buf[1];
+ *max_y = ((buf[0] & 0x0007) << 8) | buf[2];
+
+ return 0;
+}
+
static int st1232_ts_parse_and_report(struct st1232_ts_data *ts)
{
struct input_dev *input = ts->input_dev;
@@ -123,7 +140,7 @@ static irqreturn_t st1232_ts_irq_handler(int irq, void
*dev_id)
int count;
int error;
- error = st1232_ts_read_data(ts);
+ error = st1232_ts_read_data(ts, REG_XY_COORDINATES);
if (error)
goto out;
@@ -157,20 +174,14 @@ static void st1232_ts_power_off(void *data)
static const struct st_chip_info st1232_chip_info = {
.have_z = true,
- .max_x = 0x31f, /* 800 - 1 */
- .max_y = 0x1df, /* 480 -1 */
.max_area = 0xff,
.max_fingers= 2,
- .start_reg = 0x12,
};
static const struct st_chip_info st1633_chip_info = {
.have_z = false,
- .max_x = 0x13f, /* 320 - 1 */
- .max_y = 0x1df, /* 480 -1 */
.max_area = 0x00,
.max_fingers= 5,
- .start_reg = 0x12,
};
static int st1232_ts_probe(struct i2c_client *client,
@@ -179,6 +190,7 @@ static int st1232_ts_probe(struct i2c_client *client,
const struct st_chip_info *match;
struct st1232_ts_data *ts;
struct input_dev *input_dev;
+ u16 max_x, max_y;
int error;
match = device_get_match_data(>dev);
@@ -239,14 +251,22 @@ static int st1232_ts_probe(struct i2c_client *client,
input_dev->name = "st1232-touchscreen";
input_dev->id.bustype = BUS_I2C;
+ /* read resolution from chip */
+ error = st1232_ts_read_resolution(ts, _x, _y);
+ if (error) {
+ dev_err(>dev,
+ "Failed to read resolution: %d\n", error);
+ return error;
+ }
+
if (ts->chip_info->have_z)
input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR, 0,
ts->chip_info->max_area, 0, 0);
input_set_abs_params(input_dev, ABS_MT_POSITION_X,
-0, ts->chip_info->max_x, 0, 0);
+0, max_x, 0, 0);
input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
-0, ts->chip_info->max_y, 0, 0);
+0, max_y, 0, 0);
touchscreen_parse_properties(input_dev, true, >prop);
--
2.20.1
Re: [PATCH -next] irq-chip/gic-v3-its: Fixed an issue where the ITS executes the residual commands in the queue again when the ITS wakes up from sleep mode.
在 2020/11/9 18:43, Marc Zyngier 写道: On 2020-11-09 03:05, xuqiang (M) wrote: 在 2020/11/8 0:54, Marc Zyngier 写道: [dropping Jason, whose email address has been bouncing for weeks now] On 2020-11-07 10:42, Xu Qiang wrote: On my platform, ITS_FLAGS_SAVE_SUSPEND_STATE is not set,thus do nothing Which platform? Hisi Ascend platform in its suspend and resuse function.On the other hand,firmware stores GITS_CTRL,GITS_CBASER,GITS_CWRITER and GITS_BASER in the suspend, and restores these registers in the resume. As a result, the ITS executes the residual commands in the queue. Which firmware are you using? I just had a look at the trusted firmware source code, and while it definitely does something that *looks* like what you are describing, it doesn't re-enable the ITS on resume. So what are you running? I am using ATF. Since ITS_FLAGS_SAVE_SUSPEND_STATE is not set,ITS driver of OS will not re-enable ITS in th resume. To make ITS work properly, we changed the ATF code to re-enable ITS on resume. I don't think the words "work properly" apply here. The kernel didn't do what you wanted, so instead of fixing the kernel, you introduced a bug that results in memory corruption from the firmware. What are you plans to fix your firmware? Because from an upstream ATF compatibility PoV, all there is to do is to fixup the command queue and enable the ITS. M. I'm sorry I didn't make it clear how to do this. I'm going to reset commit which re-enable ITS on the ATF, and drop the checks for ITS_FLAGS_SAVE_SUSPEND_STATE in the OS. In other words, the ATF does not re-enable ITS, and OS itself re-enables ITS when it resumes. To do this, I have to remove the check of ITS_FLAGS_SAVE_SUSPEND_STATE because it is not set. Thanks Xu.
Re: [PATCH] pinctrl: pinctrl-at91-pio4: Set irq handler and data in one go
On 09/11/2020 at 12:26, Andy Shevchenko wrote: On Sun, Nov 8, 2020 at 8:05 PM Martin Kaiser wrote: Replace the two separate calls for setting the irq handler and data with a single irq_set_chained_handler_and_data() call. Can it be rewritten to use the GPIO core facility of instantiating IRQ chip? I have the feeling it's out of scope for this (tiny) patch. Regards, -- Nicolas Ferre
Re: [PATCH v2 03/10] usb: cdns3: Moves reusable code to separate module
On 20-11-06 12:42:53, Pawel Laszczak wrote:
> Patch moves common reusable code used by cdns3 and cdnsp driver
> to cdns-usb-common library. This library include core.c, drd.c
> and host.c files.
>
> Signed-off-by: Pawel Laszczak
> ---
> drivers/usb/cdns3/Kconfig | 8
> drivers/usb/cdns3/Makefile | 8 +---
> drivers/usb/cdns3/cdns3-plat.c | 2 ++
> drivers/usb/cdns3/core.c | 18 +++---
> drivers/usb/cdns3/core.h | 11 +++
> drivers/usb/cdns3/drd.c| 3 ++-
> drivers/usb/cdns3/drd.h| 4 ++--
> 7 files changed, 41 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig
> index 84716d216ae5..58154c0a73ac 100644
> --- a/drivers/usb/cdns3/Kconfig
> +++ b/drivers/usb/cdns3/Kconfig
> @@ -1,8 +1,15 @@
> +config CDNS_USB_COMMON
> + tristate
> +
> +config CDNS_USB_HOST
> + bool
> +
> config USB_CDNS3
> tristate "Cadence USB3 Dual-Role Controller"
> depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA
> select USB_XHCI_PLATFORM if USB_XHCI_HCD
> select USB_ROLE_SWITCH
> + select CDNS_USB_COMMON
> help
> Say Y here if your system has a Cadence USB3 dual-role controller.
> It supports: dual-role switch, Host-only, and Peripheral-only.
> @@ -25,6 +32,7 @@ config USB_CDNS3_GADGET
> config USB_CDNS3_HOST
> bool "Cadence USB3 host controller"
> depends on USB=y || USB=USB_CDNS3
> + select CDNS_USB_HOST
> help
> Say Y here to enable host controller functionality of the
> Cadence driver.
> diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
> index a1fe9612053a..16df87abf3cf 100644
> --- a/drivers/usb/cdns3/Makefile
> +++ b/drivers/usb/cdns3/Makefile
> @@ -2,17 +2,19 @@
> # define_trace.h needs to know how to find our header
> CFLAGS_trace.o := -I$(src)
>
> -cdns3-y := cdns3-plat.o core.o drd.o
> +cdns-usb-common-y:= core.o drd.o
> +cdns3-y := cdns3-plat.o
>
> obj-$(CONFIG_USB_CDNS3) += cdns3.o
> +obj-$(CONFIG_CDNS_USB_COMMON)+= cdns-usb-common.o
> +
> +cdns-usb-common-$(CONFIG_CDNS_USB_HOST) += host.o
> cdns3-$(CONFIG_USB_CDNS3_GADGET) += gadget.o ep0.o
>
> ifneq ($(CONFIG_USB_CDNS3_GADGET),)
> cdns3-$(CONFIG_TRACING) += trace.o
> endif
>
> -cdns3-$(CONFIG_USB_CDNS3_HOST) += host.o
> -
> obj-$(CONFIG_USB_CDNS3_PCI_WRAP) += cdns3-pci-wrap.o
> obj-$(CONFIG_USB_CDNS3_TI) += cdns3-ti.o
> obj-$(CONFIG_USB_CDNS3_IMX) += cdns3-imx.o
> diff --git a/drivers/usb/cdns3/cdns3-plat.c b/drivers/usb/cdns3/cdns3-plat.c
> index b74882af3a9f..562163c81911 100644
> --- a/drivers/usb/cdns3/cdns3-plat.c
> +++ b/drivers/usb/cdns3/cdns3-plat.c
> @@ -18,6 +18,7 @@
> #include
>
> #include "core.h"
> +#include "gadget-export.h"
>
> static int set_phy_power_on(struct cdns3 *cdns)
> {
> @@ -134,6 +135,7 @@ static int cdns3_plat_probe(struct platform_device *pdev)
> if (ret)
> goto err_phy_power_on;
>
> + cdns->gadget_init = cdns3_gadget_init;
> ret = cdns3_init(cdns);
> if (ret)
> goto err_cdns_init;
> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
> index 758fd5d67196..4fedf32855af 100644
> --- a/drivers/usb/cdns3/core.c
> +++ b/drivers/usb/cdns3/core.c
> @@ -19,10 +19,8 @@
> #include
> #include
>
> -#include "gadget.h"
> #include "core.h"
> #include "host-export.h"
> -#include "gadget-export.h"
> #include "drd.h"
>
> static int cdns3_idle_init(struct cdns3 *cdns);
> @@ -147,7 +145,11 @@ static int cdns3_core_init_role(struct cdns3 *cdns)
> }
>
> if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_PERIPHERAL) {
> - ret = cdns3_gadget_init(cdns);
> + if (cdns->gadget_init)
> + ret = cdns->gadget_init(cdns);
> + else
> + ret = -ENXIO;
> +
> if (ret) {
> dev_err(dev, "Device initialization failed with %d\n",
> ret);
> @@ -473,6 +475,7 @@ int cdns3_init(struct cdns3 *cdns)
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(cdns3_init);
>
> /**
> * cdns3_remove - unbind drd driver and clean up
> @@ -487,6 +490,7 @@ int cdns3_remove(struct cdns3 *cdns)
>
> return 0;
> }
> +EXPORT_SYMBOL_GPL(cdns3_remove);
>
> #ifdef CONFIG_PM_SLEEP
> int cdns3_suspend(struct cdns3 *cdns)
> @@ -505,6 +509,7 @@ int cdns3_suspend(struct cdns3 *cdns)
>
> return 0;
> }
> +EXPORT_SYMBOL_GPL(cdns3_suspend);
>
> int cdns3_resume(struct cdns3 *cdns, u8 set_active)
> {
> @@ -521,4 +526,11 @@ int cdns3_resume(struct cdns3 *cdns, u8 set_active)
>
> return 0;
> }
> +EXPORT_SYMBOL_GPL(cdns3_resume);
> #endif /*
Re: [tip: ras/core] x86/mce: Enable additional error logging on certain Intel CPUs
Maybe no contract ... but a bunch of places (many of them in Intel
specific code) that check for it
Interestingly, quite a few of them are actually checking for HYPERVISOR
not because of missing hypervisor features, but rather because
hypervisors don't have to work around certain errata. :)
Full analysis after my sig, but tl;dr: the only case of using HYPERVISOR
before using MSRs are in arch/x86/events/intel/cstate.c and
arch/x86/events/intel/uncore.c. There are some workarounds in
drivers/gpu that might fall into a similar bucket. But as far as MSRs
go, the way to go overwhelmingly seems to be {rd,wr}msrl_safe.
Thanks,
Paolo
On 10/11/20 00:36, Luck, Tony wrote:
arch/x86/events/core.c: if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
Print a slightly less frightening warning.
arch/x86/events/intel/core.c: if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
Working around KVM's ignore_msrs=1 option (and quite ugly; shows that
the option shouldn't be enabled by default).
arch/x86/events/intel/core.c: int assume = 3 *
!boot_cpu_has(X86_FEATURE_HYPERVISOR);
Seems unnecessary.
arch/x86/events/intel/cstate.c: if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
arch/x86/events/intel/uncore.c: if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
Too complicated. :)
arch/x86/kernel/apic/apic.c:if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
Hypervisors don't have errata.
arch/x86/kernel/cpu/bugs.c: if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
arch/x86/kernel/cpu/bugs.c: else if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
arch/x86/kernel/cpu/bugs.c: if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
arch/x86/kernel/cpu/bugs.c: if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
arch/x86/kernel/cpu/intel.c:if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
Print different vulnerability status in sysfs.
arch/x86/kernel/cpu/mshyperv.c: if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
arch/x86/kernel/cpu/vmware.c: * If !boot_cpu_has(X86_FEATURE_HYPERVISOR),
vmware_hypercall_mode
arch/x86/kernel/cpu/vmware.c: if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
arch/x86/kernel/jailhouse.c:!boot_cpu_has(X86_FEATURE_HYPERVISOR))
arch/x86/kernel/kvm.c: if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
arch/x86/kernel/paravirt.c: if (!boot_cpu_has(X86_FEATURE_HYPERVISOR))
Obviously needed before using paravirt features of the hypervisor.
arch/x86/kernel/tsc.c: if (boot_cpu_has(X86_FEATURE_HYPERVISOR) ||
Disables ART in VMs. Probably the idea is that ART does not have an
offset field similar to the TSC's, but it's not necessary. Looking at
the hypervisor-provided CPUID should be enough.
arch/x86/mm/init_64.c: if (!boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
Tweaks hotplug heuristics, no MSRs involved.
drivers/acpi/processor_idle.c: if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
Avoids pointless hypervisor exit on idle (i.e. just an optimization).
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h: return
boot_cpu_has(X86_FEATURE_HYPERVISOR);
Work around SR-IOV bugs.
drivers/gpu/drm/i915/i915_memcpy.c:
!boot_cpu_has(X86_FEATURE_HYPERVISOR))
Work around KVM deficiency.
drivers/gpu/drm/radeon/radeon_device.c: return
boot_cpu_has(X86_FEATURE_HYPERVISOR);
Work around SR-IOV bugs.
drivers/visorbus/visorchipset.c:if
(boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
Needed before using paravirt features of the hypervisor.
Re: linux-next: Tree for Nov 5
On Tue, Nov 10, 2020 at 8:50 AM Anders Roxell wrote: > > On Thu, 5 Nov 2020 at 07:06, Stephen Rothwell wrote: > > > > Hi all, > > > > Changes since 20201104: > > When building an arm64 allmodconfig and booting up that in qemu I see > > [10011.092394][ T28] task:kworker/0:2 state:D stack:26896 pid: > 1840 ppid: 2 flags:0x0428 > [10022.368093][ T28] Workqueue: events toggle_allocation_gate > [10024.827549][ T28] Call trace: > [10027.152494][ T28] __switch_to+0x1cc/0x1e0 > [10031.378073][ T28] __schedule+0x730/0x800 > [10032.164468][ T28] schedule+0xd8/0x160 > [10033.886807][ T28] toggle_allocation_gate+0x16c/0x220 > [10038.477987][ T28] process_one_work+0x5c0/0x980 > [10039.900075][ T28] worker_thread+0x428/0x720 > [10042.782911][ T28] kthread+0x23c/0x260 > [10043.171725][ T28] ret_from_fork+0x10/0x18 > [10046.227741][ T28] INFO: lockdep is turned off. > [10047.732220][ T28] Kernel panic - not syncing: hung_task: blocked tasks > [10047.741785][ T28] CPU: 0 PID: 28 Comm: khungtaskd Tainted: G > W 5.10.0-rc2-next-20201105-6-g7af110e4d8ed #1 > [10047.755348][ T28] Hardware name: linux,dummy-virt (DT) > [10047.763476][ T28] Call trace: > [10047.769802][ T28] dump_backtrace+0x0/0x420 > [10047.777104][ T28] show_stack+0x38/0xa0 > [10047.784177][ T28] dump_stack+0x1d4/0x278 > [10047.791362][ T28] panic+0x304/0x5d8 > [10047.798202][ T28] check_hung_uninterruptible_tasks+0x5e4/0x640 > [10047.807056][ T28] watchdog+0x138/0x160 > [10047.814140][ T28] kthread+0x23c/0x260 > [10047.821130][ T28] ret_from_fork+0x10/0x18 > [10047.829181][ T28] Kernel Offset: disabled > [10047.836274][ T28] CPU features: 0x0240002,20002004 > [10047.844070][ T28] Memory Limit: none > [10047.853599][ T28] ---[ end Kernel panic - not syncing: hung_task: > blocked tasks ]--- > > if I build with KFENCE=n it boots up eventually, here's my .config file [2]. > > Any idea what may happen? > > it happens on next-20201109 also, but it takes longer until we get the > "Call trace:". > > Cheers, > Anders > [1] http://ix.io/2Ddv > [2] https://people.linaro.org/~anders.roxell/allmodconfig-next-20201105.config Hi Anders, Does it happen during boot or afterwards? 10047 are seconds after boot, right? So this is like 3 hours after boot, no? Also, is there anything useful before that part of the log? It seems that at least the bug type header is stripped.
Re: [PATCH] drm/fb_helper: Use min_t() to handle size_t and unsigned long
Hi
Am 10.11.20 um 10:01 schrieb Geert Uytterhoeven:
> On arm32:
>
> drivers/gpu/drm/drm_fb_helper.c: In function ‘fb_read_screen_base’:
> include/linux/minmax.h:18:28: warning: comparison of distinct pointer
> types lacks a cast
> ...
> drivers/gpu/drm/drm_fb_helper.c:2041:22: note: in expansion of macro ‘min’
> 2041 | size_t alloc_size = min(count, PAGE_SIZE);
> | ^~~
> drivers/gpu/drm/drm_fb_helper.c: In function ‘fb_write_screen_base’:
> include/linux/minmax.h:18:28: warning: comparison of distinct pointer
> types lacks a cast
> ...
> drivers/gpu/drm/drm_fb_helper.c:2115:22: note: in expansion of macro ‘min’
> 2115 | size_t alloc_size = min(count, PAGE_SIZE);
> | ^~~
>
> Indeed, on 32-bit size_t is "unsigned int", not "unsigned long".
>
> Fixes: 222ec45f4c69dfa8 ("drm/fb_helper: Support framebuffers in I/O memory")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Thomas Zimmermann
Thanks a lot. I'll add the patch to drm-misc-next.
> ---
> Interestingly, the commit log claims v7 changed:
>
> use min_t(size_t,) (kernel test robot)
It got fixed in the functions' inner loops, but I missed the other
instances.
Best regards
Thomas
> ---
> drivers/gpu/drm/drm_fb_helper.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 01ba1da285116373..25edf670867c6f79 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2038,7 +2038,7 @@ static ssize_t fb_read_screen_base(struct fb_info
> *info, char __user *buf, size_
> loff_t pos)
> {
> const char __iomem *src = info->screen_base + pos;
> - size_t alloc_size = min(count, PAGE_SIZE);
> + size_t alloc_size = min_t(size_t, count, PAGE_SIZE);
> ssize_t ret = 0;
> int err = 0;
> char *tmp;
> @@ -2112,7 +2112,7 @@ static ssize_t fb_write_screen_base(struct fb_info
> *info, const char __user *buf
> loff_t pos)
> {
> char __iomem *dst = info->screen_base + pos;
> - size_t alloc_size = min(count, PAGE_SIZE);
> + size_t alloc_size = min_t(size_t, count, PAGE_SIZE);
> ssize_t ret = 0;
> int err = 0;
> u8 *tmp;
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Re: WARNING: can't access registers at asm_common_interrupt
On Nov 09, 2020 / 21:19, Josh Poimboeuf wrote:
> On Mon, Nov 09, 2020 at 09:10:38AM +, Shinichiro Kawasaki wrote:
> > On Nov 06, 2020 / 12:06, Josh Poimboeuf wrote:
> > > On Fri, Nov 06, 2020 at 06:04:15AM +, Shinichiro Kawasaki wrote:
> > > > Greetings,
> > > >
> > > > I observe "WARNING: can't access registers at
> > > > asm_common_interrupt+0x1e/0x40"
> > > > in my kernel test system repeatedly, which is printed by
> > > > unwind_next_frame() in
> > > > "arch/x86/kernel/unwind_orc.c". Syzbot already reported that [1].
> > > > Similar
> > > > warning was reported and discussed [2], but I suppose the cause is not
> > > > yet
> > > > clarified.
> > > >
> > > > The warning was observed with v5.10-rc2 and older tags. I bisected and
> > > > found
> > > > that the commit 044d0d6de9f5 ("lockdep: Only trace IRQ edges") in
> > > > v5.9-rc3
> > > > triggered the warning. Reverting that from 5.10-rc2, the warning
> > > > disappeared.
> > > > May I ask comment by expertise on CC how this commit can relate to the
> > > > warning?
> > > >
> > > > The test condition to reproduce the warning is rather unique (blktests,
> > > > dm-linear and ZNS device emulation by QEMU). If any action is suggested
> > > > for
> > > > further analysis, I'm willing to take it with my test system.
> > >
> > > Hi,
> > >
> > > Thanks for reporting this issue. This might be a different issue from
> > > [2].
> > >
> > > Can you send me the arch/x86/entry/entry_64.o file from your build?
> >
> > Hi Josh, thank you for your response. As a separated e-mail, I have sent the
> > entry_64.o only to your address, since I hesitate to send around the 76kb
> > attachment file to LKML. In case it does not reach to you, please let me
> > know.
>
> Got it, thanks. Unfortunately I'm still confused.
>
> Can you test with the following patch, and boot with 'unwind_debug'?
> That should hopefully dump a lot of useful data along with the warning.
Thank you for the patch. With the patch and 'unwind_debug' kernel command line,
I recreated the warning. Here I quote the kernel messages printed (smpboot
related messages are usual message printed for blktests test case block/008).
...
[ 113.022680] smpboot: CPU 1 is now offline
[ 113.030546] WARNING: can't access registers at asm_common_interrupt+0x1e/0x40
[ 113.030549] unwind stack type:0 next_sp: mask:0x6 graph_idx:0
[ 113.030554] 8881e87097b0: 11103d0e1302 (0x11103d0e1302)
[ 113.030558] 8881e87097b8: 9712a434
(unwind_next_frame+0x15e4/0x1fc0)
[ 113.030560] 8881e87097c0: 99200c5e
(asm_common_interrupt+0x1e/0x40)
[ 113.030562] 8881e87097c8: (0x0)
[ 113.030563] 8881e87097d0: 8881e87098bd (0x8881e87098bd)
[ 113.030564] 8881e87097d8: 8881e87098d8 (0x8881e87098d8)
[ 113.030565] 8881e87097e0: 8881e87098c0 (0x8881e87098c0)
[ 113.030570] 8881e87097e8: 9ac85575
(__start_orc_unwind+0x65f81/0x37a91c)
[ 113.030572] 8881e87097f0: 9ac85575
(__start_orc_unwind+0x65f81/0x37a91c)
[ 113.030573] 8881e87097f8: 8881e8709938 (0x8881e8709938)
[ 113.030574] 8881e8709800: (0x0)
[ 113.030597] 8881e8709808: 88810ebd31c0 (0x88810ebd31c0)
[ 113.030598] 8881e8709810: 41b58ab3 (0x41b58ab3)
[ 113.030602] 8881e8709818: 99d7a850 (.LC2+0x3be/0x44d)
[ 113.030604] 8881e8709820: 97128e50 (deref_stack_reg+0x160/0x160)
[ 113.030605] 8881e8709828: (0x0)
[ 113.030606] 8881e8709830: (0x0)
[ 113.030610] 8881e8709838: 972343bf
(kernel_text_address.part.0+0x1f/0xc0)
[ 113.030624] 8881e8709840: c046fd90 (nvme_irq+0x10/0x20 [nvme])
[ 113.030625] 8881e8709848: 8881e87098d0 (0x8881e87098d0)
[ 113.030628] 8881e8709850: 973994c0
(create_prof_cpu_mask+0x20/0x20)
[ 113.030629] 8881e8709858: 8881e8709908 (0x8881e8709908)
[ 113.030630] 8881e8709860: 8881e8709938 (0x8881e8709938)
[ 113.030631] 8881e8709868: (0x0)
[ 113.030632] 8881e8709870: 88810ebd31c0 (0x88810ebd31c0)
[ 113.030633] 8881e8709878: 0006 (0x6)
[ 113.030636] 8881e8709880: 9709925c (arch_stack_walk+0x6c/0xb0)
[ 113.030637] 8881e8709888: (0x0)
[ 113.030638] 8881e8709890: 88814c428000 (0x88814c428000)
[ 113.030640] 8881e8709898: 88814c43 (0x88814c43)
[ 113.030641] 8881e87098a0: (0x0)
[ 113.030642] 8881e87098a8: 0006 (0x6)
[ 113.030643] 8881e87098b0: 88810ebd31c0 (0x88810ebd31c0)
[ 113.030644] 8881e87098b8: 0100 (0x100)
[ 113.030645] 8881e87098c0: (0x0)
[ 113.030646] 8881e87098c8: (0x0)
[ 113.030648] 8881e87098d0: 99200c5e
(asm_common_interrupt+0x1e/0x40)
[ 113.030649]
Re: [PATCH 2/3] arm: introduce IRQ stacks
* Arnd Bergmann [201109 19:10]: > On Mon, Nov 9, 2020 at 3:45 PM Tony Lindgren wrote: > > > > > > As discussed on IRC, I think it can still be done in one of these > > > ways, though admittedly none of them are perfect: > > > > > > a) add runtime patching for __my_cpu_offset() when > > > CONFIG_SMP_ON_UP is set. This adds complexity but avoids the > > > fallback for for SMP&_V6. It possibly also speeds up > > > running on single-cpu systems if the TPIDRPRW access adds > > > any measurable runtime overhead compared to patching it out. > > > > Out of these options a) sounds best to me. > > Ok. Maninder, would you like to give implementing this a try? > > > > b) If irq stacks are left as a compile-time option, that could be > > > made conditional on "!(SMP&_V6)". Presumably very > > > few people still run kernels built that way any more. The only > > > supported platforms are i.MX3, OMAP2 and Realview-eb, all of > > > which are fairly uncommon these days and would usually > > > run v6-only non-SMP kernels. > > > > This has been working just fine for years though. In general, > > removing the conditional compile ifdefferey has made things quite > > a bit easier for us, so let's continue on that. > > > > > c) If we decide that we no longer care about that configuration > > > at all, we could decide to just make SMP depend on !CPU_V6, > > > and possibly kill off the entire SMP_ON_UP patching logic. > > > I suspect we still want to keep SMP_ON_UP for performance > > > reasons, but I don't know how significant they are to start with. > > > > And this too has been working just fine for years :) > > I know it works, my point was that I'm not sure anyone cares > any more ;-) Well for example whatever Linux running ARMv6 LTE modems out there might need to be supported for quite some time. Not sure how many of them are able to update kernels though. Certainly network security related issues would be a good reason to update the kernels. > I suppose the existence of omap2plus_defconfig and > imx_v6_v7_defconfig means it does at least get tested > regularly. Yes. I probably would just stop any random ARMv6 related testing if it it needs a custom .config. Regards, Tony
Re: [PATCH 2/3 v4] ftrace/x86: Allow for arguments to be passed in to ftrace_regs by default
On Mon, Nov 09, 2020 at 06:16:10PM -0500, Steven Rostedt wrote: > ftrace_caller: > [..] > movq $0, CS(%rsp) <- loads zero into pt_regs->cs for internal use only. > [..] Argh, I missed that. I failed to spot it in the patch. No worries then.
RE: [PATCH v2 03/10] usb: cdns3: Moves reusable code to separate module
Hi,
>
>On 20-11-06 12:42:53, Pawel Laszczak wrote:
>> Patch moves common reusable code used by cdns3 and cdnsp driver
>> to cdns-usb-common library. This library include core.c, drd.c
>> and host.c files.
>>
>> Signed-off-by: Pawel Laszczak
>> ---
>> drivers/usb/cdns3/Kconfig | 8
>> drivers/usb/cdns3/Makefile | 8 +---
>> drivers/usb/cdns3/cdns3-plat.c | 2 ++
>> drivers/usb/cdns3/core.c | 18 +++---
>> drivers/usb/cdns3/core.h | 11 +++
>> drivers/usb/cdns3/drd.c| 3 ++-
>> drivers/usb/cdns3/drd.h| 4 ++--
>> 7 files changed, 41 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig
>> index 84716d216ae5..58154c0a73ac 100644
>> --- a/drivers/usb/cdns3/Kconfig
>> +++ b/drivers/usb/cdns3/Kconfig
>> @@ -1,8 +1,15 @@
>> +config CDNS_USB_COMMON
>> +tristate
>> +
>> +config CDNS_USB_HOST
>> +bool
>> +
>> config USB_CDNS3
>> tristate "Cadence USB3 Dual-Role Controller"
>> depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA
>> select USB_XHCI_PLATFORM if USB_XHCI_HCD
>> select USB_ROLE_SWITCH
>> +select CDNS_USB_COMMON
>> help
>>Say Y here if your system has a Cadence USB3 dual-role controller.
>>It supports: dual-role switch, Host-only, and Peripheral-only.
>> @@ -25,6 +32,7 @@ config USB_CDNS3_GADGET
>> config USB_CDNS3_HOST
>> bool "Cadence USB3 host controller"
>> depends on USB=y || USB=USB_CDNS3
>> +select CDNS_USB_HOST
>> help
>>Say Y here to enable host controller functionality of the
>>Cadence driver.
>> diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
>> index a1fe9612053a..16df87abf3cf 100644
>> --- a/drivers/usb/cdns3/Makefile
>> +++ b/drivers/usb/cdns3/Makefile
>> @@ -2,17 +2,19 @@
>> # define_trace.h needs to know how to find our header
>> CFLAGS_trace.o := -I$(src)
>>
>> -cdns3-y := cdns3-plat.o core.o drd.o
>> +cdns-usb-common-y := core.o drd.o
>> +cdns3-y := cdns3-plat.o
>>
>> obj-$(CONFIG_USB_CDNS3) += cdns3.o
>> +obj-$(CONFIG_CDNS_USB_COMMON) += cdns-usb-common.o
>> +
>> +cdns-usb-common-$(CONFIG_CDNS_USB_HOST) += host.o
>> cdns3-$(CONFIG_USB_CDNS3_GADGET)+= gadget.o ep0.o
>>
>> ifneq ($(CONFIG_USB_CDNS3_GADGET),)
>> cdns3-$(CONFIG_TRACING) += trace.o
>> endif
>>
>> -cdns3-$(CONFIG_USB_CDNS3_HOST) += host.o
>> -
>> obj-$(CONFIG_USB_CDNS3_PCI_WRAP)+= cdns3-pci-wrap.o
>> obj-$(CONFIG_USB_CDNS3_TI) += cdns3-ti.o
>> obj-$(CONFIG_USB_CDNS3_IMX) += cdns3-imx.o
>> diff --git a/drivers/usb/cdns3/cdns3-plat.c b/drivers/usb/cdns3/cdns3-plat.c
>> index b74882af3a9f..562163c81911 100644
>> --- a/drivers/usb/cdns3/cdns3-plat.c
>> +++ b/drivers/usb/cdns3/cdns3-plat.c
>> @@ -18,6 +18,7 @@
>> #include
>>
>> #include "core.h"
>> +#include "gadget-export.h"
>>
>> static int set_phy_power_on(struct cdns3 *cdns)
>> {
>> @@ -134,6 +135,7 @@ static int cdns3_plat_probe(struct platform_device *pdev)
>> if (ret)
>> goto err_phy_power_on;
>>
>> +cdns->gadget_init = cdns3_gadget_init;
>> ret = cdns3_init(cdns);
>> if (ret)
>> goto err_cdns_init;
>> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
>> index 758fd5d67196..4fedf32855af 100644
>> --- a/drivers/usb/cdns3/core.c
>> +++ b/drivers/usb/cdns3/core.c
>> @@ -19,10 +19,8 @@
>> #include
>> #include
>>
>> -#include "gadget.h"
>> #include "core.h"
>> #include "host-export.h"
>> -#include "gadget-export.h"
>> #include "drd.h"
>>
>> static int cdns3_idle_init(struct cdns3 *cdns);
>> @@ -147,7 +145,11 @@ static int cdns3_core_init_role(struct cdns3 *cdns)
>> }
>>
>> if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_PERIPHERAL) {
>> -ret = cdns3_gadget_init(cdns);
>> +if (cdns->gadget_init)
>> +ret = cdns->gadget_init(cdns);
>> +else
>> +ret = -ENXIO;
>> +
>> if (ret) {
>> dev_err(dev, "Device initialization failed with %d\n",
>> ret);
>> @@ -473,6 +475,7 @@ int cdns3_init(struct cdns3 *cdns)
>>
>> return ret;
>> }
>> +EXPORT_SYMBOL_GPL(cdns3_init);
>>
>> /**
>> * cdns3_remove - unbind drd driver and clean up
>> @@ -487,6 +490,7 @@ int cdns3_remove(struct cdns3 *cdns)
>>
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(cdns3_remove);
>>
>> #ifdef CONFIG_PM_SLEEP
>> int cdns3_suspend(struct cdns3 *cdns)
>> @@ -505,6 +509,7 @@ int cdns3_suspend(struct cdns3 *cdns)
>>
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(cdns3_suspend);
>>
>> int cdns3_resume(struct cdns3 *cdns, u8 set_active)
>> {
>> @@ -521,4 +526,11 @@ int cdns3_resume(struct cdns3 *cdns, u8 set_active)
>>
>> return 0;
[PATCHv2] bus: ti-sysc: Fix bogus resetdone warning on enable for cpsw
Bail out early from sysc_wait_softreset() just like we do in sysc_reset()
if there's no sysstatus srst_shift to fix a bogus resetdone warning on
enable as suggested by Grygorii Strashko .
We do not currently handle resets for modules that need writing to the
sysstatus register. If we at some point add that, we also need to add
SYSS_QUIRK_RESETDONE_INVERTED flag for cpsw as the sysstatus bit is low
when reset is done as described in the am335x TRM "Table 14-202
SOFT_RESET Register Field Descriptions"
Fixes: d46f9fbec719 ("bus: ti-sysc: Use optional clocks on for enable and wait
for softreset bit")
Suggested-by: Grygorii Strashko
Signed-off-by: Tony Lindgren
---
Changes since v1:
- Drop quirk handling and use fix suggested by Grygorii
---
drivers/bus/ti-sysc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -227,6 +227,9 @@ static int sysc_wait_softreset(struct sysc *ddata)
u32 sysc_mask, syss_done, rstval;
int syss_offset, error = 0;
+ if (ddata->cap->regbits->srst_shift < 0)
+ return 0;
+
syss_offset = ddata->offsets[SYSC_SYSSTATUS];
sysc_mask = BIT(ddata->cap->regbits->srst_shift);
--
2.29.2
Re: [PATCH v1 17/24] kvm: arm64: Add __hyp_pa_symbol helper macro
On Mon, Nov 09, 2020 at 06:10:05PM +, Marc Zyngier wrote:
> On 2020-11-09 16:59, Quentin Perret wrote:
> > Hey David,
> >
> > On Monday 09 Nov 2020 at 11:32:26 (+), David Brazdil wrote:
> > > Add helper macro for computing the PA of a kernel symbol in nVHE hyp
> > > code. This will be useful for computing the PA of a PSCI CPU_ON entry
> > > point.
> > >
> > > Signed-off-by: David Brazdil
> > > ---
> > > arch/arm64/kvm/hyp/nvhe/psci.c | 10 ++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/psci.c
> > > b/arch/arm64/kvm/hyp/nvhe/psci.c
> > > index b0b5df590ba5..7510b9e174e9 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/psci.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/psci.c
> > > @@ -20,6 +20,16 @@ s64 hyp_physvirt_offset;
> > >
> > > #define __hyp_pa(x) ((phys_addr_t)((x)) + hyp_physvirt_offset)
> > >
> > > +#define __hyp_pa_symbol(sym) \
> > > + ({ \
> > > + extern char sym[]; \
> > > + unsigned long kern_va; \
> > > + \
> > > + asm volatile("ldr %0, =%1" : "=r" (kern_va) \
> > > +: "S" (sym));\
> > > + kern_va - kimage_voffset; \
> > > + })
> > > +
> >
> > Could this be simplified to __hyp_pa(hyp_symbol_addr(sym))? That would
> > avoid the dependency on kimage_voffset.
Ah, didn't see that one. Ok, removing this patch.
>
> I'm going to move away from evaluating kimage_voffset at runtime anyway,
> see [1].
Awesome! One more dependency gone.
>
> Thanks,
>
> M.
>
> [1] https://lore.kernel.org/r/20201109175923.445945-1-...@kernel.org
> --
> Jazz is not dead. It just smells funny...
Re: [PATCH 8/8] WIP: add a dma_alloc_contiguous API
On Mon, Nov 09, 2020 at 03:53:55PM +0100, Ricardo Ribalda wrote: > Hi Christoph > > I have started now to give a try to your patchset. Sorry for the delay. > > For uvc I have prepared this patch: > https://github.com/ribalda/linux/commit/9094fe223fe38f8c8ff21366d893b43cbbdf0113 > > I have tested successfully in a x86_64 noteboot..., yes I know there > is no change for that platform :). > I am trying to get hold of an arm device that can run the latest > kernel from upstream. > > On the meanwhile if you could take a look to the patch to verify that > this the way that you expect the drivers to use your api I would > appreciate it This looks pretty reaosnable. Note that ifdef CONFIG_DMA_NONCOHERENT in the old code doesn't actually work, as that option is an internal thing just for mips and sh..
Re: [PATCH v3 07/26] coresight: Introduce device access abstraction
On 11/9/20 9:00 PM, Mathieu Poirier wrote:
On Wed, Oct 28, 2020 at 10:09:26PM +, Suzuki K Poulose wrote:
We are about to introduce support for sysreg access to ETMv4.4+
component. Since there are generic routines that access the
registers (e.g, CS_LOCK/UNLOCK , claim/disclaim operations, timeout)
and in order to preserve the logic of these operations at a
single place we introduce an abstraction layer for the accesses
to a given device.
Cc: Mathieu Poirier
Cc: Mike Leach
Signed-off-by: Suzuki K Poulose
---
drivers/hwtracing/coresight/coresight-catu.c | 1 +
drivers/hwtracing/coresight/coresight-core.c | 49 +
.../hwtracing/coresight/coresight-cti-core.c | 1 +
drivers/hwtracing/coresight/coresight-etb10.c | 1 +
.../coresight/coresight-etm3x-core.c | 1 +
.../coresight/coresight-etm4x-core.c | 1 +
.../hwtracing/coresight/coresight-funnel.c| 1 +
.../coresight/coresight-replicator.c | 1 +
drivers/hwtracing/coresight/coresight-stm.c | 1 +
.../hwtracing/coresight/coresight-tmc-core.c | 1 +
drivers/hwtracing/coresight/coresight-tpiu.c | 1 +
include/linux/coresight.h | 197 ++
12 files changed, 256 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-catu.c
b/drivers/hwtracing/coresight/coresight-catu.c
index 99430f6cf5a5..5baf29510f1b 100644
--- a/drivers/hwtracing/coresight/coresight-catu.c
+++ b/drivers/hwtracing/coresight/coresight-catu.c
@@ -551,6 +551,7 @@ static int catu_probe(struct amba_device *adev, const
struct amba_id *id)
dev->platform_data = pdata;
drvdata->base = base;
+ catu_desc.access = CSDEV_ACCESS_IOMEM(base);
catu_desc.pdata = pdata;
catu_desc.dev = dev;
catu_desc.groups = catu_groups;
diff --git a/drivers/hwtracing/coresight/coresight-core.c
b/drivers/hwtracing/coresight/coresight-core.c
index cc9e8025c533..e96deaca8cab 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1452,6 +1452,54 @@ int coresight_timeout(void __iomem *addr, u32 offset,
int position, int value)
}
EXPORT_SYMBOL_GPL(coresight_timeout);
+u32 coresight_relaxed_read32(struct coresight_device *csdev, u32 offset)
+{
+ return csdev_access_relaxed_read32(>access, offset);
+}
+
+u32 coresight_read32(struct coresight_device *csdev, u32 offset)
+{
+ return csdev_access_read32(>access, offset);
+}
+
+void coresight_relaxed_write32(struct coresight_device *csdev,
+ u32 val,
+ u32 offset)
+{
+
+ csdev_access_relaxed_write32(>access, val, offset);
+}
+
+
+void coresight_write32(struct coresight_device *csdev, u32 val, u32 offset)
+{
+ csdev_access_write32(>access, val, offset);
+}
+
+u64 coresight_relaxed_read64(struct coresight_device *csdev, u32 offset)
+{
+ return csdev_access_relaxed_read64(>access, offset);
+}
+
+u64 coresight_read64(struct coresight_device *csdev, u32 offset)
+{
+ return csdev_access_read64(>access, offset);
+}
+
+void coresight_relaxed_write64(struct coresight_device *csdev,
+ u64 val,
+ u32 offset)
+{
+
+ csdev_access_relaxed_write64(>access, val, offset);
+}
+
+
+void coresight_write64(struct coresight_device *csdev, u64 val, u32 offset)
+{
+ csdev_access_write64(>access, val, offset);
+}
+
/*
* coresight_release_platform_data: Release references to the devices
connected
* to the output port of this device.
@@ -1516,6 +1564,7 @@ struct coresight_device *coresight_register(struct
coresight_desc *desc)
csdev->type = desc->type;
csdev->subtype = desc->subtype;
csdev->ops = desc->ops;
+ csdev->access = desc->access;
csdev->orphan = false;
csdev->dev.type = _dev_type[desc->type];
diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c
b/drivers/hwtracing/coresight/coresight-cti-core.c
index d28eae93e55c..3bb0de97d66e 100644
--- a/drivers/hwtracing/coresight/coresight-cti-core.c
+++ b/drivers/hwtracing/coresight/coresight-cti-core.c
@@ -870,6 +870,7 @@ static int cti_probe(struct amba_device *adev, const struct
amba_id *id)
return PTR_ERR(base);
drvdata->base = base;
+ cti_desc.access = CSDEV_ACCESS_IOMEM(base);
dev_set_drvdata(dev, drvdata);
diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 248cc82c838e..b91633c6c9b4 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -755,6 +755,7 @@ static int etb_probe(struct amba_device *adev, const struct
amba_id *id)
return PTR_ERR(base);
drvdata->base = base;
+ desc.access = CSDEV_ACCESS_IOMEM(base);
spin_lock_init(>spinlock);
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-core.c
KASAN: slab-out-of-bounds Read in btrfs_scan_one_device
Hello,
syzbot found the following issue on:
HEAD commit:521b619a Merge tag 'linux-kselftest-kunit-fixes-5.10-rc3' ..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16a5579250
kernel config: https://syzkaller.appspot.com/x/.config?x=e791ddf0875adf65
dashboard link: https://syzkaller.appspot.com/bug?extid=c4b1e5278d93269fd69c
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project.git
ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16296f5c50
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1614e74650
The issue was bisected to:
commit 3831bf0094abed51e71cbeca8b6edf8b88c2644b
Author: Johannes Thumshirn
Date: Mon Oct 7 09:11:02 2019 +
btrfs: add sha256 to checksumming algorithm
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=163a303450
final oops: https://syzkaller.appspot.com/x/report.txt?x=153a303450
console output: https://syzkaller.appspot.com/x/log.txt?x=113a303450
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c4b1e5278d93269fd...@syzkaller.appspotmail.com
Fixes: 3831bf0094ab ("btrfs: add sha256 to checksumming algorithm")
==
BUG: KASAN: slab-out-of-bounds in btrfs_printk+0x421/0x46b fs/btrfs/super.c:245
Read of size 8 at addr 8880146246a0 by task systemd-udevd/8518
CPU: 0 PID: 8518 Comm: systemd-udevd Not tainted 5.10.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x137/0x1be lib/dump_stack.c:118
print_address_description+0x6c/0x660 mm/kasan/report.c:385
__kasan_report mm/kasan/report.c:545 [inline]
kasan_report+0x136/0x1e0 mm/kasan/report.c:562
btrfs_printk+0x421/0x46b fs/btrfs/super.c:245
device_list_add+0x1a94/0x1d60 fs/btrfs/volumes.c:943
btrfs_scan_one_device+0x2e1/0x460 fs/btrfs/volumes.c:1366
btrfs_control_ioctl+0xd1/0x210 fs/btrfs/super.c:2327
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f7f94bc0017
Code: 00 00 00 48 8b 05 81 7e 2b 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff
c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01
c3 48 8b 0d 51 7e 2b 00 f7 d8 64 89 01 48
RSP: 002b:7ffc3c7245f8 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: RCX: 7f7f94bc0017
RDX: 7ffc3c724610 RSI: 90009427 RDI: 000f
RBP: 7ffc3c724610 R08: R09: 0018
R10: 0001 R11: 0246 R12: 000f
R13: R14: 564c3b1752c0 R15: 564c3b162060
Allocated by task 8745:
kasan_save_stack mm/kasan/common.c:48 [inline]
kasan_set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc+0x111/0x140 mm/kasan/common.c:461
slab_post_alloc_hook+0x3e/0x2b0 mm/slab.h:526
slab_alloc_node mm/slub.c:2891 [inline]
kmem_cache_alloc_node+0x144/0x280 mm/slub.c:2927
alloc_unbound_pwq+0x591/0x1060 kernel/workqueue.c:3801
apply_wqattrs_prepare+0x3d2/0xcb0 kernel/workqueue.c:3946
apply_workqueue_attrs_locked+0xcd/0x7b0 kernel/workqueue.c:4029
apply_workqueue_attrs kernel/workqueue.c:4066 [inline]
alloc_and_link_pwqs kernel/workqueue.c:4190 [inline]
alloc_workqueue+0xe7e/0x1480 kernel/workqueue.c:4298
__btrfs_alloc_workqueue+0x181/0x2d0 fs/btrfs/async-thread.c:108
btrfs_alloc_workqueue+0x8c/0x1b0 fs/btrfs/async-thread.c:140
btrfs_init_workqueues fs/btrfs/disk-io.c:2162 [inline]
open_ctree+0x1243/0x3b3b fs/btrfs/disk-io.c:3088
btrfs_fill_super fs/btrfs/super.c:1316 [inline]
btrfs_mount_root+0x9b8/0xb60 fs/btrfs/super.c:1672
legacy_get_tree+0xea/0x180 fs/fs_context.c:592
vfs_get_tree+0x88/0x270 fs/super.c:1549
fc_mount fs/namespace.c:978 [inline]
vfs_kern_mount+0xc9/0x160 fs/namespace.c:1008
btrfs_mount+0x345/0xa80 fs/btrfs/super.c:1732
legacy_get_tree+0xea/0x180 fs/fs_context.c:592
vfs_get_tree+0x88/0x270 fs/super.c:1549
do_new_mount fs/namespace.c:2875 [inline]
path_mount+0x17b4/0x2a20 fs/namespace.c:3205
do_mount fs/namespace.c:3218 [inline]
__do_sys_mount fs/namespace.c:3426 [inline]
__se_sys_mount+0x28c/0x320 fs/namespace.c:3403
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at 888014624400
which belongs to the cache pool_workqueue of size 512
The buggy address is located 160 bytes to the right of
512-byte region [888014624400, 888014624600)
The buggy address belongs to the page:
page:6b59311c refcount:1 mapcount:0 mapping: index:0x0
pfn:0x14624
head:6b59311c order:2 compound_mapcount:0 compound_pincount:0
Re: [PATCH tip/core/rcu 4/4] docs/rcu: Update the call_rcu() API
On Mon, Nov 09, 2020 at 05:20:32PM -0800, Paul E. McKenney wrote: > On Mon, Nov 09, 2020 at 01:24:24PM +0100, Peter Zijlstra wrote: > > On Thu, Nov 05, 2020 at 03:05:10PM -0800, paul...@kernel.org wrote: > > > From: Hui Su > > > > > > This commit updates the documented API of call_rcu() to use the > > > rcu_callback_t typedef instead of the open-coded function definition. > > > > > > Signed-off-by: Hui Su > > > Signed-off-by: Paul E. McKenney > > > --- > > > Documentation/RCU/whatisRCU.rst | 3 +-- > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > > > diff --git a/Documentation/RCU/whatisRCU.rst > > > b/Documentation/RCU/whatisRCU.rst > > > index fb3ff76..1a4723f 100644 > > > --- a/Documentation/RCU/whatisRCU.rst > > > +++ b/Documentation/RCU/whatisRCU.rst > > > @@ -497,8 +497,7 @@ long -- there might be other high-priority work to be > > > done. > > > In such cases, one uses call_rcu() rather than synchronize_rcu(). > > > The call_rcu() API is as follows:: > > > > > > - void call_rcu(struct rcu_head * head, > > > - void (*func)(struct rcu_head *head)); > > > + void call_rcu(struct rcu_head *head, rcu_callback_t func); > > > > Personally I much prefer the old form, because now I have to go look up > > rcu_callback_t to figure out wtf kind of signature is actually required. > > How about if this part of the documentation read as follows: > > typedef void (*rcu_callback_t)(struct rcu_head *head); > void call_rcu(struct rcu_head *head, rcu_callback_t func); > > Wold that help? Sure; but now it's more verbose than it was ;-)
Re: linux-next: Tree for Nov 5
On Tue, 10 Nov 2020 at 10:17, Dmitry Vyukov wrote: > > On Tue, Nov 10, 2020 at 8:50 AM Anders Roxell > wrote: > > > > On Thu, 5 Nov 2020 at 07:06, Stephen Rothwell wrote: > > > > > > Hi all, > > > > > > Changes since 20201104: > > > > When building an arm64 allmodconfig and booting up that in qemu I see > > > > [10011.092394][ T28] task:kworker/0:2 state:D stack:26896 pid: > > 1840 ppid: 2 flags:0x0428 > > [10022.368093][ T28] Workqueue: events toggle_allocation_gate > > [10024.827549][ T28] Call trace: > > [10027.152494][ T28] __switch_to+0x1cc/0x1e0 > > [10031.378073][ T28] __schedule+0x730/0x800 > > [10032.164468][ T28] schedule+0xd8/0x160 > > [10033.886807][ T28] toggle_allocation_gate+0x16c/0x220 > > [10038.477987][ T28] process_one_work+0x5c0/0x980 > > [10039.900075][ T28] worker_thread+0x428/0x720 > > [10042.782911][ T28] kthread+0x23c/0x260 > > [10043.171725][ T28] ret_from_fork+0x10/0x18 > > [10046.227741][ T28] INFO: lockdep is turned off. > > [10047.732220][ T28] Kernel panic - not syncing: hung_task: blocked tasks > > [10047.741785][ T28] CPU: 0 PID: 28 Comm: khungtaskd Tainted: G > > W 5.10.0-rc2-next-20201105-6-g7af110e4d8ed #1 > > [10047.755348][ T28] Hardware name: linux,dummy-virt (DT) > > [10047.763476][ T28] Call trace: > > [10047.769802][ T28] dump_backtrace+0x0/0x420 > > [10047.777104][ T28] show_stack+0x38/0xa0 > > [10047.784177][ T28] dump_stack+0x1d4/0x278 > > [10047.791362][ T28] panic+0x304/0x5d8 > > [10047.798202][ T28] check_hung_uninterruptible_tasks+0x5e4/0x640 > > [10047.807056][ T28] watchdog+0x138/0x160 > > [10047.814140][ T28] kthread+0x23c/0x260 > > [10047.821130][ T28] ret_from_fork+0x10/0x18 > > [10047.829181][ T28] Kernel Offset: disabled > > [10047.836274][ T28] CPU features: 0x0240002,20002004 > > [10047.844070][ T28] Memory Limit: none > > [10047.853599][ T28] ---[ end Kernel panic - not syncing: hung_task: > > blocked tasks ]--- > > > > if I build with KFENCE=n it boots up eventually, here's my .config file [2]. > > > > Any idea what may happen? > > > > it happens on next-20201109 also, but it takes longer until we get the > > "Call trace:". > > > > Cheers, > > Anders > > [1] http://ix.io/2Ddv > > [2] > > https://people.linaro.org/~anders.roxell/allmodconfig-next-20201105.config > > Hi Anders, Hi Dmitry, > > Does it happen during boot or afterwards? During boot, since it runs a lot of boot selftests. > 10047 are seconds after boot, right? No > So this is like 3 hours after boot, no? This is a boot log where I actually get to the boot prompt. https://people.linaro.org/~anders.roxell/output-next-20201109-nokfence.log > Also, is there anything useful before that part of the log? oh I missed to say that this is the full boot log with the kernel panic http://ix.io/2Ddv Cheers, Anders
Re: jitterentropy: `jent_mod_init()` takes 17 ms
Am Montag, 9. November 2020, 20:31:02 CET schrieb Paul Menzel: Hi Paul, > Dear Linux folks, > > > By mistake I built `XFRM_ESP` into the Linux kernel, resulting in > > CONFIG_CRYPTO_SEQIV=y > CONFIG_CRYPTO_ECHAINIV=y > > and also the Jitterentropy RNG to be built in. > > CRYPTO_JITTERENTROPY=y > > So, on the Asus F2A85-M PRO starting Linux 4.10-rc3 with > `initcall_debug`, the init method is run unconditionally, and it takes > 17.5 ms, which is over ten percent of the overall 900 ms the Linux Hm, 17.5 / 900 = 2%, or am I missing something? > kernel needs until loading the init process. > > [0.300544] calling jent_mod_init+0x0/0x2c @ 1 > [0.318438] initcall jent_mod_init+0x0/0x2c returned 0 after > 17471 usecs > > Looking at the output of systemd-bootchart, it looks like, that this > indeed delayed the boot a little, as the other init methods seem to be > ordered after it. > > I am now building it as a module, but am wondering if the time can be > reduced to below ten milliseconds. What you see is the test whether the Jitter RNG has a proper noise source. The function jent_entropy_init() is the cause of the operation. It performs 1024 times a test to validate the appropriateness of the noise source. You can adjust that with the TESTLOOPCOUNT in this function. But I am not sure adjusting is a wise course of action. Ciao Stephan
[RESEND PATCH] libfs: fix error cast of negative value in simple_attr_write()
The attr->set() receive a value of u64, but simple_strtoll() is used
for doing the conversion. It will lead to the error cast if user inputs
a negative value.
Use kstrtoull() instead of simple_strtoll() to convert a string got
from the user to an unsigned value. The former will return '-EINVAL' if
it gets a negetive value, but the latter can't handle the situation
correctly.
Fixes: f7b88631a897 ("fs/libfs.c: fix simple_attr_write() on 32bit machines")
Signed-off-by: Yicong Yang
---
fs/libfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/libfs.c b/fs/libfs.c
index fc34361..2dcf40e 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -977,7 +977,9 @@ ssize_t simple_attr_write(struct file *file, const char
__user *buf,
goto out;
attr->set_buf[size] = '\0';
- val = simple_strtoll(attr->set_buf, NULL, 0);
+ ret = kstrtoull(attr->set_buf, 0, );
+ if (ret)
+ goto out;
ret = attr->set(attr->data, val);
if (ret == 0)
ret = len; /* on success, claim we got the whole input */
--
2.8.1
Re: [PATCH] mm/zsmalloc: include sparsemem.h for MAX_PHYSMEM_BITS
On 2020-11-08 07:46, Mike Rapoport wrote:
> On Sat, Nov 07, 2020 at 04:22:06PM +0100, Stefan Agner wrote:
>> Most architectures define MAX_PHYSMEM_BITS in asm/sparsemem.h and don't
>> include it in asm/pgtable.h. Include asm/sparsemem.h directly to get
>> the MAX_PHYSMEM_BITS define on all architectures.
>>
>> This fixes a crash when accessing zram on 32-bit ARM platform with LPAE and
>> more than 4GB of memory:
>> Unable to handle kernel NULL pointer dereference at virtual address
>>
>> pgd = a27bd01c
>> [] *pgd=236a0003, *pmd=1ffa64003
>> Internal error: Oops: 207 [#1] SMP ARM
>> Modules linked in: mdio_bcm_unimac(+) brcmfmac cfg80211 brcmutil
>> raspberrypi_hwmon hci_uart crc32_arm_ce bcm2711_thermal phy_generic genet
>> CPU: 0 PID: 123 Comm: mkfs.ext4 Not tainted 5.9.6 #1
>> Hardware name: BCM2711
>> PC is at zs_map_object+0x94/0x338
>> LR is at zram_bvec_rw.constprop.0+0x330/0xa64
>> pc : []lr : []psr: 6013
>> sp : e376bbe0 ip : fp : c1e2921c
>> r10: 0002 r9 : c1dda730 r8 :
>> r7 : e8ff7a00 r6 : r5 : 02f9ffa0 r4 : e371
>> r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 :
>> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
>> Control: 30c5383d Table: 235c2a80 DAC: fffd
>> Process mkfs.ext4 (pid: 123, stack limit = 0x495a22e6)
>> Stack: (0xe376bbe0 to 0xe376c000)
>> ...
>> [] (zs_map_object) from []
>> (zram_bvec_rw.constprop.0+0x330/0xa64)
>> [] (zram_bvec_rw.constprop.0) from []
>> (zram_submit_bio+0x1a4/0x40c)
>> [] (zram_submit_bio) from []
>> (submit_bio_noacct+0xd0/0x3c8)
>> [] (submit_bio_noacct) from [] (submit_bio+0x4c/0x190)
>> [] (submit_bio) from [] (submit_bh_wbc+0x188/0x1b8)
>> [] (submit_bh_wbc) from []
>> (__block_write_full_page+0x340/0x5e4)
>> [] (__block_write_full_page) from []
>> (block_write_full_page+0x128/0x170)
>> [] (block_write_full_page) from []
>> (__writepage+0x14/0x68)
>> [] (__writepage) from []
>> (write_cache_pages+0x1bc/0x494)
>> [] (write_cache_pages) from []
>> (generic_writepages+0x58/0x8c)
>> [] (generic_writepages) from []
>> (do_writepages+0x48/0xec)
>> [] (do_writepages) from []
>> (__filemap_fdatawrite_range+0xf0/0x128)
>> [] (__filemap_fdatawrite_range) from []
>> (file_write_and_wait_range+0x48/0x98)
>> [] (file_write_and_wait_range) from []
>> (blkdev_fsync+0x1c/0x44)
>> [] (blkdev_fsync) from [] (do_fsync+0x3c/0x70)
>> [] (do_fsync) from [] (__sys_trace_return+0x0/0x2c)
>> Exception stack(0xe376bfa8 to 0xe376bff0)
>> bfa0: 0003d2e0 b6f7b6f0 0003 00046e40 1000
>>
>> bfc0: 0003d2e0 b6f7b6f0 0076 befcbb20
>> befcbb28
>> bfe0: b6f4e060 befcbad8 b6f23e0c b6dc4a80
>> Code: e5927000 e0050391 e0871005 e5918018 (e5983000)
>>
>> Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library")
>> Signed-off-by: Stefan Agner
>> ---
>> mm/zsmalloc.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
>> index c36fdff9a371..260bd48aacd0 100644
>> --- a/mm/zsmalloc.c
>> +++ b/mm/zsmalloc.c
>> @@ -40,6 +40,7 @@
>> #include
>> #include
>> #include
>> +#include
>
> asm/sparsemem.h is not available on some architectures.
> It's better to use linux/mmzone.h instead.
>
Hm, linux/mmzone.h only includes asm/sparsemem.h when CONFIG_SPARSEMEM
is enabled. However, on ARM at least I can have configurations without
CONFIG_SPARSEMEM and physical address extension on (e.g.
multi_v7_defconfig + CONFIG_LPAE + CONFIG_ZSMALLOC).
While sparsemem seems to be a good idea with LPAE it really seems not
required (see also https://lore.kernel.org/patchwork/patch/567589/).
There seem to be also other architectures which define MAX_PHYSMEM_BITS
only when SPARSEMEM is enabled, e.g.
arch/riscv/include/asm/sparsemem.h...
Not sure how to get out of this.. Maybe make ZSMALLOC dependent on
SPARSEMEM? It feels a bit silly restricting ZSMALLOC selection only due
to a compile time define...
--
Stefan
>> #include
>> #include
>> #include
>> --
>> 2.29.1
>>
>>
Re: [PATCH 05/10] ARM: dts: BCM5301X: Provide defaults ports container node
10.11.2020 04:31, Florian Fainelli wrote:
Provide an empty 'ports' container node with the correct #address-cells
and #size-cells properties. This silences the following warning:
arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dt.yaml:
ethernet-switch@18007000: 'oneOf' conditional failed, one must be fixed:
'ports' is a required property
'ethernet-ports' is a required property
From schema:
Documentation/devicetree/bindings/net/dsa/b53.yaml
Signed-off-by: Florian Fainelli
---
arch/arm/boot/dts/bcm5301x.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index 807580dd89f5..89993a8a6765 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -489,6 +489,10 @@ srab: ethernet-switch@18007000 {
status = "disabled";
/* ports are defined in board DTS */
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
You can drop those two lines from board files now I believe.
grep "ports {" arch/arm/boot/dts/bcm470*
+ arch/arm/boot/dts/bcm953012er.dts
Re: [PATCH v3 23/26] coresight: etm4x: Detect system instructions support
On 11/9/20 8:22 PM, Mathieu Poirier wrote:
On Wed, Oct 28, 2020 at 10:09:42PM +, Suzuki K Poulose wrote:
ETM v4.4 onwards adds support for system instruction access
to the ETM. Detect the support on an ETM and switch to using the
mode when available.
Signed-off-by: Suzuki K Poulose
---
.../coresight/coresight-etm4x-core.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index 4bc2f15b6332..dc537b5612eb 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -675,6 +675,37 @@ static const struct coresight_ops etm4_cs_ops = {
.source_ops = _source_ops,
};
+static inline bool cpu_supports_sysreg_trace(void)
+{
+ u64 dfr0 = read_sysreg_s(SYS_ID_AA64DFR0_EL1);
+
+ return ((dfr0 >> ID_AA64DFR0_TRACEVER_SHIFT) & 0xfUL) > 0;
I would do:
return ((dfr0 >> ID_AA64DFR0_TRACEVER_SHIFT) & 0xfUL) == 1;
Because any other value than '1' are reserved.
Correct. However, this is something we follow for all ID features
in the arm64 kernel and is clarified in the Arm ARM (ARM DDI 0487F.a) :
"D13.1.3 Principles of the ID scheme for fields in ID registers"
Which guarantees that a (field > n) implies, everything that field == n
is implied. (Well there are exceptions listed in the section, but
TRACEVER is not one of those). So this should cover an old kernel
running on a future CPU, using the features that it understands.
(See feature_matches() in arch/arm64/kernel/cpufeature.c, which is
the fundamental logic to detect a feature).
Please let me know if you're OK with the justification.
Thanks for the review.
Suzuki
Re: [PATCH 8/8] WIP: add a dma_alloc_contiguous API
Hi Christoph On Tue, Nov 10, 2020 at 10:25 AM Christoph Hellwig wrote: > > On Mon, Nov 09, 2020 at 03:53:55PM +0100, Ricardo Ribalda wrote: > > Hi Christoph > > > > I have started now to give a try to your patchset. Sorry for the delay. > > > > For uvc I have prepared this patch: > > https://github.com/ribalda/linux/commit/9094fe223fe38f8c8ff21366d893b43cbbdf0113 > > > > I have tested successfully in a x86_64 noteboot..., yes I know there > > is no change for that platform :). > > I am trying to get hold of an arm device that can run the latest > > kernel from upstream. > > > > On the meanwhile if you could take a look to the patch to verify that > > this the way that you expect the drivers to use your api I would > > appreciate it > > This looks pretty reaosnable. > Great Also FYI, I managed to boot an ARM device with that tree. But I could not test the uvc driver (it was a remote device with no usb device attached) Hopefully I will be able to test it for real this week. Any suggestions for how to measure performance difference? Thanks! > Note that ifdef CONFIG_DMA_NONCOHERENT in the old code doesn't actually > work, as that option is an internal thing just for mips and sh.. -- Ricardo Ribalda
Re: [PATCH v8 -tip 13/26] kernel/entry: Add support for core-wide protection of kernel-mode
On 11/3/20 2:20 AM, Joel Fernandes wrote: Hi Alexandre, Sorry for late reply as I was working on the snapshotting patch... On Fri, Oct 30, 2020 at 11:29:26AM +0100, Alexandre Chartre wrote: On 10/20/20 3:43 AM, Joel Fernandes (Google) wrote: Core-scheduling prevents hyperthreads in usermode from attacking each other, but it does not do anything about one of the hyperthreads entering the kernel for any reason. This leaves the door open for MDS and L1TF attacks with concurrent execution sequences between hyperthreads. This patch therefore adds support for protecting all syscall and IRQ kernel mode entries. Care is taken to track the outermost usermode exit and entry using per-cpu counters. In cases where one of the hyperthreads enter the kernel, no additional IPIs are sent. Further, IPIs are avoided when not needed - example: idle and non-cookie HTs do not need to be forced into kernel mode. Hi Joel, In order to protect syscall/IRQ kernel mode entries, shouldn't we have a call to sched_core_unsafe_enter() in the syscall/IRQ entry code? I don't see such a call. Am I missing something? Yes, this is known bug and fixed in v9 which I'll post soon. Meanwhile updated patch is appended below: See comments below about the updated patch. ---8<--- From b2835a587a28405ffdf8fc801e798129a014a8c8 Mon Sep 17 00:00:00 2001 From: "Joel Fernandes (Google)" Date: Mon, 27 Jul 2020 17:56:14 -0400 Subject: [PATCH] kernel/entry: Add support for core-wide protection of kernel-mode Core-scheduling prevents hyperthreads in usermode from attacking each other, but it does not do anything about one of the hyperthreads entering the kernel for any reason. This leaves the door open for MDS and L1TF attacks with concurrent execution sequences between hyperthreads. This patch therefore adds support for protecting all syscall and IRQ kernel mode entries. Care is taken to track the outermost usermode exit and entry using per-cpu counters. In cases where one of the hyperthreads enter the kernel, no additional IPIs are sent. Further, IPIs are avoided when not needed - example: idle and non-cookie HTs do not need to be forced into kernel mode. More information about attacks: For MDS, it is possible for syscalls, IRQ and softirq handlers to leak data to either host or guest attackers. For L1TF, it is possible to leak to guest attackers. There is no possible mitigation involving flushing of buffers to avoid this since the execution of attacker and victims happen concurrently on 2 or more HTs. Cc: Julien Desfossez Cc: Tim Chen Cc: Aaron Lu Cc: Aubrey Li Cc: Tim Chen Cc: Paul E. McKenney Co-developed-by: Vineeth Pillai Tested-by: Julien Desfossez Signed-off-by: Vineeth Pillai Signed-off-by: Joel Fernandes (Google) --- .../admin-guide/kernel-parameters.txt | 9 + include/linux/entry-common.h | 6 +- include/linux/sched.h | 12 + kernel/entry/common.c | 28 ++- kernel/sched/core.c | 230 ++ kernel/sched/sched.h | 3 + 6 files changed, 285 insertions(+), 3 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 3236427e2215..a338d5d64c3d 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4678,6 +4678,15 @@ sbni= [NET] Granch SBNI12 leased line adapter + sched_core_protect_kernel= + [SCHED_CORE] Pause SMT siblings of a core running in + user mode, if at least one of the siblings of the core + is running in kernel mode. This is to guarantee that + kernel data is not leaked to tasks which are not trusted + by the kernel. A value of 0 disables protection, 1 + enables protection. The default is 1. Note that protection + depends on the arch defining the _TIF_UNSAFE_RET flag. + sched_debug [KNL] Enables verbose scheduler debug messages. schedstats= [KNL,X86] Enable or disable scheduled statistics. diff --git a/include/linux/entry-common.h b/include/linux/entry-common.h index 474f29638d2c..62278c5b3b5f 100644 --- a/include/linux/entry-common.h +++ b/include/linux/entry-common.h @@ -33,6 +33,10 @@ # define _TIF_PATCH_PENDING (0) #endif +#ifndef _TIF_UNSAFE_RET +# define _TIF_UNSAFE_RET (0) +#endif + #ifndef _TIF_UPROBE # define _TIF_UPROBE (0) #endif @@ -69,7 +73,7 @@ #define EXIT_TO_USER_MODE_WORK \ (_TIF_SIGPENDING | _TIF_NOTIFY_RESUME | _TIF_UPROBE | \ -_TIF_NEED_RESCHED | _TIF_PATCH_PENDING | \ +_TIF_NEED_RESCHED | _TIF_PATCH_PENDING | _TIF_UNSAFE_RET | \ ARCH_EXIT_TO_USER_MODE_WORK)
[PATCH] rtc: cpcap: Fix missing IRQF_ONESHOT as only threaded handler
Coccinelle noticed:
drivers/rtc/rtc-cpcap.c:271:7-32: ERROR: Threaded IRQ with no
primary handler requested without IRQF_ONESHOT
drivers/rtc/rtc-cpcap.c:287:7-32: ERROR: Threaded IRQ with no
primary handler requested without IRQF_ONESHOT
Signed-off-by: Tian Tao
---
drivers/rtc/rtc-cpcap.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-cpcap.c b/drivers/rtc/rtc-cpcap.c
index 800667d..38d576b 100644
--- a/drivers/rtc/rtc-cpcap.c
+++ b/drivers/rtc/rtc-cpcap.c
@@ -269,7 +269,8 @@ static int cpcap_rtc_probe(struct platform_device *pdev)
rtc->alarm_irq = platform_get_irq(pdev, 0);
err = devm_request_threaded_irq(dev, rtc->alarm_irq, NULL,
- cpcap_rtc_alarm_irq, IRQF_TRIGGER_NONE,
+ cpcap_rtc_alarm_irq,
+ IRQF_TRIGGER_NONE | IRQF_ONESHOT,
"rtc_alarm", rtc);
if (err) {
dev_err(dev, "Could not request alarm irq: %d\n", err);
@@ -285,7 +286,8 @@ static int cpcap_rtc_probe(struct platform_device *pdev)
*/
rtc->update_irq = platform_get_irq(pdev, 1);
err = devm_request_threaded_irq(dev, rtc->update_irq, NULL,
- cpcap_rtc_update_irq, IRQF_TRIGGER_NONE,
+ cpcap_rtc_update_irq,
+ IRQF_TRIGGER_NONE | IRQF_ONESHOT,
"rtc_1hz", rtc);
if (err) {
dev_err(dev, "Could not request update irq: %d\n", err);
--
2.7.4
