[PATCH] arch: arm: mach-sa1100: Remove duplicate include
linux/tty.h has been included at line 13, so remove the duplicate one at line 21. Signed-off-by: Wan Jiabing --- arch/arm/mach-sa1100/hackkit.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-sa1100/hackkit.c b/arch/arm/mach-sa1100/hackkit.c index 3085f1c2e586..3fe34ee7c0ab 100644 --- a/arch/arm/mach-sa1100/hackkit.c +++ b/arch/arm/mach-sa1100/hackkit.c @@ -18,7 +18,6 @@ #include #include #include -#include #include #include #include -- 2.25.1
Re: [PATCH] soundwire: add slave device to linked list after device_register()
On 23-03-21, 10:25, Bard Liao wrote:
> From: Pierre-Louis Bossart
>
> We currently add the slave device to a linked list before
> device_register(), and then remove it if device_register() fails.
>
> It's not clear why this sequence was necessary, this patch moves the
> linked list management to after the device_register().
Maybe add a comment :-)
The reason here is that before calling device_register() we need to be
ready and completely initialized. device_register is absolutely the last
step in the flow, always.
The probe of the device can happen and before you get a chance to
add to list, many number of things can happen.. So adding after is not a
very good idea :)
HTH
>
> Suggested-by: Keyon Jie
> Signed-off-by: Pierre-Louis Bossart
> Reviewed-by: Guennadi Liakhovetski
> Signed-off-by: Bard Liao
> ---
> drivers/soundwire/slave.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/soundwire/slave.c b/drivers/soundwire/slave.c
> index 112b21967c7a..0c92db2e1ddc 100644
> --- a/drivers/soundwire/slave.c
> +++ b/drivers/soundwire/slave.c
> @@ -65,9 +65,6 @@ int sdw_slave_add(struct sdw_bus *bus,
> for (i = 0; i < SDW_MAX_PORTS; i++)
> init_completion(&slave->port_ready[i]);
>
> - mutex_lock(&bus->bus_lock);
> - list_add_tail(&slave->node, &bus->slaves);
> - mutex_unlock(&bus->bus_lock);
>
> ret = device_register(&slave->dev);
> if (ret) {
> @@ -77,13 +74,15 @@ int sdw_slave_add(struct sdw_bus *bus,
>* On err, don't free but drop ref as this will be freed
>* when release method is invoked.
>*/
> - mutex_lock(&bus->bus_lock);
> - list_del(&slave->node);
> - mutex_unlock(&bus->bus_lock);
> put_device(&slave->dev);
>
> return ret;
> }
> +
> + mutex_lock(&bus->bus_lock);
> + list_add_tail(&slave->node, &bus->slaves);
> + mutex_unlock(&bus->bus_lock);
> +
> sdw_slave_debugfs_init(slave);
>
> return ret;
> --
> 2.17.1
--
~Vinod
Re: [PATCH] usb: gadget: Stall OS descriptor request for unsupported functions
On 3/22/2021 11:25 PM, Jack Pham wrote: > Hi Wesley, > > On Mon, Mar 22, 2021 at 06:50:17PM -0700, Wesley Cheng wrote: >> From: Chandana Kishori Chiluveru >> >> Hosts which request "OS descriptors" from gadgets do so during >> the enumeration phase and before the configuration is set with >> SET_CONFIGURATION. Composite driver supports OS descriptor >> handling in composite_setup function. This requires to pass >> signature field, vendor code, compatibleID and subCompatibleID >> from user space. >> >> For USB compositions that contain functions which don't implement os >> descriptors, Windows is sending vendor specific requests for os >> descriptors and composite driver handling this request with invalid >> data. With this invalid info host resetting the bus and never >> selecting the configuration and leading enumeration issue. >> >> Fix this by bailing out from the OS descriptor setup request >> handling if the functions does not have OS descriptors compatibleID. >> >> Signed-off-by: Chandana Kishori Chiluveru >> Signed-off-by: Wesley Cheng >> --- >> drivers/usb/gadget/composite.c | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c >> index 72a9797..473edda6 100644 >> --- a/drivers/usb/gadget/composite.c >> +++ b/drivers/usb/gadget/composite.c >> @@ -1945,6 +1945,12 @@ composite_setup(struct usb_gadget *gadget, const >> struct usb_ctrlrequest *ctrl) >> buf[6] = w_index; >> /* Number of ext compat interfaces */ >> count = count_ext_compat(os_desc_cfg); >> +/* >> + * Bailout if device does not >> + * have ext_compat interfaces. >> + */ >> +if (count == 0) >> +break; >> buf[8] = count; >> count *= 24; /* 24 B/ext compat desc */ >> count += 16; /* header */ > > Do we still need this fix? IIRC we had this change in our downstream > kernel to fix the case when dynamically re-configuring ConfigFS, i.e. > changing the composition of functions wherein none of the interfaces > support OS Descriptors, so this causes count_ext_compat() to return > 0 and results in the issue described in $SUBJECT. > Hi Jack, You're correct. We can address this as well in the userspace perspective. > But I think this is more of a problem of an improperly configured > ConfigFS gadget. If userspace instead removes the config from the > gadget's os_desc subdirectory that should cause cdev->os_desc_config to > be set to NULL and hence composite_setup() should never enter this > handling at all, right? Sure, I'll go with fixing it in the userspace, since the support to stall the OS desc is already present in the composite driver as you mentioned. Thanks for the input. Thanks Wesley Cheng -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v2] kdb: Get rid of custom debug heap allocator
Currently the only user for debug heap is kdbnearsym() which can be
modified to rather use statically allocated buffer for symbol name as
per it's current usage. So do that and hence remove custom debug heap
allocator.
Note that this change puts a restriction on kdbnearsym() callers to
carefully use shared namebuf such that a caller should consume the symbol
returned immediately prior to another call to fetch a different symbol.
This change has been tested using kgdbtest on arm64 which doesn't show
any regressions.
Suggested-by: Daniel Thompson
Signed-off-by: Sumit Garg
---
Changes in v2:
- Use single static buffer for symbol name in kdbnearsym() instead of
per caller buffers allocated on stack.
kernel/debug/kdb/kdb_debugger.c | 1 -
kernel/debug/kdb/kdb_private.h | 5 -
kernel/debug/kdb/kdb_support.c | 318 ++--
3 files changed, 15 insertions(+), 309 deletions(-)
diff --git a/kernel/debug/kdb/kdb_debugger.c b/kernel/debug/kdb/kdb_debugger.c
index 0220afda3200..e91fc3e4edd5 100644
--- a/kernel/debug/kdb/kdb_debugger.c
+++ b/kernel/debug/kdb/kdb_debugger.c
@@ -140,7 +140,6 @@ int kdb_stub(struct kgdb_state *ks)
*/
kdb_common_deinit_state();
KDB_STATE_CLEAR(PAGER);
- kdbnearsym_cleanup();
if (error == KDB_CMD_KGDB) {
if (KDB_STATE(DOING_KGDB))
KDB_STATE_CLEAR(DOING_KGDB);
diff --git a/kernel/debug/kdb/kdb_private.h b/kernel/debug/kdb/kdb_private.h
index b857a84de3b5..ec91d7e02334 100644
--- a/kernel/debug/kdb/kdb_private.h
+++ b/kernel/debug/kdb/kdb_private.h
@@ -109,7 +109,6 @@ extern int kdbgetaddrarg(int, const char **, int*, unsigned
long *,
long *, char **);
extern int kdbgetsymval(const char *, kdb_symtab_t *);
extern int kdbnearsym(unsigned long, kdb_symtab_t *);
-extern void kdbnearsym_cleanup(void);
extern char *kdb_strdup(const char *str, gfp_t type);
extern void kdb_symbol_print(unsigned long, const kdb_symtab_t *, unsigned
int);
@@ -233,10 +232,6 @@ extern struct task_struct *kdb_curr_task(int);
#define GFP_KDB (in_dbg_master() ? GFP_ATOMIC : GFP_KERNEL)
-extern void *debug_kmalloc(size_t size, gfp_t flags);
-extern void debug_kfree(void *);
-extern void debug_kusage(void);
-
extern struct task_struct *kdb_current_task;
extern struct pt_regs *kdb_current_regs;
diff --git a/kernel/debug/kdb/kdb_support.c b/kernel/debug/kdb/kdb_support.c
index b59aad1f0b55..e131d74abb8d 100644
--- a/kernel/debug/kdb/kdb_support.c
+++ b/kernel/debug/kdb/kdb_support.c
@@ -57,35 +57,26 @@ int kdbgetsymval(const char *symname, kdb_symtab_t *symtab)
}
EXPORT_SYMBOL(kdbgetsymval);
-static char *kdb_name_table[100]; /* arbitrary size */
-
/*
- * kdbnearsym -Return the name of the symbol with the nearest address
- * less than 'addr'.
+ * kdbnearsym() - Return the name of the symbol with the nearest address
+ *less than @addr.
+ * @addr: Address to check for near symbol
+ * @symtab: Structure to receive results
*
- * Parameters:
- * addrAddress to check for symbol near
- * symtab Structure to receive results
- * Returns:
- * 0 No sections contain this address, symtab zero filled
- * 1 Address mapped to module/symbol/section, data in symtab
- * Remarks:
- * 2.6 kallsyms has a "feature" where it unpacks the name into a
- * string. If that string is reused before the caller expects it
- * then the caller sees its string change without warning. To
- * avoid cluttering up the main kdb code with lots of kdb_strdup,
- * tests and kfree calls, kdbnearsym maintains an LRU list of the
- * last few unique strings. The list is sized large enough to
- * hold active strings, no kdb caller of kdbnearsym makes more
- * than ~20 later calls before using a saved value.
+ * Note here that only single statically allocated namebuf is used for every
+ * symbol, so the caller should consume it immediately prior to another call
+ * to fetch a different symbol.
+ *
+ * Return:
+ * * 0 - No sections contain this address, symtab zero filled
+ * * 1 - Address mapped to module/symbol/section, data in symtab
*/
int kdbnearsym(unsigned long addr, kdb_symtab_t *symtab)
{
int ret = 0;
unsigned long symbolsize = 0;
unsigned long offset = 0;
-#define knt1_size 128 /* must be >= kallsyms table size */
- char *knt1 = NULL;
+ static char namebuf[KSYM_NAME_LEN];
if (KDB_DEBUG(AR))
kdb_printf("kdbnearsym: addr=0x%lx, symtab=%px\n", addr,
symtab);
@@ -93,14 +84,9 @@ int kdbnearsym(unsigned long addr, kdb_symtab_t *symtab)
if (addr < 4096)
goto out;
- knt1 = debug_kmalloc(knt1_size, GFP_ATOMIC);
- if (!knt1) {
- kdb_printf("kdbnearsym: addr=0x%lx cannot kmalloc knt1\n",
- addr);
- goto out;
- }
+
symtab->sym_name = kal
RE: Re: Re: [PATCH 1/3] dt-bindings: imx6q-pcie: specify the imx8mq pcie phy voltage
> -Original Message- > From: Lucas Stach > Sent: Monday, March 22, 2021 8:15 PM > To: Richard Zhu ; andrew.smir...@gmail.com; > shawn...@kernel.org; k...@linux.com; bhelg...@google.com; > ste...@agner.ch; lorenzo.pieral...@arm.com > Cc: linux-...@vger.kernel.org; dl-linux-imx ; > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; > ker...@pengutronix.de > Subject: [EXT] Re: Re: [PATCH 1/3] dt-bindings: imx6q-pcie: specify the > imx8mq pcie phy voltage > Hi Richard, > > Am Montag, dem 22.03.2021 um 09:06 + schrieb Richard Zhu: > > > -Original Message- > > > From: Lucas Stach > > > Sent: Friday, March 19, 2021 5:49 PM > > > To: Richard Zhu ; andrew.smir...@gmail.com; > > > shawn...@kernel.org; k...@linux.com; bhelg...@google.com; > > > ste...@agner.ch; lorenzo.pieral...@arm.com > > > Cc: linux-...@vger.kernel.org; dl-linux-imx ; > > > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; > > > ker...@pengutronix.de > > > Subject: Re: [PATCH 1/3] dt-bindings: imx6q-pcie: specify the > > > imx8mq pcie phy voltage Am Freitag, dem 19.03.2021 um 16:24 +0800 > > > schrieb Richard Zhu: > > > > Both 1.8v and 3.3v power supplies can be feeded to i.MX8MQ PCIe > > > > PHY. > > > > In default, the PCIE_VPH voltage is suggested to be 1.8v refer to > > > > data sheet. When PCIE_VPH is supplied by 3.3v in the HW schematic > > > > design, the VREG_BYPASS bits of GPR registers should be cleared > > > > from default value 1b'1 to 1b'0. > > > > > > > > Signed-off-by: Richard Zhu > > > > --- > > > > Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 4 > > > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q- > > > > pcie.txt > > > > b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt > > > > index de4b2baf91e8..23efbad9e804 100644 > > > > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt > > > > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt > > > > @@ -59,6 +59,10 @@ Additional required properties for imx7d-pcie > > > > and > > > imx8mq-pcie: > > > > Additional required properties for imx8mq-pcie: > > > > - clock-names: Must include the following additional entries: > > > > - "pcie_aux" > > > > +- pcie-vph-3v3: If present then PCIE_VPH is feeded by 3.3v in > > > > the HW > > > > + schematic design. The PCIE_VPH is suggested to be 1.8v refer > > > > to the > > > > + data sheet. If the PCIE_VPH is supplied by 3.3V, the > > > > VREG_BYPASS > > > > + should be cleared to zero accordingly. > > > > > > Uhm, no. Please don't add boolean DT properties for random parts of > > > the board design. > > > > > > If we need to know the voltage of PCIE_VPH, we should really add the > > > VPH regulator as a supply to the PCIe controller node, then work out > > > the voltage the usual way by using the Linux regulator API. > > > > > [Richard Zhu] Hi Lucas: > > Thanks for your comments. Since the vgen5_reg is used to power up PCIe > > PHY on i.MX8MQ EVK board, and it's set to be "regulator-always-on;". > > Did only the regulator_get_voltage or combined with > > regulator_enable/regulator_disable can be used in the driver? > > The regulator API doesn't care, you can call enable/disable in the driver as > normal. If the regulator is marked as always-on it will just stay enabled > even if > the use-count drops to 0. > > The other question however is if it's even allowed by the SoC design to > disable > this supply outside of deep power down. A quick look into the reference > manual and datasheet didn't yield any information about this. [Richard Zhu] Hi Lucas: Yes it is. The PCIe PHY power down manipulations are not described in the RM document. How about to get voltage here only currently, and the regulator enable/disable operations would be added further if these enable/disable operations are possible and required later? Best Regards Richard > > Regards, > Lucas
Re: [PATCH -next] powerpc: kernel/time.c - cleanup warnings
Dear Christophe, 在 2021/3/23 14:33, Christophe Leroy 写道: Le 23/03/2021 à 07:21, heying (H) a écrit : Dear Christophe, 在 2021/3/18 10:28, heying (H) 写道: 在 2021/3/17 19:16, Christophe Leroy 写道: Le 17/03/2021 à 11:34, He Ying a écrit : We found these warnings in arch/powerpc/kernel/time.c as follows: warning: symbol 'decrementer_max' was not declared. Should it be static? warning: symbol 'rtc_lock' was not declared. Should it be static? warning: symbol 'dtl_consumer' was not declared. Should it be static? Declare 'decrementer_max' in arch/powerpc/include/asm/time.h. And include proper header in which 'rtc_lock' is declared. Move 'dtl_consumer' definition behind "include " because 'dtl_consumer' is declared there. Reported-by: Hulk Robot Signed-off-by: He Ying --- arch/powerpc/include/asm/time.h | 1 + arch/powerpc/kernel/time.c | 7 +++ 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h index 8dd3cdb25338..2cd2b50bedda 100644 --- a/arch/powerpc/include/asm/time.h +++ b/arch/powerpc/include/asm/time.h @@ -22,6 +22,7 @@ extern unsigned long tb_ticks_per_jiffy; extern unsigned long tb_ticks_per_usec; extern unsigned long tb_ticks_per_sec; extern struct clock_event_device decrementer_clockevent; +extern u64 decrementer_max; extern void generic_calibrate_decr(void); diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index b67d93a609a2..409967713ca6 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -55,6 +55,7 @@ #include #include #include +#include I don't think that's the good place. It has no link to powerpc, it is only by chance that it has the same name. As rtc_lock is defined in powerpc time.c, I think you should declare it in powerpc asm/time.h My first thought was the same as yours. I tried to add declaration in powerpc asm/time.h, but got a compiling error: drivers/rtc/rtc-vr41xx.c:75:24: error: static declaration of ‘rtc_lock’ follows non-static declaration static DEFINE_SPINLOCK(rtc_lock); In file included from ./arch/powerpc/include/asm/delay.h:7:0, from ./arch/powerpc/include/asm/io.h:33, from ./include/linux/io.h:13, from drivers/rtc/rtc-vr41xx.c:11: ./arch/powerpc/include/asm/time.h:25:19: note: previous declaration of ‘rtc_lock’ was here extern spinlock_t rtc_lock; There's a conflict. Perhaps I can rename it in drivers/rtc/rtc-vr41xx.c. But I find an existing declaration in linux/mc146818rtc.h and there's only one definition for 'rtc_lock' in powerpc. There's some includes of mc146818rtc.h in powperc. I wonder they point to the same thing. But I'm not very sure because the header's name looks a bit strange. How about including mc146818rtc.h in powperpc kernel/time.c? May I have your opinions please? As I said, mc146818rtc.h is not related to powerpc, and if it works that's just chance, and there is no certainty that it will still work in the future. If you can't find a clean solution, it is better to leave the warning. OK. I see. Thanks for you relpy. I'll try to find some other better way. Thanks.
[PATCH v2] fs/dcache: fix typos and sentence disorder
change 'sould' to 'should'
change 'colocated' to 'co-located'
change 'talke' to 'take'
reorganize sentence
Signed-off-by: Xiaofeng Cao
---
v2:change 'colocated' to 'co-located' instead of 'collocated'
fs/dcache.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 7d24ff7eb206..c23834334314 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -741,7 +741,7 @@ static inline bool fast_dput(struct dentry *dentry)
unsigned int d_flags;
/*
-* If we have a d_op->d_delete() operation, we sould not
+* If we have a d_op->d_delete() operation, we should not
* let the dentry count go to zero, so use "put_or_lock".
*/
if (unlikely(dentry->d_flags & DCACHE_OP_DELETE))
@@ -1053,7 +1053,7 @@ struct dentry *d_find_alias_rcu(struct inode *inode)
struct dentry *de = NULL;
spin_lock(&inode->i_lock);
- // ->i_dentry and ->i_rcu are colocated, but the latter won't be
+ // ->i_dentry and ->i_rcu are co-located, but the latter won't be
// used without having I_FREEING set, which means no aliases left
if (likely(!(inode->i_state & I_FREEING) && !hlist_empty(l))) {
if (S_ISDIR(inode->i_mode)) {
@@ -1297,7 +1297,7 @@ void shrink_dcache_sb(struct super_block *sb)
EXPORT_SYMBOL(shrink_dcache_sb);
/**
- * enum d_walk_ret - action to talke during tree walk
+ * enum d_walk_ret - action to take during tree walk
* @D_WALK_CONTINUE: contrinue walk
* @D_WALK_QUIT: quit walk
* @D_WALK_NORETRY:quit when retry is needed
@@ -2156,8 +2156,8 @@ EXPORT_SYMBOL(d_obtain_alias);
*
* On successful return, the reference to the inode has been transferred
* to the dentry. In case of an error the reference on the inode is
- * released. A %NULL or IS_ERR inode may be passed in and will be the
- * error will be propagate to the return value, with a %NULL @inode
+ * released. A %NULL or IS_ERR inode may be passed in and the error will
+ * be propagated to the return value, with a %NULL @inode
* replaced by ERR_PTR(-ESTALE).
*/
struct dentry *d_obtain_root(struct inode *inode)
--
2.25.1
[PATCH -next] drm: Markdrm_send_event_helper with static keyword
Fix the following sparse warning:
drivers/gpu/drm/drm_file.c:789:6: warning: symbol 'drm_send_event_helper' was
not declared. Should it be static?
Signed-off-by: Zou Wei
---
drivers/gpu/drm/drm_file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 7efbccffc2ea..def5df9f19e3 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -786,8 +786,8 @@ EXPORT_SYMBOL(drm_event_cancel_free);
* The timestamp variant of dma_fence_signal is used when the caller
* sends a valid timestamp.
*/
-void drm_send_event_helper(struct drm_device *dev,
- struct drm_pending_event *e, ktime_t timestamp)
+static void drm_send_event_helper(struct drm_device *dev,
+ struct drm_pending_event *e, ktime_t
timestamp)
{
assert_spin_locked(&dev->event_lock);
--
2.17.1
Re: [PATCH] net: make unregister netdev warning timeout configurable
On Mon, Mar 22, 2021 at 8:26 PM David Miller wrote: > > From: Dmitry Vyukov > Date: Sat, 20 Mar 2021 15:28:51 +0100 > > > netdev_wait_allrefs() issues a warning if refcount does not drop to 0 > > after 10 seconds. While 10 second wait generally should not happen > > under normal workload in normal environment, it seems to fire falsely > > very often during fuzzing and/or in qemu emulation (~10x slower). > > At least it's not possible to understand if it's really a false > > positive or not. Automated testing generally bumps all timeouts > > to very high values to avoid flake failures. > > Make the timeout configurable for automated testing systems. > > Lowering the timeout may also be useful for e.g. manual bisection. > > The default value matches the current behavior. > > > > Signed-off-by: Dmitry Vyukov > > Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=211877 > > Cc: net...@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > I'd say a sysctl knob is much better than a compile time setting for this. > That way stock kernels can be used in these testing scenerios. FTR, I've mailed v2 with a sysctl: https://lore.kernel.org/netdev/20210323064923.2098711-1-dvyu...@google.com/T/#u
Re: [PATCH 0/5] soundwire: add missing \n in dev_err()
On 23-03-21, 08:58, Bard Liao wrote: > We fixed a lot of warnings in 2019 but the magic of copy-paste keeps > adding new ones... Applied, thanks -- ~Vinod
Re: [PATCH] f2fs: fix to avoid out-of-bounds memory access
Hi, I have tested the patch on 5.12.0-rc4+, it seems to fix the problem. Regards, butt3rflyh4ck. On Mon, Mar 22, 2021 at 7:47 PM Chao Yu wrote: > > butt3rflyh4ck reported a bug found by > syzkaller fuzzer with custom modifications in 5.12.0-rc3+ [1]: > > dump_stack+0xfa/0x151 lib/dump_stack.c:120 > print_address_description.constprop.0.cold+0x82/0x32c mm/kasan/report.c:232 > __kasan_report mm/kasan/report.c:399 [inline] > kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 > f2fs_test_bit fs/f2fs/f2fs.h:2572 [inline] > current_nat_addr fs/f2fs/node.h:213 [inline] > get_next_nat_page fs/f2fs/node.c:123 [inline] > __flush_nat_entry_set fs/f2fs/node.c:2888 [inline] > f2fs_flush_nat_entries+0x258e/0x2960 fs/f2fs/node.c:2991 > f2fs_write_checkpoint+0x1372/0x6a70 fs/f2fs/checkpoint.c:1640 > f2fs_issue_checkpoint+0x149/0x410 fs/f2fs/checkpoint.c:1807 > f2fs_sync_fs+0x20f/0x420 fs/f2fs/super.c:1454 > __sync_filesystem fs/sync.c:39 [inline] > sync_filesystem fs/sync.c:67 [inline] > sync_filesystem+0x1b5/0x260 fs/sync.c:48 > generic_shutdown_super+0x70/0x370 fs/super.c:448 > kill_block_super+0x97/0xf0 fs/super.c:1394 > > The root cause is, if nat entry in checkpoint journal area is corrupted, > e.g. nid of journalled nat entry exceeds max nid value, during checkpoint, > once it tries to flush nat journal to NAT area, get_next_nat_page() may > access out-of-bounds memory on nat_bitmap due to it uses wrong nid value > as bitmap offset. > > [1] > https://lore.kernel.org/lkml/cafco6xomwdr8pobek6en6-fs58kg9dorfadgjj-fnf-1x43...@mail.gmail.com/T/#u > > Reported-by: butt3rflyh4ck > Signed-off-by: Chao Yu > --- > fs/f2fs/node.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c > index caf43970510e..8311b2367c7c 100644 > --- a/fs/f2fs/node.c > +++ b/fs/f2fs/node.c > @@ -2790,6 +2790,9 @@ static void remove_nats_in_journal(struct f2fs_sb_info > *sbi) > struct f2fs_nat_entry raw_ne; > nid_t nid = le32_to_cpu(nid_in_journal(journal, i)); > > + if (f2fs_check_nid_range(sbi, nid)) > + continue; > + > raw_ne = nat_in_journal(journal, i); > > ne = __lookup_nat_cache(nm_i, nid); > -- > 2.29.2 >
[PATCH v2] net: make unregister netdev warning timeout configurable
netdev_wait_allrefs() issues a warning if refcount does not drop to 0
after 10 seconds. While 10 second wait generally should not happen
under normal workload in normal environment, it seems to fire falsely
very often during fuzzing and/or in qemu emulation (~10x slower).
At least it's not possible to understand if it's really a false
positive or not. Automated testing generally bumps all timeouts
to very high values to avoid flake failures.
Add net.core.netdev_unregister_timeout_secs sysctl to make
the timeout configurable for automated testing systems.
Lowering the timeout may also be useful for e.g. manual bisection.
The default value matches the current behavior.
Signed-off-by: Dmitry Vyukov
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=211877
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Changes since v1:
- use sysctl instead of a config
---
Documentation/admin-guide/sysctl/net.rst | 11 +++
include/linux/netdevice.h| 1 +
net/core/dev.c | 6 +-
net/core/sysctl_net_core.c | 10 ++
4 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/sysctl/net.rst
b/Documentation/admin-guide/sysctl/net.rst
index f2ab8a5b6a4b8..2090bfc69aa50 100644
--- a/Documentation/admin-guide/sysctl/net.rst
+++ b/Documentation/admin-guide/sysctl/net.rst
@@ -311,6 +311,17 @@ permit to distribute the load on several cpus.
If set to 1 (default), timestamps are sampled as soon as possible, before
queueing.
+netdev_unregister_timeout_secs
+--
+
+Unregister network device timeout in seconds.
+This option controls the timeout (in seconds) used to issue a warning while
+waiting for a network device refcount to drop to 0 during device
+unregistration. A lower value may be useful during bisection to detect
+a leaked reference faster. A larger value may be useful to prevent false
+warnings on slow/loaded systems.
+Default value is 10, minimum 0, maximum 3600.
+
optmem_max
--
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 87a5d186faff4..179c5693f5119 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -4611,6 +4611,7 @@ void dev_get_tstats64(struct net_device *dev, struct
rtnl_link_stats64 *s);
extern int netdev_max_backlog;
extern int netdev_tstamp_prequeue;
+extern int netdev_unregister_timeout_secs;
extern int weight_p;
extern int dev_weight_rx_bias;
extern int dev_weight_tx_bias;
diff --git a/net/core/dev.c b/net/core/dev.c
index 0f72ff5d34ba0..7accbd4a3bec1 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -10344,6 +10344,8 @@ int netdev_refcnt_read(const struct net_device *dev)
}
EXPORT_SYMBOL(netdev_refcnt_read);
+int netdev_unregister_timeout_secs __read_mostly = 10;
+
#define WAIT_REFS_MIN_MSECS 1
#define WAIT_REFS_MAX_MSECS 250
/**
@@ -10405,7 +10407,9 @@ static void netdev_wait_allrefs(struct net_device *dev)
refcnt = netdev_refcnt_read(dev);
- if (refcnt && time_after(jiffies, warning_time + 10 * HZ)) {
+ if (refcnt &&
+ time_after(jiffies, warning_time +
+ netdev_unregister_timeout_secs * HZ)) {
pr_emerg("unregister_netdevice: waiting for %s to
become free. Usage count = %d\n",
dev->name, refcnt);
warning_time = jiffies;
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index 4567de519603b..d84c8a1b280e2 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -24,6 +24,7 @@
static int two = 2;
static int three = 3;
+static int int_3600 = 3600;
static int min_sndbuf = SOCK_MIN_SNDBUF;
static int min_rcvbuf = SOCK_MIN_RCVBUF;
static int max_skb_frags = MAX_SKB_FRAGS;
@@ -570,6 +571,15 @@ static struct ctl_table net_core_table[] = {
.proc_handler = proc_dointvec_minmax,
.extra1 = SYSCTL_ONE,
},
+ {
+ .procname = "netdev_unregister_timeout_secs",
+ .data = &netdev_unregister_timeout_secs,
+ .maxlen = sizeof(unsigned int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = &int_3600,
+ },
{ }
};
base-commit: e0c755a45f6fb6e81e3a62a94db0400ef0cdc046
--
2.31.0.291.g576ba9dcdaf-goog
Re: [PATCH] soundwire: intel: move to auxiliary bus
On 23-03-21, 08:43, Bard Liao wrote:
> From: Pierre-Louis Bossart
>
> Now that the auxiliary_bus exists, there's no reason to use platform
> devices as children of a PCI device any longer.
>
> This patch refactors the code by extending a basic auxiliary device
> with Intel link-specific structures that need to be passed between
> controller and link levels. This refactoring is much cleaner with no
> need for cross-pointers between device and link structures.
>
> Note that the auxiliary bus API has separate init and add steps, which
> requires more attention in the error unwinding paths. The main loop
> needs to deal with kfree() and auxiliary_device_uninit() for the
> current iteration before jumping to the common label which releases
> everything allocated in prior iterations.
>
> Signed-off-by: Pierre-Louis Bossart
> Reviewed-by: Guennadi Liakhovetski
> Reviewed-by: Ranjani Sridharan
> Signed-off-by: Bard Liao
> ---
> drivers/soundwire/Kconfig | 1 +
> drivers/soundwire/intel.c | 52
> drivers/soundwire/intel.h | 14 +-
> drivers/soundwire/intel_init.c | 190 +++-
> include/linux/soundwire/sdw_intel.h | 6 +-
> 5 files changed, 175 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/soundwire/Kconfig b/drivers/soundwire/Kconfig
> index 016e74230bb7..2b7795233282 100644
> --- a/drivers/soundwire/Kconfig
> +++ b/drivers/soundwire/Kconfig
> @@ -25,6 +25,7 @@ config SOUNDWIRE_INTEL
> tristate "Intel SoundWire Master driver"
> select SOUNDWIRE_CADENCE
> select SOUNDWIRE_GENERIC_ALLOCATION
> + select AUXILIARY_BUS
> depends on ACPI && SND_SOC
> help
> SoundWire Intel Master driver.
> diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c
> index d2254ee2fee2..039a101982c9 100644
> --- a/drivers/soundwire/intel.c
> +++ b/drivers/soundwire/intel.c
> @@ -11,7 +11,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -1331,9 +1331,10 @@ static int intel_init(struct sdw_intel *sdw)
> /*
> * probe and init
> */
> -static int intel_master_probe(struct platform_device *pdev)
> +static int intel_link_probe(struct auxiliary_device *auxdev, const struct
> auxiliary_device_id *id)
> {
> - struct device *dev = &pdev->dev;
> + struct device *dev = &auxdev->dev;
> + struct sdw_intel_link_dev *ldev =
> auxiliary_dev_to_sdw_intel_link_dev(auxdev);
Do we need another abstractions for resources here, why not aux dev
creation set the resources required and we skip this step...
> struct sdw_intel *sdw;
> struct sdw_cdns *cdns;
> struct sdw_bus *bus;
> @@ -1346,14 +1347,14 @@ static int intel_master_probe(struct platform_device
> *pdev)
> cdns = &sdw->cdns;
> bus = &cdns->bus;
>
> - sdw->instance = pdev->id;
> - sdw->link_res = dev_get_platdata(dev);
> + sdw->instance = auxdev->id;
so auxdev has id and still we pass id as argument :( Not sure if folks
can fix this now
> + sdw->link_res = &ldev->link_res;
> cdns->dev = dev;
> cdns->registers = sdw->link_res->registers;
> cdns->instance = sdw->instance;
> cdns->msg_count = 0;
>
> - bus->link_id = pdev->id;
> + bus->link_id = auxdev->id;
>
> sdw_cdns_probe(cdns);
>
> @@ -1386,10 +1387,10 @@ static int intel_master_probe(struct platform_device
> *pdev)
> return 0;
> }
>
> -int intel_master_startup(struct platform_device *pdev)
> +int intel_link_startup(struct auxiliary_device *auxdev)
> {
> struct sdw_cdns_stream_config config;
> - struct device *dev = &pdev->dev;
> + struct device *dev = &auxdev->dev;
> struct sdw_cdns *cdns = dev_get_drvdata(dev);
> struct sdw_intel *sdw = cdns_to_intel(cdns);
> struct sdw_bus *bus = &cdns->bus;
> @@ -1526,9 +1527,9 @@ int intel_master_startup(struct platform_device *pdev)
> return ret;
> }
>
> -static int intel_master_remove(struct platform_device *pdev)
> +static void intel_link_remove(struct auxiliary_device *auxdev)
> {
> - struct device *dev = &pdev->dev;
> + struct device *dev = &auxdev->dev;
> struct sdw_cdns *cdns = dev_get_drvdata(dev);
> struct sdw_intel *sdw = cdns_to_intel(cdns);
> struct sdw_bus *bus = &cdns->bus;
> @@ -1544,19 +1545,17 @@ static int intel_master_remove(struct platform_device
> *pdev)
> snd_soc_unregister_component(dev);
> }
> sdw_bus_master_delete(bus);
> -
> - return 0;
> }
>
> -int intel_master_process_wakeen_event(struct platform_device *pdev)
> +int intel_link_process_wakeen_event(struct auxiliary_device *auxdev)
> {
> - struct device *dev = &pdev->dev;
> + struct device *dev = &auxdev->dev;
> struct sdw_intel *sdw;
> struct sdw_bus *bus;
> void __iomem *shim;
> u16 wake_sts;
>
> - sdw = platform_get_drvdata(pdev);
> + sdw = dev_get_drvdata(dev);
N
Re: [PATCH v31 2/4] scsi: ufs: L2P map management for HPB read
On 2021-03-23 14:37, Daejun Park wrote:
On 2021-03-23 14:19, Daejun Park wrote:
On 2021-03-23 13:37, Daejun Park wrote:
On 2021-03-23 12:22, Can Guo wrote:
On 2021-03-22 17:11, Bean Huo wrote:
On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:
+ switch (rsp_field->hpb_op) {
+ case HPB_RSP_REQ_REGION_UPDATE:
+ if (data_seg_len != DEV_DATA_SEG_LEN)
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"%s: data seg length is not
same.\n",
+__func__);
+ ufshpb_rsp_req_region_update(hpb, rsp_field);
+ break;
+ case HPB_RSP_DEV_RESET:
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"UFS device lost HPB information
during
PM.\n");
+ break;
Hi Deajun,
This series looks good to me. Just here I have one question. You
didn't
handle HPB_RSP_DEV_RESET, just a warning. Based on your SS UFS,
how
to
handle HPB_RSP_DEV_RESET from the host side? Do you think we
shoud
reset host side HPB entry as well or what else?
Bean
Same question here - I am still collecting feedbacks from flash
vendors
about
what is recommanded host behavior on reception of HPB Op code
0x2,
since it
is not cleared defined in HPB2.0 specs.
Can Guo.
I think the question should be asked in the HPB2.0 patch, since in
HPB1.0 device
control mode, a HPB reset in device side does not impact anything
in
host side -
host is not writing back any HPB entries to device anyways and HPB
Read
cmd with
invalid HPB entries shall be treated as normal Read(10) cmd
without
any
problems.
Yes, UFS device will process read command even the HPB entries are
valid or
not. So it is warning about read performance drop by dev reset.
Yeah, but still I am 100% sure about what should host do in case of
HPB2.0
when it receives HPB Op code 0x2, I am waiting for feedbacks.
I think the host has two choices when it receives 0x2.
One is nothing on host.
The other is discarding all HPB entries in the host.
In the JEDEC HPB spec, it as follows:
When the device is powered off by the host, the device may restore
L2P
map
data upon power up or build from the host’s HPB READ command.
If some UFS builds L2P map data from the host's HPB READ commands, we
don't
have to discard HPB entries in the host.
So I thinks there is nothing to do when it receives 0x2.
But in HPB2.0, if we do nothing to active regions in host side, host
can
write
HPB entries (which host thinks valid, but actually invalid in device
side since
reset happened) back to device through HPB Write Buffer cmds (BUFFER
ID
= 0x2).
My question is that are all UFSs OK with this?
Yes, it must be OK.
Please refer the following the HPB 2.0 spec:
If the HPB Entries sent by HPB WRITE BUFFER are removed by the device,
for example, because they are not consumed for a long enough period of
time,
then the HPB READ command for the removed HPB entries shall be handled
as a
normal READ command.
No, it is talking about the subsequent HPB READ cmd sent after a HPB
WRITE BUFFER cmd,
but not the HPB WRITE BUFFER cmd itself...
Thanks,
Can Guo.
Thanks,
Daejun
Thanks,
Can Guo.
Thanks,
Daejun
Thanks,
Can Guo.
Thanks,
Daejun
Please correct me if I am wrong.
Thanks,
Can Guo.
Re: [PATCH] kernel: kcov: fix a typo in comment
On Tue, Mar 23, 2021 at 7:24 AM tl455047 wrote: > > Fixed a typo in comment. > > Signed-off-by: tl455047 Reviewed-by: Dmitry Vyukov +Andrew, linux-mm as KCOV patches are generally merged into mm. Thanks for the fix > --- > kernel/kcov.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/kcov.c b/kernel/kcov.c > index 80bfe71bbe13..6f59842f2caf 100644 > --- a/kernel/kcov.c > +++ b/kernel/kcov.c > @@ -527,7 +527,7 @@ static int kcov_get_mode(unsigned long arg) > > /* > * Fault in a lazily-faulted vmalloc area before it can be used by > - * __santizer_cov_trace_pc(), to avoid recursion issues if any code on the > + * __sanitizer_cov_trace_pc(), to avoid recursion issues if any code on the > * vmalloc fault handling path is instrumented. > */ > static void kcov_fault_in_area(struct kcov *kcov) > -- > 2.25.1 >
Re: [PATCH] f2fs: fix to avoid out-of-bounds memory access
Hi butt3rflyh4ck, On 2021/3/23 13:48, butt3rflyh4ck wrote: Hi, I have tested the patch on 5.12.0-rc4+, it seems to fix the problem. Thanks for helping to test this patch. Thanks, Regards, butt3rflyh4ck. On Mon, Mar 22, 2021 at 7:47 PM Chao Yu wrote: butt3rflyh4ck reported a bug found by syzkaller fuzzer with custom modifications in 5.12.0-rc3+ [1]: dump_stack+0xfa/0x151 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x82/0x32c mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 f2fs_test_bit fs/f2fs/f2fs.h:2572 [inline] current_nat_addr fs/f2fs/node.h:213 [inline] get_next_nat_page fs/f2fs/node.c:123 [inline] __flush_nat_entry_set fs/f2fs/node.c:2888 [inline] f2fs_flush_nat_entries+0x258e/0x2960 fs/f2fs/node.c:2991 f2fs_write_checkpoint+0x1372/0x6a70 fs/f2fs/checkpoint.c:1640 f2fs_issue_checkpoint+0x149/0x410 fs/f2fs/checkpoint.c:1807 f2fs_sync_fs+0x20f/0x420 fs/f2fs/super.c:1454 __sync_filesystem fs/sync.c:39 [inline] sync_filesystem fs/sync.c:67 [inline] sync_filesystem+0x1b5/0x260 fs/sync.c:48 generic_shutdown_super+0x70/0x370 fs/super.c:448 kill_block_super+0x97/0xf0 fs/super.c:1394 The root cause is, if nat entry in checkpoint journal area is corrupted, e.g. nid of journalled nat entry exceeds max nid value, during checkpoint, once it tries to flush nat journal to NAT area, get_next_nat_page() may access out-of-bounds memory on nat_bitmap due to it uses wrong nid value as bitmap offset. [1] https://lore.kernel.org/lkml/cafco6xomwdr8pobek6en6-fs58kg9dorfadgjj-fnf-1x43...@mail.gmail.com/T/#u Reported-by: butt3rflyh4ck Signed-off-by: Chao Yu --- fs/f2fs/node.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index caf43970510e..8311b2367c7c 100644 --- a/fs/f2fs/node.c +++ b/fs/f2fs/node.c @@ -2790,6 +2790,9 @@ static void remove_nats_in_journal(struct f2fs_sb_info *sbi) struct f2fs_nat_entry raw_ne; nid_t nid = le32_to_cpu(nid_in_journal(journal, i)); + if (f2fs_check_nid_range(sbi, nid)) + continue; + raw_ne = nat_in_journal(journal, i); ne = __lookup_nat_cache(nm_i, nid); -- 2.29.2 .
Re: [PATCH 2/2] Revert "xen: fix p2m size in dom0 for disabled memory hotplug case"
On 17.03.21 12:04, Roger Pau Monne wrote: This partially reverts commit 882213990d32fd224340a4533f6318dd152be4b2. There's no need to special case XEN_UNPOPULATED_ALLOC anymore in order to correctly size the p2m. The generic memory hotplug option has already been tied together with the Xen hotplug limit, so enabling memory hotplug should already trigger a properly sized p2m on Xen PV. Can you add some words here that XEN_UNPOPULATED_ALLOC depends on MEMORY_HOTPLUG via ZONE_DEVICE? Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[PATCH] Revert "f2fs: give a warning only for readonly partition"
This reverts commit 938a184265d75ea474f1c6fe1da96a5196163789.
Because that commit fails generic/050 testcase which expect failure
during mount a recoverable readonly partition.
Fixes: 938a184265d7 ("f2fs: give a warning only for readonly partition")
Signed-off-by: Chao Yu
---
fs/f2fs/super.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index b48281642e98..2b78ee11f093 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -3952,10 +3952,12 @@ static int f2fs_fill_super(struct super_block *sb, void
*data, int silent)
* previous checkpoint was not done by clean system shutdown.
*/
if (f2fs_hw_is_readonly(sbi)) {
- if (!is_set_ckpt_flags(sbi, CP_UMOUNT_FLAG))
+ if (!is_set_ckpt_flags(sbi, CP_UMOUNT_FLAG)) {
+ err = -EROFS;
f2fs_err(sbi, "Need to recover fsync data, but
write access unavailable");
- else
- f2fs_info(sbi, "write access unavailable,
skipping recovery");
+ goto free_meta;
+ }
+ f2fs_info(sbi, "write access unavailable, skipping
recovery");
goto reset_checkpoint;
}
--
2.29.2
Re: [RFC v3] net: sched: implement TCQ_F_CAN_BYPASS for lockless qdisc
Hi,
On 22.03.21 10:09, Yunsheng Lin wrote:
> Currently pfifo_fast has both TCQ_F_CAN_BYPASS and TCQ_F_NOLOCK
> flag set, but queue discipline by-pass does not work for lockless
> qdisc because skb is always enqueued to qdisc even when the qdisc
> is empty, see __dev_xmit_skb().
>
> This patch calls sch_direct_xmit() to transmit the skb directly
> to the driver for empty lockless qdisc too, which aviod enqueuing
> and dequeuing operation. qdisc->empty is set to false whenever a
> skb is enqueued, see pfifo_fast_enqueue(), and is set to true when
> skb dequeuing return NULL, see pfifo_fast_dequeue().
>
> There is a data race between enqueue/dequeue and qdisc->empty
> setting, qdisc->empty is only used as a hint, so we need to call
> sch_may_need_requeuing() to see if the queue is really empty and if
> there is requeued skb, which has higher priority than the current
> skb.
>
> The performance for ip_forward test increases about 10% with this
> patch.
>
> Signed-off-by: Yunsheng Lin
> ---
> Hi, Vladimir and Ahmad
> Please give it a test to see if there is any out of order
> packet for this patch, which has removed the priv->lock added in
> RFC v2.
Overnight test (10h, 64 mil frames) didn't see any out-of-order frames
between 2 FlexCANs on a dual core machine:
Tested-by: Ahmad Fatoum
No performance measurements taken.
>
> There is a data race as below:
>
> CPU1 CPU2
> qdisc_run_begin(q).
> .q->enqueue()
> sch_may_need_requeuing() .
> return true .
> . .
> . .
> q->enqueue() .
>
> When above happen, the skb enqueued by CPU1 is dequeued after the
> skb enqueued by CPU2 because sch_may_need_requeuing() return true.
> If there is not qdisc bypass, the CPU1 has better chance to queue
> the skb quicker than CPU2.
>
> This patch does not take care of the above data race, because I
> view this as similar as below:
>
> Even at the same time CPU1 and CPU2 write the skb to two socket
> which both heading to the same qdisc, there is no guarantee that
> which skb will hit the qdisc first, becuase there is a lot of
> factor like interrupt/softirq/cache miss/scheduling afffecting
> that.
>
> So I hope the above data race will not cause problem for Vladimir
> and Ahmad.
> ---
> include/net/pkt_sched.h | 1 +
> include/net/sch_generic.h | 1 -
> net/core/dev.c| 22 ++
> net/sched/sch_generic.c | 11 +++
> 4 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h
> index f5c1bee..5715ddf 100644
> --- a/include/net/pkt_sched.h
> +++ b/include/net/pkt_sched.h
> @@ -122,6 +122,7 @@ void qdisc_warn_nonwc(const char *txt, struct Qdisc
> *qdisc);
> bool sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,
>struct net_device *dev, struct netdev_queue *txq,
>spinlock_t *root_lock, bool validate);
> +bool sch_may_need_requeuing(struct Qdisc *q);
>
> void __qdisc_run(struct Qdisc *q);
>
> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
> index f7a6e14..e08cc77 100644
> --- a/include/net/sch_generic.h
> +++ b/include/net/sch_generic.h
> @@ -161,7 +161,6 @@ static inline bool qdisc_run_begin(struct Qdisc *qdisc)
> if (qdisc->flags & TCQ_F_NOLOCK) {
> if (!spin_trylock(&qdisc->seqlock))
> return false;
> - WRITE_ONCE(qdisc->empty, false);
> } else if (qdisc_is_running(qdisc)) {
> return false;
> }
> diff --git a/net/core/dev.c b/net/core/dev.c
> index be941ed..317180a 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3796,9 +3796,31 @@ static inline int __dev_xmit_skb(struct sk_buff *skb,
> struct Qdisc *q,
> qdisc_calculate_pkt_len(skb, q);
>
> if (q->flags & TCQ_F_NOLOCK) {
> + if (q->flags & TCQ_F_CAN_BYPASS && READ_ONCE(q->empty) &&
> + qdisc_run_begin(q)) {
> + if (sch_may_need_requeuing(q)) {
> + rc = q->enqueue(skb, q, &to_free) &
> NET_XMIT_MASK;
> + __qdisc_run(q);
> + qdisc_run_end(q);
> +
> + goto no_lock_out;
> + }
> +
> + qdisc_bstats_cpu_update(q, skb);
> +
> + if (sch_direct_xmit(skb, q, dev, txq, NULL, true) &&
> + !READ_ONCE(q->empty))
> + __qdisc_run(q);
> +
> + qdisc_run_end(q);
> + return NET_XMIT_SUCCESS;
> + }
> +
> rc = q->enqueue(skb, q, &to_free) & NET_XMIT_MASK;
> + WRITE_ONCE(q->empty, false);
>
Re: [PATCH v3] kdb: Refactor env variables get/set code
Hi Daniel,
On Mon, 8 Feb 2021 at 13:32, Sumit Garg wrote:
>
> Add two new kdb environment access methods as kdb_setenv() and
> kdb_printenv() in order to abstract out environment access code
> from kdb command functions.
>
> Also, replace (char *)0 with NULL as an initializer for environment
> variables array.
>
> Signed-off-by: Sumit Garg
> Reviewed-by: Douglas Anderson
> ---
>
> Changes in v3:
> - Remove redundant '\0' char assignment.
> - Pick up Doug's review tag.
>
> Changes in v2:
> - Get rid of code motion to separate kdb_env.c file.
> - Replace (char *)0 with NULL.
> - Use kernel-doc style function comments.
> - s/kdb_prienv/kdb_printenv/
>
> kernel/debug/kdb/kdb_main.c | 164
>
> 1 file changed, 91 insertions(+), 73 deletions(-)
>
Do you have any further comments on this? If no, can you pick this up as well?
-Sumit
> diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
> index 588062a..69b8f55 100644
> --- a/kernel/debug/kdb/kdb_main.c
> +++ b/kernel/debug/kdb/kdb_main.c
> @@ -142,40 +142,40 @@ static const int __nkdb_err = ARRAY_SIZE(kdbmsgs);
>
> static char *__env[] = {
> #if defined(CONFIG_SMP)
> - "PROMPT=[%d]kdb> ",
> + "PROMPT=[%d]kdb> ",
> #else
> - "PROMPT=kdb> ",
> + "PROMPT=kdb> ",
> #endif
> - "MOREPROMPT=more> ",
> - "RADIX=16",
> - "MDCOUNT=8", /* lines of md output */
> - KDB_PLATFORM_ENV,
> - "DTABCOUNT=30",
> - "NOSECT=1",
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> - (char *)0,
> + "MOREPROMPT=more> ",
> + "RADIX=16",
> + "MDCOUNT=8",/* lines of md output */
> + KDB_PLATFORM_ENV,
> + "DTABCOUNT=30",
> + "NOSECT=1",
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> };
>
> static const int __nenv = ARRAY_SIZE(__env);
> @@ -318,6 +318,63 @@ int kdbgetintenv(const char *match, int *value)
> }
>
> /*
> + * kdb_setenv() - Alter an existing environment variable or create a new one.
> + * @var: Name of the variable
> + * @val: Value of the variable
> + *
> + * Return: Zero on success, a kdb diagnostic on failure.
> + */
> +static int kdb_setenv(const char *var, const char *val)
> +{
> + int i;
> + char *ep;
> + size_t varlen, vallen;
> +
> + varlen = strlen(var);
> + vallen = strlen(val);
> + ep = kdballocenv(varlen + vallen + 2);
> + if (ep == (char *)0)
> + return KDB_ENVBUFFULL;
> +
> + sprintf(ep, "%s=%s", var, val);
> +
> + for (i = 0; i < __nenv; i++) {
> + if (__env[i]
> +&& ((strncmp(__env[i], var, varlen) == 0)
> + && ((__env[i][varlen] == '\0')
> + || (__env[i][varlen] == '=' {
> + __env[i] = ep;
> + return 0;
> + }
> + }
> +
> + /*
> +* Wasn't existing variable. Fit into slot.
> +*/
> + for (i = 0; i < __nenv-1; i++) {
> + if (__env[i] == (char *)0) {
> + __env[i] = ep;
> + return 0;
> + }
> + }
> +
> + return KDB_ENVFULL;
> +}
> +
> +/*
> + * kdb_printenv() - Display the current environment variables.
> + */
> +static void kdb_printenv(void)
> +{
> + int i;
> +
> + for (i = 0; i < __nenv; i++) {
> + if (__env[i])
> + kdb_printf("%s\n", __env[i]);
> + }
> +}
> +
> +/*
> * kdbgetularg - This function will convert a numeric string into an
> * unsigned long value.
> * Parameters:
> @@ -374,10 +431,6 @@ int kdbgetu64arg(const char *arg, u64 *value)
> */
> int kdb_set(int argc, const char **argv)
> {
> - int i;
> - char *ep;
> - size_t varlen, vallen;
> -
> /*
> * we can be invoked two ways:
> * set var=valueargv[1]="var", argv[2]="value"
> @@ -422,37 +475,7 @@ int kdb_set(int argc, const char **argv)
> * Tokenizer squashed the '=' sign. argv[1] is variable
> * name, argv[2] = value.
> */
> - varlen = strlen(argv[1]);
> - vallen = strlen(argv[2]);
> - ep = kdballocenv(varlen + vallen + 2);
> - if (ep == (char *)0)
> - return KDB_ENVBUFFULL;
> -
> - sprintf(ep, "%s=%s", argv[1], argv[2]);
> -
> - ep[va
RE: Re: [PATCH v31 2/4] scsi: ufs: L2P map management for HPB read
>On 2021-03-23 14:19, Daejun Park wrote:
>>> On 2021-03-23 13:37, Daejun Park wrote:
> On 2021-03-23 12:22, Can Guo wrote:
>> On 2021-03-22 17:11, Bean Huo wrote:
>>> On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:
+ switch (rsp_field->hpb_op) {
+ case HPB_RSP_REQ_REGION_UPDATE:
+ if (data_seg_len != DEV_DATA_SEG_LEN)
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"%s: data seg length is not
same.\n",
+__func__);
+ ufshpb_rsp_req_region_update(hpb, rsp_field);
+ break;
+ case HPB_RSP_DEV_RESET:
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"UFS device lost HPB information during
PM.\n");
+ break;
>>>
>>> Hi Deajun,
>>> This series looks good to me. Just here I have one question. You
>>> didn't
>>> handle HPB_RSP_DEV_RESET, just a warning. Based on your SS UFS,
>>> how
>>> to
>>> handle HPB_RSP_DEV_RESET from the host side? Do you think we shoud
>>> reset host side HPB entry as well or what else?
>>>
>>>
>>> Bean
>>
>> Same question here - I am still collecting feedbacks from flash
>> vendors
>> about
>> what is recommanded host behavior on reception of HPB Op code 0x2,
>> since it
>> is not cleared defined in HPB2.0 specs.
>>
>> Can Guo.
>
> I think the question should be asked in the HPB2.0 patch, since in
> HPB1.0 device
> control mode, a HPB reset in device side does not impact anything in
> host side -
> host is not writing back any HPB entries to device anyways and HPB
> Read
> cmd with
> invalid HPB entries shall be treated as normal Read(10) cmd without
> any
> problems.
Yes, UFS device will process read command even the HPB entries are
valid or
not. So it is warning about read performance drop by dev reset.
>>>
>>> Yeah, but still I am 100% sure about what should host do in case of
>>> HPB2.0
>>> when it receives HPB Op code 0x2, I am waiting for feedbacks.
>>
>> I think the host has two choices when it receives 0x2.
>> One is nothing on host.
>> The other is discarding all HPB entries in the host.
>>
>> In the JEDEC HPB spec, it as follows:
>> When the device is powered off by the host, the device may restore L2P
>> map
>> data upon power up or build from the host’s HPB READ command.
>>
>> If some UFS builds L2P map data from the host's HPB READ commands, we
>> don't
>> have to discard HPB entries in the host.
>>
>> So I thinks there is nothing to do when it receives 0x2.
>
>But in HPB2.0, if we do nothing to active regions in host side, host can
>write
>HPB entries (which host thinks valid, but actually invalid in device
>side since
>reset happened) back to device through HPB Write Buffer cmds (BUFFER ID
>= 0x2).
>My question is that are all UFSs OK with this?
Yes, it must be OK.
Please refer the following the HPB 2.0 spec:
If the HPB Entries sent by HPB WRITE BUFFER are removed by the device,
for example, because they are not consumed for a long enough period of time,
then the HPB READ command for the removed HPB entries shall be handled as a
normal READ command.
Thanks,
Daejun
>Thanks,
>Can Guo.
>
>>
>> Thanks,
>> Daejun
>>
>>> Thanks,
>>> Can Guo.
>>>
Thanks,
Daejun
> Please correct me if I am wrong.
> Thanks,
> Can Guo.
>
>
>
>>>
>>>
>>>
>
>
>
drivers/net/ethernet/chelsio/cxgb4/sge.c:2396:13: warning: stack frame size of 1168 bytes in function 'ethofld_xmit'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 84196390620ac0e5070ae36af84c137c6216a7dc
commit: 97e4910232fa1f81e806aa60c25a0450276d99a2 linux/compiler-clang.h: define
HAVE_BUILTIN_BSWAP*
date: 9 days ago
config: mips-randconfig-r023-20210322 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
78a65cd945d006ff02f9d24d9cc20a302ed93b08)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97e4910232fa1f81e806aa60c25a0450276d99a2
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 97e4910232fa1f81e806aa60c25a0450276d99a2
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/net/ethernet/chelsio/cxgb4/sge.c:814:28: warning: unused function
'calc_tx_descs' [-Wunused-function]
static inline unsigned int calc_tx_descs(const struct sk_buff *skb,
^
>> drivers/net/ethernet/chelsio/cxgb4/sge.c:2396:13: warning: stack frame size
>> of 1168 bytes in function 'ethofld_xmit' [-Wframe-larger-than=]
static void ethofld_xmit(struct net_device *dev, struct sge_eosw_txq
*eosw_txq)
^
2 warnings generated.
vim +/ethofld_xmit +2396 drivers/net/ethernet/chelsio/cxgb4/sge.c
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2395
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 @2396 static void
ethofld_xmit(struct net_device *dev, struct sge_eosw_txq *eosw_txq)
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2397 {
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2398struct sk_buff *skb;
4f1d97262d58e0 Rahul Lakkireddy 2020-05-15 2399int pktcount, ret;
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2400
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2401switch
(eosw_txq->state) {
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2402case
CXGB4_EO_STATE_ACTIVE:
0e395b3cb1fb82 Rahul Lakkireddy 2019-11-07 2403case
CXGB4_EO_STATE_FLOWC_OPEN_SEND:
0e395b3cb1fb82 Rahul Lakkireddy 2019-11-07 2404case
CXGB4_EO_STATE_FLOWC_CLOSE_SEND:
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2405pktcount =
eosw_txq->pidx - eosw_txq->last_pidx;
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2406if (pktcount <
0)
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2407
pktcount += eosw_txq->ndesc;
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2408break;
0e395b3cb1fb82 Rahul Lakkireddy 2019-11-07 2409case
CXGB4_EO_STATE_FLOWC_OPEN_REPLY:
0e395b3cb1fb82 Rahul Lakkireddy 2019-11-07 2410case
CXGB4_EO_STATE_FLOWC_CLOSE_REPLY:
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2411case
CXGB4_EO_STATE_CLOSED:
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2412default:
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2413return;
272630feb4c0d2 Rahul Lakkireddy 2019-11-19 2414}
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2415
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2416while (pktcount--) {
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2417skb =
eosw_txq_peek(eosw_txq);
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2418if (!skb) {
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2419
eosw_txq_advance_index(&eosw_txq->last_pidx, 1,
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2420
eosw_txq->ndesc);
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2421
continue;
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2422}
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2423
4f1d97262d58e0 Rahul Lakkireddy 2020-05-15 2424ret =
ethofld_hard_xmit(dev, eosw_txq);
4f1d97262d58e0 Rahul Lakkireddy 2020-05-15 2425if (ret)
4f1d97262d58e0 Rahul Lakkireddy 2020-05-15 2426break;
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2427}
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2428 }
4846d5330dafc8 Rahul Lakkireddy 2019-11-07 2429
:: The code at line 2396 was first introduced by commit
:: 4846d5330dafc82990be7ffe1d1b383157268bd9 cxgb4: add Tx and Rx path for
ETHOFLD traffic
:: TO: Rahul Lakkireddy
:: CC: David S. Miller
---
0-DAY CI Kernel Test Service, Intel Corporation
https://li
A potential data race in drivers/media/platform/s5p-mfc/
Hi, s5p_mfc_probe[1] registers an interrupt handler s5p_mfc_irq before compete initialization. For example, the interrupt handler operates with mfc_ops, which are set up in [2]. So, potentially, the interrupt handler may be executed in parallel with initialization. The question is if the device can produce the interrupts. Its registers are initialized in [3] and there are nothing like "enabling interrupts". So, likely, they are activated. And if interrupts can come, then this is a data race. Best regards, Pavel Andrianov Linux Verification Center, ISPRAS web:http://linuxtesting.org [1]https://elixir.bootlin.com/linux/v5.4.106/source/drivers/media/platform/s5p-mfc/s5p_mfc.c#L1299 [2]https://elixir.bootlin.com/linux/v5.4.106/source/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c#L19 [3]https://elixir.bootlin.com/linux/v5.4.106/source/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c#L2229
Re: [PATCH -next] powerpc: kernel/time.c - cleanup warnings
Le 23/03/2021 à 07:21, heying (H) a écrit : Dear Christophe, 在 2021/3/18 10:28, heying (H) 写道: 在 2021/3/17 19:16, Christophe Leroy 写道: Le 17/03/2021 à 11:34, He Ying a écrit : We found these warnings in arch/powerpc/kernel/time.c as follows: warning: symbol 'decrementer_max' was not declared. Should it be static? warning: symbol 'rtc_lock' was not declared. Should it be static? warning: symbol 'dtl_consumer' was not declared. Should it be static? Declare 'decrementer_max' in arch/powerpc/include/asm/time.h. And include proper header in which 'rtc_lock' is declared. Move 'dtl_consumer' definition behind "include " because 'dtl_consumer' is declared there. Reported-by: Hulk Robot Signed-off-by: He Ying --- arch/powerpc/include/asm/time.h | 1 + arch/powerpc/kernel/time.c | 7 +++ 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h index 8dd3cdb25338..2cd2b50bedda 100644 --- a/arch/powerpc/include/asm/time.h +++ b/arch/powerpc/include/asm/time.h @@ -22,6 +22,7 @@ extern unsigned long tb_ticks_per_jiffy; extern unsigned long tb_ticks_per_usec; extern unsigned long tb_ticks_per_sec; extern struct clock_event_device decrementer_clockevent; +extern u64 decrementer_max; extern void generic_calibrate_decr(void); diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index b67d93a609a2..409967713ca6 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -55,6 +55,7 @@ #include #include #include +#include I don't think that's the good place. It has no link to powerpc, it is only by chance that it has the same name. As rtc_lock is defined in powerpc time.c, I think you should declare it in powerpc asm/time.h My first thought was the same as yours. I tried to add declaration in powerpc asm/time.h, but got a compiling error: drivers/rtc/rtc-vr41xx.c:75:24: error: static declaration of ‘rtc_lock’ follows non-static declaration static DEFINE_SPINLOCK(rtc_lock); In file included from ./arch/powerpc/include/asm/delay.h:7:0, from ./arch/powerpc/include/asm/io.h:33, from ./include/linux/io.h:13, from drivers/rtc/rtc-vr41xx.c:11: ./arch/powerpc/include/asm/time.h:25:19: note: previous declaration of ‘rtc_lock’ was here extern spinlock_t rtc_lock; There's a conflict. Perhaps I can rename it in drivers/rtc/rtc-vr41xx.c. But I find an existing declaration in linux/mc146818rtc.h and there's only one definition for 'rtc_lock' in powerpc. There's some includes of mc146818rtc.h in powperc. I wonder they point to the same thing. But I'm not very sure because the header's name looks a bit strange. How about including mc146818rtc.h in powperpc kernel/time.c? May I have your opinions please? As I said, mc146818rtc.h is not related to powerpc, and if it works that's just chance, and there is no certainty that it will still work in the future. If you can't find a clean solution, it is better to leave the warning. Christophe
Re: [PATCH] mm: process_vm_access: Remove duplicate include of compat.h
On 2021/3/23 11:23, Wan Jiabing wrote:
> linux/compat.h has been included at line 8.So we remove
> the duplicate one at line 12.
>
line 12 one is added via eb351d75ce1e ("mm/process_vm_access.c: include
compat.h") to fix the build error:
mm/process_vm_access.c:277:5: error: implicit declaration of function
'in_compat_syscall'; did you mean 'in_ia32_syscall'?
[-Werror=implicit-function-declaration]
There might be something wrong.
> Signed-off-by: Wan Jiabing
> ---
> mm/process_vm_access.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
> index f5fee9cf90f8..4bcc11958089 100644
> --- a/mm/process_vm_access.c
> +++ b/mm/process_vm_access.c
> @@ -9,7 +9,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
>
Re: [PATCH 1/2] clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue
* Daniel Lezcano [210322 18:24]: > On 22/03/2021 17:33, Tony Lindgren wrote: > > Hi, > > > > * Daniel Lezcano [210322 15:56]: > >> On 04/03/2021 08:37, Tony Lindgren wrote: > >>> There is a timer wrap issue on dra7 for the ARM architected timer. > >>> In a typical clock configuration the timer fails to wrap after 388 days. > >>> > >>> To work around the issue, we need to use timer-ti-dm timers instead. > >>> > >>> Let's prepare for adding support for percpu timers by adding a common > >>> dmtimer_clkevt_init_common() and call it from dmtimer_clockevent_init(). > >>> This patch makes no intentional functional changes. > >>> > >>> Signed-off-by: Tony Lindgren > >>> --- > >> > >> [ ... ] > >> > >>> @@ -575,33 +574,60 @@ static int __init dmtimer_clockevent_init(struct > >>> device_node *np) > >>>*/ > >>> writel_relaxed(OMAP_TIMER_CTRL_POSTED, t->base + t->ifctrl); > >>> > >>> + if (dev->cpumask == cpu_possible_mask) > >>> + irqflags = IRQF_TIMER; > >>> + else > >>> + irqflags = IRQF_TIMER | IRQF_NOBALANCING; > >> > >> Can you explain the reasoning behind the test above ? > > > > In the per cpu case we assign one dmtimer per cpu, and we want the > > interrupt handling on the assigned CPU. In the per cpu case we have > > the cpu specified with dev->cpumask unlike for the normal clockevent > > case. > > > > In the per cpu dmtimer case the interrupt line is not wired per cpu > > though, so I don't think we want to add IRQF_PERCPU here. > > If it is per cpu, then the parameter will be cpumask_of(cpu). If there > is one cpu, no balancing can happen and then the IRQF_NOBALANCING is not > needed, neither this test and the irqflags, right? Oh yeah you're right, none of that is needed. For the percpu case we already have irq_force_affinity() in omap_dmtimer_starting_cpu(). I'll update and send out v2 of these two patches. Thanks, Tony
[PATCH] [v2] arch: powerpc: Remove duplicate includes
mmu-hash.h: asm/bug.h has been included at line 12, so remove the duplicate one at line 21. interrupt.c: asm/interrupt.h has been included at line 12, so remove the duplicate one at line 10. time.c: linux/sched/clock.h has been included at line 33,so remove the duplicate one at line 56 and move sched/cputime.h under sched including segament. Signed-off-by: Wan Jiabing --- arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1 - arch/powerpc/kernel/interrupt.c | 1 - arch/powerpc/kernel/time.c| 3 +-- 3 files changed, 1 insertion(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h index f911bdb68d8b..3004f3323144 100644 --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h @@ -18,7 +18,6 @@ * complete pgtable.h but only a portion of it. */ #include -#include #include #include diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c index c475a229a42a..11d456896772 100644 --- a/arch/powerpc/kernel/interrupt.c +++ b/arch/powerpc/kernel/interrupt.c @@ -7,7 +7,6 @@ #include #include #include -#include #include #include #include diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index b67d93a609a2..e2766e0e2a3a 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -31,6 +31,7 @@ #include #include #include +#include #include #include #include @@ -52,8 +53,6 @@ #include #include #include -#include -#include #include #include -- 2.25.1
Re: [PATCH v7 3/3] arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems
Hi Aswath,
On 23/03/21 10:54 am, Aswath Govindraju wrote:
> Hi Nishanth,
>
> On 22/03/21 9:05 pm, Nishanth Menon wrote:
>> On 18:42-20210322, Aswath Govindraju wrote:
>>> The following speed modes are now supported in J7200 SoC,
>>> - HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1].
>>> - UHS-I speed modes in MMCSD1 subsystem [1].
>>>
>>> Add support for UHS-I modes by adding voltage regulator device tree nodes
>>> and corresponding pinmux details, to power cycle and voltage switch cards.
>>> Set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1
>>> device tree nodes.
>>>
>>> Also update the delay values for various speed modes supported, based on
>>> the revised january 2021 J7200 datasheet[2].
>>>
>>> [1] - section 12.3.6.1.1 MMCSD Features, in
>>> https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf,
>>> (SPRUIU1A – JULY 2020 – REVISED JANUARY 2021)
>>>
>>> [2] - https://www.ti.com/lit/ds/symlink/dra821u.pdf,
>>> (SPRSP57B – APRIL 2020 – REVISED JANUARY 2021)
>>>
>>> Signed-off-by: Aswath Govindraju
>>> ---
>>> .../dts/ti/k3-j7200-common-proc-board.dts | 42 +++
>>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 14 ++-
>>> 2 files changed, 54 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>>> b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>>> index b493f939b09a..de8c06bdc825 100644
>>> --- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>>> +++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>>> @@ -16,6 +16,29 @@
>>> stdout-path = "serial2:115200n8";
>>> bootargs = "console=ttyS2,115200n8
>>> earlycon=ns16550a,mmio32,0x0280";
>>> };
>>> +
>>> + vdd_mmc1: fixedregulator-sd {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "vdd_mmc1";
>>> + regulator-min-microvolt = <330>;
>>> + regulator-max-microvolt = <330>;
>>> + regulator-boot-on;
>>> + enable-active-high;
>>> + gpios = <&exp2 2 GPIO_ACTIVE_HIGH>;
>>
>> is that gpio ?
>
> Yes, that is correct. I'll correct it in the respin
>
>> I'd encourage to use vin-supply as well.
>
> Will add this in respin.
>
>>
>>> + };
>>> +
>>> + vdd_sd_dv: gpio-regulator-vdd-sd-dv {
>> What does this drive? TLV71033 ?
>
> Yes, this node models the TLV71033 voltage regulator that switches the
> MMC IO signal voltage level between 3.3V and 1.8V.
Nope. Unlike J721e SOM which uses TLV71033 for switching voltage, J7200
SOM directly uses GPIO input to PMIC to control the output voltage. So
this should model the gpio input to PMIC.
Thanks
Kishon
Re: [PATCH v2] kdb: Get rid of custom debug heap allocator
On Fri, 19 Mar 2021 at 23:05, Daniel Thompson wrote: > > On Mon, Mar 01, 2021 at 11:33:00AM +0530, Sumit Garg wrote: > > On Fri, 26 Feb 2021 at 23:07, Daniel Thompson > > wrote: > > > > > > On Fri, Feb 26, 2021 at 06:12:13PM +0530, Sumit Garg wrote: > > > > On Fri, 26 Feb 2021 at 16:29, Daniel Thompson > > > > wrote: > > > > > > > > > > On Fri, Feb 26, 2021 at 03:23:06PM +0530, Sumit Garg wrote: > > > > > > Currently the only user for debug heap is kdbnearsym() which can be > > > > > > modified to rather ask the caller to supply a buffer for symbol > > > > > > name. > > > > > > So do that and modify kdbnearsym() callers to pass a symbol name > > > > > > buffer > > > > > > allocated statically and hence remove custom debug heap allocator. > > > > > > > > > > Why make the callers do this? > > > > > > > > > > The LRU buffers were managed inside kdbnearsym() why does switching to > > > > > an approach with a single buffer require us to push that buffer out to > > > > > the callers? > > > > > > > > > > > > > Earlier the LRU buffers managed namebuf uniqueness per caller (upto > > > > 100 callers) > > > > > > The uniqueness is per symbol, not per caller. > > > > > > > Agree. > > > > > > but if we switch to single entry in kdbnearsym() then all > > > > callers need to share common buffer which will lead to incorrect > > > > results from following simple sequence: > > > > > > > > kdbnearsym(word, &symtab1); > > > > kdbnearsym(word, &symtab2); > > > > kdb_symbol_print(word, &symtab1, 0); > > > > kdb_symbol_print(word, &symtab2, 0); > > > > > > > > But if we change to a unique static namebuf per caller then the > > > > following sequence will work: > > > > > > > > kdbnearsym(word, &symtab1, namebuf1); > > > > kdbnearsym(word, &symtab2, namebuf2); > > > > kdb_symbol_print(word, &symtab1, 0); > > > > kdb_symbol_print(word, &symtab2, 0); > > > > > > This is true but do any of the callers of kdbnearsym ever do this? > > > > No, but any of prospective callers may need this. > > > > > The > > > main reaason that heap stuck out as redundant was that I've only ever > > > seen the output of kdbnearsym() consumed almost immediately by a print. > > > > > > > Yeah but I think the alternative proposed in this patch isn't as > > burdensome as the heap and tries to somewhat match existing > > functionality. > > > > > I wrote an early version of a patch like this that just shrunk the LRU > > > cache down to 2 and avoided any heap usage... but I threw it away > > > when I realized we never carry cached values outside the function > > > that obtained them. > > > > > > > Okay, so if you still think that having a single static buffer inside > > kdbnearsym() is an appropriate approach for time being then I will > > switch to use that instead. > > Sorry to drop this thread for so long. > > On reflection I still have a few concerns about the current code. > To be clear this is not really about wasting 128 bytes of RAM (your > patch saves 256K after all). > > It's more that the current static buffers "look weird". They are static > so any competent OS programmer reads them and thinks "but what about > concurrency/reentrancy"). With the static buffers scattered through the > code they don't have a single place to find the answer. > > I originally proposed handling this by the static buffer horror in > kdbnearsym() and describing how it all works in the header comment! > As much as anything this was to centralize the commentary in the > contract for calling kdbnearsym(). Hence nobody should write the > theoretic bug you describe because they read the contract! > > You are welcome to counter propose but you must ensure that there are > equivalent comments so our "competent OS programmer" from the paragraph > above can figure out how the static buffer works without having to run > git blame` and digging out the patch history. > Okay, I understand your point here. Let me go ahead with a single static buffer in kdbnearsym() with a proper header comment. -Sumit > > Daniel. > > > > > > > -Sumit > > > > > > > > > > > @@ -526,6 +526,7 @@ int kdbgetaddrarg(int argc, const char **argv, > > > > > > int *nextarg, > > > > > > > > > > > > > > > diff --git a/kernel/debug/kdb/kdb_main.c > > > > > > b/kernel/debug/kdb/kdb_main.c > > > > > > index 9d69169582c6..6efe9ec53906 100644 > > > > > > --- a/kernel/debug/kdb/kdb_main.c > > > > > > +++ b/kernel/debug/kdb/kdb_main.c > > > > > > @@ -526,6 +526,7 @@ int kdbgetaddrarg(int argc, const char **argv, > > > > > > int *nextarg, > > > > > > > > > > The documentation comment for this function has not been updated to > > > > > describe the new contract on callers of this function (e.g. if they > > > > > consume the symbol name they must do so before calling kdbgetaddrarg() > > > > > (and maybe kdbnearsym() again). > > > > > > > > > > > > > I am not sure if I follow you here. If we have a unique static buffer > > > > per caller then why do we need this new contract? > > > > > > I traced the code wrong. I th
Re: [PATCH v31 2/4] scsi: ufs: L2P map management for HPB read
On 2021-03-23 14:19, Daejun Park wrote:
On 2021-03-23 13:37, Daejun Park wrote:
On 2021-03-23 12:22, Can Guo wrote:
On 2021-03-22 17:11, Bean Huo wrote:
On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:
+ switch (rsp_field->hpb_op) {
+ case HPB_RSP_REQ_REGION_UPDATE:
+ if (data_seg_len != DEV_DATA_SEG_LEN)
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"%s: data seg length is not
same.\n",
+__func__);
+ ufshpb_rsp_req_region_update(hpb, rsp_field);
+ break;
+ case HPB_RSP_DEV_RESET:
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"UFS device lost HPB information during
PM.\n");
+ break;
Hi Deajun,
This series looks good to me. Just here I have one question. You
didn't
handle HPB_RSP_DEV_RESET, just a warning. Based on your SS UFS,
how
to
handle HPB_RSP_DEV_RESET from the host side? Do you think we shoud
reset host side HPB entry as well or what else?
Bean
Same question here - I am still collecting feedbacks from flash
vendors
about
what is recommanded host behavior on reception of HPB Op code 0x2,
since it
is not cleared defined in HPB2.0 specs.
Can Guo.
I think the question should be asked in the HPB2.0 patch, since in
HPB1.0 device
control mode, a HPB reset in device side does not impact anything in
host side -
host is not writing back any HPB entries to device anyways and HPB
Read
cmd with
invalid HPB entries shall be treated as normal Read(10) cmd without
any
problems.
Yes, UFS device will process read command even the HPB entries are
valid or
not. So it is warning about read performance drop by dev reset.
Yeah, but still I am 100% sure about what should host do in case of
HPB2.0
when it receives HPB Op code 0x2, I am waiting for feedbacks.
I think the host has two choices when it receives 0x2.
One is nothing on host.
The other is discarding all HPB entries in the host.
In the JEDEC HPB spec, it as follows:
When the device is powered off by the host, the device may restore L2P
map
data upon power up or build from the host’s HPB READ command.
If some UFS builds L2P map data from the host's HPB READ commands, we
don't
have to discard HPB entries in the host.
So I thinks there is nothing to do when it receives 0x2.
But in HPB2.0, if we do nothing to active regions in host side, host can
write
HPB entries (which host thinks valid, but actually invalid in device
side since
reset happened) back to device through HPB Write Buffer cmds (BUFFER ID
= 0x2).
My question is that are all UFSs OK with this?
Thanks,
Can Guo.
Thanks,
Daejun
Thanks,
Can Guo.
Thanks,
Daejun
Please correct me if I am wrong.
Thanks,
Can Guo.
[PATCH v2] Bluetooth: Remove trailing semicolon in macros
remove trailing semicolon in macros and coding style fix.
Signed-off-by: Meng Yu
---
Changes in v2
-Re-base in bluetooth-next
net/bluetooth/smp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index efc19f9..2def906 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -54,7 +54,7 @@
#define SMP_ALLOW_CMD(smp, code) set_bit(code, &smp->allow_cmd)
/* Keys which are not distributed with Secure Connections */
-#define SMP_SC_NO_DIST (SMP_DIST_ENC_KEY | SMP_DIST_LINK_KEY);
+#define SMP_SC_NO_DIST (SMP_DIST_ENC_KEY | SMP_DIST_LINK_KEY)
#define SMP_TIMEOUTmsecs_to_jiffies(3)
@@ -398,7 +398,7 @@ static int smp_e(const u8 *k, u8 *r)
SMP_DBG("r %16phN", r);
- memzero_explicit(&ctx, sizeof (ctx));
+ memzero_explicit(&ctx, sizeof(ctx));
return err;
}
--
2.8.1
Re: [PATCH] usb: gadget: Stall OS descriptor request for unsupported functions
Hi Wesley, On Mon, Mar 22, 2021 at 06:50:17PM -0700, Wesley Cheng wrote: > From: Chandana Kishori Chiluveru > > Hosts which request "OS descriptors" from gadgets do so during > the enumeration phase and before the configuration is set with > SET_CONFIGURATION. Composite driver supports OS descriptor > handling in composite_setup function. This requires to pass > signature field, vendor code, compatibleID and subCompatibleID > from user space. > > For USB compositions that contain functions which don't implement os > descriptors, Windows is sending vendor specific requests for os > descriptors and composite driver handling this request with invalid > data. With this invalid info host resetting the bus and never > selecting the configuration and leading enumeration issue. > > Fix this by bailing out from the OS descriptor setup request > handling if the functions does not have OS descriptors compatibleID. > > Signed-off-by: Chandana Kishori Chiluveru > Signed-off-by: Wesley Cheng > --- > drivers/usb/gadget/composite.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c > index 72a9797..473edda6 100644 > --- a/drivers/usb/gadget/composite.c > +++ b/drivers/usb/gadget/composite.c > @@ -1945,6 +1945,12 @@ composite_setup(struct usb_gadget *gadget, const > struct usb_ctrlrequest *ctrl) > buf[6] = w_index; > /* Number of ext compat interfaces */ > count = count_ext_compat(os_desc_cfg); > + /* > + * Bailout if device does not > + * have ext_compat interfaces. > + */ > + if (count == 0) > + break; > buf[8] = count; > count *= 24; /* 24 B/ext compat desc */ > count += 16; /* header */ Do we still need this fix? IIRC we had this change in our downstream kernel to fix the case when dynamically re-configuring ConfigFS, i.e. changing the composition of functions wherein none of the interfaces support OS Descriptors, so this causes count_ext_compat() to return 0 and results in the issue described in $SUBJECT. But I think this is more of a problem of an improperly configured ConfigFS gadget. If userspace instead removes the config from the gadget's os_desc subdirectory that should cause cdev->os_desc_config to be set to NULL and hence composite_setup() should never enter this handling at all, right? Jack -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH] kernel: kcov: fix a typo in comment
Fixed a typo in comment. Signed-off-by: tl455047 --- kernel/kcov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/kcov.c b/kernel/kcov.c index 80bfe71bbe13..6f59842f2caf 100644 --- a/kernel/kcov.c +++ b/kernel/kcov.c @@ -527,7 +527,7 @@ static int kcov_get_mode(unsigned long arg) /* * Fault in a lazily-faulted vmalloc area before it can be used by - * __santizer_cov_trace_pc(), to avoid recursion issues if any code on the + * __sanitizer_cov_trace_pc(), to avoid recursion issues if any code on the * vmalloc fault handling path is instrumented. */ static void kcov_fault_in_area(struct kcov *kcov) -- 2.25.1
RE: [PATCH v4 1/2] platform/x86: dell-privacy: Add support for Dell hardware privacy
Hi Pierre：
> -Original Message-
> From: Pierre-Louis Bossart
> Sent: Monday, March 22, 2021 10:50 PM
> To: Perry Yuan; Yuan, Perry; po...@protonmail.com;
> oder_ch...@realtek.com; pe...@perex.cz; ti...@suse.com;
> hdego...@redhat.com; mgr...@linux.intel.com; Limonciello, Mario
> Cc: linux-kernel@vger.kernel.org; alsa-de...@alsa-project.org;
> broo...@kernel.org; lgirdw...@gmail.com; platform-driver-
> x...@vger.kernel.org
> Subject: Re: [PATCH v4 1/2] platform/x86: dell-privacy: Add support for Dell
> hardware privacy
>
>
> [EXTERNAL EMAIL]
>
>
> > As you suggested,I should add the alignment change in another patch.
> > But if i keep the old alignment, the code will be very odd.
> > Seems like that I have to change the below code to new alignment in
> > this patch.
> >
> > if (dell_smbios_find_token(GLOBAL_MIC_MUTE_DISABLE) &&
> > dell_smbios_find_token(GLOBAL_MIC_MUTE_ENABLE)) { <<--- changed
> > back
> > if (!privacy_valid)
> > has_privacy = true;
> > else
> > has_privacy = false;
> > if (!has_privacy) {
> > micmute_led_cdev.brightness <<--- new alignment
> > ...
> > }
> > ...
> > }
>
> I don't get the point, sorry. The code above doesn't seem properly indented
> or there were spurious tab/spaces conversions?
Could you help to take a look the V5 patch ?
I recovery some part of original code alignment and add my new codes with new
Tabs added
Thank you !
Perry
Re: [PATCH -next] powerpc: kernel/time.c - cleanup warnings
Dear Christophe, 在 2021/3/18 10:28, heying (H) 写道: 在 2021/3/17 19:16, Christophe Leroy 写道: Le 17/03/2021 à 11:34, He Ying a écrit : We found these warnings in arch/powerpc/kernel/time.c as follows: warning: symbol 'decrementer_max' was not declared. Should it be static? warning: symbol 'rtc_lock' was not declared. Should it be static? warning: symbol 'dtl_consumer' was not declared. Should it be static? Declare 'decrementer_max' in arch/powerpc/include/asm/time.h. And include proper header in which 'rtc_lock' is declared. Move 'dtl_consumer' definition behind "include " because 'dtl_consumer' is declared there. Reported-by: Hulk Robot Signed-off-by: He Ying --- arch/powerpc/include/asm/time.h | 1 + arch/powerpc/kernel/time.c | 7 +++ 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h index 8dd3cdb25338..2cd2b50bedda 100644 --- a/arch/powerpc/include/asm/time.h +++ b/arch/powerpc/include/asm/time.h @@ -22,6 +22,7 @@ extern unsigned long tb_ticks_per_jiffy; extern unsigned long tb_ticks_per_usec; extern unsigned long tb_ticks_per_sec; extern struct clock_event_device decrementer_clockevent; +extern u64 decrementer_max; extern void generic_calibrate_decr(void); diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index b67d93a609a2..409967713ca6 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -55,6 +55,7 @@ #include #include #include +#include I don't think that's the good place. It has no link to powerpc, it is only by chance that it has the same name. As rtc_lock is defined in powerpc time.c, I think you should declare it in powerpc asm/time.h My first thought was the same as yours. I tried to add declaration in powerpc asm/time.h, but got a compiling error: drivers/rtc/rtc-vr41xx.c:75:24: error: static declaration of ‘rtc_lock’ follows non-static declaration static DEFINE_SPINLOCK(rtc_lock); In file included from ./arch/powerpc/include/asm/delay.h:7:0, from ./arch/powerpc/include/asm/io.h:33, from ./include/linux/io.h:13, from drivers/rtc/rtc-vr41xx.c:11: ./arch/powerpc/include/asm/time.h:25:19: note: previous declaration of ‘rtc_lock’ was here extern spinlock_t rtc_lock; There's a conflict. Perhaps I can rename it in drivers/rtc/rtc-vr41xx.c. But I find an existing declaration in linux/mc146818rtc.h and there's only one definition for 'rtc_lock' in powerpc. There's some includes of mc146818rtc.h in powperc. I wonder they point to the same thing. But I'm not very sure because the header's name looks a bit strange. How about including mc146818rtc.h in powperpc kernel/time.c? May I have your opinions please? Thanks.
RE: [PATCH v5 1/2] platform/x86: dell-privacy: Add support for Dell hardware privacy
Hi Randy. > -Original Message- > From: Randy Dunlap > Sent: Tuesday, March 23, 2021 1:15 AM > To: Yuan, Perry; po...@protonmail.com; pierre- > louis.boss...@linux.intel.com; oder_ch...@realtek.com; pe...@perex.cz; > ti...@suse.com; hdego...@redhat.com; mgr...@linux.intel.com; > Limonciello, Mario > Cc: lgirdw...@gmail.com; broo...@kernel.org; alsa-de...@alsa-project.org; > linux-kernel@vger.kernel.org; platform-driver-...@vger.kernel.org > Subject: Re: [PATCH v5 1/2] platform/x86: dell-privacy: Add support for Dell > hardware privacy > > > [EXTERNAL EMAIL] > > On 3/22/21 2:38 AM, Perry Yuan wrote: > > From: Perry Yuan > > > > > diff --git a/drivers/platform/x86/dell/Kconfig > > b/drivers/platform/x86/dell/Kconfig > > index e0a55337f51a..0e0f1eb35bd6 100644 > > --- a/drivers/platform/x86/dell/Kconfig > > +++ b/drivers/platform/x86/dell/Kconfig > > @@ -204,4 +204,20 @@ config DELL_WMI_SYSMAN > > To compile this driver as a module, choose M here: the module will > > be called dell-wmi-sysman. > > > > +config DELL_PRIVACY > > + tristate "Dell Hardware Privacy Support" > > + depends on ACPI > > + depends on ACPI_WMI > > + depends on INPUT > > + depends on DELL_LAPTOP > > + depends on LEDS_TRIGGER_AUDIO > > + select DELL_WMI > > + help > > + This driver provides support for the "Dell Hardware Privacy" feature > > + of Dell laptops. > > + Support for a micmute and camera mute privacy will be provided as > > better: > are provided as > > > + hardware button Ctrl+F4 and Ctrl+F9 hotkey. > > Does that say that Ctrl+F4 is a hardware button and that Ctrl+F9 is a hotkey? > If so, what's the difference? and why? Are they different hardware > implementations? Does the user care? They all use the Ctrl button, Ctrl +F4 requires that the Ctrl button and F4 button are pressed at the same time. F9+ctrl also have the same meaning. They are belonging to same hardware privacy solution, just use different keys combination to activate different privacy function . > > > + > > + To compile this driver as a module, choose M here: the module will > > + be called dell_privacy. > > endif # X86_PLATFORM_DRIVERS_DELL > thanks. > -- > ~Randy
[PATCH v10] i2c: virtio: add a virtio i2c frontend driver
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
The device specification can be found on
https://lists.oasis-open.org/archives/virtio-comment/202101/msg8.html.
By following the specification, people may implement different
backend drivers to emulate different controllers according to
their needs.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
---
Changes in v10:
- Fix some typo errors.
- Refined the virtio_i2c_complete_reqs to use less code lines.
Changes in v9:
- Remove the virtio_adapter and update its members in probe.
- Refined the virtio_i2c_complete_reqs for buf free.
Changes in v8:
- Make virtio_i2c.adap a pointer.
- Mark members in virtio_i2c_req with cacheline_aligned.
Changes in v7:
- Remove unused headers.
- Update Makefile and Kconfig.
- Add the cleanup after completing reqs.
- Avoid memcpy for data marked with I2C_M_DMA_SAFE.
- Fix something reported by kernel test robot.
Changes in v6:
- Move struct virtio_i2c_req into the driver.
- Use only one buf in struct virtio_i2c_req.
Changes in v5:
- The first version based on the acked specification.
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 3 +
drivers/i2c/busses/i2c-virtio.c | 276
include/uapi/linux/virtio_i2c.h | 40 ++
include/uapi/linux/virtio_ids.h | 1 +
5 files changed, 331 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-virtio.c
create mode 100644 include/uapi/linux/virtio_i2c.h
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 05ebf75..cb8d0d8 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -21,6 +21,17 @@ config I2C_ALI1535
This driver can also be built as a module. If so, the module
will be called i2c-ali1535.
+config I2C_VIRTIO
+ tristate "Virtio I2C Adapter"
+ select VIRTIO
+ help
+ If you say yes to this option, support will be included for the virtio
+ I2C adapter driver. The hardware can be emulated by any device model
+ software according to the virtio protocol.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-virtio.
+
config I2C_ALI1563
tristate "ALI 1563"
depends on PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 615f35e..efdd3f3 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -145,4 +145,7 @@ obj-$(CONFIG_I2C_XGENE_SLIMPRO) += i2c-xgene-slimpro.o
obj-$(CONFIG_SCx200_ACB) += scx200_acb.o
obj-$(CONFIG_I2C_FSI) += i2c-fsi.o
+# VIRTIO I2C host controller driver
+obj-$(CONFIG_I2C_VIRTIO) += i2c-virtio.o
+
ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
new file mode 100644
index 000..99a1e30
--- /dev/null
+++ b/drivers/i2c/busses/i2c-virtio.c
@@ -0,0 +1,276 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Virtio I2C Bus Driver
+ *
+ * The Virtio I2C Specification:
+ *
https://raw.githubusercontent.com/oasis-tcs/virtio-spec/master/virtio-i2c.tex
+ *
+ * Copyright (c) 2021 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct virtio_i2c - virtio I2C data
+ * @vdev: virtio device for this controller
+ * @completion: completion of virtio I2C message
+ * @adap: I2C adapter for this controller
+ * @lock: lock for virtqueue processing
+ * @vq: the virtio virtqueue for communication
+ */
+struct virtio_i2c {
+ struct virtio_device *vdev;
+ struct completion completion;
+ struct i2c_adapter adap;
+ struct mutex lock;
+ struct virtqueue *vq;
+};
+
+/**
+ * struct virtio_i2c_req - the virtio I2C request structure
+ * @out_hdr: the OUT header of the virtio I2C message
+ * @buf: the buffer into which data is read, or from which it's written
+ * @in_hdr: the IN header of the virtio I2C message
+ */
+struct virtio_i2c_req {
+ struct virtio_i2c_out_hdr out_hdr cacheline_aligned;
+ uint8_t *bufcacheline_aligned;
+ struct virtio_i2c_in_hdr in_hdr cacheline_aligned;
+};
+
+static void virtio_i2c_msg_done(struct virtqueue *vq)
+{
+ struct virtio_i2c *vi = vq->vdev->priv;
+
+ complete(&vi->completion);
+}
+
+static int virtio_i2c_send_reqs(struct virtqueue *vq,
+ struct virtio_i2c_req *reqs,
+ struct i2c_msg *msgs, int nr)
+{
+ struct scatterlist *sgs[3], out_hdr, msg_buf, in_hdr;
+ int i, outcnt, incnt, err = 0;
+
RE: Re: [PATCH v31 2/4] scsi: ufs: L2P map management for HPB read
>On 2021-03-23 13:37, Daejun Park wrote:
>>> On 2021-03-23 12:22, Can Guo wrote:
On 2021-03-22 17:11, Bean Huo wrote:
> On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:
>> + switch (rsp_field->hpb_op) {
>>
>> + case HPB_RSP_REQ_REGION_UPDATE:
>>
>> + if (data_seg_len != DEV_DATA_SEG_LEN)
>>
>> + dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
>>
>> +"%s: data seg length is not
>> same.\n",
>>
>> +__func__);
>>
>> + ufshpb_rsp_req_region_update(hpb, rsp_field);
>>
>> + break;
>>
>> + case HPB_RSP_DEV_RESET:
>>
>> + dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
>>
>> +"UFS device lost HPB information during
>> PM.\n");
>>
>> + break;
>
> Hi Deajun,
> This series looks good to me. Just here I have one question. You
> didn't
> handle HPB_RSP_DEV_RESET, just a warning. Based on your SS UFS, how
> to
> handle HPB_RSP_DEV_RESET from the host side? Do you think we shoud
> reset host side HPB entry as well or what else?
>
>
> Bean
Same question here - I am still collecting feedbacks from flash
vendors
about
what is recommanded host behavior on reception of HPB Op code 0x2,
since it
is not cleared defined in HPB2.0 specs.
Can Guo.
>>>
>>> I think the question should be asked in the HPB2.0 patch, since in
>>> HPB1.0 device
>>> control mode, a HPB reset in device side does not impact anything in
>>> host side -
>>> host is not writing back any HPB entries to device anyways and HPB
>>> Read
>>> cmd with
>>> invalid HPB entries shall be treated as normal Read(10) cmd without
>>> any
>>> problems.
>>
>> Yes, UFS device will process read command even the HPB entries are
>> valid or
>> not. So it is warning about read performance drop by dev reset.
>
>Yeah, but still I am 100% sure about what should host do in case of
>HPB2.0
>when it receives HPB Op code 0x2, I am waiting for feedbacks.
I think the host has two choices when it receives 0x2.
One is nothing on host.
The other is discarding all HPB entries in the host.
In the JEDEC HPB spec, it as follows:
When the device is powered off by the host, the device may restore L2P map
data upon power up or build from the host’s HPB READ command.
If some UFS builds L2P map data from the host's HPB READ commands, we don't
have to discard HPB entries in the host.
So I thinks there is nothing to do when it receives 0x2.
Thanks,
Daejun
>Thanks,
>Can Guo.
>
>>
>> Thanks,
>> Daejun
>>
>>> Please correct me if I am wrong.
>>
>>
>>
>>> Thanks,
>>> Can Guo.
>>>
>>>
>>>
>
>
>
[PATCH] [v2] tools: testing: Remove duplicate includes
sched.h has been included at line 33, so remove the duplicate one at line 36. inttypes.h has been included at line 19, so remove the duplicate one at line 23. pthread.h has been included at line 17,so remove the duplicate one at line 20. Signed-off-by: Wan Jiabing --- tools/testing/selftests/powerpc/mm/tlbie_test.c | 1 - tools/testing/selftests/powerpc/tm/tm-poison.c | 1 - tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c | 1 - 3 files changed, 3 deletions(-) diff --git a/tools/testing/selftests/powerpc/mm/tlbie_test.c b/tools/testing/selftests/powerpc/mm/tlbie_test.c index f85a0938ab25..48344a74b212 100644 --- a/tools/testing/selftests/powerpc/mm/tlbie_test.c +++ b/tools/testing/selftests/powerpc/mm/tlbie_test.c @@ -33,7 +33,6 @@ #include #include #include -#include #include #include #include diff --git a/tools/testing/selftests/powerpc/tm/tm-poison.c b/tools/testing/selftests/powerpc/tm/tm-poison.c index 29e5f26af7b9..27c083a03d1f 100644 --- a/tools/testing/selftests/powerpc/tm/tm-poison.c +++ b/tools/testing/selftests/powerpc/tm/tm-poison.c @@ -20,7 +20,6 @@ #include #include #include -#include #include "tm.h" diff --git a/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c b/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c index e2a0c07e8362..9ef37a9836ac 100644 --- a/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c +++ b/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c @@ -17,7 +17,6 @@ #include #include #include -#include #include "tm.h" #include "utils.h" -- 2.25.1
Re: [PATCH] kdb: Refactor kdb_defcmd implementation
On Fri, 19 Mar 2021 at 22:47, Daniel Thompson
wrote:
>
> On Tue, Mar 09, 2021 at 05:47:47PM +0530, Sumit Garg wrote:
> > Switch to use kdbtab_t instead of separate struct defcmd_set since
> > now we have kdb_register_table() to register pre-allocated kdb commands.
>
> This needs rewriting. I've been struggling for some time to figure out
> what it actually means means and how it related to the patch. I'm
> starting to conclude that this might not be my fault!
>
Okay.
>
> > Also, switch to use a linked list for sub-commands instead of dynamic
> > array which makes traversing the sub-commands list simpler.
>
> We can't call these things sub-commands! These days a sub-commands
> implies something like `git subcommand` and kdb doesn't have anything
> like that.
>
To me, defcmd_set implied that we are defining a kdb command which
will run a list of other kdb commands which I termed as sub-commands
here. But yes I agree with you that these don't resemble `git
subcommand`.
>
> > +struct kdb_subcmd {
> > + char*scmd_name; /* Sub-command name */
> > + struct list_head list_node;/* Sub-command node */
> > +};
> > +
> > /* The KDB shell command table */
> > typedef struct _kdbtab {
> > char*cmd_name; /* Command name */
> > @@ -175,6 +181,7 @@ typedef struct _kdbtab {
> > kdb_cmdflags_t cmd_flags; /* Command behaviour flags */
> > struct list_head list_node; /* Command list */
> > boolis_dynamic; /* Command table allocation type */
> > + struct list_head kdb_scmds_head; /* Sub-commands list */
> > } kdbtab_t;
>
> Perhaps this should be more like:
>
> struct defcmd_set {
> kdbtab_t cmd;
> struct list_head commands;
>
> };
>
> This still gets registers using kdb_register_table() but it keeps the
> macro code all in once place:
>
> kdb_register_table(¯o->cmd, 1);
>
> I think that is what I *meant* to suggest ;-) . It also avoids having to
> talk about sub-commands!
Okay, I will use this struct instead.
> BTW I'm open to giving defcmd_set a better name
> (kdb_macro?)
>
kdb_macro sounds more appropriate.
> but I don't see why we want to give all commands a macro
> list.
I am not sure if I follow you here but I think it's better to
distinguish between a normal kdb command and a kdb command which is a
super-set (or macro) representing a list of other kdb commands.
-Sumit
>
> Daniel.
Re: [PATCH v12 1/2] scsi: ufs: Enable power management for wlun
On 22/03/21 9:53 pm, Asutosh Das (asd) wrote: > On 3/19/2021 10:47 AM, Adrian Hunter wrote: >> On 19/03/21 2:35 am, Asutosh Das wrote: >>> During runtime-suspend of ufs host, the scsi devices are >>> already suspended and so are the queues associated with them. >>> But the ufs host sends SSU to wlun during its runtime-suspend. >>> During the process blk_queue_enter checks if the queue is not in >>> suspended state. If so, it waits for the queue to resume, and never >>> comes out of it. >>> The commit >>> (d55d15a33: scsi: block: Do not accept any requests while suspended) >>> adds the check if the queue is in suspended state in blk_queue_enter(). >>> >>> Call trace: >>> __switch_to+0x174/0x2c4 >>> __schedule+0x478/0x764 >>> schedule+0x9c/0xe0 >>> blk_queue_enter+0x158/0x228 >>> blk_mq_alloc_request+0x40/0xa4 >>> blk_get_request+0x2c/0x70 >>> __scsi_execute+0x60/0x1c4 >>> ufshcd_set_dev_pwr_mode+0x124/0x1e4 >>> ufshcd_suspend+0x208/0x83c >>> ufshcd_runtime_suspend+0x40/0x154 >>> ufshcd_pltfrm_runtime_suspend+0x14/0x20 >>> pm_generic_runtime_suspend+0x28/0x3c >>> __rpm_callback+0x80/0x2a4 >>> rpm_suspend+0x308/0x614 >>> rpm_idle+0x158/0x228 >>> pm_runtime_work+0x84/0xac >>> process_one_work+0x1f0/0x470 >>> worker_thread+0x26c/0x4c8 >>> kthread+0x13c/0x320 >>> ret_from_fork+0x10/0x18 >>> >>> Fix this by registering ufs device wlun as a scsi driver and >>> registering it for block runtime-pm. Also make this as a >>> supplier for all other luns. That way, this device wlun >>> suspends after all the consumers and resumes after >>> hba resumes. >>> >>> Co-developed-by: Can Guo >>> Signed-off-by: Can Guo >>> Signed-off-by: Asutosh Das >> >> I have some more comments that may help straighten things out. >> >> Also please look at ufs_debugfs_get_user_access() and >> ufs_debugfs_put_user_access() that now need to scsi_autopm_get/put_device >> sdev_ufs_device. >> >> It would also be good if you could re-base on linux-next. >> > > Hi Adrian > Thanks for the comments. > > I agree moving the code to wlun probe and other changes. > But it looks to me that it may not fully solve the issue. > > Please let me explain my understanding on this: > > (Please refer to the logs in v10) > scsi_autopm_*() are invoked on a sdev. > pm_runtime_get_suppliers()/rpm_put_suppliers() are on the supplier device. > > For the device wlun: > slave_configure(): > - doesn't set the rpm_autosuspend > - pm_runtime_getnoresume() > scsi_sysfs_add_sdev(): > - pm_runtime_forbid() > - scsi_autopm_get_device() > - device_add() > - ufshcd_wl_probe() > - scsi_autopm_put_device() > > For all other scsi devices: > slave_alloc(): > - ufshcd_setup_links() > Say all link_add: pm_runtime_put(&hba->sdev_ufs_device->sdev_gendev); With DL_FLAG_RPM_ACTIVE, links will 'get' not 'put' > slave_configure(): > - set rpm_autosuspend > scsi_sysfs_add_sdev(): > - scsi_autopm_get_device() > - device_add() -> schedules an async probe() > - scsi_autopm_put_device() - (1) > > Now the rpm_put_suppliers() can be invoked *after* pm_runtime_get_suppliers() > of the async probe(), since both are running in different contexts. Only if the sd device suspends. > In that case, the usage_count of supplier would be decremented until > rpm_active of this link becomes 1. Right, because the sd device suspended. > Now the pm_runtime_get_suppliers() expects the link_active to be more than 1. Not sure what you mean here. pm_runtime_*put*_suppliers() won't do anything if the link count is 1. > Now then, there comes a time, that when sd_probe() schedules a suspend, the > supplier usage_count becomes 0 and the link_active becomes 1. > And the supplier suspends before the consumer. sd probe first resumes the sd device which will resume the supplier. > > So I was wondering, what'd make sure that the pm_runtime_get_suppliers() from > driver_probe_device() is invoked after scsi_autopm_put_device() (1) finishes > the rpm_put_suppliers(). > > Am not sure if I'm missing something in this. > Do you think, the current changes alone can fix the above issue? Yes, but let's see. > > -asd > >>> --- >>> drivers/scsi/ufs/cdns-pltfrm.c | 2 + >>> drivers/scsi/ufs/tc-dwc-g210-pci.c | 2 + >>> drivers/scsi/ufs/ufs-debugfs.c | 2 +- >>> drivers/scsi/ufs/ufs-debugfs.h | 2 +- >>> drivers/scsi/ufs/ufs-exynos.c | 2 + >>> drivers/scsi/ufs/ufs-hisi.c | 2 + >>> drivers/scsi/ufs/ufs-mediatek.c | 12 +- >>> drivers/scsi/ufs/ufs-qcom.c | 2 + >>> drivers/scsi/ufs/ufs_bsg.c | 6 +- >>> drivers/scsi/ufs/ufshcd-pci.c | 36 +-- >>> drivers/scsi/ufs/ufshcd.c | 622 >>> ++--- >>> drivers/scsi/ufs/ufshcd.h | 6 + >>> include/trace/events/ufs.h | 20 ++ >>> 13 files changed, 491 insertions(+), 225 delet
RE: [PATCH V2 0/6] PM / devfreq: a few small fixes and improvements
> From: Chanwoo Choi > Sent: Tuesday, March 23, 2021 12:11 PM > > Hi, > > On 3/23/21 12:25 PM, Dong Aisheng wrote: > > Hi Chanwoo, > > > > On Tue, Mar 23, 2021 at 11:13 AM Dong Aisheng > wrote: > >> > >> A few small fixes and improvements > >> > >> ChangeLog: > >> v1->v2: > >> * squash a few patches > >> * rebase to devfreq-testing > > > > I have to rebase to devfreq-testing instead of devfreq-next because > > below two patches only exist in devfreq-testing. > > 5cc75e9252e9 (devfreq/devfreq-testing) PM / devfreq: Add > > devfreq_transitions debugfs file > > dc9e557845c1 PM / devfreq: Add new up_threshold and down_differential > > sysfs attrs My patch 5 needs change based on it according to your > > suggestion. So i have to rebase to that branch. > > > > However, i found devfreq-testing can't build with GOV_PASSVIE enabled. > > Patch 1 fixed it. You can squash to the original one when apply. > > > > Please help take a look at this new series. > > Please rebase your patches either devfreq-next or linux-next.git Because > devfreq-testing branch is not official. Okay, then how about the patch 5 below? [PATCH V2 5/6] PM / devfreq: governor: optimize simpleondemand get_target_freq Should I also rebase it to devfreq-next or drop it first and then resend when your patch merged into mainline? https://patchwork.kernel.org/project/linux-arm-kernel/patch/1615294733-22761-10-git-send-email-aisheng.d...@nxp.com/ Regards Aisheng > > > Thanks > > > > Regards > > Aisheng > > > >> * drop two patches which are already in devfreq-next > >> > >> Dong Aisheng (6): > >> PM / devfreq: fix build error when DEVFREQ_GOV_PASSIVE enabled > >> PM / devfreq: Use more accurate returned new_freq as resume_freq > >> PM / devfreq: Remove the invalid description for get_target_freq > >> PM / devfreq: bail out early if no freq changes in devfreq_set_target > >> PM / devfreq: governor: optimize simpleondemand get_target_freq > >> PM / devfreq: imx8m-ddrc: remove imx8m_ddrc_get_dev_status > >> > >> Documentation/ABI/testing/sysfs-class-devfreq | 5 +-- > >> drivers/devfreq/devfreq.c | 37 +++ > >> drivers/devfreq/governor.h| 2 - > >> drivers/devfreq/governor_simpleondemand.c | 31 ++-- > >> drivers/devfreq/imx8m-ddrc.c | 14 --- > >> 5 files changed, 35 insertions(+), 54 deletions(-) > >> > >> -- > >> 2.25.1 > >> > > > > > > > -- > Best Regards, > Chanwoo Choi > Samsung Electronics
Re: [kbuild-all] Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(st
Hi Vincent,
On 3/23/21 1:46 PM, Vincent MAILHOL wrote:
Hi Oliver and Rong,
This is an interesting and quite surprising issue!
On Tue. 23 mars 2021 at 11:54, Rong Chen wrote:
On 3/23/21 12:24 AM, Oliver Hartkopp wrote:
Hi Rong,
On 22.03.21 09:52, Rong Chen wrote:
On 3/21/21 10:19 PM, Oliver Hartkopp wrote:
Two reminders in two days? ;-)
Did you check my answer here?
https://lore.kernel.org/lkml/afffeb73-ba4c-ca2c-75d0-9e7899e5c...@hartkopp.net/
And did you try the partly revert?
Hi Oliver,
Sorry for the delay, we tried the revert patch and the problem still
exists,
we also found that commit c7b74967 changed the error message which
triggered
the report.
The problem is that offsetof(struct can_frame, data) !=
offsetof(struct canfd_frame, data)
the following struct layout shows that the offset has been changed by
union:
struct can_frame {
canid_tcan_id; /* 0 4 */
union {
__u8 len; /* 4 1 */
__u8 can_dlc; /* 4 1 */
}; /* 4 4 */
Ugh! Why did the compiler extend the space for the union to 4 bytes?!?
Just a random idea but maybe the added padding is due to some
kind of odd intrication with the __attribute__((__aligned__(8)))
just below? Does this reproduce if we remove the
__attribute__((__aligned__(8)))?
Here is the layout without __attribute__((__aligned__(8))),
the union is still extended to 4 bytes:
struct can_frame {
canid_t can_id; /* 0 4 */
union {
__u8 len; /* 4 1 */
__u8 can_dlc; /* 4 1 */
}; /* 4 4 */
__u8 __pad; /* 8 1 */
__u8 __res0; /* 9 1 */
__u8 len8_dlc; /* 10 1 */
__u8 data[8]; /* 11 8 */
/* size: 20, cachelines: 1, members: 6 */
/* padding: 1 */
/* last cacheline: 20 bytes */
};
Best Regards,
Rong Chen
(I am not saying that we should permanently remove it, this is
only a suggestion for troubleshooting).
__u8 __pad;/* 8 1 */
__u8 __res0; /* 9 1 */
__u8 len8_dlc; /* 10 1 */
/* XXX 5 bytes hole, try to pack */
__u8 data[8]
__attribute__((__aligned__(8))); /*16 8 */
/* size: 24, cachelines: 1, members: 6 */
/* sum members: 19, holes: 1, sum holes: 5 */
/* forced alignments: 1, forced holes: 1, sum forced holes:
5 */
/* last cacheline: 24 bytes */
} __attribute__((__aligned__(8)));
struct canfd_frame {
canid_tcan_id; /* 0 4 */
__u8 len; /* 4 1 */
__u8 flags;/* 5 1 */
__u8 __res0; /* 6 1 */
__u8 __res1; /* 7 1 */
__u8 data[64]
__attribute__((__aligned__(8))); /* 864 */
/* size: 72, cachelines: 2, members: 6 */
/* forced alignments: 1 */
/* last cacheline: 8 bytes */
} __attribute__((__aligned__(8)))
and I tried to add "__attribute__((packed))" to the union, the issue
is gone:
diff --git a/include/uapi/linux/can.h b/include/uapi/linux/can.h
index f75238ac6dce..9842bb55ffd9 100644
--- a/include/uapi/linux/can.h
+++ b/include/uapi/linux/can.h
@@ -113,7 +113,7 @@ struct can_frame {
*/
__u8 len;
__u8 can_dlc; /* deprecated */
- };
+ } __attribute__((packed));
__u8 __pad; /* padding */
__u8 __res0; /* reserved / padding */
__u8 len8_dlc; /* optional DLC for 8 byte payload length (9
.. 15) */
This is pretty strange!
pahole on my x86_64 machine shows the correct data structure layout:
struct can_frame {
canid_tcan_id; /* 0 4 */
union {
__u8 len; /* 4 1 */
__u8 can_dlc; /* 4 1 */
}; /* 4 1 */
__u8 __pad;/* 5 1 */
__u8 __res0; /* 6 1 */
__u8 len8_dlc; /* 7 1 */
__u8 data[8]
__attribute__((__aligned__(8))); /* 8 8 */
Re: [PATCH v31 2/4] scsi: ufs: L2P map management for HPB read
On 2021-03-23 13:37, Daejun Park wrote:
On 2021-03-23 12:22, Can Guo wrote:
On 2021-03-22 17:11, Bean Huo wrote:
On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:
+ switch (rsp_field->hpb_op) {
+ case HPB_RSP_REQ_REGION_UPDATE:
+ if (data_seg_len != DEV_DATA_SEG_LEN)
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"%s: data seg length is not
same.\n",
+__func__);
+ ufshpb_rsp_req_region_update(hpb, rsp_field);
+ break;
+ case HPB_RSP_DEV_RESET:
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"UFS device lost HPB information during
PM.\n");
+ break;
Hi Deajun,
This series looks good to me. Just here I have one question. You
didn't
handle HPB_RSP_DEV_RESET, just a warning. Based on your SS UFS, how
to
handle HPB_RSP_DEV_RESET from the host side? Do you think we shoud
reset host side HPB entry as well or what else?
Bean
Same question here - I am still collecting feedbacks from flash
vendors
about
what is recommanded host behavior on reception of HPB Op code 0x2,
since it
is not cleared defined in HPB2.0 specs.
Can Guo.
I think the question should be asked in the HPB2.0 patch, since in
HPB1.0 device
control mode, a HPB reset in device side does not impact anything in
host side -
host is not writing back any HPB entries to device anyways and HPB
Read
cmd with
invalid HPB entries shall be treated as normal Read(10) cmd without
any
problems.
Yes, UFS device will process read command even the HPB entries are
valid or
not. So it is warning about read performance drop by dev reset.
Yeah, but still I am 100% sure about what should host do in case of
HPB2.0
when it receives HPB Op code 0x2, I am waiting for feedbacks.
Thanks,
Can Guo.
Thanks,
Daejun
Please correct me if I am wrong.
Thanks,
Can Guo.
[PATCH 2/2] iommu/mediatek: Alloc building as module
The IOMMU in many SoC depends on the MM clocks and power-domain which
are device_initcall normally, thus the subsys_init here is not helpful.
This patch switches it to module_platform_driver which allow the
driver built as module.
Correspondingly switch the config to tristate.
Signed-off-by: Yong Wu
---
drivers/iommu/Kconfig | 2 +-
drivers/iommu/mtk_iommu.c | 16
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index bc93da48bed0..74f3e15edc14 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -349,7 +349,7 @@ config S390_AP_IOMMU
is not implemented as it is not necessary for VFIO.
config MTK_IOMMU
- bool "MTK IOMMU Support"
+ tristate "MediaTek IOMMU Support"
depends on ARCH_MEDIATEK || COMPILE_TEST
select ARM_DMA_USE_IOMMU
select IOMMU_API
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6ecc007f07cd..a73ff3e20480 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1079,16 +1080,7 @@ static struct platform_driver mtk_iommu_driver = {
.pm = &mtk_iommu_pm_ops,
}
};
+module_platform_driver(mtk_iommu_driver);
-static int __init mtk_iommu_init(void)
-{
- int ret;
-
- ret = platform_driver_register(&mtk_iommu_driver);
- if (ret != 0)
- pr_err("Failed to register MTK IOMMU driver\n");
-
- return ret;
-}
-
-subsys_initcall(mtk_iommu_init)
+MODULE_DESCRIPTION("IOMMU API for MediaTek M4U implementations");
+MODULE_LICENSE("GPL v2");
--
2.18.0
[PATCH 1/2] iommu/mediatek-v1: Alloc building as module
This patch only adds support for building the IOMMU-v1 driver as module.
Correspondingly switch the config to tristate.
Signed-off-by: Yong Wu
---
rebase on v5.12-rc2.
---
drivers/iommu/Kconfig| 2 +-
drivers/iommu/mtk_iommu_v1.c | 9 -
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 192ef8f61310..bc93da48bed0 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -364,7 +364,7 @@ config MTK_IOMMU
If unsure, say N here.
config MTK_IOMMU_V1
- bool "MTK IOMMU Version 1 (M4U gen1) Support"
+ tristate "MediaTek IOMMU Version 1 (M4U gen1) Support"
depends on ARM
depends on ARCH_MEDIATEK || COMPILE_TEST
select ARM_DMA_USE_IOMMU
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 82ddfe9170d4..71370037083a 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -691,9 +692,7 @@ static struct platform_driver mtk_iommu_driver = {
.pm = &mtk_iommu_pm_ops,
}
};
+module_platform_driver(mtk_iommu_driver);
-static int __init m4u_init(void)
-{
- return platform_driver_register(&mtk_iommu_driver);
-}
-subsys_initcall(m4u_init);
+MODULE_DESCRIPTION("IOMMU API for MediaTek M4U v1 implementations");
+MODULE_LICENSE("GPL v2");
--
2.18.0
Re: linux-next: build warning after merge of the sound-asoc tree
On 3/23/21 11:13 AM, Stephen Rothwell wrote:
Hi all,
After merging the sound-asoc tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
sound/soc/amd/acp-da7219-max98357a.c:684:28: warning: 'cz_rt5682_card' defined
but not used [-Wunused-variable]
684 | static struct snd_soc_card cz_rt5682_card = {
|^~
sound/soc/amd/acp-da7219-max98357a.c:671:28: warning: 'cz_card' defined but not
used [-Wunused-variable]
671 | static struct snd_soc_card cz_card = {
|^~~
Introduced by commit
7e71b48f9e27 ("ASoC: amd: Add support for RT5682 codec in machine driver")
Will add ACPI dependency in Kconfig and submit the supplement patch.
linux-next: build warning after merge of the v4l-dvb tree
Hi all,
After merging the v4l-dvb tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/driver-api/media/camera-sensor.rst:147: WARNING: Error in
"c:function" directive:
1 argument(s) required, 0 supplied.
.. c:function::
int pm_runtime_get_if_in_use(struct device *dev);
Introduced by commit
c0e3bcb25390 ("media: camera-sensor.rst: fix a doc build warning")
--
Cheers,
Stephen Rothwell
pgpqSC44tkRva.pgp
Description: OpenPGP digital signature
linux-next: build warning in Linus' tree
Hi all,
Building Linus' tree, today's linux-next build (x86_64 allnoconfig)
produced this warning:
kernel/static_call.c: In function '__static_call_update':
kernel/static_call.c:153:18: warning: unused variable 'mod' [-Wunused-variable]
153 | struct module *mod = site_mod->mod;
| ^~~
Introduced by commit
698bacefe993 ("static_call: Align static_call_is_init() patching condition")
--
Cheers,
Stephen Rothwell
pgpB9INoHqX51.pgp
Description: OpenPGP digital signature
[PATCH] soc: mediatek: mmsys: Add mt8183 mmsys routing table
mt8183 has different routing registers than mt8173.
Signed-off-by: Hsin-Yi Wang
---
This patch is based on series ("soc: mediatek: Prepare MMSYS for DDP routing
using tables")[1]
and tested with mt8183 krand and mt8183 juniper device.
The register value is referenced from [2].
[1]
https://patchwork.kernel.org/project/linux-mediatek/cover/20210317181711.795245-1-enric.balle...@collabora.com/
[2]
https://patchwork.kernel.org/project/linux-mediatek/patch/1609815993-22744-6-git-send-email-yongqiang@mediatek.com/
---
drivers/soc/mediatek/mtk-mmsys.c | 2 ++
drivers/soc/mediatek/mtk-mmsys.h | 47
2 files changed, 49 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index c46d8ab8b0c2..16bb55b0463a 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -40,6 +40,8 @@ static const struct mtk_mmsys_driver_data
mt8173_mmsys_driver_data = {
static const struct mtk_mmsys_driver_data mt8183_mmsys_driver_data = {
.clk_driver = "clk-mt8183-mm",
+ .routes = mmsys_mt8183_routing_table,
+ .num_routes = ARRAY_SIZE(mmsys_mt8183_routing_table),
};
struct mtk_mmsys {
diff --git a/drivers/soc/mediatek/mtk-mmsys.h b/drivers/soc/mediatek/mtk-mmsys.h
index a760a34e6eca..c55baf5932b8 100644
--- a/drivers/soc/mediatek/mtk-mmsys.h
+++ b/drivers/soc/mediatek/mtk-mmsys.h
@@ -66,6 +66,28 @@
#define DPI_SEL_IN_BLS 0x0
#define DSI_SEL_IN_RDMA0x1
+#define MT8183_DISP_OVL0_MOUT_EN 0xf00
+#define MT8183_DISP_OVL0_2L_MOUT_EN0xf04
+#define MT8183_DISP_OVL1_2L_MOUT_EN0xf08
+#define MT8183_DISP_DITHER0_MOUT_EN0xf0c
+#define MT8183_DISP_PATH0_SEL_IN 0xf24
+#define MT8183_DISP_DSI0_SEL_IN0xf2c
+#define MT8183_DISP_DPI0_SEL_IN0xf30
+#define MT8183_DISP_RDMA0_SOUT_SEL_IN 0xf50
+#define MT8183_DISP_RDMA1_SOUT_SEL_IN 0xf54
+
+#define MT8183_OVL0_MOUT_EN_OVL0_2LBIT(4)
+#define MT8183_OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
+#define MT8183_OVL1_2L_MOUT_EN_RDMA1 BIT(4)
+#define MT8183_DITHER0_MOUT_IN_DSI0BIT(0)
+#define MT8183_DISP_PATH0_SEL_IN_OVL0_2L 0x1
+#define MT8183_DSI0_SEL_IN_RDMA0 0x1
+#define MT8183_DSI0_SEL_IN_RDMA1 0x3
+#define MT8183_DPI0_SEL_IN_RDMA0 0x1
+#define MT8183_DPI0_SEL_IN_RDMA1 0x2
+#define MT8183_RDMA0_SOUT_COLOR0 0x1
+#define MT8183_RDMA1_SOUT_DSI0 0x1
+
struct mtk_mmsys_routes {
u32 from_comp;
u32 to_comp;
@@ -212,4 +234,29 @@ static const struct mtk_mmsys_routes
mmsys_default_routing_table[] = {
}
};
+static const struct mtk_mmsys_routes mmsys_mt8183_routing_table[] = {
+ {
+ DDP_COMPONENT_OVL0, DDP_COMPONENT_OVL_2L0,
+ MT8183_DISP_OVL0_MOUT_EN, MT8183_OVL0_MOUT_EN_OVL0_2L
+ }, {
+ DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
+ MT8183_DISP_OVL0_2L_MOUT_EN, MT8183_OVL0_2L_MOUT_EN_DISP_PATH0
+ }, {
+ DDP_COMPONENT_OVL_2L1, DDP_COMPONENT_RDMA1,
+ MT8183_DISP_OVL1_2L_MOUT_EN, MT8183_OVL1_2L_MOUT_EN_RDMA1
+ }, {
+ DDP_COMPONENT_DITHER, DDP_COMPONENT_DSI0,
+ MT8183_DISP_DITHER0_MOUT_EN, MT8183_DITHER0_MOUT_IN_DSI0
+ }, {
+ DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
+ MT8183_DISP_PATH0_SEL_IN, MT8183_DISP_PATH0_SEL_IN_OVL0_2L
+ }, {
+ DDP_COMPONENT_RDMA1, DDP_COMPONENT_DPI0,
+ MT8183_DISP_DPI0_SEL_IN, MT8183_DPI0_SEL_IN_RDMA1
+ }, {
+ DDP_COMPONENT_RDMA0, DDP_COMPONENT_COLOR0,
+ MT8183_DISP_RDMA0_SOUT_SEL_IN, MT8183_RDMA0_SOUT_COLOR0
+ }
+};
+
#endif /* __SOC_MEDIATEK_MTK_MMSYS_H */
--
2.31.0.rc2.261.g7f71774620-goog
Re: [kbuild-all] Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(st
Hi Oliver and Rong,
This is an interesting and quite surprising issue!
On Tue. 23 mars 2021 at 11:54, Rong Chen wrote:
> On 3/23/21 12:24 AM, Oliver Hartkopp wrote:
> > Hi Rong,
> >
> > On 22.03.21 09:52, Rong Chen wrote:
> >
> >> On 3/21/21 10:19 PM, Oliver Hartkopp wrote:
> >>> Two reminders in two days? ;-)
> >>>
> >>> Did you check my answer here?
> >>> https://lore.kernel.org/lkml/afffeb73-ba4c-ca2c-75d0-9e7899e5c...@hartkopp.net/
> >>>
> >>>
> >>> And did you try the partly revert?
> >>
> >> Hi Oliver,
> >>
> >> Sorry for the delay, we tried the revert patch and the problem still
> >> exists,
> >> we also found that commit c7b74967 changed the error message which
> >> triggered
> >> the report.
> >>
> >> The problem is that offsetof(struct can_frame, data) !=
> >> offsetof(struct canfd_frame, data)
> >> the following struct layout shows that the offset has been changed by
> >> union:
> >>
> >> struct can_frame {
> >> canid_tcan_id; /* 0 4 */
> >> union {
> >> __u8 len; /* 4 1 */
> >> __u8 can_dlc; /* 4 1 */
> >> }; /* 4 4 */
> >
> > Ugh! Why did the compiler extend the space for the union to 4 bytes?!?
Just a random idea but maybe the added padding is due to some
kind of odd intrication with the __attribute__((__aligned__(8)))
just below? Does this reproduce if we remove the
__attribute__((__aligned__(8)))?
(I am not saying that we should permanently remove it, this is
only a suggestion for troubleshooting).
> >> __u8 __pad;/* 8 1 */
> >> __u8 __res0; /* 9 1 */
> >> __u8 len8_dlc; /* 10 1 */
> >>
> >> /* XXX 5 bytes hole, try to pack */
> >>
> >> __u8 data[8]
> >> __attribute__((__aligned__(8))); /*16 8 */
> >>
> >> /* size: 24, cachelines: 1, members: 6 */
> >> /* sum members: 19, holes: 1, sum holes: 5 */
> >> /* forced alignments: 1, forced holes: 1, sum forced holes:
> >> 5 */
> >> /* last cacheline: 24 bytes */
> >> } __attribute__((__aligned__(8)));
> >>
> >> struct canfd_frame {
> >> canid_tcan_id; /* 0 4 */
> >> __u8 len; /* 4 1 */
> >> __u8 flags;/* 5 1 */
> >> __u8 __res0; /* 6 1 */
> >> __u8 __res1; /* 7 1 */
> >> __u8 data[64]
> >> __attribute__((__aligned__(8))); /* 864 */
> >>
> >> /* size: 72, cachelines: 2, members: 6 */
> >> /* forced alignments: 1 */
> >> /* last cacheline: 8 bytes */
> >> } __attribute__((__aligned__(8)))
> >>
> >>
> >> and I tried to add "__attribute__((packed))" to the union, the issue
> >> is gone:
> >>
> >> diff --git a/include/uapi/linux/can.h b/include/uapi/linux/can.h
> >> index f75238ac6dce..9842bb55ffd9 100644
> >> --- a/include/uapi/linux/can.h
> >> +++ b/include/uapi/linux/can.h
> >> @@ -113,7 +113,7 @@ struct can_frame {
> >> */
> >> __u8 len;
> >> __u8 can_dlc; /* deprecated */
> >> - };
> >> + } __attribute__((packed));
> >> __u8 __pad; /* padding */
> >> __u8 __res0; /* reserved / padding */
> >> __u8 len8_dlc; /* optional DLC for 8 byte payload length (9
> >> .. 15) */
> >
> > This is pretty strange!
> >
> > pahole on my x86_64 machine shows the correct data structure layout:
> >
> > struct can_frame {
> > canid_tcan_id; /* 0 4 */
> > union {
> > __u8 len; /* 4 1 */
> > __u8 can_dlc; /* 4 1 */
> > }; /* 4 1 */
> > __u8 __pad;/* 5 1 */
> > __u8 __res0; /* 6 1 */
> > __u8 len8_dlc; /* 7 1 */
> > __u8 data[8]
> > __attribute__((__aligned__(8))); /* 8 8 */
> >
> > /* size: 16, cachelines: 1, members: 6 */
> > /* forced alignments: 1 */
> > /* last cacheline: 16 bytes */
> > } __attribute__((__aligned__(8)));
> >
> > Target: x86_64-linux-gnu
> > gcc version 10.2.1 20210110 (Debian 10.2.1-6)
> > Linux 5.12.0-rc3-00070-g8b12a62a4e3e x86_64 GNU/Linux
> >
> > So it looks like your compiler does not behave correctly - and I
> > wonder if it would be the correct approach to add the __packed()
> > attribute or better fix/change the (A
Re: [PATCH] hwmon: (ftsteutates): Rudimentary typo fixes
On 3/22/21 9:34 PM, Bhaskar Chowdhury wrote:
>
> s/Temprature/Temperature/
> s/revsion/revision/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> drivers/hwmon/ftsteutates.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwmon/ftsteutates.c b/drivers/hwmon/ftsteutates.c
> index ef88a156efc2..ceffc76a0c51 100644
> --- a/drivers/hwmon/ftsteutates.c
> +++ b/drivers/hwmon/ftsteutates.c
> @@ -509,7 +509,7 @@ fan_alarm_store(struct device *dev, struct
> device_attribute *devattr,
> /* SysFS structs */
>
> /*/
>
> -/* Temprature sensors */
> +/* Temperature sensors */
> static SENSOR_DEVICE_ATTR_RO(temp1_input, temp_value, 0);
> static SENSOR_DEVICE_ATTR_RO(temp2_input, temp_value, 1);
> static SENSOR_DEVICE_ATTR_RO(temp3_input, temp_value, 2);
> @@ -713,7 +713,7 @@ static int fts_detect(struct i2c_client *client,
> {
> int val;
>
> - /* detection works with revsion greater or equal to 0x2b */
> + /* detection works with revision greater or equal to 0x2b */
> val = i2c_smbus_read_byte_data(client, FTS_DEVICE_REVISION_REG);
> if (val < 0x2b)
> return -ENODEV;
> --
--
~Randy
Re: [PATCH] tools: testing: Remove duplicate include of sched.h
Le 23/03/2021 à 04:34, Wan Jiabing a écrit : sched.h has been included at line 33. So we remove the duplicate one at line 36. Can you please send a single patch for all files in tools/testing/selftests/powerpc/ Thanks Christophe Signed-off-by: Wan Jiabing --- tools/testing/selftests/powerpc/mm/tlbie_test.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/powerpc/mm/tlbie_test.c b/tools/testing/selftests/powerpc/mm/tlbie_test.c index f85a0938ab25..48344a74b212 100644 --- a/tools/testing/selftests/powerpc/mm/tlbie_test.c +++ b/tools/testing/selftests/powerpc/mm/tlbie_test.c @@ -33,7 +33,6 @@ #include #include #include -#include #include #include #include
linux-next: build warning after merge of the sound-asoc tree
Hi all,
After merging the sound-asoc tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
sound/soc/amd/acp-da7219-max98357a.c:684:28: warning: 'cz_rt5682_card' defined
but not used [-Wunused-variable]
684 | static struct snd_soc_card cz_rt5682_card = {
|^~
sound/soc/amd/acp-da7219-max98357a.c:671:28: warning: 'cz_card' defined but not
used [-Wunused-variable]
671 | static struct snd_soc_card cz_card = {
|^~~
Introduced by commit
7e71b48f9e27 ("ASoC: amd: Add support for RT5682 codec in machine driver")
--
Cheers,
Stephen Rothwell
pgpKrzfX_1vvo.pgp
Description: OpenPGP digital signature
Re: [PATCH] octeontx2-af: cn10k: Few mundane typos fixed
On 3/22/21 9:28 PM, Bhaskar Chowdhury wrote:
>
> s/preceeds/precedes/ .two different places
> s/rsponse/response/
> s/cetain/certain/
> s/precison/precision/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> index ea456099b33c..14a184c3f6a4 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
> @@ -277,7 +277,7 @@ struct msg_req {
> struct mbox_msghdr hdr;
> };
>
> -/* Generic rsponse msg used a ack or response for those mbox
> +/* Generic response msg used a ack or response for those mbox> * messages
> which doesn't have a specific rsp msg format.
> */
Nak, negative. ETOOMANYERRORS.
How about:
/* Generic response msg used an ack or response for those mbox
* messages which don't have a specific rsp msg format.
*/
The other changes look good.
--
~Randy
Re: [PATCH] arch: powerpc: Remove duplicate include of interrupt.h
Le 23/03/2021 à 03:41, Wan Jiabing a écrit : asm/interrupt.h has been included at line 12. According to alphabetic order,we remove the duplicate one at line 10. Could you please cook a single patch for all files in arch/powerpc/ Thanks Christophe Signed-off-by: Wan Jiabing --- arch/powerpc/kernel/interrupt.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c index c475a229a42a..11d456896772 100644 --- a/arch/powerpc/kernel/interrupt.c +++ b/arch/powerpc/kernel/interrupt.c @@ -7,7 +7,6 @@ #include #include #include -#include #include #include #include
[syzbot] WARNING in io_sq_thread_park
Hello, syzbot found the following issue on: HEAD commit:84196390 Merge tag 'selinux-pr-20210322' of git://git.kern.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=152a6ad6d0 kernel config: https://syzkaller.appspot.com/x/.config?x=5adab0bdee099d7a dashboard link: https://syzkaller.appspot.com/bug?extid=e3a3f84f5cecf61f0583 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e3a3f84f5cecf61f0...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 1 PID: 27907 at fs/io_uring.c:7147 io_sq_thread_park+0xb5/0xd0 fs/io_uring.c:7147 Modules linked in: CPU: 1 PID: 27907 Comm: iou-sqp-27905 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:io_sq_thread_park+0xb5/0xd0 fs/io_uring.c:7147 Code: 3c 02 00 75 29 48 8b ab a8 00 00 00 48 85 ed 74 0d e8 df a3 99 ff 48 89 ef e8 f7 49 75 ff 5b 5d e9 d0 a3 99 ff e8 cb a3 99 ff <0f> 0b eb 85 48 89 ef e8 bf 36 dd ff eb cd 48 89 ef e8 b5 36 dd ff RSP: 0018:c90001bff9e8 EFLAGS: 00010293 RAX: RBX: 88802489a000 RCX: RDX: 88808e7e RSI: 81da4a65 RDI: 88802489a000 RBP: 88802489a0a8 R08: 0001 R09: 88806a7420c7 R10: ed100d4e8418 R11: R12: 88806a742590 R13: 88806a742458 R14: 19200037ff42 R15: 88806a7424b8 FS: 7f63505a8700() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00540198 CR3: 24531000 CR4: 00350ef0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0111062a Call Trace: io_ring_ctx_wait_and_kill+0x214/0x700 fs/io_uring.c:8619 io_uring_release+0x3e/0x50 fs/io_uring.c:8646 __fput+0x288/0x920 fs/file_table.c:280 task_work_run+0xdd/0x1a0 kernel/task_work.c:140 io_run_task_work fs/io_uring.c:2238 [inline] io_run_task_work fs/io_uring.c:2228 [inline] io_uring_try_cancel_requests+0x8ec/0xc60 fs/io_uring.c:8770 io_uring_cancel_sqpoll+0x1cf/0x290 fs/io_uring.c:8974 io_sqpoll_cancel_cb+0x87/0xb0 fs/io_uring.c:8907 io_run_task_work_head+0x58/0xb0 fs/io_uring.c:1961 io_sq_thread+0x3e2/0x18d0 fs/io_uring.c:6763 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: [PATCH] perf tools: Trivial spelling fixes
On 3/22/21 9:46 PM, Bhaskar Chowdhury wrote:
>
> s/succeded/succeeded/ five different places
> s/revsions/revisions/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
> ---
> tools/perf/util/header.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
> index 20effdff76ce..97a0eeb6d2ab 100644
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c
> @@ -127,7 +127,7 @@ static int __do_write_buf(struct feat_fd *ff, const void
> *buf, size_t size)
> return 0;
> }
>
> -/* Return: 0 if succeded, -ERR if failed. */
> +/* Return: 0 if succeeded, -ERR if failed. */
> int do_write(struct feat_fd *ff, const void *buf, size_t size)
> {
> if (!ff->buf)
> @@ -135,7 +135,7 @@ int do_write(struct feat_fd *ff, const void *buf, size_t
> size)
> return __do_write_buf(ff, buf, size);
> }
>
> -/* Return: 0 if succeded, -ERR if failed. */
> +/* Return: 0 if succeeded, -ERR if failed. */
> static int do_write_bitmap(struct feat_fd *ff, unsigned long *set, u64 size)
> {
> u64 *p = (u64 *) set;
> @@ -154,7 +154,7 @@ static int do_write_bitmap(struct feat_fd *ff, unsigned
> long *set, u64 size)
> return 0;
> }
>
> -/* Return: 0 if succeded, -ERR if failed. */
> +/* Return: 0 if succeeded, -ERR if failed. */
> int write_padded(struct feat_fd *ff, const void *bf,
>size_t count, size_t count_aligned)
> {
> @@ -170,7 +170,7 @@ int write_padded(struct feat_fd *ff, const void *bf,
> #define string_size(str) \
> (PERF_ALIGN((strlen(str) + 1), NAME_ALIGN) + sizeof(u32))
>
> -/* Return: 0 if succeded, -ERR if failed. */
> +/* Return: 0 if succeeded, -ERR if failed. */
> static int do_write_string(struct feat_fd *ff, const char *str)
> {
> u32 len, olen;
> @@ -266,7 +266,7 @@ static char *do_read_string(struct feat_fd *ff)
> return NULL;
> }
>
> -/* Return: 0 if succeded, -ERR if failed. */
> +/* Return: 0 if succeeded, -ERR if failed. */
> static int do_read_bitmap(struct feat_fd *ff, unsigned long **pset, u64
> *psize)
> {
> unsigned long *set;
> @@ -3485,7 +3485,7 @@ static const size_t attr_pipe_abi_sizes[] = {
> * between host recording the samples, and host parsing the samples is the
> * same. This is not always the case given that the pipe output may always be
> * redirected into a file and analyzed on a different machine with possibly a
> - * different endianness and perf_event ABI revsions in the perf tool itself.
> + * different endianness and perf_event ABI revisions in the perf tool itself.
> */
> static int try_all_pipe_abis(uint64_t hdr_sz, struct perf_header *ph)
> {
> --
--
~Randy
RE: Re: [PATCH v31 2/4] scsi: ufs: L2P map management for HPB read
>On 2021-03-23 12:22, Can Guo wrote:
>> On 2021-03-22 17:11, Bean Huo wrote:
>>> On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:
+ switch (rsp_field->hpb_op) {
+ case HPB_RSP_REQ_REGION_UPDATE:
+ if (data_seg_len != DEV_DATA_SEG_LEN)
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"%s: data seg length is not
same.\n",
+__func__);
+ ufshpb_rsp_req_region_update(hpb, rsp_field);
+ break;
+ case HPB_RSP_DEV_RESET:
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"UFS device lost HPB information during
PM.\n");
+ break;
>>>
>>> Hi Deajun,
>>> This series looks good to me. Just here I have one question. You
>>> didn't
>>> handle HPB_RSP_DEV_RESET, just a warning. Based on your SS UFS, how
>>> to
>>> handle HPB_RSP_DEV_RESET from the host side? Do you think we shoud
>>> reset host side HPB entry as well or what else?
>>>
>>>
>>> Bean
>>
>> Same question here - I am still collecting feedbacks from flash vendors
>> about
>> what is recommanded host behavior on reception of HPB Op code 0x2,
>> since it
>> is not cleared defined in HPB2.0 specs.
>>
>> Can Guo.
>
>I think the question should be asked in the HPB2.0 patch, since in
>HPB1.0 device
>control mode, a HPB reset in device side does not impact anything in
>host side -
>host is not writing back any HPB entries to device anyways and HPB Read
>cmd with
>invalid HPB entries shall be treated as normal Read(10) cmd without any
>problems.
Yes, UFS device will process read command even the HPB entries are valid or
not. So it is warning about read performance drop by dev reset.
Thanks,
Daejun
>Please correct me if I am wrong.
>Thanks,
>Can Guo.
>
>
>
Re: [PATCH] rcu: Fix various typos in comments
On Tue, Mar 23, 2021 at 08:26:14AM +0530, Bhaskar Chowdhury wrote:
> On 00:02 Tue 23 Mar 2021, Ingo Molnar wrote:
> >
> > Hi Paul,
> >
> > Was working on automation to make it a bit more straightforward to fix
> > typos within comments (which we tend to reintroduce during
> > development), and here are the ones it found in the RCU code.
> >
> > Thanks,
> >
> > Ingo
> >
> > =>
> > From: Ingo Molnar
> > Date: Mon, 22 Mar 2021 23:57:26 +0100
> > Subject: [PATCH] rcu: Fix various typos in comments
> >
> > Fix ~12 single-word typos in RCU code comments.
> >
> > Signed-off-by: Ingo Molnar
> > Cc: Paul E. McKenney
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > kernel/rcu/srcutree.c | 4 ++--
> > kernel/rcu/sync.c | 2 +-
> > kernel/rcu/tasks.h | 8
> > kernel/rcu/tree.c | 4 ++--
> > kernel/rcu/tree.h | 2 +-
> > kernel/rcu/tree_plugin.h| 2 +-
> > tools/testing/selftests/rcutorture/formal/srcu-cbmc/src/locks.h | 2 +-
> > 7 files changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> > index e26547b34ad3..036ff5499ad5 100644
> > --- a/kernel/rcu/srcutree.c
> > +++ b/kernel/rcu/srcutree.c
> > @@ -777,9 +777,9 @@ static bool srcu_might_be_idle(struct srcu_struct *ssp)
> > spin_unlock_irqrestore_rcu_node(sdp, flags);
> >
> > /*
> > -* No local callbacks, so probabalistically probe global state.
> > +* No local callbacks, so probabilistically probe global state.
> > * Exact information would require acquiring locks, which would
> > -* kill scalability, hence the probabalistic nature of the probe.
> > +* kill scalability, hence the probabilistic nature of the probe.
> > */
> >
> > /* First, see if enough time has passed since the last GP. */
> > diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c
> > index d4558ab7a07d..3eeb871cf0de 100644
> > --- a/kernel/rcu/sync.c
> > +++ b/kernel/rcu/sync.c
> > @@ -94,7 +94,7 @@ static void rcu_sync_func(struct rcu_head *rhp)
> > rcu_sync_call(rsp);
> > } else {
> > /*
> > -* We're at least a GP after the last rcu_sync_exit(); eveybody
> > +* We're at least a GP after the last rcu_sync_exit(); everybody
> > * will now have observed the write side critical section.
> > * Let 'em rip!.
> > */
> > diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
> > index af7c19439f4e..ac3c362e08a3 100644
> > --- a/kernel/rcu/tasks.h
> > +++ b/kernel/rcu/tasks.h
> > @@ -23,7 +23,7 @@ typedef void (*postgp_func_t)(struct rcu_tasks *rtp);
> > * Definition for a Tasks-RCU-like mechanism.
> > * @cbs_head: Head of callback list.
> > * @cbs_tail: Tail pointer for callback list.
> > - * @cbs_wq: Wait queue allowning new callback to get kthread's attention.
> > + * @cbs_wq: Wait queue allowing new callback to get kthread's attention.
> > * @cbs_lock: Lock protecting callback list.
> > * @kthread_ptr: This flavor's grace-period/callback-invocation kthread.
> > * @gp_func: This flavor's grace-period-wait function.
> > @@ -504,7 +504,7 @@ DEFINE_RCU_TASKS(rcu_tasks, rcu_tasks_wait_gp,
> > call_rcu_tasks, "RCU Tasks");
> > * or transition to usermode execution. As such, there are no read-side
> > * primitives analogous to rcu_read_lock() and rcu_read_unlock() because
> > * this primitive is intended to determine that all tasks have passed
> > - * through a safe state, not so much for data-strcuture synchronization.
> > + * through a safe state, not so much for data-structure synchronization.
> > *
> > * See the description of call_rcu() for more detailed information on
> > * memory ordering guarantees.
> > @@ -637,7 +637,7 @@ DEFINE_RCU_TASKS(rcu_tasks_rude,
> > rcu_tasks_rude_wait_gp, call_rcu_tasks_rude,
> > * there are no read-side primitives analogous to rcu_read_lock() and
> > * rcu_read_unlock() because this primitive is intended to determine
> > * that all tasks have passed through a safe state, not so much for
> > - * data-strcuture synchronization.
> > + * data-structure synchronization.
> > *
>
> The "hyphen" in the middle of the word "data structure" is required or
> keeping by
> convention or has some significance?
Yes, this is one of many peculiarities of English, and an optional one
at that. English is not a block-structured language, so grouping can
be ambiguous. Is is "(data structure) synchronization" or is it instead
"data (structure synchronization)"? The default is the latter, and
the hyphen indicates the former. In this case, the former is intended,
hence the hyphen.
> > * See the description of call_rcu() for more detailed information on
> > * memory ordering guarantees.
> > @@ -1127,7 +
[PATCH] HID: quirks: Set INCREMENT_USAGE_ON_DUPLICATE for Saitek X65
The Saitek X65 joystick has a pair of axes that were used as mouse
pointer controls by the Windows driver. The corresponding usage page is
the Game Controls page, which is not recognized by the generic HID
driver, and therefore, both axes get mapped to ABS_MISC. The quirk makes
the second axis get mapped to ABS_MISC+1, and therefore made available
separately.
Signed-off-by: Nirenjan Krishnan
---
drivers/hid/hid-ids.h| 1 +
drivers/hid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index e42aaae..413a06a0 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1039,6 +1039,7 @@
#define USB_DEVICE_ID_SAITEK_X52 0x075c
#define USB_DEVICE_ID_SAITEK_X52_2 0x0255
#define USB_DEVICE_ID_SAITEK_X52_PRO 0x0762
+#define USB_DEVICE_ID_SAITEK_X65 0x0b6a
#define USB_VENDOR_ID_SAMSUNG 0x0419
#define USB_DEVICE_ID_SAMSUNG_IR_REMOTE0x0001
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 1a9daf0..df68dd7 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -158,6 +158,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_X52),
HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
{ HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_X52_2),
HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
{ HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_X52_PRO),
HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
+ { HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_X65),
HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
{ HID_USB_DEVICE(USB_VENDOR_ID_SEMICO,
USB_DEVICE_ID_SEMICO_USB_KEYKOARD2), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_SEMICO,
USB_DEVICE_ID_SEMICO_USB_KEYKOARD), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_SENNHEISER,
USB_DEVICE_ID_SENNHEISER_BTD500USB), HID_QUIRK_NOGET },
--
2.7.4
Re: [PATCH] rcu: Fix various typos in comments
On Mon, Mar 22, 2021 at 07:55:05PM -0700, Randy Dunlap wrote:
> On 3/22/21 4:02 PM, Ingo Molnar wrote:
> >
> > Hi Paul,
> >
> > Was working on automation to make it a bit more straightforward to fix
> > typos within comments (which we tend to reintroduce during
> > development), and here are the ones it found in the RCU code.
> >
> > Thanks,
> >
> > Ingo
> >
> > =>
> > From: Ingo Molnar
> > Date: Mon, 22 Mar 2021 23:57:26 +0100
> > Subject: [PATCH] rcu: Fix various typos in comments
> >
> > Fix ~12 single-word typos in RCU code comments.
> >
> > Signed-off-by: Ingo Molnar
> > Cc: Paul E. McKenney
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > kernel/rcu/srcutree.c | 4 ++--
> > kernel/rcu/sync.c | 2 +-
> > kernel/rcu/tasks.h | 8
> >
> > kernel/rcu/tree.c | 4 ++--
> > kernel/rcu/tree.h | 2 +-
> > kernel/rcu/tree_plugin.h| 2 +-
> > tools/testing/selftests/rcutorture/formal/srcu-cbmc/src/locks.h | 2 +-
> > 7 files changed, 12 insertions(+), 12 deletions(-)
>
> > diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c
> > index d4558ab7a07d..3eeb871cf0de 100644
> > --- a/kernel/rcu/sync.c
> > +++ b/kernel/rcu/sync.c
> > @@ -94,7 +94,7 @@ static void rcu_sync_func(struct rcu_head *rhp)
> > rcu_sync_call(rsp);
> > } else {
> > /*
> > -* We're at least a GP after the last rcu_sync_exit(); eveybody
> > +* We're at least a GP after the last rcu_sync_exit(); everybody
> > * will now have observed the write side critical section.
> > * Let 'em rip!.
>
> Drop the '.'.
>
> > */
> Otherwise LGTM. Thanks.
>
> Reviewed-by: Randy Dunlap
Applied, dropping the "." and adding the Reviewed-by.
Thank you both!
Thanx, Paul
Re: [net-next PATCH v7 04/16] of: mdio: Refactor of_phy_find_device()
On Fri, Mar 19, 2021 at 11:21:15AM +, Daniel Thompson wrote: > On Wed, Mar 17, 2021 at 02:15:20PM +0530, Calvin Johnson wrote: > > Hi Daniel, > > > > On Tue, Mar 16, 2021 at 07:17:19PM +, Daniel Thompson wrote: > > > On Thu, Mar 11, 2021 at 11:49:59AM +0530, Calvin Johnson wrote: > > > > Refactor of_phy_find_device() to use fwnode_phy_find_device(). > > > > > > > > Signed-off-by: Calvin Johnson > > > > > > This patch series is provoking depmod dependency cycles for me and > > > it bisected down to this patch (although I think later patches in > > > the series add further cycles). > > > > > > The problems emerge when running modules_install either directly or > > > indirectly via packaging rules such as bindeb-pkg. > > > > > > ~~~ > > > make -j16 INSTALL_MOD_PATH=$PWD/modules modules_install > > > ... > > > INSTALL sound/usb/misc/snd-ua101.ko > > > INSTALL sound/usb/snd-usb-audio.ko > > > INSTALL sound/usb/snd-usbmidi-lib.ko > > > INSTALL sound/xen/snd_xen_front.ko > > > DEPMOD 5.12.0-rc3-9-g1fda33bf463d > > > depmod: ERROR: Cycle detected: fwnode_mdio -> of_mdio -> fwnode_mdio > > > depmod: ERROR: Found 2 modules in dependency cycles! > > > ~~~ > > > > > > Kconfig can be found here: > > > https://gist.github.com/daniel-thompson/6a7d224f3d3950ffa3f63f979b636474 > > > > > > This Kconfig file is for a highly modular kernel derived from the Debian > > > 5.10 arm64 kernel config. I was not able to reproduce using the defconfig > > > kernel for arm64. > > > > > Thanks for catching this. I'm able to reproduce the issue and will fix it. > > > > By the way, is there any integration tool/mechanism out there to which I can > > submit the patch series and build for various possible configs like these? > > Not sure which autotester would be most likely to pick this up. > > This issue is slightly unusual because it broke the install rather then > the build... and lots of people (including me) primarily run build > tests ;-) . > > Anyhow, I guess the best way to pick up module problems like this is > going to be an `allmodconfig` build followed up with `rm -rf modtest; > make modules_install INSTALL_MOD_PATH=$PWD/modtest`. Thanks Daniel for the info. To resolve this issue, I need to add more fwnode MDIO functions. I'm working on these. Meanwhile, will separately send out two patches that got Reviewed-by tag. Regards Calvin
Re: [PATCH v7 3/3] arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems
Hi Nishanth,
On 22/03/21 9:05 pm, Nishanth Menon wrote:
> On 18:42-20210322, Aswath Govindraju wrote:
>> The following speed modes are now supported in J7200 SoC,
>> - HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1].
>> - UHS-I speed modes in MMCSD1 subsystem [1].
>>
>> Add support for UHS-I modes by adding voltage regulator device tree nodes
>> and corresponding pinmux details, to power cycle and voltage switch cards.
>> Set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1
>> device tree nodes.
>>
>> Also update the delay values for various speed modes supported, based on
>> the revised january 2021 J7200 datasheet[2].
>>
>> [1] - section 12.3.6.1.1 MMCSD Features, in
>> https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf,
>> (SPRUIU1A – JULY 2020 – REVISED JANUARY 2021)
>>
>> [2] - https://www.ti.com/lit/ds/symlink/dra821u.pdf,
>> (SPRSP57B – APRIL 2020 – REVISED JANUARY 2021)
>>
>> Signed-off-by: Aswath Govindraju
>> ---
>> .../dts/ti/k3-j7200-common-proc-board.dts | 42 +++
>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 14 ++-
>> 2 files changed, 54 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> index b493f939b09a..de8c06bdc825 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
>> @@ -16,6 +16,29 @@
>> stdout-path = "serial2:115200n8";
>> bootargs = "console=ttyS2,115200n8
>> earlycon=ns16550a,mmio32,0x0280";
>> };
>> +
>> +vdd_mmc1: fixedregulator-sd {
>> +compatible = "regulator-fixed";
>> +regulator-name = "vdd_mmc1";
>> +regulator-min-microvolt = <330>;
>> +regulator-max-microvolt = <330>;
>> +regulator-boot-on;
>> +enable-active-high;
>> +gpios = <&exp2 2 GPIO_ACTIVE_HIGH>;
>
> is that gpio ?
Yes, that is correct. I'll correct it in the respin
> I'd encourage to use vin-supply as well.
Will add this in respin.
>
>> +};
>> +
>> +vdd_sd_dv: gpio-regulator-vdd-sd-dv {
> What does this drive? TLV71033 ?
Yes, this node models the TLV71033 voltage regulator that switches the
MMC IO signal voltage level between 3.3V and 1.8V.
>> +compatible = "regulator-gpio";
>> +regulator-name = "vdd_sd_dv";
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&vdd_sd_dv_pins_default>;
>> +regulator-min-microvolt = <180>;
>> +regulator-max-microvolt = <330>;
>> +regulator-boot-on;
>
> normally, I'd encourage to use vin-supply as well.
Will add this in the respin
>
>> +gpios = <&main_gpio0 55 GPIO_ACTIVE_HIGH>;
>> +states = <180 0x0
>> + 330 0x1>;
> states = <180 0x0>,
> <330 0x1>;
>
Will make this change in the respin.
> Can you look at j721e as reference?
>
Will make changes accordingly.
>> +};
>> };
>>
>
> Kishon,
> can you look closer at this series?
>
I'll wait for kishon's feedback and then post respin of this series.
Thank you for the review.
Regards,
Aswath
Re: GTE - The hardware timestamping engine
On Mon, Mar 22, 2021 at 09:09:50PM -0700, Dipen Patel wrote: > > > On 3/22/21 7:59 PM, Kent Gibson wrote: > > On Mon, Mar 22, 2021 at 06:53:10PM -0700, Dipen Patel wrote: > >> > >> > >> On 3/22/21 5:32 PM, Kent Gibson wrote: > >>> On Mon, Mar 22, 2021 at 01:21:46PM -0700, Dipen Patel wrote: > Hi Linus and Kent, > > > > > [snip] > > > >>> In response to all your comments above... > >>> > >>> Firstly, I'm not suggesting that other kernel modules would use the > >>> cdev lineevents, only that they would use the same mechanism that > >>> gpiolib-cdev would use to timestamp the lineevents for userspace. > >>> > >> Sure, I just wanted to mention the different scenarios and wanted to know > >> how can we fit all those together. Having said that, shouldn't this serve > >> an opportunity to extend the linevent framework to accommodate kernel > >> drivers as a clients? > >> > >> If we can't, then there is a risk of duplicating lineevent mechanism in all > >> of those kernel drivers or at least in GTE framework/infrastructure as far > >> as GPIO related GTE part is concerned. > >> > > > > In-kernel the lineevents are just IRQs so anything needing a "lineevent" > > can request the IRQ directly. Or am I missing something? > > > > In the GPIO context, I meant we can extend line_event_timestamp to kernel > drivers as well in that way, both userspace and kernel drivers requesting > particular GPIO for the hardware timestamp would be managed by same > lineevent_* infrastructure from the gpiolib. Something like lineevent_create > version of the kernel drivers, so if they need hardware timestamp on the > GPIO line, they can request with some flags. In that way, GTE can leverage > linevent* codes from gpiolib to cover its both the GPIO related use cases i.e. > userspace app and kernel drivers. > I still don't see what that gives you that is better than an IRQ and a function to provide the timestamp for that IRQ. What specific features of a lineevent are you after? The gpiolib-cdev code is there to provide a palettable API for userspace, and the bulk of that code is specific to the userspace API. Reusing that code for clients within the kernel is just introducing pointless overhead when they can get what they need more directly. There may be a case for some additional gpiolib/irq helper functions, but I don't see gpiolib-cdev as a good fit for that role. > >>> As to that mechanism, my current thinking is that the approach of > >>> associating GTE event FIFO entries with particular physical IRQ events is > >>> problematic, as keeping the two in sync would be difficult, if not > >>> impossible. > >>> > >>> A more robust approach is to ignore the physical IRQs and instead service > >>> the GTE event FIFO, generating IRQs from those events in software - > >>> essentially a pre-timestamped IRQ. The IRQ framework could provide the > >>> timestamping functionality, equivalent to line_event_timestamp(), for > >>> the IRQ handler/thread and in this case provide the timestamp from the GTE > >>> event. > >>> > >> > >> I have not fully understood above two paragraphs (except about > >> lineevent_event_timestamp related part). > >> > >> I have no idea what it means to "ignore the physical IRQs and service the > >> GTE event FIFO". Just like GPIO clients, there could be IRQ clients which > >> want to monitor certain IRQ line, like ethernet driver wanted to retrieve > >> timestamp for its IRQ line and so on. > >> > > > > I mean that in the IRQ framework, rather than enabling the physical IRQ > > line it would leave that masked and would instead enable the FIFO line to > > service the FIFO, configure the GTE to generate the events for that > > line, and then generate IRQs in response to the FIFO events. > > That way the client requesting the IRQ is guaranteed to only receive an > > IRQ that corresponds to a GTE FIFO event and the timestamp stored in the > > IRQ framework would match. > > > > I do not think we need to do such things, for example, below is > the rough sequence how GTE can notify its clients be it GPIO or IRQ > lines. I believe this will also help understand better ongoing GPIO > discussions. > > 1. Configure GTE FIFO watermark or threshold, lets assume 1, i.e >generate GTE interrupt when FIFO depth is 1. > 2. In the GTE ISR or ISR thread, drain internal FIFO entries > 3. Through GTE driver's internal mapping, identify which IRQ or >GPIO number this entry belongs to. (This is possible as GTE >has predefined bits for each supported signals, for example GTE >supports 40 GPIOs and 352 IRQ lines, and it has multliple GTE instances >which can take care all of them) > 4. GTE driver pushes the event data (in this case it will be timestamp and >direction of the event ie.rising or falling) to the GTE generic framework > 5. GTE framework will store per event data to its per client/event sw FIFO > 6. wake up any sleeping client thread > 7. Points 3 to 6 are happening in GTE ISR context
Re: [PATCH v2 01/18] vfs: add miscattr ops
> > +``miscattr_get`` > > I wish this wasn't named "misc" because miscellaneous is vague. > > fileattr_get, perhaps? > > (FWIW I'm not /that/ passionate about starting a naming bikeshed, feel > free to ignore.) > Eventual bikeshedding is hard to avoid in this case... I don't feel strongly against "misc", but I do think the flags and ioctl are already known as "fsx" so it would be more friendly to go with that. If you don't like "fsxflags" because it's not only flags and you think "fsxattr" is too close to "xattr" (FWIW I don't think it is going to be a source of confusion), we can simply go with get_fsx(), similar to get_acl(). It doesn't matter what name we use as long as everyone is clear on what it is. "struct fsx" is not any more or any less clear than "struct statx" and while "fsx" it is a pretty arbitrary name, it is not much less arbitrary than "miscattr". Thanks, Amir.
[PATCH] fuse: Fix a potential double free in virtio_fs_get_tree
In virtio_fs_get_tree, fm is allocated by kzalloc() and
assigned to fsc->s_fs_info by fsc->s_fs_info=fm statement.
If the kzalloc() failed, it will goto err directly, so that
fsc->s_fs_info must be non-NULL and fm will be freed.
But later fm is freed again when virtio_fs_fill_super() fialed.
I think the statement if (fsc->s_fs_info) {kfree(fm);} is
misplaced.
My patch puts this statement in the correct palce to avoid
double free.
Signed-off-by: Lv Yunlong
---
fs/fuse/virtio_fs.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index 8868ac31a3c0..727cf436828f 100644
--- a/fs/fuse/virtio_fs.c
+++ b/fs/fuse/virtio_fs.c
@@ -1437,10 +1437,7 @@ static int virtio_fs_get_tree(struct fs_context *fsc)
fsc->s_fs_info = fm;
sb = sget_fc(fsc, virtio_fs_test_super, set_anon_super_fc);
- if (fsc->s_fs_info) {
- fuse_conn_put(fc);
- kfree(fm);
- }
+
if (IS_ERR(sb))
return PTR_ERR(sb);
@@ -1457,6 +1454,11 @@ static int virtio_fs_get_tree(struct fs_context *fsc)
sb->s_flags |= SB_ACTIVE;
}
+ if (fsc->s_fs_info) {
+ fuse_conn_put(fc);
+ kfree(fm);
+ }
+
WARN_ON(fsc->root);
fsc->root = dget(sb->s_root);
return 0;
--
2.25.1
[PATCH] tools: perf: Remove duplicate includes
sys/stat.h has been included at line 23, so remove the duplicate one at line 27. linux/string.h has been included at line 7, so remove the duplicate one at line 9. time.h has been included at line 14, so remove the duplicate one at line 28. Signed-off-by: Wan Jiabing --- tools/perf/builtin-daemon.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/tools/perf/builtin-daemon.c b/tools/perf/builtin-daemon.c index ace8772a4f03..632ecd010a4f 100644 --- a/tools/perf/builtin-daemon.c +++ b/tools/perf/builtin-daemon.c @@ -6,7 +6,6 @@ #include #include #include -#include #include #include #include @@ -24,8 +23,6 @@ #include #include #include -#include -#include #include "builtin.h" #include "perf.h" #include "debug.h" -- 2.25.1
[rcu:lkmm-dev] BUILD SUCCESS 052aaf10b7a5b2023be4623d2293ae51a6978e27
10323 i386 randconfig-a004-20210323 i386 randconfig-a001-20210323 i386 randconfig-a002-20210323 i386 randconfig-a006-20210323 i386 randconfig-a005-20210323 i386 randconfig-a004-20210322 i386 randconfig-a003-20210322 i386 randconfig-a001-20210322 i386 randconfig-a002-20210322 i386 randconfig-a006-20210322 i386 randconfig-a005-20210322 x86_64 randconfig-a012-20210322 x86_64 randconfig-a015-20210322 x86_64 randconfig-a013-20210322 x86_64 randconfig-a014-20210322 x86_64 randconfig-a016-20210322 x86_64 randconfig-a011-20210322 i386 randconfig-a014-20210322 i386 randconfig-a011-20210322 i386 randconfig-a015-20210322 i386 randconfig-a016-20210322 i386 randconfig-a012-20210322 i386 randconfig-a013-20210322 riscvnommu_k210_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a002-20210322 x86_64 randconfig-a003-20210322 x86_64 randconfig-a001-20210322 x86_64 randconfig-a006-20210322 x86_64 randconfig-a004-20210322 x86_64 randconfig-a005-20210322 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[rcu:lkmm] BUILD SUCCESS 49ab51b01ec6fd837ae3efe2e0cdb41fcf5cf048
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git lkmm branch HEAD: 49ab51b01ec6fd837ae3efe2e0cdb41fcf5cf048 tools/memory-model: Add access-marking documentation elapsed time: 720m configs tested: 129 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig riscvallmodconfig x86_64 allyesconfig i386 allyesconfig riscvallyesconfig arc axs101_defconfig m68k amiga_defconfig powerpc asp8347_defconfig sh sh7710voipgw_defconfig m68k m5208evb_defconfig arc haps_hs_defconfig powerpc katmai_defconfig sh rts7751r2dplus_defconfig mips ip27_defconfig riscvnommu_virt_defconfig arc alldefconfig arc axs103_defconfig powerpc motionpro_defconfig powerpc chrp32_defconfig arm moxart_defconfig arm colibri_pxa270_defconfig arm s3c2410_defconfig arm ixp4xx_defconfig mips ip28_defconfig arm mxs_defconfig riscvalldefconfig shedosk7705_defconfig powerpc mpc5200_defconfig mips pic32mzda_defconfig powerpc ppc64e_defconfig sh ecovec24_defconfig powerpc mpc85xx_cds_defconfig sh defconfig mips decstation_64_defconfig openrisc simple_smp_defconfig powerpc walnut_defconfig mips capcella_defconfig arm am200epdkit_defconfig powerpc wii_defconfig powerpc akebono_defconfig powerpc redwood_defconfig armlart_defconfig arm palmz72_defconfig armmvebu_v7_defconfig sh se7780_defconfig powerpc mpc836x_rdk_defconfig openrisc alldefconfig m68k m5249evb_defconfig mipsmaltaup_defconfig arm omap1_defconfig i386defconfig arm colibri_pxa300_defconfig mips jazz_defconfig powerpc mpc83xx_defconfig powerpcmpc7448_hpc2_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386 tinyconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20210323 i386 randconfig-a004-20210323 i386 randconfig-a001-20210323 i386 randconfig-a002-20210323 i386 randconfig-a006-20210323 i386 randconfig-a005-20210323 i386 randconfig-a004-20210322 i386 randconfig-a003-20210322 i386 randconfig-a001-20210322 i386 randconfig-a002-20210322 i386
Re: [PATCH] cpufreq: intel_pstate: Clean up frequency computations
On Tue, Mar 16, 2021 at 04:52:43PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Notice that some computations related to frequency in intel_pstate > can be simplified if (a) intel_pstate_get_hwp_max() updates the > relevant members of struct cpudata by itself and (b) the "turbo > disabled" check is moved from it to its callers, so modify the code > accordingly and while at it rename intel_pstate_get_hwp_max() to > intel_pstate_get_hwp_cap() which better reflects its purpose and > provide a simplified variat of it, __intel_pstate_get_hwp_cap(), > suitable for the initialization path. > > No intentional functional impact. > > Signed-off-by: Rafael J. Wysocki Tested-by: Chen Yu thanks, Chenyu
Re: [PATCH] ACPI: CPPC: Add emtpy stubs of functions for CONFIG_ACPI_CPPC_LIB unset
On Tue, Mar 16, 2021 at 04:54:03PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > For convenience, add empty stubs of library functions defined in > cppc_acpi.c for the CONFIG_ACPI_CPPC_LIB unset case. > > Because one of them needs to return CPUFREQ_ETERNAL, include > linux/cpufreq.h into the CPPC library header file and drop the > direct inclusion of it from cppc_acpi.c. > > Signed-off-by: Rafael J. Wysocki Tested-by: Chen Yu thanks, Chenyu
[PATCH] perf tools: Trivial spelling fixes
s/succeded/succeeded/ five different places
s/revsions/revisions/
Signed-off-by: Bhaskar Chowdhury
---
tools/perf/util/header.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 20effdff76ce..97a0eeb6d2ab 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -127,7 +127,7 @@ static int __do_write_buf(struct feat_fd *ff, const void
*buf, size_t size)
return 0;
}
-/* Return: 0 if succeded, -ERR if failed. */
+/* Return: 0 if succeeded, -ERR if failed. */
int do_write(struct feat_fd *ff, const void *buf, size_t size)
{
if (!ff->buf)
@@ -135,7 +135,7 @@ int do_write(struct feat_fd *ff, const void *buf, size_t
size)
return __do_write_buf(ff, buf, size);
}
-/* Return: 0 if succeded, -ERR if failed. */
+/* Return: 0 if succeeded, -ERR if failed. */
static int do_write_bitmap(struct feat_fd *ff, unsigned long *set, u64 size)
{
u64 *p = (u64 *) set;
@@ -154,7 +154,7 @@ static int do_write_bitmap(struct feat_fd *ff, unsigned
long *set, u64 size)
return 0;
}
-/* Return: 0 if succeded, -ERR if failed. */
+/* Return: 0 if succeeded, -ERR if failed. */
int write_padded(struct feat_fd *ff, const void *bf,
size_t count, size_t count_aligned)
{
@@ -170,7 +170,7 @@ int write_padded(struct feat_fd *ff, const void *bf,
#define string_size(str) \
(PERF_ALIGN((strlen(str) + 1), NAME_ALIGN) + sizeof(u32))
-/* Return: 0 if succeded, -ERR if failed. */
+/* Return: 0 if succeeded, -ERR if failed. */
static int do_write_string(struct feat_fd *ff, const char *str)
{
u32 len, olen;
@@ -266,7 +266,7 @@ static char *do_read_string(struct feat_fd *ff)
return NULL;
}
-/* Return: 0 if succeded, -ERR if failed. */
+/* Return: 0 if succeeded, -ERR if failed. */
static int do_read_bitmap(struct feat_fd *ff, unsigned long **pset, u64 *psize)
{
unsigned long *set;
@@ -3485,7 +3485,7 @@ static const size_t attr_pipe_abi_sizes[] = {
* between host recording the samples, and host parsing the samples is the
* same. This is not always the case given that the pipe output may always be
* redirected into a file and analyzed on a different machine with possibly a
- * different endianness and perf_event ABI revsions in the perf tool itself.
+ * different endianness and perf_event ABI revisions in the perf tool itself.
*/
static int try_all_pipe_abis(uint64_t hdr_sz, struct perf_header *ph)
{
--
2.31.0
Re: [PATCH] staging: wimax: Mundane typo fixes
On 21:14 Mon 22 Mar 2021, Randy Dunlap wrote: On 3/22/21 6:06 PM, Bhaskar Chowdhury wrote: s/procesing/processing/ s/comunication/communication/ Signed-off-by: Bhaskar Chowdhury drivers/staging/wimax/ is in the process of being deleted. Yes ...I saw the mail day or two back ...skipped my mind ...anyway we can ignore this. --- drivers/staging/wimax/i2400m/driver.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/wimax/i2400m/driver.c b/drivers/staging/wimax/i2400m/driver.c index f5186458bb3d..162a92682977 100644 --- a/drivers/staging/wimax/i2400m/driver.c +++ b/drivers/staging/wimax/i2400m/driver.c -- ~Randy signature.asc Description: PGP signature
Re: [PATCH] KVM: VMX: Check the corresponding bits according to the intel sdm
On Tue, Mar 23, 2021 at 11:16 AM Jim Mattson wrote: > > On Mon, Mar 22, 2021 at 7:37 PM wrote: > > > > From: Haiwei Li > > > > According to IA-32 SDM Vol.3D "A.1 BASIC VMX INFORMATION", two inspections > > are missing. > > * Bit 31 is always 0. Earlier versions of this manual specified that the > > VMCS revision identifier was a 32-bit field in bits 31:0 of this MSR. For > > all processors produced prior to this change, bit 31 of this MSR was read > > as 0. > > For all *Intel* processors produced prior to this change, bit 31 of > this MSR may have been 0. However, a conforming hypervisor may have > selected a full 32-bit VMCS revision identifier with the high bit set > for nested VMX. Furthermore, there are other vendors, such as VIA, > which have implemented the VMX extensions, and they, too, may have > selected a full 32-bit VMCS revision identifier with the high bit set. > Intel should know better than to change the documentation after the > horse is out of the barn. Got it, thanks. > > What, exactly, is the value you are adding with this check? I did this just to match the sdm. -- Haiwei Li
[PATCH] brcmfmac: A typo fix
s/revsion/revision/
Signed-off-by: Bhaskar Chowdhury
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.h
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.h
index ee273e3bb101..e000ef78928c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.h
@@ -28,7 +28,7 @@ struct brcmf_usbdev {
int ntxq, nrxq, rxsize;
u32 bus_mtu;
int devid;
- int chiprev; /* chip revsion number */
+ int chiprev; /* chip revision number */
};
/* IO Request Block (IRB) */
--
2.31.0
[PATCH] hwmon: (ftsteutates): Rudimentary typo fixes
s/Temprature/Temperature/
s/revsion/revision/
Signed-off-by: Bhaskar Chowdhury
---
drivers/hwmon/ftsteutates.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/ftsteutates.c b/drivers/hwmon/ftsteutates.c
index ef88a156efc2..ceffc76a0c51 100644
--- a/drivers/hwmon/ftsteutates.c
+++ b/drivers/hwmon/ftsteutates.c
@@ -509,7 +509,7 @@ fan_alarm_store(struct device *dev, struct device_attribute
*devattr,
/* SysFS structs*/
/*/
-/* Temprature sensors */
+/* Temperature sensors */
static SENSOR_DEVICE_ATTR_RO(temp1_input, temp_value, 0);
static SENSOR_DEVICE_ATTR_RO(temp2_input, temp_value, 1);
static SENSOR_DEVICE_ATTR_RO(temp3_input, temp_value, 2);
@@ -713,7 +713,7 @@ static int fts_detect(struct i2c_client *client,
{
int val;
- /* detection works with revsion greater or equal to 0x2b */
+ /* detection works with revision greater or equal to 0x2b */
val = i2c_smbus_read_byte_data(client, FTS_DEVICE_REVISION_REG);
if (val < 0x2b)
return -ENODEV;
--
2.31.0
[PATCH 5/6] i2c: mpc: use device managed APIs
Use device managed functions an clean up error handling.
Signed-off-by: Chris Packham
---
drivers/i2c/busses/i2c-mpc.c | 46 ++--
1 file changed, 18 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 5b746a898e8e..46cdb36e2f9b 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -654,7 +654,6 @@ static int fsl_i2c_probe(struct platform_device *op)
u32 clock = MPC_I2C_CLOCK_LEGACY;
int result = 0;
int plen;
- struct resource res;
struct clk *clk;
int err;
@@ -662,7 +661,7 @@ static int fsl_i2c_probe(struct platform_device *op)
if (!match)
return -EINVAL;
- i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
+ i2c = devm_kzalloc(&op->dev, sizeof(*i2c), GFP_KERNEL);
if (!i2c)
return -ENOMEM;
@@ -670,24 +669,21 @@ static int fsl_i2c_probe(struct platform_device *op)
init_waitqueue_head(&i2c->queue);
- i2c->base = of_iomap(op->dev.of_node, 0);
- if (!i2c->base) {
+ i2c->base = devm_platform_ioremap_resource(op, 0);
+ if (IS_ERR(i2c->base)) {
dev_err(i2c->dev, "failed to map controller\n");
- result = -ENOMEM;
- goto fail_map;
+ return PTR_ERR(i2c->base);
}
- i2c->irq = irq_of_parse_and_map(op->dev.of_node, 0);
- if (i2c->irq < 0) {
- result = i2c->irq;
- goto fail_map;
- }
+ i2c->irq = platform_get_irq(op, 0);
+ if (i2c->irq < 0)
+ return i2c->irq;
- result = request_irq(i2c->irq, mpc_i2c_isr,
+ result = devm_request_irq(&op->dev, i2c->irq, mpc_i2c_isr,
IRQF_SHARED, "i2c-mpc", i2c);
if (result < 0) {
dev_err(i2c->dev, "failed to attach interrupt\n");
- goto fail_request;
+ return result;
}
/*
@@ -699,7 +695,7 @@ static int fsl_i2c_probe(struct platform_device *op)
err = clk_prepare_enable(clk);
if (err) {
dev_err(&op->dev, "failed to enable clock\n");
- goto fail_request;
+ return err;
} else {
i2c->clk_per = clk;
}
@@ -731,32 +727,26 @@ static int fsl_i2c_probe(struct platform_device *op)
}
dev_info(i2c->dev, "timeout %u us\n", mpc_ops.timeout * 100 / HZ);
- platform_set_drvdata(op, i2c);
-
i2c->adap = mpc_ops;
- of_address_to_resource(op->dev.of_node, 0, &res);
scnprintf(i2c->adap.name, sizeof(i2c->adap.name),
- "MPC adapter at 0x%llx", (unsigned long long)res.start);
- i2c_set_adapdata(&i2c->adap, i2c);
+ "MPC adapter (%s)", of_node_full_name(op->dev.of_node));
i2c->adap.dev.parent = &op->dev;
+ i2c->adap.nr = op->id;
i2c->adap.dev.of_node = of_node_get(op->dev.of_node);
i2c->adap.bus_recovery_info = &fsl_i2c_recovery_info;
+ platform_set_drvdata(op, i2c);
+ i2c_set_adapdata(&i2c->adap, i2c);
- result = i2c_add_adapter(&i2c->adap);
- if (result < 0)
+ result = i2c_add_numbered_adapter(&i2c->adap);
+ if (result)
goto fail_add;
- return result;
+ return 0;
fail_add:
if (i2c->clk_per)
clk_disable_unprepare(i2c->clk_per);
- free_irq(i2c->irq, i2c);
- fail_request:
- irq_dispose_mapping(i2c->irq);
- iounmap(i2c->base);
- fail_map:
- kfree(i2c);
+
return result;
};
--
2.30.2
[PATCH 6/6] i2c: mpc: Interrupt driven transfer
The fsl-i2c controller will generate an interrupt after every byte
transferred. Make use of this interrupt to drive a state machine which
allows the next part of a transfer to happen as soon as the interrupt is
received. This is particularly helpful with SMBUS devices like the LM81
which will timeout if we take too long between bytes in a transfer.
Signed-off-by: Chris Packham
---
drivers/i2c/busses/i2c-mpc.c | 430 +++
1 file changed, 237 insertions(+), 193 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 46cdb36e2f9b..5ffde3428232 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -1,16 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
/*
- * (C) Copyright 2003-2004
- * Humboldt Solutions Ltd, adr...@humboldt.co.uk.
-
* This is a combined i2c adapter and algorithm driver for the
* MPC107/Tsi107 PowerPC northbridge and processors that include
* the same I2C unit (8240, 8245, 85xx).
*
- * Release 0.8
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
+ * Copyright (C) 2003-2004 Humboldt Solutions Ltd, adr...@humboldt.co.uk
+ * Copyright (C) 2021 Allied Telesis Labs
*/
#include
@@ -58,11 +53,32 @@
#define CSR_MIF 0x02
#define CSR_RXAK 0x01
+enum mpc_i2c_action {
+ MPC_I2C_ACTION_INVALID = 0,
+ MPC_I2C_ACTION_START,
+ MPC_I2C_ACTION_RESTART,
+ MPC_I2C_ACTION_READ_BEGIN,
+ MPC_I2C_ACTION_READ_BYTE,
+ MPC_I2C_ACTION_WRITE,
+ MPC_I2C_ACTION_STOP,
+};
+
+static char *action_str[] = {
+ "invalid",
+ "start",
+ "restart",
+ "read begin",
+ "read",
+ "write",
+ "stop",
+};
+
struct mpc_i2c {
struct device *dev;
void __iomem *base;
u32 interrupt;
- wait_queue_head_t queue;
+ wait_queue_head_t waitq;
+ spinlock_t lock;
struct i2c_adapter adap;
int irq;
u32 real_clk;
@@ -70,6 +86,16 @@ struct mpc_i2c {
u8 fdr, dfsrr;
#endif
struct clk *clk_per;
+ u32 cntl_bits;
+ enum mpc_i2c_action action;
+ struct i2c_msg *msgs;
+ int num_msgs;
+ int curr_msg;
+ u32 byte_posn;
+ u32 block;
+ int rc;
+ int expect_rxack;
+
};
struct mpc_i2c_divider {
@@ -86,19 +112,6 @@ static inline void writeccr(struct mpc_i2c *i2c, u32 x)
writeb(x, i2c->base + MPC_I2C_CR);
}
-static irqreturn_t mpc_i2c_isr(int irq, void *dev_id)
-{
- struct mpc_i2c *i2c = dev_id;
- if (readb(i2c->base + MPC_I2C_SR) & CSR_MIF) {
- /* Read again to allow register to stabilise */
- i2c->interrupt = readb(i2c->base + MPC_I2C_SR);
- writeb(0, i2c->base + MPC_I2C_SR);
- wake_up(&i2c->queue);
- return IRQ_HANDLED;
- }
- return IRQ_NONE;
-}
-
/* Sometimes 9th clock pulse isn't generated, and slave doesn't release
* the bus, because it wants to send ACK.
* Following sequence of enabling/disabling and sending start/stop generates
@@ -121,45 +134,6 @@ static void mpc_i2c_fixup(struct mpc_i2c *i2c)
}
}
-static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
-{
- u32 cmd_err;
- int result;
-
- result = wait_event_timeout(i2c->queue,
- (i2c->interrupt & CSR_MIF), timeout);
-
- if (unlikely(!(i2c->interrupt & CSR_MIF))) {
- dev_dbg(i2c->dev, "wait timeout\n");
- writeccr(i2c, 0);
- result = -ETIMEDOUT;
- }
-
- cmd_err = i2c->interrupt;
- i2c->interrupt = 0;
-
- if (result < 0)
- return result;
-
- if (!(cmd_err & CSR_MCF)) {
- dev_dbg(i2c->dev, "unfinished\n");
- return -EIO;
- }
-
- if (cmd_err & CSR_MAL) {
- dev_dbg(i2c->dev, "MAL\n");
- return -EAGAIN;
- }
-
- if (writing && (cmd_err & CSR_RXAK)) {
- dev_dbg(i2c->dev, "No RXAK\n");
- /* generate stop */
- writeccr(i2c, CCR_MEN);
- return -ENXIO;
- }
- return 0;
-}
-
#if defined(CONFIG_PPC_MPC52xx) || defined(CONFIG_PPC_MPC512x)
static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
{20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
@@ -434,168 +408,209 @@ static void mpc_i2c_setup_8xxx(struct device_node *node,
}
#endif /* CONFIG_FSL_SOC */
-static void mpc_i2c_start(struct mpc_i2c *i2c)
+static void mpc_i2c_finish(struct mpc_i2c *i2c, int rc)
{
- /* Clear arbitration */
- writeb(0, i2c->base + MPC_I2C_SR);
- /* Start with MEN */
- writeccr(i2c, CCR_MEN);
+ i2c->rc = rc;
+ i2c->block = 0;
+ i2c->cntl_bits = CCR_MEN;
+ writeccr(i2c, i2c->cntl_bits);
+
[PATCH 3/6] i2c: mpc: Make use of i2c_recover_bus()
Move the existing calls of mpc_i2c_fixup() to a recovery function
registered via bus_recovery_info. This makes it more obvious that
recovery is supported and allows for a future where recovery is
triggered by the i2c core.
Signed-off-by: Chris Packham
---
drivers/i2c/busses/i2c-mpc.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index d94f05c8b8b7..6a0d55e9e8e3 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -586,7 +586,7 @@ static int mpc_xfer(struct i2c_adapter *adap, struct
i2c_msg *msgs, int num)
if ((status & (CSR_MCF | CSR_MBB | CSR_RXAK)) != 0) {
writeb(status & ~CSR_MAL,
i2c->base + MPC_I2C_SR);
- mpc_i2c_fixup(i2c);
+ i2c_recover_bus(&i2c->adap);
}
return -EIO;
}
@@ -622,7 +622,7 @@ static int mpc_xfer(struct i2c_adapter *adap, struct
i2c_msg *msgs, int num)
if ((status & (CSR_MCF | CSR_MBB | CSR_RXAK)) != 0) {
writeb(status & ~CSR_MAL,
i2c->base + MPC_I2C_SR);
- mpc_i2c_fixup(i2c);
+ i2c_recover_bus(&i2c->adap);
}
return -EIO;
}
@@ -637,6 +637,15 @@ static u32 mpc_functionality(struct i2c_adapter *adap)
| I2C_FUNC_SMBUS_READ_BLOCK_DATA | I2C_FUNC_SMBUS_BLOCK_PROC_CALL;
}
+static int fsl_i2c_bus_recovery(struct i2c_adapter *adap)
+{
+ struct mpc_i2c *i2c = i2c_get_adapdata(adap);
+
+ mpc_i2c_fixup(i2c);
+
+ return 0;
+}
+
static const struct i2c_algorithm mpc_algo = {
.master_xfer = mpc_xfer,
.functionality = mpc_functionality,
@@ -648,6 +657,10 @@ static struct i2c_adapter mpc_ops = {
.timeout = HZ,
};
+static struct i2c_bus_recovery_info fsl_i2c_recovery_info = {
+ .recover_bus = fsl_i2c_bus_recovery,
+};
+
static const struct of_device_id mpc_i2c_of_match[];
static int fsl_i2c_probe(struct platform_device *op)
{
@@ -740,6 +753,7 @@ static int fsl_i2c_probe(struct platform_device *op)
i2c_set_adapdata(&i2c->adap, i2c);
i2c->adap.dev.parent = &op->dev;
i2c->adap.dev.of_node = of_node_get(op->dev.of_node);
+ i2c->adap.bus_recovery_info = &fsl_i2c_recovery_info;
result = i2c_add_adapter(&i2c->adap);
if (result < 0)
--
2.30.2
[PATCH 0/6] i2c: mpc: Refactor to improve responsiveness
The "meat" of this series is in the last patch which is the change that actually starts making use of the interrupts to drive a state machine. The dt-bindings patches can probably go in at any time. The rest of the series isn't dependent on them. I've tested it on a T2081 based system with a number of i2c and smbus devices. Its the end of my work day so I figured I'd get this out now but I'll do some more testing on a P2041 board and a few different i2c devices tomorrow. Chris Packham (6): dt-bindings: i2c-mpc: Document interrupt property as required dt-bindings: i2c: convert i2c-mpc to json-schema i2c: mpc: Make use of i2c_recover_bus() i2c: mpc: make interrupt mandatory and remove polling code i2c: mpc: use device managed APIs i2c: mpc: Interrupt driven transfer .../devicetree/bindings/i2c/i2c-mpc.txt | 62 --- .../devicetree/bindings/i2c/i2c-mpc.yaml | 99 drivers/i2c/busses/i2c-mpc.c | 513 ++ 3 files changed, 373 insertions(+), 301 deletions(-) delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-mpc.txt create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mpc.yaml -- 2.30.2
[PATCH 2/6] dt-bindings: i2c: convert i2c-mpc to json-schema
Convert i2c-mpc to YAML.
Signed-off-by: Chris Packham
---
.../devicetree/bindings/i2c/i2c-mpc.txt | 62
.../devicetree/bindings/i2c/i2c-mpc.yaml | 99 +++
2 files changed, 99 insertions(+), 62 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-mpc.txt
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.txt
b/Documentation/devicetree/bindings/i2c/i2c-mpc.txt
deleted file mode 100644
index b15acb43d84d..
--- a/Documentation/devicetree/bindings/i2c/i2c-mpc.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-* I2C
-
-Required properties :
-
- - reg : Offset and length of the register set for the device
- - compatible : should be "fsl,CHIP-i2c" where CHIP is the name of a
- compatible processor, e.g. mpc8313, mpc8543, mpc8544, mpc5121,
- mpc5200 or mpc5200b. For the mpc5121, an additional node
- "fsl,mpc5121-i2c-ctrl" is required as shown in the example below.
- - interrupts : where a is the interrupt number and b is a
- field that represents an encoding of the sense and level
- information for the interrupt. This should be encoded based on
- the information in section 2) depending on the type of interrupt
- controller you have.
-
-Recommended properties :
-
- - fsl,preserve-clocking : boolean; if defined, the clock settings
- from the bootloader are preserved (not touched).
- - clock-frequency : desired I2C bus clock frequency in Hz.
- - fsl,timeout : I2C bus timeout in microseconds.
-
-Examples :
-
- /* MPC5121 based board */
- i2c@1740 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,mpc5121-i2c", "fsl-i2c";
- reg = <0x1740 0x20>;
- interrupts = <11 0x8>;
- interrupt-parent = <&ipic>;
- clock-frequency = <10>;
- };
-
- i2ccontrol@1760 {
- compatible = "fsl,mpc5121-i2c-ctrl";
- reg = <0x1760 0x8>;
- };
-
- /* MPC5200B based board */
- i2c@3d00 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
- reg = <0x3d00 0x40>;
- interrupts = <2 15 0>;
- interrupt-parent = <&mpc5200_pic>;
- fsl,preserve-clocking;
- };
-
- /* MPC8544 base board */
- i2c@3100 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,mpc8544-i2c", "fsl-i2c";
- reg = <0x3100 0x100>;
- interrupts = <43 2>;
- interrupt-parent = <&mpic>;
- clock-frequency = <40>;
- fsl,timeout = <1>;
- };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
new file mode 100644
index ..97cea8a817ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-mpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: I2C-Bus adapter for MPC824x/83xx/85xx/86xx/512x/52xx SoCs
+
+maintainers:
+ - Chris Packham
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+anyOf:
+ - items:
+- enum:
+ - mpc5200-i2c
+ - fsl,mpc5200b-i2c
+ - fsl,mpc5200-i2c
+ - fsl,mpc5121-i2c
+ - fsl,mpc8313-i2c
+ - fsl,mpc8543-i2c
+ - fsl,mpc8544-i2c
+
+- const: fsl-i2c
+
+ - contains:
+ const: fsl-i2c
+minItems: 1
+maxItems: 4
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ fsl,preserve-clocking:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+ if defined, the clock settings from the bootloader are
+ preserved (not touched)
+
+ fsl,timeout:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: |
+ I2C bus timeout in microseconds
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+/* MPC5121 based board */
+i2c@1740 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,mpc5121-i2c", "fsl-i2c";
+reg = <0x1740 0x20>;
+interrupts = <11 0x8>;
+interrupt-parent = <&ipic>;
+clock-frequency = <10>;
+};
+
+i2ccontrol@1760 {
+compatible = "fsl,mpc5121-i2c-ctrl";
+reg = <0x1760 0x8>;
+};
+
+/* MPC5200B based board */
+i2c@3d00 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,mpc5200b-i2c", "fsl,mpc5200-i2c", "fsl-i2c";
+reg = <0x3d00 0x40>;
+interrupts = <2 15 0>;
+interr
[PATCH 1/6] dt-bindings: i2c-mpc: Document interrupt property as required
All of the in-tree device-trees that use the one of the compatible strings from i2c-mpc.c supply an interrupts property. Make this property mandatory to aid refactoring the driver. Signed-off-by: Chris Packham --- Documentation/devicetree/bindings/i2c/i2c-mpc.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.txt b/Documentation/devicetree/bindings/i2c/i2c-mpc.txt index 42a390526957..b15acb43d84d 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mpc.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.txt @@ -7,14 +7,14 @@ Required properties : compatible processor, e.g. mpc8313, mpc8543, mpc8544, mpc5121, mpc5200 or mpc5200b. For the mpc5121, an additional node "fsl,mpc5121-i2c-ctrl" is required as shown in the example below. - -Recommended properties : - - interrupts : where a is the interrupt number and b is a field that represents an encoding of the sense and level information for the interrupt. This should be encoded based on the information in section 2) depending on the type of interrupt controller you have. + +Recommended properties : + - fsl,preserve-clocking : boolean; if defined, the clock settings from the bootloader are preserved (not touched). - clock-frequency : desired I2C bus clock frequency in Hz. -- 2.30.2
[PATCH 4/6] i2c: mpc: make interrupt mandatory and remove polling code
All the in-tree dts files that use one of the compatible strings from
i2c-mpc.c provide an interrupt property. By making this mandatory we
can simplify the code.
Signed-off-by: Chris Packham
---
drivers/i2c/busses/i2c-mpc.c | 51 ++--
1 file changed, 19 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 6a0d55e9e8e3..5b746a898e8e 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -123,37 +123,21 @@ static void mpc_i2c_fixup(struct mpc_i2c *i2c)
static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
{
- unsigned long orig_jiffies = jiffies;
u32 cmd_err;
- int result = 0;
+ int result;
- if (!i2c->irq) {
- while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
- schedule();
- if (time_after(jiffies, orig_jiffies + timeout)) {
- dev_dbg(i2c->dev, "timeout\n");
- writeccr(i2c, 0);
- result = -ETIMEDOUT;
- break;
- }
- }
- cmd_err = readb(i2c->base + MPC_I2C_SR);
- writeb(0, i2c->base + MPC_I2C_SR);
- } else {
- /* Interrupt mode */
- result = wait_event_timeout(i2c->queue,
+ result = wait_event_timeout(i2c->queue,
(i2c->interrupt & CSR_MIF), timeout);
- if (unlikely(!(i2c->interrupt & CSR_MIF))) {
- dev_dbg(i2c->dev, "wait timeout\n");
- writeccr(i2c, 0);
- result = -ETIMEDOUT;
- }
-
- cmd_err = i2c->interrupt;
- i2c->interrupt = 0;
+ if (unlikely(!(i2c->interrupt & CSR_MIF))) {
+ dev_dbg(i2c->dev, "wait timeout\n");
+ writeccr(i2c, 0);
+ result = -ETIMEDOUT;
}
+ cmd_err = i2c->interrupt;
+ i2c->interrupt = 0;
+
if (result < 0)
return result;
@@ -694,13 +678,16 @@ static int fsl_i2c_probe(struct platform_device *op)
}
i2c->irq = irq_of_parse_and_map(op->dev.of_node, 0);
- if (i2c->irq) { /* no i2c->irq implies polling */
- result = request_irq(i2c->irq, mpc_i2c_isr,
-IRQF_SHARED, "i2c-mpc", i2c);
- if (result < 0) {
- dev_err(i2c->dev, "failed to attach interrupt\n");
- goto fail_request;
- }
+ if (i2c->irq < 0) {
+ result = i2c->irq;
+ goto fail_map;
+ }
+
+ result = request_irq(i2c->irq, mpc_i2c_isr,
+ IRQF_SHARED, "i2c-mpc", i2c);
+ if (result < 0) {
+ dev_err(i2c->dev, "failed to attach interrupt\n");
+ goto fail_request;
}
/*
--
2.30.2
Re: [PATCH v31 2/4] scsi: ufs: L2P map management for HPB read
On 2021-03-23 12:22, Can Guo wrote:
On 2021-03-22 17:11, Bean Huo wrote:
On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:
+ switch (rsp_field->hpb_op) {
+ case HPB_RSP_REQ_REGION_UPDATE:
+ if (data_seg_len != DEV_DATA_SEG_LEN)
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"%s: data seg length is not
same.\n",
+__func__);
+ ufshpb_rsp_req_region_update(hpb, rsp_field);
+ break;
+ case HPB_RSP_DEV_RESET:
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"UFS device lost HPB information during
PM.\n");
+ break;
Hi Deajun,
This series looks good to me. Just here I have one question. You
didn't
handle HPB_RSP_DEV_RESET, just a warning. Based on your SS UFS, how
to
handle HPB_RSP_DEV_RESET from the host side? Do you think we shoud
reset host side HPB entry as well or what else?
Bean
Same question here - I am still collecting feedbacks from flash vendors
about
what is recommanded host behavior on reception of HPB Op code 0x2,
since it
is not cleared defined in HPB2.0 specs.
Can Guo.
I think the question should be asked in the HPB2.0 patch, since in
HPB1.0 device
control mode, a HPB reset in device side does not impact anything in
host side -
host is not writing back any HPB entries to device anyways and HPB Read
cmd with
invalid HPB entries shall be treated as normal Read(10) cmd without any
problems.
Please correct me if I am wrong.
Thanks,
Can Guo.
[PATCH] octeontx2-af: cn10k: Few mundane typos fixed
s/preceeds/precedes/ .two different places
s/rsponse/response/
s/cetain/certain/
s/precison/precision/
Signed-off-by: Bhaskar Chowdhury
---
drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
index ea456099b33c..14a184c3f6a4 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
@@ -74,13 +74,13 @@ struct otx2_mbox {
struct otx2_mbox_dev *dev;
};
-/* Header which preceeds all mbox messages */
+/* Header which precedes all mbox messages */
struct mbox_hdr {
u64 msg_size; /* Total msgs size embedded */
u16 num_msgs; /* No of msgs embedded */
};
-/* Header which preceeds every msg and is also part of it */
+/* Header which precedes every msg and is also part of it */
struct mbox_msghdr {
u16 pcifunc; /* Who's sending this msg */
u16 id; /* Mbox message ID */
@@ -277,7 +277,7 @@ struct msg_req {
struct mbox_msghdr hdr;
};
-/* Generic rsponse msg used a ack or response for those mbox
+/* Generic response msg used a ack or response for those mbox
* messages which doesn't have a specific rsp msg format.
*/
struct msg_rsp {
@@ -299,7 +299,7 @@ struct ready_msg_rsp {
/* Structure for requesting resource provisioning.
* 'modify' flag to be used when either requesting more
- * or to detach partial of a cetain resource type.
+ * or to detach partial of a certain resource type.
* Rest of the fields specify how many of what type to
* be attached.
* To request LFs from two blocks of same type this mailbox
@@ -489,7 +489,7 @@ struct cgx_set_link_mode_rsp {
};
#define RVU_LMAC_FEAT_FC BIT_ULL(0) /* pause frames */
-#define RVU_LMAC_FEAT_PTP BIT_ULL(1) /* precison time protocol */
+#define RVU_LMAC_FEAT_PTP BIT_ULL(1) /* precision time protocol */
#define RVU_MAC_VERSIONBIT_ULL(2)
#define RVU_MAC_CGXBIT_ULL(3)
#define RVU_MAC_RPMBIT_ULL(4)
--
2.31.0
RE: [PATCH v2] dt-binding: leds: Document leds-multi-gpio bindings
> -Original Message- > From: Rob Herring > Sent: 2021年3月23日 1:38 > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > /builds/robherring/linux-dt- > review/Documentation/devicetree/bindings/leds/leds-multi- > gpio.example.dt.yaml: gpios-led: led-states: 'oneOf' conditional failed, one > must be fixed: > [[0, 1, 2, 3]] is too short > [0, 1, 2, 3] is too long > From schema: /builds/robherring/linux-dt- > review/Documentation/devicetree/bindings/leds/leds-multi-gpio.yaml > Hi Rob, Thanks. Yes, now I can see the warning, but I could not understand what was wrong? Could you give some hint? Best Regards, Hermes
Re: [PATCH] drivers: scsi: Remove duplicate include of blkdev.h
On 2021-03-22 20:28, Wan Jiabing wrote: linux/blkdev.h has been included at line 18, so remove the duplicate include at line 27. Signed-off-by: Wan Jiabing --- drivers/scsi/ufs/ufshcd.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index c86760788c72..e8aa7de17d0a 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -24,7 +24,6 @@ #include "ufs_bsg.h" #include "ufshcd-crypto.h" #include -#include #define CREATE_TRACE_POINTS #include Someone has addressed it before you - check https://git.kernel.org/mkp/scsi/c/b4388e3db56a Can Guo.
Re: [PATCH v31 2/4] scsi: ufs: L2P map management for HPB read
On 2021-03-22 17:11, Bean Huo wrote:
On Mon, 2021-03-22 at 15:54 +0900, Daejun Park wrote:
+ switch (rsp_field->hpb_op) {
+ case HPB_RSP_REQ_REGION_UPDATE:
+ if (data_seg_len != DEV_DATA_SEG_LEN)
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"%s: data seg length is not
same.\n",
+__func__);
+ ufshpb_rsp_req_region_update(hpb, rsp_field);
+ break;
+ case HPB_RSP_DEV_RESET:
+ dev_warn(&hpb->sdev_ufs_lu->sdev_dev,
+"UFS device lost HPB information during
PM.\n");
+ break;
Hi Deajun,
This series looks good to me. Just here I have one question. You didn't
handle HPB_RSP_DEV_RESET, just a warning. Based on your SS UFS, how to
handle HPB_RSP_DEV_RESET from the host side? Do you think we shoud
reset host side HPB entry as well or what else?
Bean
Same question here - I am still collecting feedbacks from flash vendors
about
what is recommanded host behavior on reception of HPB Op code 0x2, since
it
is not cleared defined in HPB2.0 specs.
Can Guo.
Re: [PATCH] staging: wimax: Mundane typo fixes
On 3/22/21 6:06 PM, Bhaskar Chowdhury wrote: > > s/procesing/processing/ > s/comunication/communication/ > > Signed-off-by: Bhaskar Chowdhury drivers/staging/wimax/ is in the process of being deleted. > --- > drivers/staging/wimax/i2400m/driver.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/wimax/i2400m/driver.c > b/drivers/staging/wimax/i2400m/driver.c > index f5186458bb3d..162a92682977 100644 > --- a/drivers/staging/wimax/i2400m/driver.c > +++ b/drivers/staging/wimax/i2400m/driver.c -- ~Randy
[syzbot] possible deadlock in __loop_clr_fd
Hello,
syzbot found the following issue on:
HEAD commit:ba5b053a Add linux-next specific files for 20210318
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10cfb406d0
kernel config: https://syzkaller.appspot.com/x/.config?x=cd6e556bdf0188e4
dashboard link: https://syzkaller.appspot.com/bug?extid=707d51092ab7b87b23df
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+707d51092ab7b87b2...@syzkaller.appspotmail.com
UDF-fs: warning (device loop4): udf_load_vrs: No VRS found
UDF-fs: Scanning with blocksize 4096 failed
==
WARNING: possible circular locking dependency detected
5.12.0-rc3-next-20210318-syzkaller #0 Not tainted
--
syz-executor.4/13936 is trying to acquire lock:
88805cb9b138 ((wq_completion)loop292057088){+.+.}-{0:0}, at:
flush_workqueue+0xe1/0x13e0 kernel/workqueue.c:2783
but task is already holding lock:
88801a730468 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x95/0x14a0
drivers/block/loop.c:1278
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #6 (&lo->lo_mutex){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:952 [inline]
__mutex_lock+0x139/0x1120 kernel/locking/mutex.c:1099
lo_open drivers/block/loop.c:1983 [inline]
lo_open+0xa1/0x130 drivers/block/loop.c:1965
__blkdev_get+0x135/0xa30 fs/block_dev.c:1302
blkdev_get_by_dev fs/block_dev.c:1454 [inline]
blkdev_get_by_dev+0x26c/0x600 fs/block_dev.c:1422
blkdev_open+0x154/0x2b0 fs/block_dev.c:1551
do_dentry_open+0x4b9/0x11b0 fs/open.c:826
do_open fs/namei.c:3365 [inline]
path_openat+0x1c0e/0x27e0 fs/namei.c:3498
do_filp_open+0x17e/0x3c0 fs/namei.c:3525
do_sys_openat2+0x16d/0x420 fs/open.c:1187
do_sys_open fs/open.c:1203 [inline]
__do_sys_open fs/open.c:1211 [inline]
__se_sys_open fs/open.c:1207 [inline]
__x64_sys_open+0x119/0x1c0 fs/open.c:1207
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #5 (loop_ctl_mutex){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:952 [inline]
__mutex_lock+0x139/0x1120 kernel/locking/mutex.c:1099
loop_probe+0xc7/0x150 drivers/block/loop.c:2407
blk_request_module+0x111/0x1d0 block/genhd.c:769
blkdev_get_no_open+0x225/0x2b0 fs/block_dev.c:1368
blkdev_get_by_dev fs/block_dev.c:1440 [inline]
blkdev_get_by_dev+0x1f9/0x600 fs/block_dev.c:1422
blkdev_open+0x154/0x2b0 fs/block_dev.c:1551
do_dentry_open+0x4b9/0x11b0 fs/open.c:826
do_open fs/namei.c:3365 [inline]
path_openat+0x1c0e/0x27e0 fs/namei.c:3498
do_filp_open+0x17e/0x3c0 fs/namei.c:3525
do_sys_openat2+0x16d/0x420 fs/open.c:1187
do_sys_open fs/open.c:1203 [inline]
__do_sys_openat fs/open.c:1219 [inline]
__se_sys_openat fs/open.c:1214 [inline]
__x64_sys_openat+0x13f/0x1f0 fs/open.c:1214
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #4 (major_names_lock){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:952 [inline]
__mutex_lock+0x139/0x1120 kernel/locking/mutex.c:1099
blkdev_show+0x27/0x160 block/genhd.c:263
devinfo_show+0xc1/0xf0 fs/proc/devices.c:22
seq_read_iter+0xb66/0x1220 fs/seq_file.c:269
proc_reg_read_iter+0x1fb/0x2d0 fs/proc/inode.c:310
call_read_iter include/linux/fs.h:1969 [inline]
new_sync_read+0x41e/0x6e0 fs/read_write.c:415
vfs_read+0x35c/0x570 fs/read_write.c:496
ksys_read+0x12d/0x250 fs/read_write.c:634
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #3 (&p->lock){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:952 [inline]
__mutex_lock+0x139/0x1120 kernel/locking/mutex.c:1099
seq_read_iter+0xdf/0x1220 fs/seq_file.c:179
call_read_iter include/linux/fs.h:1969 [inline]
generic_file_splice_read+0x450/0x6c0 fs/splice.c:311
do_splice_to+0x1bf/0x250 fs/splice.c:796
splice_direct_to_actor+0x2c2/0x8c0 fs/splice.c:870
do_splice_direct+0x1b3/0x280 fs/splice.c:979
do_sendfile+0x9f0/0x1110 fs/read_write.c:1260
__do_sys_sendfile64 fs/read_write.c:1325 [inline]
__se_sys_sendfile64 fs/read_write.c:1311 [inline]
__x64_sys_sendfile64+0x1cc/0x210 fs/read_write.c:1311
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #2 (sb_writers#3){.+.+}-{0:0}:
percpu_down_read include/linux/percpu-rwsem.h:51 [inline]
__sb_start_write include/linux/fs.h:1638 [inline]
sb_start_write includ
Re: GTE - The hardware timestamping engine
On 3/22/21 7:59 PM, Kent Gibson wrote: > On Mon, Mar 22, 2021 at 06:53:10PM -0700, Dipen Patel wrote: >> >> >> On 3/22/21 5:32 PM, Kent Gibson wrote: >>> On Mon, Mar 22, 2021 at 01:21:46PM -0700, Dipen Patel wrote: Hi Linus and Kent, > > [snip] > >>> In response to all your comments above... >>> >>> Firstly, I'm not suggesting that other kernel modules would use the >>> cdev lineevents, only that they would use the same mechanism that >>> gpiolib-cdev would use to timestamp the lineevents for userspace. >>> >> Sure, I just wanted to mention the different scenarios and wanted to know >> how can we fit all those together. Having said that, shouldn't this serve >> an opportunity to extend the linevent framework to accommodate kernel >> drivers as a clients? >> >> If we can't, then there is a risk of duplicating lineevent mechanism in all >> of those kernel drivers or at least in GTE framework/infrastructure as far >> as GPIO related GTE part is concerned. >> > > In-kernel the lineevents are just IRQs so anything needing a "lineevent" > can request the IRQ directly. Or am I missing something? > In the GPIO context, I meant we can extend line_event_timestamp to kernel drivers as well in that way, both userspace and kernel drivers requesting particular GPIO for the hardware timestamp would be managed by same lineevent_* infrastructure from the gpiolib. Something like lineevent_create version of the kernel drivers, so if they need hardware timestamp on the GPIO line, they can request with some flags. In that way, GTE can leverage linevent* codes from gpiolib to cover its both the GPIO related use cases i.e. userspace app and kernel drivers. >>> As to that mechanism, my current thinking is that the approach of >>> associating GTE event FIFO entries with particular physical IRQ events is >>> problematic, as keeping the two in sync would be difficult, if not >>> impossible. >>> >>> A more robust approach is to ignore the physical IRQs and instead service >>> the GTE event FIFO, generating IRQs from those events in software - >>> essentially a pre-timestamped IRQ. The IRQ framework could provide the >>> timestamping functionality, equivalent to line_event_timestamp(), for >>> the IRQ handler/thread and in this case provide the timestamp from the GTE >>> event. >>> >> >> I have not fully understood above two paragraphs (except about >> lineevent_event_timestamp related part). >> >> I have no idea what it means to "ignore the physical IRQs and service the >> GTE event FIFO". Just like GPIO clients, there could be IRQ clients which >> want to monitor certain IRQ line, like ethernet driver wanted to retrieve >> timestamp for its IRQ line and so on. >> > > I mean that in the IRQ framework, rather than enabling the physical IRQ > line it would leave that masked and would instead enable the FIFO line to > service the FIFO, configure the GTE to generate the events for that > line, and then generate IRQs in response to the FIFO events. > That way the client requesting the IRQ is guaranteed to only receive an > IRQ that corresponds to a GTE FIFO event and the timestamp stored in the > IRQ framework would match. > I do not think we need to do such things, for example, below is the rough sequence how GTE can notify its clients be it GPIO or IRQ lines. I believe this will also help understand better ongoing GPIO discussions. 1. Configure GTE FIFO watermark or threshold, lets assume 1, i.e generate GTE interrupt when FIFO depth is 1. 2. In the GTE ISR or ISR thread, drain internal FIFO entries 3. Through GTE driver's internal mapping, identify which IRQ or GPIO number this entry belongs to. (This is possible as GTE has predefined bits for each supported signals, for example GTE supports 40 GPIOs and 352 IRQ lines, and it has multliple GTE instances which can take care all of them) 4. GTE driver pushes the event data (in this case it will be timestamp and direction of the event ie.rising or falling) to the GTE generic framework 5. GTE framework will store per event data to its per client/event sw FIFO 6. wake up any sleeping client thread 7. Points 3 to 6 are happening in GTE ISR context. 8. gte_retrieve_event (which can block if no event) at later convenient time do whatever it wants with it. We can extend it to non blocking version where some sort of client callbacks can be implemented. > And that is what I mean by this being an IRQ feature. > We need feedback from the IRQ guys as to whether that makes sense to > them. > > Cheers, > Kent. > Best Regards, Dipen Patel
Re: [PATCH] coresight: core: Fix typo in coresight-core.c
On 2021/3/22 22:38, Suzuki K Poulose wrote:
On 22/03/2021 13:11, Qi Liu wrote:
Fix up one typo: compoment->component.
Fixes: 8e264c52e1da ("coresight: core: Allow the coresight core
driver to be built as a module")
Signed-off-by: Qi Liu
Thanks for the patch. I will queue this.
.
Hi Suzuki,
Randy pointed out it should be "components" here, so I'll send a v2 with
this fixed.
Thanks,
Qi
[PATCH v2] sched: Warn on long periods of pending need_resched
From: Paul Turner
CPU scheduler marks need_resched flag to signal a schedule() on a
particular CPU. But, schedule() may not happen immediately in cases
where the current task is executing in the kernel mode (no
preemption state) for extended periods of time.
This patch adds a warn_on if need_resched is pending for more than the
time specified in sysctl resched_latency_warn_ms. If it goes off, it is
likely that there is a missing cond_resched() somewhere. Monitoring is
done via the tick and the accuracy is hence limited to jiffy scale. This
also means that we won't trigger the warning if the tick is disabled.
This feature is default disabled. It can be toggled on using sysctl
resched_latency_warn_enabled.
Signed-off-by: Paul Turner
Signed-off-by: Josh Don
---
Delta from v1:
- separate sysctl for enabling/disabling and triggering warn_once
behavior
- add documentation
- static branch for the enable
Documentation/admin-guide/sysctl/kernel.rst | 23 ++
include/linux/sched/sysctl.h| 4 ++
kernel/sched/core.c | 78 -
kernel/sched/debug.c| 10 +++
kernel/sched/sched.h| 10 +++
kernel/sysctl.c | 24 +++
6 files changed, 148 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/sysctl/kernel.rst
b/Documentation/admin-guide/sysctl/kernel.rst
index 1d56a6b73a4e..2d4a21d3b79f 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1077,6 +1077,29 @@ ROM/Flash boot loader. Maybe to tell it what to do after
rebooting. ???
+resched_latency_warn_enabled
+
+
+Enables/disables a warning that will trigger if need_resched is set for
+longer than sysctl ``resched_latency_warn_ms``. This warning likely
+indicates a kernel bug, such as a failure to call cond_resched().
+
+Requires ``CONFIG_SCHED_DEBUG``.
+
+
+resched_latency_warn_ms
+===
+
+See ``resched_latency_warn_enabled``.
+
+
+resched_latency_warn_once
+=
+
+If set, ``resched_latency_warn_enabled`` will only trigger one warning
+per boot.
+
+
sched_energy_aware
==
diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h
index 3c31ba88aca5..43a1f5ab819a 100644
--- a/include/linux/sched/sysctl.h
+++ b/include/linux/sched/sysctl.h
@@ -48,6 +48,10 @@ extern unsigned int sysctl_numa_balancing_scan_size;
extern __read_mostly unsigned int sysctl_sched_migration_cost;
extern __read_mostly unsigned int sysctl_sched_nr_migrate;
+extern struct static_key_false resched_latency_warn_enabled;
+extern int sysctl_resched_latency_warn_ms;
+extern int sysctl_resched_latency_warn_once;
+
int sched_proc_update_handler(struct ctl_table *table, int write,
void *buffer, size_t *length, loff_t *ppos);
#endif
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 98191218d891..d69ae342b450 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -58,7 +58,21 @@ const_debug unsigned int sysctl_sched_features =
#include "features.h"
0;
#undef SCHED_FEAT
-#endif
+
+/*
+ * Print a warning if need_resched is set for the given duration (if
+ * resched_latency_warn_enabled is set).
+ *
+ * If sysctl_resched_latency_warn_once is set, only one warning will be shown
+ * per boot.
+ *
+ * Resched latency will be ignored for the first resched_boot_quiet_sec, to
+ * reduce false alarms.
+ */
+int sysctl_resched_latency_warn_ms = 100;
+int sysctl_resched_latency_warn_once = 1;
+const long resched_boot_quiet_sec = 600;
+#endif /* CONFIG_SCHED_DEBUG */
/*
* Number of tasks to iterate in a single balance run.
@@ -4520,6 +4534,58 @@ unsigned long long task_sched_runtime(struct task_struct
*p)
return ns;
}
+#ifdef CONFIG_SCHED_DEBUG
+static u64 resched_latency_check(struct rq *rq)
+{
+ int latency_warn_ms = READ_ONCE(sysctl_resched_latency_warn_ms);
+ u64 need_resched_latency, now = rq_clock(rq);
+ static bool warned_once;
+
+ if (sysctl_resched_latency_warn_once && warned_once)
+ return 0;
+
+ if (!need_resched() || WARN_ON_ONCE(latency_warn_ms < 2))
+ return 0;
+
+ /* Disable this warning for the first few mins after boot */
+ if (now < resched_boot_quiet_sec * NSEC_PER_SEC)
+ return 0;
+
+ if (!rq->last_seen_need_resched_ns) {
+ rq->last_seen_need_resched_ns = now;
+ rq->ticks_without_resched = 0;
+ return 0;
+ }
+
+ rq->ticks_without_resched++;
+ need_resched_latency = now - rq->last_seen_need_resched_ns;
+ if (need_resched_latency <= latency_warn_ms * NSEC_PER_MSEC)
+ return 0;
+
+ warned_once = true;
+
+ return need_resched_latency;
+}
+
+static int __init setup_resched_latency_warn_ms(char *str)
+{
+ long val;
+
+ if ((kstrtol(
[PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU
Add an openssl command option example for generating CodeSign extended key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled. Signed-off-by: "Lee, Chun-Yi" --- Documentation/admin-guide/module-signing.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst index 7d7c7c8a545c..ca3b8f19466c 100644 --- a/Documentation/admin-guide/module-signing.rst +++ b/Documentation/admin-guide/module-signing.rst @@ -170,6 +170,12 @@ generate the public/private key files:: -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem +When ``CONFIG_CHECK_CODESIGN_EKU`` option is enabled, the following openssl +command option should be added where for generating CodeSign extended key usage +in X.509:: + +-addext "extendedKeyUsage=codeSigning" + The full pathname for the resulting kernel_key.pem file can then be specified in the ``CONFIG_MODULE_SIG_KEY`` option, and the certificate and key therein will be used instead of an autogenerated keypair. -- 2.16.4
[PATCH 3/4] modsign: Add codeSigning EKU when generating X.509 key generation config
Add codeSigning EKU to the X.509 key generation config for the build time autogenerated kernel key. Signed-off-by: "Lee, Chun-Yi" --- certs/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/certs/Makefile b/certs/Makefile index f4c25b67aad9..1ef4d6ca43b7 100644 --- a/certs/Makefile +++ b/certs/Makefile @@ -88,6 +88,7 @@ $(obj)/x509.genkey: @echo >>$@ "keyUsage=digitalSignature" @echo >>$@ "subjectKeyIdentifier=hash" @echo >>$@ "authorityKeyIdentifier=keyid" + @echo >>$@ "extendedKeyUsage=codeSigning" endif # CONFIG_MODULE_SIG_KEY $(eval $(call config_filename,MODULE_SIG_KEY)) -- 2.16.4
[PATCH 2/4] PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification
This patch adds the logic for checking the CodeSigning extended
key usage when verifying signature of kernel module or
kexec PE binary in PKCS#7.
Signed-off-by: "Lee, Chun-Yi"
---
certs/system_keyring.c | 2 +-
crypto/asymmetric_keys/Kconfig | 9 +
crypto/asymmetric_keys/pkcs7_trust.c | 37 +---
include/crypto/pkcs7.h | 3 ++-
4 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 4b693da488f1..c9f8bca0b0d3 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -243,7 +243,7 @@ int verify_pkcs7_message_sig(const void *data, size_t len,
goto error;
}
}
- ret = pkcs7_validate_trust(pkcs7, trusted_keys);
+ ret = pkcs7_validate_trust(pkcs7, trusted_keys, usage);
if (ret < 0) {
if (ret == -ENOKEY)
pr_devel("PKCS#7 signature not signed with a trusted
key\n");
diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
index 1f1f004dc757..1754812df989 100644
--- a/crypto/asymmetric_keys/Kconfig
+++ b/crypto/asymmetric_keys/Kconfig
@@ -96,4 +96,13 @@ config SIGNED_PE_FILE_VERIFICATION
This option provides support for verifying the signature(s) on a
signed PE binary.
+config CHECK_CODESIGN_EKU
+ bool "Check codeSigning extended key usage"
+ depends on PKCS7_MESSAGE_PARSER=y
+ depends on SYSTEM_DATA_VERIFICATION
+ help
+ This option provides support for checking the codeSigning extended
+ key usage when verifying the signature in PKCS#7. It affects kernel
+ module verification and kexec PE binary verification.
+
endif # ASYMMETRIC_KEY_TYPE
diff --git a/crypto/asymmetric_keys/pkcs7_trust.c
b/crypto/asymmetric_keys/pkcs7_trust.c
index b531df2013c4..077bfef928b6 100644
--- a/crypto/asymmetric_keys/pkcs7_trust.c
+++ b/crypto/asymmetric_keys/pkcs7_trust.c
@@ -16,12 +16,36 @@
#include
#include "pkcs7_parser.h"
+#ifdef CONFIG_CHECK_CODESIGN_EKU
+static bool check_codesign_eku(struct key *key,
+enum key_being_used_for usage)
+{
+ struct public_key *public_key = key->payload.data[asym_crypto];
+
+ switch (usage) {
+ case VERIFYING_MODULE_SIGNATURE:
+ case VERIFYING_KEXEC_PE_SIGNATURE:
+ return !!(public_key->eku & EKU_codeSigning);
+ default:
+ break;
+ }
+ return true;
+}
+#else
+static bool check_codesign_eku(struct key *key,
+enum key_being_used_for usage)
+{
+ return true;
+}
+#endif
+
/*
* Check the trust on one PKCS#7 SignedInfo block.
*/
static int pkcs7_validate_trust_one(struct pkcs7_message *pkcs7,
struct pkcs7_signed_info *sinfo,
- struct key *trust_keyring)
+ struct key *trust_keyring,
+ enum key_being_used_for usage)
{
struct public_key_signature *sig = sinfo->sig;
struct x509_certificate *x509, *last = NULL, *p;
@@ -112,6 +136,12 @@ static int pkcs7_validate_trust_one(struct pkcs7_message
*pkcs7,
return -ENOKEY;
matched:
+ if (!check_codesign_eku(key, usage)) {
+ pr_warn("sinfo %u: The signer %x key is not CodeSigning\n",
+ sinfo->index, key_serial(key));
+ key_put(key);
+ return -ENOKEY;
+ }
ret = verify_signature(key, sig);
key_put(key);
if (ret < 0) {
@@ -156,7 +186,8 @@ static int pkcs7_validate_trust_one(struct pkcs7_message
*pkcs7,
* May also return -ENOMEM.
*/
int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
-struct key *trust_keyring)
+struct key *trust_keyring,
+enum key_being_used_for usage)
{
struct pkcs7_signed_info *sinfo;
struct x509_certificate *p;
@@ -167,7 +198,7 @@ int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
p->seen = false;
for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
- ret = pkcs7_validate_trust_one(pkcs7, sinfo, trust_keyring);
+ ret = pkcs7_validate_trust_one(pkcs7, sinfo, trust_keyring,
usage);
switch (ret) {
case -ENOKEY:
continue;
diff --git a/include/crypto/pkcs7.h b/include/crypto/pkcs7.h
index 38ec7f5f9041..b3b48240ba73 100644
--- a/include/crypto/pkcs7.h
+++ b/include/crypto/pkcs7.h
@@ -30,7 +30,8 @@ extern int pkcs7_get_content_data(const struct pkcs7_message
*pkcs7,
* pkcs7_trust.c
*/
extern int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
- struct key *trust_keyring);
+ struct key *trust_keyring,
+
[PATCH 1/4] X.509: Add CodeSigning extended key usage parsing
This patch adds the logic for parsing the CodeSign extended key usage
extension in X.509. The parsing result will be set to the eku flag
which is carried by public key. It can be used in the PKCS#7
verification.
Signed-off-by: "Lee, Chun-Yi"
---
crypto/asymmetric_keys/x509_cert_parser.c | 24
include/crypto/public_key.h | 1 +
include/linux/oid_registry.h | 5 +
3 files changed, 30 insertions(+)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/crypto/asymmetric_keys/x509_cert_parser.c
index 52c9b455fc7d..65721313b265 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -497,6 +497,8 @@ int x509_process_extension(void *context, size_t hdrlen,
struct x509_parse_context *ctx = context;
struct asymmetric_key_id *kid;
const unsigned char *v = value;
+ int i = 0;
+ enum OID oid;
pr_debug("Extension: %u\n", ctx->last_oid);
@@ -526,6 +528,28 @@ int x509_process_extension(void *context, size_t hdrlen,
return 0;
}
+ if (ctx->last_oid == OID_extKeyUsage) {
+ if (v[0] != ((ASN1_UNIV << 6) | ASN1_CONS_BIT | ASN1_SEQ) ||
+ v[1] != vlen - 2)
+ return -EBADMSG;
+ i += 2;
+
+ while (i < vlen) {
+ /* A 10 bytes EKU OID Octet blob =
+* ASN1_OID + size byte + 8 bytes OID */
+ if (v[i] != ASN1_OID || v[i + 1] != 8 || (i + 10) >
vlen)
+ return -EBADMSG;
+
+ oid = look_up_OID(v + i + 2, v[i + 1]);
+ if (oid == OID_codeSigning) {
+ ctx->cert->pub->eku |= EKU_codeSigning;
+ }
+ i += 10;
+ }
+ pr_debug("extKeyUsage: %d\n", ctx->cert->pub->eku);
+ return 0;
+ }
+
return 0;
}
diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index 47accec68cb0..1ccaebe2a28b 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -28,6 +28,7 @@ struct public_key {
bool key_is_private;
const char *id_type;
const char *pkey_algo;
+ unsigned int eku : 9; /* Extended Key Usage (9-bit) */
};
extern void public_key_free(struct public_key *key);
diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
index 4462ed2c18cd..e20e8eb53b21 100644
--- a/include/linux/oid_registry.h
+++ b/include/linux/oid_registry.h
@@ -113,9 +113,14 @@ enum OID {
OID_SM2_with_SM3, /* 1.2.156.10197.1.501 */
OID_sm3WithRSAEncryption, /* 1.2.156.10197.1.504 */
+ /* Extended key purpose OIDs [RFC 5280] */
+ OID_codeSigning,/* 1.3.6.1.5.5.7.3.3 */
+
OID__NR
};
+#define EKU_codeSigning(1 << 2)
+
extern enum OID look_up_OID(const void *data, size_t datasize);
extern int sprint_oid(const void *, size_t, char *, size_t);
extern int sprint_OID(enum OID, char *, size_t);
--
2.16.4
[PATCH v5 0/4] Check codeSigning extended key usage extension
NIAP PP_OS certification requests that the OS shall validate the CodeSigning extended key usage extension field for integrity verifiction of exectable code: https://www.niap-ccevs.org/MMO/PP/-442-/ FIA_X509_EXT.1.1 This patchset adds the logic for parsing the codeSigning EKU extension field in X.509. And checking the CodeSigning EKU when verifying signature of kernel module or kexec PE binary in PKCS#7. v5: Fixed the wording in module-signing.rst. v4: Fixed the wording in patch description. v3: - Add codeSigning EKU to x509.genkey key generation config. - Add openssl command option example for generating CodeSign EKU to module-signing.rst document. v2: Changed the help wording in the Kconfig. Lee, Chun-Yi (4): X.509: Add CodeSigning extended key usage parsing PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification modsign: Add codeSigning EKU when generating X.509 key generation config Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU Documentation/admin-guide/module-signing.rst | 6 + certs/Makefile | 1 + certs/system_keyring.c | 2 +- crypto/asymmetric_keys/Kconfig | 9 +++ crypto/asymmetric_keys/pkcs7_trust.c | 37 +--- crypto/asymmetric_keys/x509_cert_parser.c| 24 ++ include/crypto/pkcs7.h | 3 ++- include/crypto/public_key.h | 1 + include/linux/oid_registry.h | 5 9 files changed, 83 insertions(+), 5 deletions(-) -- 2.16.4
Re: [PATCH 1/6] sched: migration changes for core scheduling
On 2021/3/22 20:56, Peter Zijlstra wrote:
> On Mon, Mar 22, 2021 at 08:31:09PM +0800, Li, Aubrey wrote:
>> Please let me know if I put cookie match check at the right position
>> in task_hot(), if so, I'll obtain some performance data of it.
>>
>> Thanks,
>> -Aubrey
>>
>> ===
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 7f2fb08..d4bdcf9 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -1912,6 +1912,13 @@ static void task_numa_find_cpu(struct task_numa_env
>> *env,
>> if (!cpumask_test_cpu(cpu, env->p->cpus_ptr))
>> continue;
>>
>> +/*
>> + * Skip this cpu if source task's cookie does not match
>> + * with CPU's core cookie.
>> + */
>> +if (!sched_core_cookie_match(cpu_rq(cpu), env->p))
>> +continue;
>> +
>> env->dst_cpu = cpu;
>> if (task_numa_compare(env, taskimp, groupimp, maymove))
>> break;
>
> This one might need a little help too, I've not fully considered NUMA
> balancing though.
>
I dropped this numa change for now as it may be too strong, too. I'll
do more experiment about this on the new iteration.
The following patch is rebased on top of queue tree, cookie check is moved
from can_migrate_task to task_hot.
please let me know if any issues.
Thanks,
-Aubrey
==
>From 70d0ed9bab658b0bad60fda73f81b747f20975f0 Mon Sep 17 00:00:00 2001
From: Aubrey Li
Date: Tue, 23 Mar 2021 03:26:34 +
Subject: [PATCH] sched: migration changes for core scheduling
- Don't migrate if there is a cookie mismatch
Load balance tries to move task from busiest CPU to the
destination CPU. When core scheduling is enabled, if the
task's cookie does not match with the destination CPU's
core cookie, this task may be skipped by this CPU. This
mitigates the forced idle time on the destination CPU.
- Select cookie matched idle CPU
In the fast path of task wakeup, select the first cookie matched
idle CPU instead of the first idle CPU.
- Find cookie matched idlest CPU
In the slow path of task wakeup, find the idlest CPU whose core
cookie matches with task's cookie
Signed-off-by: Aubrey Li
Signed-off-by: Tim Chen
Signed-off-by: Vineeth Remanan Pillai
Signed-off-by: Joel Fernandes (Google)
---
kernel/sched/fair.c | 29 ++
kernel/sched/sched.h | 73
2 files changed, 96 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index efde8df2bc35..a74061484194 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5877,11 +5877,15 @@ find_idlest_group_cpu(struct sched_group *group, struct
task_struct *p, int this
/* Traverse only the allowed CPUs */
for_each_cpu_and(i, sched_group_span(group), p->cpus_ptr) {
+ struct rq *rq = cpu_rq(i);
+
+ if (!sched_core_cookie_match(rq, p))
+ continue;
+
if (sched_idle_cpu(i))
return i;
if (available_idle_cpu(i)) {
- struct rq *rq = cpu_rq(i);
struct cpuidle_state *idle = idle_get_state(rq);
if (idle && idle->exit_latency < min_exit_latency) {
/*
@@ -5967,9 +5971,10 @@ static inline int find_idlest_cpu(struct sched_domain
*sd, struct task_struct *p
return new_cpu;
}
-static inline int __select_idle_cpu(int cpu)
+static inline int __select_idle_cpu(int cpu, struct task_struct *p)
{
- if (available_idle_cpu(cpu) || sched_idle_cpu(cpu))
+ if ((available_idle_cpu(cpu) || sched_idle_cpu(cpu)) &&
+ sched_cpu_cookie_match(cpu_rq(cpu), p))
return cpu;
return -1;
@@ -6039,7 +6044,7 @@ static int select_idle_core(struct task_struct *p, int
core, struct cpumask *cpu
int cpu;
if (!static_branch_likely(&sched_smt_present))
- return __select_idle_cpu(core);
+ return __select_idle_cpu(core, p);
for_each_cpu(cpu, cpu_smt_mask(core)) {
if (!available_idle_cpu(cpu)) {
@@ -6077,7 +6082,7 @@ static inline bool test_idle_cores(int cpu, bool def)
static inline int select_idle_core(struct task_struct *p, int core, struct
cpumask *cpus, int *idle_cpu)
{
- return __select_idle_cpu(core);
+ return __select_idle_cpu(core, p);
}
#endif /* CONFIG_SCHED_SMT */
@@ -6130,7 +6135,7 @@ static int select_idle_cpu(struct task_struct *p, struct
sched_domain *sd, int t
} else {
if (!--nr)
return -1;
- idle_cpu = __select_idle_cpu(cpu);
+ idle_cpu = __select_idle_cpu(cpu
