Re: [PATCH v11 0/7] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port
Hi, On Wed, Jan 13, 2021 at 10:24:49PM +, Srinivas Kandagatla wrote: > On 13/01/2021 20:08, Stephan Gerhold wrote: > > On Thu, Oct 08, 2020 at 06:37:40AM +0100, Srinivas Kandagatla wrote: > > > On 08/10/2020 06:16, Srinivasa Rao Mandadapu wrote: > > > > These patches are to support audio over DP port on Qualcomm's SC7180 > > > > LPASS > > > > Asoc. It includes machine driver, cpu driver, platform driver updates > > > > for > > > > HDMI path support, device tree documention, lpass variant structure > > > > optimization and configuration changes. > > > > These patches depends on the DP patch series > > > > https://patchwork.kernel.org/project/dri-devel/list/?series=332029 > > > > https://lore.kernel.org/patchwork/project/lkml/list/?series=464856 > > > > > > > > changes since V10: > > > > -- Moved hdmi regmap functions from lpass-hdmi.c to lpass-cpu.c > > > > -- Moved QCOM_REGMAP_FIELD_ALLOC macro from lpass-hdmi.c to > > > > lpass.h > > > > changes since V9: > > > > -- Removed unused structures lpass_hdmi.h > > > > changes since V8: > > > > -- Removed redundant structure wrapper for reg map field memebrs > > > > -- Updated lpass_hdmi_regmap_volatile API with appropriate > > > > registers as true > > > > and others as false. > > > > changes since V7: > > > > -- Fixed typo errors > > > > -- Created Separate patch for buffer size change > > > > changes since V6: > > > > -- Removed compile time define flag, which used for enabling > > > >HDMI code, based on corresponding config param is included. > > > > -- Updated reg map alloc API with reg map bulk API. > > > > -- Removed unnecessary line splits > > > > changes since V5: > > > > -- Removed unused struct regmap *map in > > > > lpass_platform_alloc_hdmidmactl_fields. > > > > -- DMA alloc and free API signature change in lpass-apq8016.c, > > > > lpass-ipq806x.c > > > > -- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under > > > > ifdef macro > > > > Changes Since v4: > > > > -- Updated with single compatible node for both I2S and HDMI. > > > > Changes Since v3: > > > > -- Removed id in lpass variant structure and used > > > > snd_soc_dai_driver id. > > > > Changes Since v2: > > > > -- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in > > > > lpass-platform.c increased. > > > > Changes Since v1: > > > > -- Commit messages are updated > > > > -- Addressed Rob Herring review comments > > > > > > > > V Sujith Kumar Reddy (7): > > > > ASoC: Add sc7180-lpass binding header hdmi define > > > > ASoC: dt-bindings: Add dt binding for lpass hdmi > > > > Asoc:qcom:lpass-cpu:Update dts property read API > > > > Asoc: qcom: lpass:Update lpaif_dmactl members order > > > > ASoC: qcom: Add support for lpass hdmi driver > > > > Asoc: qcom: lpass-platform : Increase buffer size > > > > ASoC: qcom: sc7180: Add support for audio over DP > > > > > > > >.../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 74 ++-- > > > >include/dt-bindings/sound/sc7180-lpass.h | 1 + > > > >sound/soc/qcom/Kconfig | 5 + > > > >sound/soc/qcom/Makefile| 2 + > > > >sound/soc/qcom/lpass-apq8016.c | 4 +- > > > >sound/soc/qcom/lpass-cpu.c | 249 > > > > - > > > >sound/soc/qcom/lpass-hdmi.c| 258 > > > > ++ > > > >sound/soc/qcom/lpass-hdmi.h| 102 ++ > > > >sound/soc/qcom/lpass-ipq806x.c | 4 +- > > > >sound/soc/qcom/lpass-lpaif-reg.h | 49 ++- > > > >sound/soc/qcom/lpass-platform.c| 395 > > > > + > > > >sound/soc/qcom/lpass-sc7180.c | 116 +- > > > >sound/soc/qcom/lpass.h | 124 ++- > > > >13 files changed, 1240 insertions(+), 143 deletions(-) > > > >create mode 100644 sound/soc/qcom/lpass-hdmi.c > > > >create mode 100644 sound/soc/qcom/lpass-hdmi.h > > > > > > > > > > Tested this series on DragonBoard 410c > > > > > > Tested-by: Srinivas Kandagatla > > > Reviewed-by: Srinivas Kandagatla > > > > I spent quite some time today trying to track down another regression > > for MSM8916/DragonBoard 410c audio in 5.10 and identified this patch > > series as the cause. So I'm very surprised that you successfully tested > > this on DB410c. > > > > Attempting to play HDMI audio results in: > > > >ADV7533: lpass_platform_pcmops_hw_params: invalid interface: 3 > >ADV7533: lpass_platform_pcmops_trigger: invalid 3 interface > >apq8016-lpass-cpu 7708000.audio-controller: ASoC: error at > > soc_component_trigger on 7708000.audio-controller: -22 > > > > Attempting to record analog audio results in: > > > >Unable to handle kernel NULL poi
Question on workqueue: Manually break affinity on hotplug
Hello Peter
Excuse me, I have some questions for you, about a description of this change:
''Don't rely on the scheduler to force break affinity for us -- it will
stop doing that for per-cpu-kthreads."
this mean when cpuhotplug, scheduler do not change affinity for
per-cpu-kthread's task, if we not active setting affinity?
but if per-cpu-kthread's task is not run state, when wake up, will reset it's
affinity, this is done automatically.
or is it, this place modified to fit the new one hotplug mechanism which
("sched/hotplug: Consolidate task migration on CPU unplug")?
Thanks
Qiang
[PATCH v6 02/16] rapidio: fix kernel-doc a markup
Probaly this was due to a cut and paste issue. Signed-off-by: Mauro Carvalho Chehab --- drivers/rapidio/rio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rapidio/rio.c b/drivers/rapidio/rio.c index c2b79736a92b..e74cf09eeff0 100644 --- a/drivers/rapidio/rio.c +++ b/drivers/rapidio/rio.c @@ -749,7 +749,7 @@ int rio_map_outb_region(struct rio_mport *mport, u16 destid, u64 rbase, EXPORT_SYMBOL_GPL(rio_map_outb_region); /** - * rio_unmap_inb_region -- Unmap the inbound memory region + * rio_unmap_outb_region -- Unmap the inbound memory region * @mport: Master port * @destid: destination id mapping points to * @rstart: RIO base address window translates to -- 2.29.2
[PATCH v6 03/16] fs: fix kernel-doc markups
Two markups are at the wrong place. Kernel-doc only
support having the comment just before the identifier.
Also, some identifiers have different names between their
prototypes and the kernel-doc markup.
Signed-off-by: Mauro Carvalho Chehab
---
fs/dcache.c | 73 ++-
fs/inode.c| 4 +--
fs/seq_file.c | 5 ++--
fs/super.c| 12 -
4 files changed, 48 insertions(+), 46 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 737631c8ca7e..51e7081aacdd 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -456,23 +456,6 @@ static void d_lru_shrink_move(struct list_lru_one *lru,
struct dentry *dentry,
list_lru_isolate_move(lru, &dentry->d_lru, list);
}
-/**
- * d_drop - drop a dentry
- * @dentry: dentry to drop
- *
- * d_drop() unhashes the entry from the parent dentry hashes, so that it won't
- * be found through a VFS lookup any more. Note that this is different from
- * deleting the dentry - d_delete will try to mark the dentry negative if
- * possible, giving a successful _negative_ lookup, while d_drop will
- * just make the cache lookup fail.
- *
- * d_drop() is used mainly for stuff that wants to invalidate a dentry for some
- * reason (NFS timeouts or autofs deletes).
- *
- * __d_drop requires dentry->d_lock
- * ___d_drop doesn't mark dentry as "unhashed"
- * (dentry->d_hash.pprev will be LIST_POISON2, not NULL).
- */
static void ___d_drop(struct dentry *dentry)
{
struct hlist_bl_head *b;
@@ -501,6 +484,24 @@ void __d_drop(struct dentry *dentry)
}
EXPORT_SYMBOL(__d_drop);
+/**
+ * d_drop - drop a dentry
+ * @dentry: dentry to drop
+ *
+ * d_drop() unhashes the entry from the parent dentry hashes, so that it won't
+ * be found through a VFS lookup any more. Note that this is different from
+ * deleting the dentry - d_delete will try to mark the dentry negative if
+ * possible, giving a successful _negative_ lookup, while d_drop will
+ * just make the cache lookup fail.
+ *
+ * d_drop() is used mainly for stuff that wants to invalidate a dentry for some
+ * reason (NFS timeouts or autofs deletes).
+ *
+ * __d_drop requires dentry->d_lock
+ *
+ * ___d_drop doesn't mark dentry as "unhashed"
+ * (dentry->d_hash.pprev will be LIST_POISON2, not NULL).
+ */
void d_drop(struct dentry *dentry)
{
spin_lock(&dentry->d_lock);
@@ -996,6 +997,25 @@ struct dentry *d_find_any_alias(struct inode *inode)
}
EXPORT_SYMBOL(d_find_any_alias);
+static struct dentry *__d_find_alias(struct inode *inode)
+{
+ struct dentry *alias;
+
+ if (S_ISDIR(inode->i_mode))
+ return __d_find_any_alias(inode);
+
+ hlist_for_each_entry(alias, &inode->i_dentry, d_u.d_alias) {
+ spin_lock(&alias->d_lock);
+ if (!d_unhashed(alias)) {
+ __dget_dlock(alias);
+ spin_unlock(&alias->d_lock);
+ return alias;
+ }
+ spin_unlock(&alias->d_lock);
+ }
+ return NULL;
+}
+
/**
* d_find_alias - grab a hashed alias of inode
* @inode: inode in question
@@ -1010,25 +1030,6 @@ EXPORT_SYMBOL(d_find_any_alias);
* If the inode has an IS_ROOT, DCACHE_DISCONNECTED alias, then prefer
* any other hashed alias over that one.
*/
-static struct dentry *__d_find_alias(struct inode *inode)
-{
- struct dentry *alias;
-
- if (S_ISDIR(inode->i_mode))
- return __d_find_any_alias(inode);
-
- hlist_for_each_entry(alias, &inode->i_dentry, d_u.d_alias) {
- spin_lock(&alias->d_lock);
- if (!d_unhashed(alias)) {
- __dget_dlock(alias);
- spin_unlock(&alias->d_lock);
- return alias;
- }
- spin_unlock(&alias->d_lock);
- }
- return NULL;
-}
-
struct dentry *d_find_alias(struct inode *inode)
{
struct dentry *de = NULL;
diff --git a/fs/inode.c b/fs/inode.c
index dd52b6444fdf..af280ffb105d 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -1494,7 +1494,7 @@ struct inode *find_inode_rcu(struct super_block *sb,
unsigned long hashval,
EXPORT_SYMBOL(find_inode_rcu);
/**
- * find_inode_by_rcu - Find an inode in the inode cache
+ * find_inode_by_ino_rcu - Find an inode in the inode cache
* @sb:Super block of file system to search
* @ino: The inode number to match
*
@@ -1780,7 +1780,7 @@ static int update_time(struct inode *inode, struct
timespec64 *time, int flags)
}
/**
- * touch_atime - update the access time
+ * atime_needs_update - update the access time
* @path: the &struct path to update
* @inode: inode to update
*
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 03a369ccd28c..cb11a34fb871 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -669,7 +669,8 @@ void seq_puts(struct seq_file *m, const char *s)
EXPORT_SYMBOL(seq_puts);
/**
- * A helper routine for putting de
[PATCH v6 06/16] connector: fix a kernel-doc markup
A function has a different name between their prototype and its kernel-doc markup. Signed-off-by: Mauro Carvalho Chehab --- include/linux/connector.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/connector.h b/include/linux/connector.h index 8ea860efea37..487350bb19c3 100644 --- a/include/linux/connector.h +++ b/include/linux/connector.h @@ -99,7 +99,7 @@ void cn_del_callback(const struct cb_id *id); int cn_netlink_send_mult(struct cn_msg *msg, u16 len, u32 portid, u32 group, gfp_t gfp_mask); /** - * cn_netlink_send_mult - Sends message to the specified groups. + * cn_netlink_send - Sends message to the specified groups. * * @msg: message header(with attached data). * @portid:destination port. -- 2.29.2
[PATCH v6 04/16] pstore/zone: fix a kernel-doc markup
The documented struct is psz_head and not psz_buffer. Reviewed-by: Kees Cook Signed-off-by: Mauro Carvalho Chehab --- fs/pstore/zone.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/pstore/zone.c b/fs/pstore/zone.c index 5266ccbec007..7c8f8feac6c3 100644 --- a/fs/pstore/zone.c +++ b/fs/pstore/zone.c @@ -23,7 +23,7 @@ #include "internal.h" /** - * struct psz_head - header of zone to flush to storage + * struct psz_buffer - header of zone to flush to storage * * @sig: signature to indicate header (PSZ_SIG xor PSZONE-type value) * @datalen: length of data in @data -- 2.29.2
arch/arm64/include/asm/syscall_wrapper.h:41:25: warning: no previous prototype for '__arm64_compat_sys_epoll_pwait2'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 65f0d2414b7079556fbbcc070b3d1c9f9587606d commit: b0a0c2615f6f199a656ed8549d7dce625d77aa77 epoll: wire up syscall epoll_pwait2 date: 4 weeks ago config: arm64-randconfig-r005-20210113 (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b0a0c2615f6f199a656ed8549d7dce625d77aa77 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout b0a0c2615f6f199a656ed8549d7dce625d77aa77 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): | ^~~~ kernel/sys_ni.c:45:1: note: in expansion of macro 'COND_SYSCALL' 45 | COND_SYSCALL(io_getevents_time32); | ^~~~ arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous prototype for '__arm64_sys_io_getevents' [-Wmissing-prototypes] 76 | asmlinkage long __weak __arm64_sys_##name(const struct pt_regs *regs) \ | ^~~~ kernel/sys_ni.c:46:1: note: in expansion of macro 'COND_SYSCALL' 46 | COND_SYSCALL(io_getevents); | ^~~~ arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous prototype for '__arm64_sys_io_pgetevents_time32' [-Wmissing-prototypes] 76 | asmlinkage long __weak __arm64_sys_##name(const struct pt_regs *regs) \ | ^~~~ kernel/sys_ni.c:47:1: note: in expansion of macro 'COND_SYSCALL' 47 | COND_SYSCALL(io_pgetevents_time32); | ^~~~ arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous prototype for '__arm64_sys_io_pgetevents' [-Wmissing-prototypes] 76 | asmlinkage long __weak __arm64_sys_##name(const struct pt_regs *regs) \ | ^~~~ kernel/sys_ni.c:48:1: note: in expansion of macro 'COND_SYSCALL' 48 | COND_SYSCALL(io_pgetevents); | ^~~~ arch/arm64/include/asm/syscall_wrapper.h:41:25: warning: no previous prototype for '__arm64_compat_sys_io_pgetevents_time32' [-Wmissing-prototypes] 41 | asmlinkage long __weak __arm64_compat_sys_##name(const struct pt_regs *regs) \ | ^~~ kernel/sys_ni.c:49:1: note: in expansion of macro 'COND_SYSCALL_COMPAT' 49 | COND_SYSCALL_COMPAT(io_pgetevents_time32); | ^~~ arch/arm64/include/asm/syscall_wrapper.h:41:25: warning: no previous prototype for '__arm64_compat_sys_io_pgetevents' [-Wmissing-prototypes] 41 | asmlinkage long __weak __arm64_compat_sys_##name(const struct pt_regs *regs) \ | ^~~ kernel/sys_ni.c:50:1: note: in expansion of macro 'COND_SYSCALL_COMPAT' 50 | COND_SYSCALL_COMPAT(io_pgetevents); | ^~~ arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous prototype for '__arm64_sys_io_uring_setup' [-Wmissing-prototypes] 76 | asmlinkage long __weak __arm64_sys_##name(const struct pt_regs *regs) \ | ^~~~ kernel/sys_ni.c:51:1: note: in expansion of macro 'COND_SYSCALL' 51 | COND_SYSCALL(io_uring_setup); | ^~~~ arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous prototype for '__arm64_sys_io_uring_enter' [-Wmissing-prototypes] 76 | asmlinkage long __weak __arm64_sys_##name(const struct pt_regs *regs) \ | ^~~~ kernel/sys_ni.c:52:1: note: in expansion of macro 'COND_SYSCALL' 52 | COND_SYSCALL(io_uring_enter); | ^~~~ arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous prototype for '__arm64_sys_io_uring_register' [-Wmissing-prototypes] 76 | asmlinkage long __weak __arm64_sys_##name(const struct pt_regs *regs) \ | ^~~~ kernel/sys_ni.c:53:1: note: in expansion of macro 'COND_SYSCALL' 53 | COND_SYSCALL(io_uring_register); | ^~~~ arch/arm64/include/asm/syscall_wrapper.h:76:25: warning: no previous prototype for '__arm64_sys_lookup_dcookie' [-Wmissing-prototypes] 76 | asmlinkage long __weak __arm64_sys_##name(const struct pt_regs *regs) \ | ^~~~ kernel/sys_ni.c:60:1: note: in expansion of macro 'COND_SYSCALL'
[PATCH v6 05/16] firmware: stratix10-svc: fix kernel-doc markups
There are some common comments marked, instead, with kernel-doc notation, which won't work. While here, rename an identifier, in order to match the function prototype below kernel-doc markup. Acked-by: Richard Gong Signed-off-by: Mauro Carvalho Chehab --- include/linux/firmware/intel/stratix10-svc-client.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/linux/firmware/intel/stratix10-svc-client.h b/include/linux/firmware/intel/stratix10-svc-client.h index a93d85932eb9..ebc295647581 100644 --- a/include/linux/firmware/intel/stratix10-svc-client.h +++ b/include/linux/firmware/intel/stratix10-svc-client.h @@ -6,7 +6,7 @@ #ifndef __STRATIX10_SVC_CLIENT_H #define __STRATIX10_SVC_CLIENT_H -/** +/* * Service layer driver supports client names * * fpga: for FPGA configuration @@ -15,7 +15,7 @@ #define SVC_CLIENT_FPGA"fpga" #define SVC_CLIENT_RSU "rsu" -/** +/* * Status of the sent command, in bit number * * SVC_STATUS_OK: @@ -50,7 +50,7 @@ #define SVC_STATUS_ERROR 5 #define SVC_STATUS_NO_SUPPORT 6 -/** +/* * Flag bit for COMMAND_RECONFIG * * COMMAND_RECONFIG_FLAG_PARTIAL: @@ -58,7 +58,7 @@ */ #define COMMAND_RECONFIG_FLAG_PARTIAL 1 -/** +/* * Timeout settings for service clients: * timeout value used in Stratix10 FPGA manager driver. * timeout value used in RSU driver @@ -218,7 +218,7 @@ void stratix10_svc_free_memory(struct stratix10_svc_chan *chan, void *kaddr); int stratix10_svc_send(struct stratix10_svc_chan *chan, void *msg); /** - * intel_svc_done() - complete service request + * stratix10_svc_done() - complete service request * @chan: service channel assigned to the client * * This function is used by service client to inform service layer that -- 2.29.2
[PATCH v6 09/16] w1: fix a kernel-doc markup
A function has a different name between their prototype and its kernel-doc markup. Signed-off-by: Mauro Carvalho Chehab --- include/linux/w1.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/w1.h b/include/linux/w1.h index 949d3b10e531..9a2a0ef39018 100644 --- a/include/linux/w1.h +++ b/include/linux/w1.h @@ -280,7 +280,7 @@ int w1_register_family(struct w1_family *family); void w1_unregister_family(struct w1_family *family); /** - * module_w1_driver() - Helper macro for registering a 1-Wire families + * module_w1_family() - Helper macro for registering a 1-Wire families * @__w1_family: w1_family struct * * Helper macro for 1-Wire families which do not do anything special in module -- 2.29.2
[PATCH v6 13/16] net: cfg80211: fix a kerneldoc markup
A function has a different name between their prototype
and its kernel-doc markup:
../include/net/cfg80211.h:1766: warning: expecting prototype for struct
cfg80211_sar_chan_ranges. Prototype was for struct cfg80211_sar_freq_ranges
instead
Signed-off-by: Mauro Carvalho Chehab
---
include/net/cfg80211.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 1b3954afcda4..0d6f7ec86061 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1756,7 +1756,7 @@ struct cfg80211_sar_specs {
/**
- * struct cfg80211_sar_chan_ranges - sar frequency ranges
+ * struct cfg80211_sar_freq_ranges - sar frequency ranges
* @start_freq: start range edge frequency
* @end_freq:end range edge frequency
*/
--
2.29.2
[PATCH v6 01/16] parport: fix a kernel-doc markup
The kernel-doc markup inside share.c is actually for __parport_register_driver. The actual goal seems to be to document parport_register_driver(). So, fix the existing markup and add a new one. Signed-off-by: Mauro Carvalho Chehab --- drivers/parport/share.c | 2 +- include/linux/parport.h | 31 +++ 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/drivers/parport/share.c b/drivers/parport/share.c index 7fec4fefe151..62f8407923d4 100644 --- a/drivers/parport/share.c +++ b/drivers/parport/share.c @@ -243,7 +243,7 @@ static int port_detect(struct device *dev, void *dev_drv) } /** - * parport_register_driver - register a parallel port device driver + * __parport_register_driver - register a parallel port device driver * @drv: structure describing the driver * @owner: owner module of drv * @mod_name: module name string diff --git a/include/linux/parport.h b/include/linux/parport.h index 1fb508c19e83..f981f794c850 100644 --- a/include/linux/parport.h +++ b/include/linux/parport.h @@ -297,6 +297,37 @@ int __must_check __parport_register_driver(struct parport_driver *, * parport_register_driver must be a macro so that KBUILD_MODNAME can * be expanded */ + +/** + * parport_register_driver - register a parallel port device driver + * @driver: structure describing the driver + * + * This can be called by a parallel port device driver in order + * to receive notifications about ports being found in the + * system, as well as ports no longer available. + * + * If devmodel is true then the new device model is used + * for registration. + * + * The @driver structure is allocated by the caller and must not be + * deallocated until after calling parport_unregister_driver(). + * + * If using the non device model: + * The driver's attach() function may block. The port that + * attach() is given will be valid for the duration of the + * callback, but if the driver wants to take a copy of the + * pointer it must call parport_get_port() to do so. Calling + * parport_register_device() on that port will do this for you. + * + * The driver's detach() function may block. The port that + * detach() is given will be valid for the duration of the + * callback, but if the driver wants to take a copy of the + * pointer it must call parport_get_port() to do so. + * + * + * Returns 0 on success. The non device model will always succeeds. + * but the new device model can fail and will return the error code. + **/ #define parport_register_driver(driver) \ __parport_register_driver(driver, THIS_MODULE, KBUILD_MODNAME) -- 2.29.2
Re: [PATCH v2 1/2] rtc: pcf2127: Disable Power-On Reset Override
On Wed, Jan 13, 2021 at 12:27:41PM +0100, Philipp Rosenberger wrote:
> To resume normal operation after a total power loss (no or empty
> battery) the "Power-On Reset Override (PORO)" facility needs to be
> disabled.
>
> As the oscillator may take a long time (200 ms to 2 s) to resume normal
> operation. The default behaviour is to use the PORO facility.
I'd write instead: The register reset value sets PORO enabled and the
data sheet recommends setting it to disabled for normal operation.
In my eyes having a reset default value that is unsuitable for
production use is just another bad design choice of this chip. At least
now this is known and can be somewhat fixed in software. :-\
> But with the PORO active no interrupts are generated on the interrupt
> pin (INT).
This sentence about no interrupts is your observation, or does this base
on some authoritative source (datasheet, FAE or similar)?
> Signed-off-by: Philipp Rosenberger
> ---
> drivers/rtc/rtc-pcf2127.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
> index 39a7b5116aa4..378b1ce812d6 100644
> --- a/drivers/rtc/rtc-pcf2127.c
> +++ b/drivers/rtc/rtc-pcf2127.c
> @@ -26,6 +26,7 @@
>
> /* Control register 1 */
> #define PCF2127_REG_CTRL10x00
> +#define PCF2127_BIT_CTRL1_POR_OVRD BIT(3)
> #define PCF2127_BIT_CTRL1_TSF1 BIT(4)
> /* Control register 2 */
> #define PCF2127_REG_CTRL20x01
> @@ -612,6 +613,23 @@ static int pcf2127_probe(struct device *dev, struct
> regmap *regmap,
> ret = devm_rtc_nvmem_register(pcf2127->rtc, &nvmem_cfg);
> }
>
> + /*
> + * The "Power-On Reset Override" facility prevents the RTC to do a reset
> + * after power on. For normal operation the PORO must be disabled.
> + */
> + regmap_clear_bits(pcf2127->regmap, PCF2127_REG_CTRL1,
> + PCF2127_BIT_CTRL1_POR_OVRD);
> + /*
> + * If the PORO can't be disabled, just move on. The RTC should
> + * work fine, but functions like watchdog and alarm interrupts might
> + * not work. There will be no interrupt generated on the interrupt pin.
> + */
> + ret = regmap_test_bits(pcf2127->regmap, PCF2127_REG_CTRL1,
> PCF2127_BIT_CTRL1_POR_OVRD);
> + if (ret <= 0) {
> + dev_err(dev, "%s: can't disable PORO (ctrl1).\n", __func__);
> + dev_warn(dev, "Watchdog and alarm functions might not work
> properly\n");
I would not emit two messages here. Also including __func__ isn't so
nice IMHO. (Great for debugging, but not in production code IMHO.)
We should consider a Cc: to stable.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
[PATCH v6 11/16] scripts: kernel-doc: validate kernel-doc markup with the actual names
Kernel-doc currently expects that the kernel-doc markup to come
just before the function/enum/struct/union/typedef prototype.
Yet, if it find things like:
/**
* refcount_add - add a value to a refcount
* @i: the value to add to the refcount
* @r: the refcount
*/
static inline void __refcount_add(int i, refcount_t *r, int *oldp);
static inline void refcount_add(int i, refcount_t *r);
Kernel-doc will do the wrong thing:
foobar.h:6: warning: Function parameter or member 'oldp' not described
in '__refcount_add'
.. c:function:: void __refcount_add (int i, refcount_t *r, int *oldp)
add a value to a refcount
**Parameters**
``int i``
the value to add to the refcount
``refcount_t *r``
the refcount
``int *oldp``
*undescribed*
Basically, it will document "__refcount_add" with the kernel-doc
markup for refcount_add.
If both functions have the same arguments, this won't even
produce any warning!
Add a logic to check if the kernel-doc identifier matches the actual
name of the C function or data structure that will be documented.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/kernel-doc | 62 ++
1 file changed, 46 insertions(+), 16 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 6325bec3f66f..a9a92e623dbc 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -382,6 +382,9 @@ my $inline_doc_state;
# 'function', 'struct', 'union', 'enum', 'typedef'
my $decl_type;
+# Name of the kernel-doc identifier for non-DOC markups
+my $identifier;
+
my $doc_start = '^/\*\*\s*$'; # Allow whitespace at end of comment start.
my $doc_end = '\*/';
my $doc_com = '\s*\*\s*';
@@ -1203,6 +1206,11 @@ sub dump_struct($$) {
$declaration_name = $2;
my $members = $3;
+ if ($identifier ne $declaration_name) {
+ print STDERR "${file}:$.: warning: expecting prototype for
$decl_type $identifier. Prototype was for $decl_type $declaration_name
instead\n";
+ return;
+ }
+
# ignore members marked private:
$members =~ s/\/\*\s*private:.*?\/\*\s*public:.*?\*\///gosi;
$members =~ s/\/\*\s*private:.*//gosi;
@@ -1391,6 +1399,11 @@ sub dump_enum($$) {
}
if ($members) {
+ if ($identifier ne $declaration_name) {
+ print STDERR "${file}:$.: warning: expecting prototype for enum
$identifier. Prototype was for enum $declaration_name instead\n";
+ return;
+ }
+
my %_members;
$members =~ s/\s+$//;
@@ -1451,6 +1464,11 @@ sub dump_typedef($$) {
my $args = $3;
$return_type =~ s/^\s+//;
+ if ($identifier ne $declaration_name) {
+ print STDERR "${file}:$.: warning: expecting prototype for typedef
$identifier. Prototype was for typedef $declaration_name instead\n";
+ return;
+ }
+
create_parameterlist($args, ',', $file, $declaration_name);
output_declaration($declaration_name,
@@ -1477,6 +1495,11 @@ sub dump_typedef($$) {
if ($x =~ /typedef.*\s+(\w+)\s*;/) {
$declaration_name = $1;
+ if ($identifier ne $declaration_name) {
+ print STDERR "${file}:$.: warning: expecting prototype for typedef
$identifier. Prototype was for typedef $declaration_name instead\n";
+ return;
+ }
+
output_declaration($declaration_name,
'typedef',
{'typedef' => $declaration_name,
@@ -1796,6 +1819,11 @@ sub dump_function($$) {
return;
}
+if ($identifier ne $declaration_name) {
+ print STDERR "${file}:$.: warning: expecting prototype for
$identifier(). Prototype was for $declaration_name() instead\n";
+ return;
+}
+
my $prms = join " ", @parameterlist;
check_sections($file, $declaration_name, "function", $sectcheck, $prms);
@@ -1878,6 +1906,7 @@ sub tracepoint_munge($) {
"$prototype\n";
} else {
$prototype = "static inline void
trace_$tracepointname($tracepointargs)";
+ $identifier = "trace_$identifier";
}
}
@@ -2041,7 +2070,6 @@ sub process_normal() {
#
sub process_name($$) {
my $file = shift;
-my $identifier;
my $descr;
if (/$doc_block/o) {
@@ -2054,12 +2082,19 @@ sub process_name($$) {
} else {
$section = $1;
}
-}
-elsif (/$doc_decl/o) {
+} elsif (/$doc_decl/o) {
$identifier = $1;
- if (/\s*([\w\s]+?)(\(\))?\s*-/) {
+ if (/\s*([\w\s]+?)(\(\))?\s*([-:].*)?$/) {
$identifier = $1;
}
+ if ($identifier =~ m/^(struct|union|enum|typedef)\b\s*(\S*)/) {
+ $decl_type = $1;
+ $identifier = $2;
+ } else {
+ $decl_type = 'function';
+ $identifier =~ s/^define\s+//;
+ }
+
[PATCH v6 00/16] Fix several bad kernel-doc markups
Hi Jon, This series have three parts: 1) 10 remaining fixup patches from the series I sent back on Dec, 1st: parport: fix a kernel-doc markup rapidio: fix kernel-doc a markup fs: fix kernel-doc markups pstore/zone: fix a kernel-doc markup firmware: stratix10-svc: fix kernel-doc markups connector: fix a kernel-doc markup lib/crc7: fix a kernel-doc markup memblock: fix kernel-doc markups w1: fix a kernel-doc markup selftests: kselftest_harness.h: partially fix kernel-doc markups 2) The patch adding the new check to ensure that the kernel-doc markup will be used for the right declaration; 3) 5 additional patches, produced against next-20210114 with new problems detected after the original series: net: tip: fix a couple kernel-doc markups net: cfg80211: fix a kerneldoc markup reset: core: fix a kernel-doc markup drm: drm_crc: fix a kernel-doc markup platform/surface: aggregator: fix a kernel-doc markup It probably makes sense to merge at least the first 11 patches via the doc tree, as they should apply cleanly there, and having the last 5 patches merged via each maintainer's tree. - Kernel-doc has always be limited to a probably bad documented rule: The kernel-doc markups should appear *imediatelly before* the function or data structure that it documents. On other words, if a C file would contain something like this: /** * foo - function foo * @args: foo args */ static inline void bar(int args); /** * bar - function bar * @args: foo args */ static inline void foo(void *args); The output (in ReST format) will be: .. c:function:: void bar (int args) function foo **Parameters** ``int args`` foo args .. c:function:: void foo (void *args) function bar **Parameters** ``void *args`` foo args Which is clearly a wrong result. Before this changeset, not even a warning is produced on such cases. As placing such markups just before the documented data is a common practice, on most cases this is fine. However, as patches touch things, identifiers may be renamed, and people may forget to update the kernel-doc markups to follow such changes. This has been happening for quite a while, as there are lots of files with kernel-doc problems. This series address those issues and add a file at the end that will enforce that the identifier will match the kernel-doc markup, avoiding this problem from keep happening as time goes by. This series is based on current upstream tree. @maintainers: feel free to pick the patches and apply them directly on your trees, as all patches on this series are independent from the other ones. -- v6: - rebased on the top of next-20210114 and added a few extra fixes v5: - The completion.h patch was replaced by another one which drops an obsolete macro; - Some typos got fixed and review tags got added; - Dropped patches that were already merged at linux-next. v4: - Patches got rebased and got some acks. Mauro Carvalho Chehab (16): parport: fix a kernel-doc markup rapidio: fix kernel-doc a markup fs: fix kernel-doc markups pstore/zone: fix a kernel-doc markup firmware: stratix10-svc: fix kernel-doc markups connector: fix a kernel-doc markup lib/crc7: fix a kernel-doc markup memblock: fix kernel-doc markups w1: fix a kernel-doc markup selftests: kselftest_harness.h: partially fix kernel-doc markups scripts: kernel-doc: validate kernel-doc markup with the actual names net: tip: fix a couple kernel-doc markups net: cfg80211: fix a kerneldoc markup reset: core: fix a kernel-doc markup drm: drm_crc: fix a kernel-doc markup platform/surface: aggregator: fix a kernel-doc markup drivers/parport/share.c | 2 +- .../surface/aggregator/ssh_request_layer.c| 2 +- drivers/rapidio/rio.c | 2 +- drivers/reset/core.c | 4 +- fs/dcache.c | 73 ++- fs/inode.c| 4 +- fs/pstore/zone.c | 2 +- fs/seq_file.c | 5 +- fs/super.c| 12 +-- include/drm/drm_crtc.h| 2 +- include/linux/connector.h | 2 +- .../firmware/intel/stratix10-svc-client.h | 10 +-- include/linux/memblock.h | 4 +- include/linux/parport.h | 31 include/linux/w1.h| 2 +- include/net/cfg80211.h| 2 +- lib/crc7.c| 2 +- net/tipc/link.c | 2 +- net/tipc/node.c | 2 +- scripts/kernel-doc| 62 tools/te
[PATCH v6 15/16] drm: drm_crc: fix a kernel-doc markup
A function has a different name between their prototype and its kernel-doc markup: ../include/drm/drm_crtc.h:1257: warning: expecting prototype for drm_crtc_alloc_with_planes(). Prototype was for drmm_crtc_alloc_with_planes() instead Signed-off-by: Mauro Carvalho Chehab --- include/drm/drm_crtc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 540e2e43ec93..13eeba2a750a 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -1232,7 +1232,7 @@ void *__drmm_crtc_alloc_with_planes(struct drm_device *dev, const char *name, ...); /** - * drm_crtc_alloc_with_planes - Allocate and initialize a new CRTC object with + * drmm_crtc_alloc_with_planes - Allocate and initialize a new CRTC object with *specified primary and cursor planes. * @dev: DRM device * @type: the type of the struct which contains struct &drm_crtc -- 2.29.2
[PATCH v6 07/16] lib/crc7: fix a kernel-doc markup
A function has a different name between their prototype
and its kernel-doc markup.
Signed-off-by: Mauro Carvalho Chehab
---
lib/crc7.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/crc7.c b/lib/crc7.c
index 6a848d73e804..3848e313b722 100644
--- a/lib/crc7.c
+++ b/lib/crc7.c
@@ -51,7 +51,7 @@ const u8 crc7_be_syndrome_table[256] = {
EXPORT_SYMBOL(crc7_be_syndrome_table);
/**
- * crc7 - update the CRC7 for the data buffer
+ * crc7_be - update the CRC7 for the data buffer
* @crc: previous CRC7 value
* @buffer: data pointer
* @len: number of bytes in the buffer
--
2.29.2
[PATCH v6 08/16] memblock: fix kernel-doc markups
Some identifiers have different names between their prototypes and the kernel-doc markup. Acked-by: Mike Rapoport Signed-off-by: Mauro Carvalho Chehab --- include/linux/memblock.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/memblock.h b/include/linux/memblock.h index b93c44b9121e..9cc6da7b513e 100644 --- a/include/linux/memblock.h +++ b/include/linux/memblock.h @@ -272,7 +272,7 @@ void __next_mem_pfn_range_in_zone(u64 *idx, struct zone *zone, unsigned long *out_spfn, unsigned long *out_epfn); /** - * for_each_free_mem_range_in_zone - iterate through zone specific free + * for_each_free_mem_pfn_range_in_zone - iterate through zone specific free * memblock areas * @i: u64 used as loop variable * @zone: zone in which all of the memory blocks reside @@ -292,7 +292,7 @@ void __next_mem_pfn_range_in_zone(u64 *idx, struct zone *zone, __next_mem_pfn_range_in_zone(&i, zone, p_start, p_end)) /** - * for_each_free_mem_range_in_zone_from - iterate through zone specific + * for_each_free_mem_pfn_range_in_zone_from - iterate through zone specific * free memblock areas from a given point * @i: u64 used as loop variable * @zone: zone in which all of the memory blocks reside -- 2.29.2
[PATCH v6 16/16] platform/surface: aggregator: fix a kernel-doc markup
A function has a different name between their prototype and its kernel-doc markup: ../drivers/platform/surface/aggregator/ssh_request_layer.c:1065: warning: expecting prototype for ssh_rtl_tx_start(). Prototype was for ssh_rtl_start() instead Signed-off-by: Mauro Carvalho Chehab --- drivers/platform/surface/aggregator/ssh_request_layer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/surface/aggregator/ssh_request_layer.c b/drivers/platform/surface/aggregator/ssh_request_layer.c index bb1c862411a2..25db4d638cfa 100644 --- a/drivers/platform/surface/aggregator/ssh_request_layer.c +++ b/drivers/platform/surface/aggregator/ssh_request_layer.c @@ -1056,7 +1056,7 @@ void ssh_rtl_destroy(struct ssh_rtl *rtl) } /** - * ssh_rtl_tx_start() - Start request transmitter and receiver. + * ssh_rtl_start() - Start request transmitter and receiver. * @rtl: The request transport layer. * * Return: Returns zero on success, a negative error code on failure. -- 2.29.2
Re: [PATCH v2 2/2] rtc: pcf2127: Run a OTP refresh if not done before
On Wed, Jan 13, 2021 at 12:27:42PM +0100, Philipp Rosenberger wrote:
> The datasheet of the PCF2127 states,it is recommended to process an OTP
s/,/, /
> refresh once the power is up and the oscillator is operating stable. The
> OTP refresh takes less than 100 ms to complete.
>
> Signed-off-by: Philipp Rosenberger
> ---
> drivers/rtc/rtc-pcf2127.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
> index 378b1ce812d6..ca56dba64e79 100644
> --- a/drivers/rtc/rtc-pcf2127.c
> +++ b/drivers/rtc/rtc-pcf2127.c
> @@ -58,6 +58,9 @@
> #define PCF2127_REG_ALARM_DM 0x0D
> #define PCF2127_REG_ALARM_DW 0x0E
> #define PCF2127_BIT_ALARM_AE BIT(7)
> +/* CLKOUT control register */
> +#define PCF2127_REG_CLKOUT 0x0f
> +#define PCF2127_BIT_CLKOUT_OTPR BIT(5)
> /* Watchdog registers */
> #define PCF2127_REG_WD_CTL 0x10
> #define PCF2127_BIT_WD_CTL_TF0 BIT(0)
> @@ -630,6 +633,19 @@ static int pcf2127_probe(struct device *dev, struct
> regmap *regmap,
> dev_warn(dev, "Watchdog and alarm functions might not work
> properly\n");
> }
>
> + /*
> + * Set the OTP refresh bit unconditionally. If an OTP refresh was
> + * already done the bit is already set and will not rerun the refresh
> + * operation.
> + */
> + ret = regmap_set_bits(pcf2127->regmap, PCF2127_REG_CLKOUT,
> + PCF2127_BIT_CLKOUT_OTPR);
> + if (ret < 0) {
> + dev_err(dev, "%s: OTP refresh (clkout_ctrl) failed.\n",
> __func__);
> + return ret;
> + }
> + msleep(100);
This unconditional sleep isn't so nice. Maybe it makes sense to only do
this when the chip reports a power loss?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
[PATCH v6 10/16] selftests: kselftest_harness.h: partially fix kernel-doc markups
The kernel-doc markups on this file are weird: they don't follow what's specified at: Documentation/doc-guide/kernel-doc.rst In particular, markups should use this format: identifier - description and not this: identifier(args) The way the definitions are inside this file cause the parser to completely miss the identifier name of each function. This prevents improving the script to do some needed validation tests. Address this part. Yet, furter changes are needed in order for it to fully follow the specs. Acked-by: Kees Cook Signed-off-by: Mauro Carvalho Chehab --- tools/testing/selftests/kselftest_harness.h | 26 - 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/tools/testing/selftests/kselftest_harness.h b/tools/testing/selftests/kselftest_harness.h index edce85420d19..ae0f0f33b2a6 100644 --- a/tools/testing/selftests/kselftest_harness.h +++ b/tools/testing/selftests/kselftest_harness.h @@ -79,7 +79,7 @@ #endif /** - * TH_LOG(fmt, ...) + * TH_LOG() * * @fmt: format string * @...: optional arguments @@ -113,12 +113,16 @@ __FILE__, __LINE__, _metadata->name, ##__VA_ARGS__) /** - * SKIP(statement, fmt, ...) + * SKIP() * * @statement: statement to run after reporting SKIP * @fmt: format string * @...: optional arguments * + * .. code-block:: c + * + * SKIP(statement, fmt, ...); + * * This forces a "pass" after reporting why something is being skipped * and runs "statement", which is usually "return" or "goto skip". */ @@ -136,7 +140,7 @@ } while (0) /** - * TEST(test_name) - Defines the test function and creates the registration + * TEST() - Defines the test function and creates the registration * stub * * @test_name: test name @@ -155,7 +159,7 @@ #define TEST(test_name) __TEST_IMPL(test_name, -1) /** - * TEST_SIGNAL(test_name, signal) + * TEST_SIGNAL() * * @test_name: test name * @signal: signal number @@ -195,7 +199,7 @@ struct __test_metadata __attribute__((unused)) *_metadata) /** - * FIXTURE_DATA(datatype_name) - Wraps the struct name so we have one less + * FIXTURE_DATA() - Wraps the struct name so we have one less * argument to pass around * * @datatype_name: datatype name @@ -212,7 +216,7 @@ #define FIXTURE_DATA(datatype_name) struct _test_data_##datatype_name /** - * FIXTURE(fixture_name) - Called once per fixture to setup the data and + * FIXTURE() - Called once per fixture to setup the data and * register * * @fixture_name: fixture name @@ -239,7 +243,7 @@ FIXTURE_DATA(fixture_name) /** - * FIXTURE_SETUP(fixture_name) - Prepares the setup function for the fixture. + * FIXTURE_SETUP() - Prepares the setup function for the fixture. * *_metadata* is included so that EXPECT_* and ASSERT_* work correctly. * * @fixture_name: fixture name @@ -265,7 +269,7 @@ __attribute__((unused)) *variant) /** - * FIXTURE_TEARDOWN(fixture_name) + * FIXTURE_TEARDOWN() * *_metadata* is included so that EXPECT_* and ASSERT_* work correctly. * * @fixture_name: fixture name @@ -286,7 +290,7 @@ FIXTURE_DATA(fixture_name) __attribute__((unused)) *self) /** - * FIXTURE_VARIANT(fixture_name) - Optionally called once per fixture + * FIXTURE_VARIANT() - Optionally called once per fixture * to declare fixture variant * * @fixture_name: fixture name @@ -305,7 +309,7 @@ #define FIXTURE_VARIANT(fixture_name) struct _fixture_variant_##fixture_name /** - * FIXTURE_VARIANT_ADD(fixture_name, variant_name) - Called once per fixture + * FIXTURE_VARIANT_ADD() - Called once per fixture * variant to setup and register the data * * @fixture_name: fixture name @@ -339,7 +343,7 @@ _##fixture_name##_##variant_name##_variant = /** - * TEST_F(fixture_name, test_name) - Emits test registration and helpers for + * TEST_F() - Emits test registration and helpers for * fixture-based test cases * * @fixture_name: fixture name -- 2.29.2
Re: [PATCH v6 15/16] drm: drm_crc: fix a kernel-doc markup
On Thursday, January 14th, 2021 at 9:04 AM, Mauro Carvalho Chehab wrote: > A function has a different name between their prototype > and its kernel-doc markup: > > ../include/drm/drm_crtc.h:1257: warning: expecting prototype for > drm_crtc_alloc_with_planes(). Prototype was for drmm_crtc_alloc_with_planes() > instead > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Simon Ser
[PATCH v6 12/16] net: tip: fix a couple kernel-doc markups
A function has a different name between their prototype and its kernel-doc markup: ../net/tipc/link.c:2551: warning: expecting prototype for link_reset_stats(). Prototype was for tipc_link_reset_stats() instead ../net/tipc/node.c:1678: warning: expecting prototype for is the general link level function for message sending(). Prototype was for tipc_node_xmit() instead Signed-off-by: Mauro Carvalho Chehab --- net/tipc/link.c | 2 +- net/tipc/node.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/tipc/link.c b/net/tipc/link.c index a6a694b78927..115109259430 100644 --- a/net/tipc/link.c +++ b/net/tipc/link.c @@ -2544,7 +2544,7 @@ void tipc_link_set_queue_limits(struct tipc_link *l, u32 min_win, u32 max_win) } /** - * link_reset_stats - reset link statistics + * tipc_link_reset_stats - reset link statistics * @l: pointer to link */ void tipc_link_reset_stats(struct tipc_link *l) diff --git a/net/tipc/node.c b/net/tipc/node.c index 83d9eb830592..008670d1f43e 100644 --- a/net/tipc/node.c +++ b/net/tipc/node.c @@ -1665,7 +1665,7 @@ static void tipc_lxc_xmit(struct net *peer_net, struct sk_buff_head *list) } /** - * tipc_node_xmit() is the general link level function for message sending + * tipc_node_xmit() - general link level function for message sending * @net: the applicable net namespace * @list: chain of buffers containing message * @dnode: address of destination node -- 2.29.2
[PATCH v6 14/16] reset: core: fix a kernel-doc markup
A function has a different name between their prototype and its kernel-doc markup: ../drivers/reset/core.c:888: warning: expecting prototype for device_reset(). Prototype was for __device_reset() instead Signed-off-by: Mauro Carvalho Chehab --- drivers/reset/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/reset/core.c b/drivers/reset/core.c index 34e89aa0fb5e..dbf881b586d9 100644 --- a/drivers/reset/core.c +++ b/drivers/reset/core.c @@ -875,8 +875,8 @@ struct reset_control *__devm_reset_control_get(struct device *dev, EXPORT_SYMBOL_GPL(__devm_reset_control_get); /** - * device_reset - find reset controller associated with the device - *and perform reset + * __device_reset - find reset controller associated with the device + * and perform reset * @dev: device to be reset by the controller * @optional: whether it is optional to reset the device * -- 2.29.2
[PATCH] udf: fix the problem that the disc content is not displayed
When the capacity of the disc is too large (assuming the 4.7G
specification), the disc (UDF file system) will be burned
multiple times in the windows (Multisession Usage). When the
remaining capacity of the CD is less than 300M (estimated
value, for reference only), open the CD in the Linux system,
the content of the CD is displayed as blank (the kernel will
say "No VRS found"). Windows can display the contents of the
CD normally.
Through analysis, in the "fs/udf/super.c": udf_check_vsd
function, the actual value of VSD_MAX_SECTOR_OFFSET may
be much larger than 0x80. According to the current code
logic, it is found that the type of sbi->s_session is "__s32",
when the remaining capacity of the disc is less than 300M
(take a set of test values: sector=3154903040,
sbi->s_session=1540464, sb->s_blocksize_bits=11 ), the
calculation result of "sbi->s_session << sb->s_blocksize_bits"
will overflow. Therefore, it is necessary to convert the
type of s_session to "loff_t" (when udf_check_vsd starts,
assign a value to _sector, which is also converted in this
way), so that the result will not overflow, and then the
content of the disc can be displayed normally.
Signed-off-by: lianzhi chang
---
fs/udf/super.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 5bef3a68395d..f2ff98f393fb 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -705,6 +705,7 @@ static int udf_check_vsd(struct super_block *sb)
struct buffer_head *bh = NULL;
int nsr = 0;
struct udf_sb_info *sbi;
+ loff_t sector_offset;
sbi = UDF_SB(sb);
if (sb->s_blocksize < sizeof(struct volStructDesc))
@@ -712,7 +713,8 @@ static int udf_check_vsd(struct super_block *sb)
else
sectorsize = sb->s_blocksize;
- sector += (((loff_t)sbi->s_session) << sb->s_blocksize_bits);
+ sector_offset = (loff_t)sbi->s_session << sb->s_blocksize_bits);
+ sector += sector_offset;
udf_debug("Starting at sector %u (%lu byte sectors)\n",
(unsigned int)(sector >> sb->s_blocksize_bits),
@@ -757,8 +759,7 @@ static int udf_check_vsd(struct super_block *sb)
if (nsr > 0)
return 1;
- else if (!bh && sector - (sbi->s_session << sb->s_blocksize_bits) ==
- VSD_FIRST_SECTOR_OFFSET)
+ else if (!bh && sector - sector_offset == VSD_FIRST_SECTOR_OFFSET)
return -1;
else
return 0;
--
2.20.1
Re: [PATCH v6 5/5] media: i2c: max9286: Configure reverse channel amplitude
Hi Laurent,
On Thu, Jan 14, 2021 at 07:53:36AM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> >
> > All in all:
> > - yes, I think there might be a need to control the noise immunity
> > settings after initialization
> > - I think it should be done on the serializer side, possibly with a DT
> > property, possibly something like a boolean 'maxim,high-threshold-enable'
> > - the deserializer can query that information with a kAPI like
> > get_mbus_config() after the remote has probed
> > - Because of that there is no need for an additional deserializer property
> >
> > Hope this makes sense
>
> Now I get what you meant. Sorry for missing the point.
>
> While it would be technically feasible to query the property from the
> serializer at runtime, there's the additional issue that the
> deserializer has a single reverse channel amplitude setting for all the
> channels. We would need to ensure that the property is set to the same
> value in all camera DT nodes. Wouldn't it be best to then set it once
> only, in the deserializer node ?
>
To be honest I wouldn't mind a run-time error, or a fallback like "the
first one to probe is the authoritative one, the rest have to follow".
And don't forget we would need a serializer property anyway to tell
the chip if it has to enable its noise immunity threshold or not.
But anyway, the here introduced new property already requires
knwoledge on the deserializer about which camera is connected on the
other side. It's not so bad, as if cameras are described in a .dtsi or
.dtbo the deserializer property can be overridden. We can do the same
for an additional property.
ie. a deserializer-serializer 'maxim,high-threshold-enable' property
RDACM20: pre-programmed high threshold enable
-- rdacm20.dtsi ---
&gmsl {
maxim,reverse-channel-microvolt = <17>;
i2c-mux {
i2c@0 {
camera@51 {
}
}
}
};
-
RDACM21: no pre-programmed high-threshold, high threshold enabled
after camera probe
-- rdacm21.dtsi ---
&gmsl {
maxim,reverse-channel-microvolt = <10>;
maxim,high-threshold-enable;
i2c-mux {
i2c@0 {
camera@51 {
maxim,high-threshold-enable;
}
}
}
};
-
RDACM21: no high-threshold enabled at all
-- rdacm21.dtsi ---
&gmsl {
maxim,reverse-channel-microvolt = <10>;
i2c-mux {
i2c@0 {
camera@51 {
}
}
}
};
-
For the serializer it's a boolean, for the deser we might need to
specify a voltage, so it might become an uint32
'maxim,high-threshold-microvolt' there.
-- rdacm21.dtsi ---
&gmsl {
maxim,reverse-channel-microvolt = <10>;
maxim,high-threshold-microvolt = <17>;
i2c-mux {
i2c@0 {
camera@51 {
maxim,high-threshold-enable;
}
}
}
};
-
> --
> Regards,
>
> Laurent Pinchart
RE: [PATCH bpf-next v6 00/11] Atomics for eBPF
Brendan Jackman wrote: > Happy new year everyone, and thanks once again for the reviews. > > There's still one unresolved review comment from John[3] but I don't > think it needs to block the patchset as it stands, it can be a > separate patch. Hope that's OK. Its ok on my side if it comes as a follow up. I think it limits the use cases without it, but no reason to hold up the series IMO.
Re: [PATCH v5] drm/sun4i: tcon: fix inverted DCLK polarity
Hi Giulio,
You did a typo
Il 13/01/2021 17:05, Giulio Benetti ha scritto:
From: Giulio Benetti
During commit 88bc4178568b ("drm: Use new
DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_*
macros have been changed to avoid ambiguity but just because of this
ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning
_SAMPLE_ not _DRIVE_. This leads to DLCK inversion and need to fix but
instead of swapping phase values, let's adopt an easier approach Maxime
suggested:
It turned out that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to
invert DCLK polarity and this makes things really easier than before. So
let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE
as bit 26 and activating according to bus_flags the same way it is done
for all the other signals polarity.
Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE
flags")
Suggested-by: Maxime Ripard
Signed-off-by: Giulio Benetti
---
V2->V3:
- squash 2 patches into 1
V3->V4:
- add SUN4I_TCON0_IO_POL_DCLK_POSITIVE to regmap_update_bits()
V4->V5:
polarity is still wrong so:
- let's use SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE macro
instead of _DCLK_POSITIVE(that would make sense only in realtion with DCLK)
- invert condition using _NEGEDGE instead of _POSEDGE and then matching with
register bit SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE
- correct commit log according to V4->V5 changes
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 21 ++---
drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
2 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index eaaf5d70e352..c172ccfff7e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,30 +569,13 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
- /*
-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
- if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
- clk_set_phase(tcon->dclk, 240);
-
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
- clk_set_phase(tcon->dclk, 0);
+ val |= SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE;
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE |
Here Below you missed an 'E'
+ SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGDGE |
SUN4I_TCON0_IO_POL_DE_NEGATIVE,
val);
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index cfbf4e6c1679..c5ac1b02482c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -113,6 +113,7 @@
#define SUN4I_TCON0_IO_POL_REG0x88
#define SUN4I_TCON0_IO_POL_DCLK_PHASE(phase) ((phase & 3) << 28)
#define SUN4I_TCON0_IO_POL_DE_NEGATIVEBIT(27)
+#define SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE BIT(26)
#define SUN4I_TCON0_IO_POL_HSYNC_POSITIVE BIT(25)
#define SUN4I_TCON0_IO_POL_VSYNC_POSITIVE BIT(24)
Re: [PATCH v2] kbuild: check the minimum compiler version in Kconfig
On Thu, Jan 14, 2021 at 8:55 AM Ilie Halip wrote: > > Hi Masahiro, > > > + #elif defined(__INTEL_COMPILER) > > + /* How to get the version of intel compiler? */ > > + ICC 0 0 0 > > According to Intel documentation[1], this should do the trick: > > ICC __INTEL_COMPILER __INTEL_COMPILER_UPDATE > __INTEL_COMPILER_BUILD_DATE > > I don't have the compiler installed, but I tested this on godbolt[2] and > looks fine to me. What do you think? > I remember at university I used ICC successfully with building a Linux-kernel. Anyone has used ICC recently? I cannot remember to have seen any bug-reports regarding ICC to linux-kernel or linux-kbuild mailing-lists. - Sedat - > [1] > https://software.intel.com/content/www/us/en/develop/documentation/cpp-compiler-developer-guide-and-reference/top/compiler-reference/macros/additional-predefined-macros.html > [2] https://godbolt.org/z/E5PE6f > > I.H. > > -- > You received this message because you are subscribed to the Google Groups > "Clang Built Linux" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clang-built-linux+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clang-built-linux/CAHFW8PRr6kjEE%3D7BSzWo7itSZgAhy_dhmnSe1yq5wMfDwEyJ9g%40mail.gmail.com.
Re: [PATCH v1 1/1] time64.h: Consolidated PSEC_PER_SEC definition
On 14-01-21, 09:10, Andy Shevchenko wrote: > On Thursday, January 14, 2021, Jakub Kicinski wrote: > > > On Tue, 12 Jan 2021 17:37:09 +0200 Andy Shevchenko wrote: > > > We have currently three users of the PSEC_PER_SEC each of them defining > > it > > > individually. Instead, move it to time64.h to be available for everyone. > > > > > > There is a new user coming with the same constant in use. It will also > > > make its life easier. > > > > > > Signed-off-by: Andy Shevchenko > > > > Which tree will you send the new user to? I'm not sure who you're > > expecting to take this patch :S > > > I think PHY tree is the best candidate with providing an immutable branch > for others. Sure I can do that, I would wait for other folks to ack this Thanks -- ~Vinod
Re: [PATCH v5] drm/sun4i: tcon: fix inverted DCLK polarity
Hi Marjan,
On 1/14/21 8:58 AM, Marjan Pascolo wrote:
Hi Giulio,
You did a typo
Il 13/01/2021 17:05, Giulio Benetti ha scritto:
From: Giulio Benetti
During commit 88bc4178568b ("drm: Use new
DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_*
macros have been changed to avoid ambiguity but just because of this
ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning
_SAMPLE_ not _DRIVE_. This leads to DLCK inversion and need to fix but
instead of swapping phase values, let's adopt an easier approach Maxime
suggested:
It turned out that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to
invert DCLK polarity and this makes things really easier than before. So
let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE
as bit 26 and activating according to bus_flags the same way it is done
for all the other signals polarity.
Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE
flags")
Suggested-by: Maxime Ripard
Signed-off-by: Giulio Benetti
---
V2->V3:
- squash 2 patches into 1
V3->V4:
- add SUN4I_TCON0_IO_POL_DCLK_POSITIVE to regmap_update_bits()
V4->V5:
polarity is still wrong so:
- let's use SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE macro
instead of _DCLK_POSITIVE(that would make sense only in realtion with DCLK)
- invert condition using _NEGEDGE instead of _POSEDGE and then matching with
register bit SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE
- correct commit log according to V4->V5 changes
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 21 ++---
drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
2 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index eaaf5d70e352..c172ccfff7e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,30 +569,13 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
- /*
-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
- if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
- clk_set_phase(tcon->dclk, 240);
-
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
- clk_set_phase(tcon->dclk, 0);
+ val |= SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE;
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE |
Here Below you missed an 'E'
yes, thank you, going to send v6.
Best regards
--
Giulio Benetti
Benetti Engineering sas
+ SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGDGE |
SUN4I_TCON0_IO_POL_DE_NEGATIVE,
val);
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index cfbf4e6c1679..c5ac1b02482c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -113,6 +113,7 @@
#define SUN4I_TCON0_IO_POL_REG 0x88
#define SUN4I_TCON0_IO_POL_DCLK_PHASE(phase) ((phase & 3) << 28)
#define SUN4I_TCON0_IO_POL_DE_NEGATIVE BIT(27)
+#define SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE BIT(26)
#define SUN4I_TCON0_IO_POL_HSYNC_POSITIVEBIT(25)
#define SUN4I_TCON0_IO_POL_VSYNC_POSITIVEBIT(24)
[PATCH] watchdog: stop wdd when watchdog hw running in reboot_notifier
From: Zhao Qiang
In watchdog_reboot_notifier, wdd should be stopped when the device
is in hw_running state
Signed-off-by: Zhao Qiang
---
drivers/watchdog/watchdog_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index 861daf4..ec670cc 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -154,7 +154,7 @@ static int watchdog_reboot_notifier(struct notifier_block
*nb,
wdd = container_of(nb, struct watchdog_device, reboot_nb);
if (code == SYS_DOWN || code == SYS_HALT) {
- if (watchdog_active(wdd)) {
+ if (watchdog_active(wdd) || watchdog_hw_running(wdd)) {
int ret;
ret = wdd->ops->stop(wdd);
--
2.7.4
[PATCH v6] drm/sun4i: tcon: fix inverted DCLK polarity
From: Giulio Benetti
During commit 88bc4178568b ("drm: Use new
DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_*
macros have been changed to avoid ambiguity but just because of this
ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning
_SAMPLE_ not _DRIVE_. This leads to DLCK inversion and need to fix but
instead of swapping phase values, let's adopt an easier approach Maxime
suggested:
It turned out that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to
invert DCLK polarity and this makes things really easier than before. So
let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE
as bit 26 and activating according to bus_flags the same way it is done
for all the other signals polarity.
Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE
flags")
Suggested-by: Maxime Ripard
Signed-off-by: Giulio Benetti
---
V2->V3:
- squash 2 patches into 1
V3->V4:
- add SUN4I_TCON0_IO_POL_DCLK_POSITIVE to regmap_update_bits() as suggested by
Maxime
V4->V5:
polarity is still wrong so:
- let's use SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE macro
instead of _DCLK_POSITIVE(that would make sense only in realtion with DCLK)
- invert condition using _NEGEDGE instead of _POSEDGE and then matching with
register bit SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE
- correct commit log according to V4->V5 changes
V5->V6:
- fix typo in SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE as suggested by Marjan
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 21 ++---
drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
2 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index eaaf5d70e352..6b9af4c08cd6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -569,30 +569,13 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
if (info->bus_flags & DRM_BUS_FLAG_DE_LOW)
val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE;
- /*
-* On A20 and similar SoCs, the only way to achieve Positive Edge
-* (Rising Edge), is setting dclk clock phase to 2/3(240°).
-* By default TCON works in Negative Edge(Falling Edge),
-* this is why phase is set to 0 in that case.
-* Unfortunately there's no way to logically invert dclk through
-* IO_POL register.
-* The only acceptable way to work, triple checked with scope,
-* is using clock phase set to 0° for Negative Edge and set to 240°
-* for Positive Edge.
-* On A33 and similar SoCs there would be a 90° phase option,
-* but it divides also dclk by 2.
-* Following code is a way to avoid quirks all around TCON
-* and DOTCLOCK drivers.
-*/
- if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
- clk_set_phase(tcon->dclk, 240);
-
if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
- clk_set_phase(tcon->dclk, 0);
+ val |= SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE;
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE |
+ SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE |
SUN4I_TCON0_IO_POL_DE_NEGATIVE,
val);
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index cfbf4e6c1679..c5ac1b02482c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -113,6 +113,7 @@
#define SUN4I_TCON0_IO_POL_REG 0x88
#define SUN4I_TCON0_IO_POL_DCLK_PHASE(phase) ((phase & 3) << 28)
#define SUN4I_TCON0_IO_POL_DE_NEGATIVE BIT(27)
+#define SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE BIT(26)
#define SUN4I_TCON0_IO_POL_HSYNC_POSITIVE BIT(25)
#define SUN4I_TCON0_IO_POL_VSYNC_POSITIVE BIT(24)
--
2.25.1
Re: [PATCH] compiler.h: Raise minimum version of GCC to 5.1 for arm64
On Wed, 13 Jan 2021 at 23:09, Linus Torvalds wrote: > > On Wed, Jan 13, 2021 at 1:44 PM Russell King - ARM Linux admin > wrote: > > > > So, maybe the Sparc issue was just a similar but different bug in gcc > > 4.9.x. > > Good catch. And I know this bug has happened independently on > different architectures several times (I remember this on x86-64 as > well), so I started looking around. > > And in fact, 4.9 was buggy on x86-64 too: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 > > And yeah, _that_ gcc bug wasn't actually x86-64 specific, but > apparently a generic instruction scheduling bug. > > So it's an independent bug, but I do have to admit that the arguments > against 4.9 are piling up (even if that particular fix apparently got > fixed in the gcc branches and apparently backported to distro > compilers too). > So if the arguments are piling up, what is holding us back, other than inertia? RHEL 7 used to be a factor, but it ships with 4.8 not 4.9, so its users already need to upgrade. Is anyone aware of a good reason to keep 4.9 supported? Are any other long term supported distros using 4.9.x? I know that distros probably backported fixes for all of these issues, but without a way to interrogate the compiler about this, that doesn't really make a difference IMHO. Note that banning 4.9 for arm64 and banning it in general should be two different changes in any case, as the former will need to be backported to -stable kernels as well. -- Ard.
Re: Infinite recursion in device_reorder_to_tail() due to circular device links
Hi Peter,
On Thu, Jan 14, 2021 at 08:54:54AM +0800, Peter Chen wrote:
> On 21-01-13 12:18:35, Stephan Gerhold wrote:
> >
> > Also, on a completely different note I looked again at the chipidea USB
> > driver that produces this situation. To request the PHY (which ends up
> > in the circular device link) it does:
> >
> > /* Look for a generic PHY first */
> > ci->phy = devm_phy_get(dev->parent, "usb-phy");
> >
> > To me it doesn't really seem great to use the devm_* helpers on the
> > parent device either, so I will check if I can refactor this somehow.
> > Perhaps this situation can be prevented entirely.
> >
>
> You could try to get the PHY at parent driver
> (drivers/usb/chipidea/ci_hdrc_msm.c) to see the difference.
>
Unfortunately, I don't think this works in my case because I have an
ULPI PHY. It's not available until ret = ci_ulpi_init(ci); is called
from the ci_hdrc.0 platform device.
I tried the following diff yesterday. It prevents the circular device
link, therefore also the crash and even devm_* on the parent device:
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index aa40e510b806..79f556d0c93e 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -847,6 +847,8 @@ struct platform_device *ci_hdrc_add_device(struct device
*dev,
}
pdev->dev.parent = dev;
+ device_set_of_node_from_dev(&pdev->dev, dev);
+ pdev->driver_override = kstrdup("ci_hdrc", GFP_KERNEL);
ret = platform_device_add_resources(pdev, res, nres);
if (ret)
@@ -1027,7 +1029,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ci->usb_phy = ci->platdata->usb_phy;
} else {
/* Look for a generic PHY first */
- ci->phy = devm_phy_get(dev->parent, "usb-phy");
+ ci->phy = devm_phy_get(dev, "usb-phy");
if (PTR_ERR(ci->phy) == -EPROBE_DEFER) {
ret = -EPROBE_DEFER;
Basically my idea was to share the of_node with the ci_hdrc.0 platform
device, so that it can request the PHY itself instead of going through
the parent.
It seems to work fine but I had to add pdev->driver_override to prevent
the ci_hdrc.0 device from probing using ci_hdrc_msm (since it considers
the "compatible" value on the of_node otherwise).
This is a bit weird (I think driver_override is mainly intended to be
written through sysfs, not from kernel code directly).
That is why I did not post this as a proper patch yet...
Thanks,
Stephan
Re: [PATCH v7 4/7] dt-bindings: media: max9286: Document 'maxim,reverse-channel-microvolt'
Hello! On 13.01.2021 21:55, Jacopo Mondi wrote: Document the 'reverse-channel-microvolt' vendor property in the Where is "maxim,"? bindings document of the max9286 driver. The newly introduced property allows to specifying the initial Specify? configuration of the GMSL reverse control channel to accommodate remote serializers pre-programmed with the high threshold power supply noise immunity enabled. Reviewed-by: Rob Herring Reviewed-by: Laurent Pinchart Reviewed-by: Kieran Bingham Signed-off-by: Jacopo Mondi [...] MBR, Sergei
Re: [PATCH 0/3] arm64: cpufeature: Add filter function to control
On 2021-01-14 07:15, Srinivas Ramana wrote: Hi Marc, On 1/11/2021 5:40 AM, Marc Zyngier wrote: Hi Srinivas, On 2021-01-09 00:29, Srinivas Ramana wrote: This patchset adds a control function for cpufeature framework so that the feature can be controlled at runtime. Defer PAC on boot core and use the filter function added to disable PAC from command line. This will help toggling the feature on systems that do not support PAC or where PAC needs to be disabled at runtime, without modifying the core kernel. The idea of adding the filter function for cpufeature is taken from https://lore.kernel.org/linux-arm-kernel/20200515171612.1020-25-catalin.mari...@arm.com/ https://lore.kernel.org/linux-arm-kernel/20200515171612.1020-24-catalin.mari...@arm.com/ Srinivas Ramana (3): arm64: Defer enabling pointer authentication on boot core arm64: cpufeature: Add a filter function to cpufeature arm64: Enable control of pointer authentication using early param Documentation/admin-guide/kernel-parameters.txt | 6 +++ arch/arm64/include/asm/cpufeature.h | 8 +++- arch/arm64/include/asm/pointer_auth.h | 10 + arch/arm64/include/asm/stackprotector.h | 1 + arch/arm64/kernel/cpufeature.c | 53 +++-- arch/arm64/kernel/head.S | 4 -- 6 files changed, 64 insertions(+), 18 deletions(-) I've been working for some time on a similar series to allow a feature set to be disabled during the early boot phase, initially to prevent booting a kernel with VHE, but the mechanism is generic enough to deal with most architectural features. I took the liberty to lift your first patch and to add it to my series[1], further allowing PAuth to be disabled at boot time on top of BTI and VHE. I'd appreciate your comments on this. Thanks for sending this series. It seems to be more flexible compared you what we did. Following your discussion on allowing EXACT ftr_reg values. Btw, do you have plan to add MTE in similar lines to control the feature? We may be needing this on some systems. I don't have any need for this at the moment, as my initial goal was to enable a different boot flow for VHE. The BTI "support" was added as a way to demonstrate the use of __read_sysreg_by_encoding(), and your patches were a good opportunity to converge on a single solution. But if you write the patches that do that, I can add them to the series, and Catalin/Will can decide whether they want to take them. Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [RFC PATCH 0/5] running kernel mode SIMD with softirqs disabled
On Sat, 19 Dec 2020 at 03:05, Herbert Xu wrote: > > On Fri, Dec 18, 2020 at 06:01:01PM +0100, Ard Biesheuvel wrote: > > > > Questions: > > - what did I miss or break horribly? > > - does any of this matter for RT? AIUI, RT runs softirqs from a dedicated > > kthread, so I don't think it cares. > > - what would be a reasonable upper bound to keep softirqs disabled? I > > suppose > > 100s of cycles or less is overkill, but I'm not sure how to derive a > > better > > answer. > > - could we do the same on x86, now that kernel_fpu_begin/end is no longer > > expensive? > > If this approach works not only would it allow us to support the > synchronous users better, it would also allow us to remove loads > of cruft in the Crypto API that exist solely to support these SIMD > code paths. > > So I eagerly await the assessment of the scheduler/RT folks on this > approach. > Any insights here? Is there a ballpark upper bound for the duration of a softirq disabled section? Other reasons why dis/enabling softirq handling is a bad idea?
Re: [PATCH v6 14/16] reset: core: fix a kernel-doc markup
Hi Mauro, On Thu, 2021-01-14 at 09:04 +0100, Mauro Carvalho Chehab wrote: > A function has a different name between their prototype > and its kernel-doc markup: > > ../drivers/reset/core.c:888: warning: expecting prototype for > device_reset(). Prototype was for __device_reset() instead > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/reset/core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/reset/core.c b/drivers/reset/core.c > index 34e89aa0fb5e..dbf881b586d9 100644 > --- a/drivers/reset/core.c > +++ b/drivers/reset/core.c > @@ -875,8 +875,8 @@ struct reset_control *__devm_reset_control_get(struct > device *dev, > EXPORT_SYMBOL_GPL(__devm_reset_control_get); > > /** > - * device_reset - find reset controller associated with the device > - *and perform reset > + * __device_reset - find reset controller associated with the device > + * and perform reset > * @dev: device to be reset by the controller > * @optional: whether it is optional to reset the device > * Thank you, applied to reset/next. regards Philipp
[PATCH] ALSA: hda/realtek - Limit int mic boost on Acer Aspire E5-575T
The Acer Apire E5-575T laptop with codec ALC255 has a terrible
background noise comes from internal mic capture. And the jack
sensing dose not work for headset like some other Acer laptops.
This patch limits the internal mic boost on top of the existing
ALC255_FIXUP_ACER_MIC_NO_PRESENCE quirk for Acer Aspire E5-575T.
Signed-off-by: Chris Chiu
---
sound/pci/hda/patch_realtek.c | 8
1 file changed, 8 insertions(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 3c1d2a3fb1a4..60eb8383a704 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6371,6 +6371,7 @@ enum {
ALC256_FIXUP_HP_HEADSET_MIC,
ALC236_FIXUP_DELL_AIO_HEADSET_MIC,
ALC282_FIXUP_ACER_DISABLE_LINEOUT,
+ ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -7808,6 +7809,12 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE
},
+ [ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc269_fixup_limit_int_mic_boost,
+ .chained = true,
+ .chain_id = ALC255_FIXUP_ACER_MIC_NO_PRESENCE,
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7826,6 +7833,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x102b, "Acer Aspire C24-860",
ALC286_FIXUP_ACER_AIO_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1065, "Acer Aspire C20-820",
ALC269VC_FIXUP_ACER_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x106d, "Acer Cloudbook 14",
ALC283_FIXUP_CHROME_BOOK),
+ SND_PCI_QUIRK(0x1025, 0x1094, "Acer Aspire E5-575T",
ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST),
SND_PCI_QUIRK(0x1025, 0x1099, "Acer Aspire E5-523G",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x110e, "Acer Aspire ES1-432",
ALC255_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1166, "Acer Veriton N4640G",
ALC269_FIXUP_LIFEBOOK),
--
2.20.1
Re: [PATCH v2] software_node: Add kernel-doc comments to exported symbols
Hi Randy
On 13/01/2021 01:01, Randy Dunlap wrote:
> On 1/12/21 4:02 PM, Daniel Scally wrote:
>> A number of functions which are exported via EXPORT_SYMBOL_GPL() lack any
>> kernel-doc comments; add those in so all exported symbols are documented.
>>
>> Reviewed-by: Andy Shevchenko
>> Reviewed-by: Heikki Krogerus
>> Signed-off-by: Daniel Scally
>> ---
>> Changes in version 2:
>> - Replaced "fwnode_handle" with either @fwnode or natural language
>> reference to a firmware node handle as appropriate.
>>
>> drivers/base/swnode.c | 53 +++
>> 1 file changed, 53 insertions(+)
>>
>> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
>> index 4a4b2008fbc2..e98018aa8b2f 100644
>> --- a/drivers/base/swnode.c
>> +++ b/drivers/base/swnode.c
>> @@ -33,6 +33,13 @@ static struct kset *swnode_kset;
>>
>> static const struct fwnode_operations software_node_ops;
>>
>> +/**
>> + * is_software_node() - check if given fwnode was created from a
>> software_node
>> + * @fwnode: The &struct fwnode_handle to check
>> + *
>> + * This function is used to check whether a given firmware node handle was
>> + * created by registering a &struct software_node or not.
>> + */
>> bool is_software_node(const struct fwnode_handle *fwnode)
>> {
>> return !IS_ERR_OR_NULL(fwnode) && fwnode->ops == &software_node_ops;
>> @@ -71,6 +78,14 @@ software_node_to_swnode(const struct software_node *node)
>> return swnode;
>> }
>>
>> +/**
>> + * to_software_node() - Fetch software node associated with a firmware node
>> handle
>> + * @fwnode: The pointer to a &struct fwnode_handle to parse
>> + *
>> + * This function attempts to fetch a pointer to the &struct software_node
>> which
>> + * was used to create the given @fwnode. Note that this will only work if
>> the
>> + * software node has **not** been released.
>> + */
>> const struct software_node *to_software_node(const struct fwnode_handle
>> *fwnode)
>> {
>> const struct swnode *swnode = to_swnode(fwnode);
>> @@ -79,6 +94,14 @@ const struct software_node *to_software_node(const struct
>> fwnode_handle *fwnode)
>> }
>> EXPORT_SYMBOL_GPL(to_software_node);
>>
>> +/**
>> + * software_node_fwnode() - Fetch firmware node associated with a given
>> software node
>> + * @node: The pointer to a &struct software_node to parse
>> + *
>> + * This function attempts to fetch a pointer to the &struct fwnode_handle
>> which
>> + * was created from the given @node. Note that this will only work after the
>> + * software node has been registered.
>> + */
>> struct fwnode_handle *software_node_fwnode(const struct software_node *node)
>> {
>> struct swnode *swnode = software_node_to_swnode(node);
>> @@ -800,6 +823,27 @@ void software_node_unregister(const struct
>> software_node *node)
>> }
>> EXPORT_SYMBOL_GPL(software_node_unregister);
>>
>> +/**
>> + * fwnode_create_software_node() - Create and register a new software_node
>> + * @properties: NULL terminated array of properties to assign to the new
>> node
>> + * @parent: Pointer to a &struct fwnode_handle to assign as parent to the
>> new
>> + * node
>> + *
>> + * NOTE: The pointer passed to @parent **must** be to a firmware node handle
> maybe: passed as @parent
> ?
Sure, I'll make that change.
> Otherwise, LGTM. Thanks for doing this.
>
> Reviewed-by: Randy Dunlap
Thanks!
>
>> + * that was created by registering a software node, meaning
>> is_software_node()
>> + * must return true when passed that pointer.
>> + *
>> + * This function creates a new instance of &struct software_node, assigns
>> it a
>> + * copy of the given array of properties and registers it as a new
>> fwnode_handle.
>> + * Freeing of the allocated memory when the fwnode_handle is no longer
>> needed is
>> + * handled via software_node_release() and does not need to be done
>> separately.
>> + *
>> + * Returns:
>> + * * fwnode_handle *- On success
>> + * * -EINVAL- When @parent is not associated with a
>> software_node
>> + * * -ENOMEM- When memory allocation fails
>> + * * -Other - Propagated errors from sub-functions
>> + */
>> struct fwnode_handle *
>> fwnode_create_software_node(const struct property_entry *properties,
>> const struct fwnode_handle *parent)
>> @@ -832,6 +876,15 @@ fwnode_create_software_node(const struct property_entry
>> *properties,
>> }
>> EXPORT_SYMBOL_GPL(fwnode_create_software_node);
>>
>> +/**
>> + * fwnode_remove_software_node() - Put a reference to a registered
>> software_node
>> + * @fwnode: The pointer to the &struct fwnode_handle you want to release
>> + *
>> + * Release a reference to a registered &struct software_node. This function
>> + * differs from software_node_put() in that it takes no action if the
>> + * firmware node handle passed to @fwnode turns out not to have been
>> created by
>> + * registering a software_node.
>> + */
>
[RESEND PATCH v5 1/2] dt-bindings: PCI: sprd: Document Unisoc PCIe RC host controller
From: Hongtao Wu
This series adds PCIe bindings for Unisoc SoCs.
This controller is based on DesignWare PCIe IP.
Reviewed-by: Rob Herring
Signed-off-by: Hongtao Wu
---
.../devicetree/bindings/pci/sprd-pcie.yaml | 93 ++
1 file changed, 93 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/sprd-pcie.yaml
diff --git a/Documentation/devicetree/bindings/pci/sprd-pcie.yaml
b/Documentation/devicetree/bindings/pci/sprd-pcie.yaml
new file mode 100644
index 000..ede06a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/sprd-pcie.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/sprd-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SoC PCIe Host Controller Device Tree Bindings
+
+maintainers:
+ - Hongtao Wu
+
+allOf:
+ - $ref: /schemas/pci/pci-bus.yaml#
+
+properties:
+ compatible:
+items:
+ - const: sprd,ums9520-pcie
+
+ reg:
+minItems: 2
+items:
+ - description: Controller control and status registers.
+ - description: PCIe configuration registers.
+
+ reg-names:
+items:
+ - const: dbi
+ - const: config
+
+ ranges:
+maxItems: 2
+
+ num-lanes:
+maximum: 1
+description: Number of lanes to use for this port.
+
+ interrupts:
+minItems: 1
+description: Builtin MSI controller and PCIe host controller.
+
+ interrupt-names:
+items:
+ - const: msi
+
+ sprd,regmap-aon:
+$ref: '/schemas/types.yaml#/definitions/phandle'
+description:
+ Phandle to the AON system controller node (to access the
+ AON_ACCESS_PCIE_EN register on ums9520).
+ sprd,regmap-pmu:
+$ref: '/schemas/types.yaml#/definitions/phandle'
+description:
+ Phandle to the PMU system controller node (to access the PERST_N_ASSERT
+ register on ums9520).
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - num-lanes
+ - ranges
+ - interrupts
+ - interrupt-names
+
+additionalProperties: true
+
+examples:
+ - |
+#include
+
+ipa {
+#address-cells = <2>;
+#size-cells = <2>;
+
+pcie0: pcie@2b10 {
+compatible = "sprd,ums9520-pcie";
+reg = <0x0 0x2b10 0x0 0x2000>,
+ <0x2 0x 0x0 0x2000>;
+reg-names = "dbi", "config";
+#address-cells = <3>;
+#size-cells = <2>;
+device_type = "pci";
+ranges = <0x0100 0x0 0x 0x2 0x2000 0x0 0x0001>,
+ <0x0300 0x0 0x1000 0x2 0x1000 0x1 0xefff>;
+num-lanes = <1>;
+interrupts = ;
+interrupt-names = "msi";
+
+sprd,regmap-aon = <&aon_regs>;
+sprd,regmap-pmu = <&pmu_regs>;
+};
+};
--
2.7.4
[RESEND PATCH v5 0/2] PCI: Add new Unisoc PCIe driver
From: Hongtao Wu This series adds PCIe controller driver for Unisoc SoCs. This controller is based on DesignWare PCIe IP. Changes from v1: 1) Test this patch on top of Rob Herring's 40 part series of DWC clean-ups: https://lore.kernel.org/linux-pci/20200821035420.380495-1-r...@kernel.org/ 2) Delete empty function 3) Document property "sprd,pcie-poweron-syscons" and 'sprd,pcie-poweroff-syscons' 4) Delete runtime suspend/resume function 5) Add COMPILE_TEST which CONFIG_PCIE_SPRD depends on Changes from v2: 1) Change RC mode to host mode in drivers/pci/controller/dwc/Kconfig 2) Change Signed-off-by from Billows Wu to Hongtao Wu Changes from v3: 1) Split the property 'sprd,pcie-poweron-syscons' and 'sprd,pcie-poweroff-syscons' into reset, power domains, phy and so on. 2) Delete the function to get resource 'msi' and 'dbi' which were parsed by the DW core. 3) Delete the function 'sprd_pcie_host_init', because the DW core has done it. Changes from v4: 1) Install 'yamllint' and upgrade dt-schema in order to solve the yamllint and dtschema/dtc warnings/errors. Hongtao Wu (2): dt-bindings: PCI: sprd: Document Unisoc PCIe RC host controller PCI: sprd: Add support for Unisoc SoCs' PCIe controller .../devicetree/bindings/pci/sprd-pcie.yaml | 93 +++ drivers/pci/controller/dwc/Kconfig | 12 + drivers/pci/controller/dwc/Makefile| 1 + drivers/pci/controller/dwc/pcie-sprd.c | 293 + 4 files changed, 399 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/sprd-pcie.yaml create mode 100644 drivers/pci/controller/dwc/pcie-sprd.c -- 2.7.4
[RESEND PATCH v5 2/2] PCI: sprd: Add support for Unisoc SoCs' PCIe controller
From: Hongtao Wu
This series adds PCIe controller driver for Unisoc SoCs.
This controller is based on DesignWare PCIe IP.
Signed-off-by: Hongtao Wu
---
drivers/pci/controller/dwc/Kconfig | 12 ++
drivers/pci/controller/dwc/Makefile| 1 +
drivers/pci/controller/dwc/pcie-sprd.c | 293 +
3 files changed, 306 insertions(+)
create mode 100644 drivers/pci/controller/dwc/pcie-sprd.c
diff --git a/drivers/pci/controller/dwc/Kconfig
b/drivers/pci/controller/dwc/Kconfig
index 22c5529..61f0b79 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -318,4 +318,16 @@ config PCIE_AL
required only for DT-based platforms. ACPI platforms with the
Annapurna Labs PCIe controller don't need to enable this.
+config PCIE_SPRD
+ tristate "Unisoc PCIe controller - Host Mode"
+ depends on ARCH_SPRD || COMPILE_TEST
+ depends on PCI_MSI_IRQ_DOMAIN
+ select PCIE_DW_HOST
+ help
+ Unisoc PCIe controller uses the DesignWare core. It can be configured
+ as an Endpoint (EP) or a Root complex (RC). In order to enable host
+ mode (the controller works as RC), PCIE_SPRD must be selected.
+ Say Y or M here if you want to PCIe RC controller support on Unisoc
+ SoCs.
+
endmenu
diff --git a/drivers/pci/controller/dwc/Makefile
b/drivers/pci/controller/dwc/Makefile
index a751553..eb546e9 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PCI_MESON) += pci-meson.o
obj-$(CONFIG_PCIE_TEGRA194) += pcie-tegra194.o
obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
obj-$(CONFIG_PCIE_UNIPHIER_EP) += pcie-uniphier-ep.o
+obj-$(CONFIG_PCIE_SPRD) += pcie-sprd.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/controller/dwc/pcie-sprd.c
b/drivers/pci/controller/dwc/pcie-sprd.c
new file mode 100644
index 000..27d7231
--- /dev/null
+++ b/drivers/pci/controller/dwc/pcie-sprd.c
@@ -0,0 +1,293 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PCIe host controller driver for Unisoc SoCs
+ *
+ * Copyright (C) 2020-2021 Unisoc, Inc.
+ *
+ * Author: Hongtao Wu
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pcie-designware.h"
+
+/* aon apb syscon */
+#define IPA_ACCESS_CFG 0xcd8
+#define AON_ACCESS_PCIE_ENBIT(1)
+
+/* pmu apb syscon */
+#define SNPS_PCIE3_SLP_CTRL0xac
+#define PERST_N_ASSERTBIT(1)
+#define PERST_N_AUTO_EN BIT(0)
+#define PD_PCIE_CFG_0 0x3e8
+#define PCIE_FORCE_SHUTDOWN BIT(25)
+
+#define PCIE_SS_REG_BASE 0xE00
+#define APB_CLKFREQ_TIMEOUT0x4
+#define BUSERR_EN BIT(12)
+#define APB_TIMER_DIS BIT(10)
+#define APB_TIMER_LIMIT GENMASK(31, 16)
+
+#define PE0_GEN_CTRL_3 0x58
+#define LTSSM_EN BIT(0)
+
+struct sprd_pcie_soc_data {
+ u32 syscon_offset;
+};
+
+static const struct sprd_pcie_soc_data ums9520_syscon_data = {
+ .syscon_offset = 0x1000,/* The offset of set/clear register */
+};
+
+struct sprd_pcie {
+ u32 syscon_offset;
+ struct device *dev;
+ struct dw_pcie *pci;
+ struct regmap *aon_map;
+ struct regmap *pmu_map;
+ const struct sprd_pcie_soc_data *socdata;
+};
+
+enum sprd_pcie_syscon_type {
+ normal_syscon, /* it's not a set/clear register */
+ set_syscon, /* set a set/clear register */
+ clr_syscon, /* clear a set/clear register */
+};
+
+static void sprd_pcie_buserr_enable(struct dw_pcie *pci)
+{
+ u32 val;
+
+ val = dw_pcie_readl_dbi(pci, PCIE_SS_REG_BASE + APB_CLKFREQ_TIMEOUT);
+ val &= ~APB_TIMER_DIS;
+ val |= BUSERR_EN;
+ val |= APB_TIMER_LIMIT & (0x1f4 << 16);
+ dw_pcie_writel_dbi(pci, PCIE_SS_REG_BASE + APB_CLKFREQ_TIMEOUT, val);
+}
+
+static void sprd_pcie_ltssm_enable(struct dw_pcie *pci, bool enable)
+{
+ u32 val;
+
+ val = dw_pcie_readl_dbi(pci, PCIE_SS_REG_BASE + PE0_GEN_CTRL_3);
+ if (enable)
+ dw_pcie_writel_dbi(pci, PCIE_SS_REG_BASE + PE0_GEN_CTRL_3,
+ val | LTSSM_EN);
+ else
+ dw_pcie_writel_dbi(pci, PCIE_SS_REG_BASE + PE0_GEN_CTRL_3,
+ val & ~LTSSM_EN);
+}
+
+static int sprd_pcie_syscon_set(struct sprd_pcie *ctrl, struct regmap *map,
+ u32 reg, u32 mask, u32 val,
+ enum sprd_pcie_syscon_type type)
+{
+ int ret = 0;
+ u32 read_val;
+ u32 offset = ctrl->syscon_offset;
+ struct device *dev = ctrl->pci->dev;
+
+ /*
+* Each set/clear register has three registers:
+
Re: [PATCH v5] usb: xhci-mtk: fix unreleased bandwidth data
Hi Ikjoon,
On Tue, 2021-01-12 at 13:48 +0800, Ikjoon Jang wrote:
> On Fri, Jan 8, 2021 at 10:44 PM Mathias Nyman
> wrote:
> >
> > On 8.1.2021 8.11, Chunfeng Yun wrote:
> > > On Thu, 2021-01-07 at 13:09 +0200, Mathias Nyman wrote:
> > >> On 29.12.2020 8.24, Ikjoon Jang wrote:
> > >>> xhci-mtk has hooks on add_endpoint() and drop_endpoint() from xhci
> > >>> to handle its own sw bandwidth managements and stores bandwidth data
> > >>> into internal table every time add_endpoint() is called,
> > >>> so when bandwidth allocation fails at one endpoint, all earlier
> > >>> allocation from the same interface could still remain at the table.
> > >>>
> > >>> This patch adds two more hooks from check_bandwidth() and
> > >>> reset_bandwidth(), and make mtk-xhci to releases all failed endpoints
> > >>> from reset_bandwidth().
> > >>>
> > >>> Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with
> > >>> multi-TT")
> > >>> Signed-off-by: Ikjoon Jang
> > >>>
> > >>
> > >> ...
> > >>
> > >>>
> > >>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > >>> index d4a8d0efbbc4..e1fcd3cf723f 100644
> > >>> --- a/drivers/usb/host/xhci.c
> > >>> +++ b/drivers/usb/host/xhci.c
> > >>> @@ -2882,6 +2882,12 @@ static int xhci_check_bandwidth(struct usb_hcd
> > >>> *hcd, struct usb_device *udev)
> > >>> xhci_dbg(xhci, "%s called for udev %p\n", __func__, udev);
> > >>> virt_dev = xhci->devs[udev->slot_id];
> > >>>
> > >>> + if (xhci->quirks & XHCI_MTK_HOST) {
> > >>> + ret = xhci_mtk_check_bandwidth(hcd, udev);
> > >>> + if (ret < 0)
> > >>> + return ret;
> > >>> + }
> > >>> +
> > >>
> > >> Just noticed that XHCI_MTK_HOST quirk is only set in xhci-mtk.c.
> > >> xhci-mtk.c calls xhci_init_driver(..., xhci_mtk_overrides) with a .reset
> > >> override function.
> > >>
> > >> why not add override functions for .check_bandwidth and .reset_bandwidth
> > >> to xhci_mtk_overrides instead?
> > >>
> > >> Another patch to add similar overrides for .add_endpoint and
> > >> .drop_endpoint should probably be
> > >> done so that we can get rid of the xhci_mtk_add/drop_ep_quirk() calls in
> > >> xhci.c as well
> > > You mean, we can export xhci_add/drop_endpoint()?
> >
> > I think so, unless you have a better idea.
> > I prefer exporting the generic add/drop_endpoint functions rather than the
> > vendor specific quirk functions.
> >
>
> When moving out all MTK_HOST quirks and unlink xhci-mtk-sch from xhci,
> xhci-mtk-sch still needs to touch the xhci internals, at least struct
> xhci_ep_ctx.
>
> My naive idea is just let xhci export one more function to expose xhci_ep_ctx.
> But I'm not sure whether this is acceptable:
I find that xhci_add_endpoint() ignores some errors with return 0, for
these cases we needn't call xhci_mtk_add_ep-quirk(), so may be not a
good way to just export xhci_add_endpoint().
>
> +struct xhci_ep_ctx* xhci_get_ep_contex(struct xhci_hcd *xhci, struct
> usb_host_endpoint *ep)
> +{ ... }
> +EXPORT_SYMBOL(xhci_get_ep_context);
>
> But for v6, I'm going to submit a patch with {check|reset}_bandwidth()
> quirk function
> switched into xhci_driver_overrides first. (and preserve existing
> MTK_HOST quirk functions).
>
> Thanks!
>
> > -Mathias
> >
Re: [PATCH] ata: remove redundant error print in rb532_pata_driver_probe
Hello!
On 13.01.2021 17:04, Menglong Dong wrote:
[...]
irq = platform_get_irq(pdev, 0);
- if (irq <= 0) {
- dev_err(&pdev->dev, "no IRQ resource found\n");
+ if (irq <= 0)
return -ENOENT;
This still beaks the probe deferral. :-(
But that's another problem...
[...]
MBR, Sergei
What does this 'MBR' mean? I am a novice~~~
Generally speaking, Master Boot Record. But I also use it to send you My
Best Regards. :-)
So, is it better to replace 'platform_get_irq' with
'platform_get_irq_optional' here?
No. You should stop overriding the result to -ENOENT and pass the result
up the call chain instead. In order to do it, you should only check for (irq <
0).
--
Best Regards
Menglong Dong
MBR, Sergei
Re: [PATCH 2/3] reset: mchp: sparx5: add switch reset driver
On Thu, 2021-01-14 at 00:23 +0100, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> > +static int sparx5_switch_reset(struct reset_controller_dev *rcdev,
> > + unsigned long id)
> > +{
> > + struct mchp_reset_context *ctx =
> > + container_of(rcdev, struct mchp_reset_context,
> > reset_ctrl);
> > + u32 val;
> > +
> > + /* Make sure the core is PROTECTED from reset */
> > + regmap_update_bits(ctx->cpu_ctrl, PROTECT_REG, PROTECT_BIT,
> > PROTECT_BIT);
> > +
> > + dev_info(ctx->dev, "soft reset of switchcore\n");
>
> dev_dbg()?
I will remove that.
>
> > +
> > + /* Start soft reset */
> > + regmap_write(ctx->gcb_ctrl, SOFT_RESET_REG, SOFT_RESET_BIT);
> > +
> > + /* Wait for soft reset done */
> > + return read_poll_timeout(sparx5_read_soft_rst, val,
> > + (val & SOFT_RESET_BIT) == 0,
> > + 1, 100, false,
> > + ctx);
> > +}
>
> > +static int mchp_sparx5_reset_config(struct platform_device *pdev,
> > + struct mchp_reset_context *ctx)
> > +{
> > + struct device_node *dn = pdev->dev.of_node;
> > + struct regmap *cpu_ctrl, *gcb_ctrl;
> > + struct device_node *syscon_np;
> > + int err;
> > +
> > + syscon_np = of_parse_phandle(dn, "syscons", 0);
> > + if (!syscon_np)
> > + return -ENODEV;
> > + cpu_ctrl = syscon_node_to_regmap(syscon_np);
> > + if (IS_ERR(cpu_ctrl))
> > + goto err_cpu;
> > + of_node_put(syscon_np);
> > +
> > + syscon_np = of_parse_phandle(dn, "syscons", 1);
> > + if (!syscon_np)
> > + return -ENODEV;
> > + gcb_ctrl = syscon_node_to_regmap(syscon_np);
> > + if (IS_ERR(gcb_ctrl))
> > + goto err_gcb;
> > + of_node_put(syscon_np);
> > +
> > + ctx->cpu_ctrl = cpu_ctrl;
> > + ctx->gcb_ctrl = gcb_ctrl;
> > +
> > + ctx->reset_ctrl.owner = THIS_MODULE;
> > + ctx->reset_ctrl.nr_resets = 1;
> > + ctx->reset_ctrl.ops = &sparx5_reset_ops;
> > + ctx->reset_ctrl.of_node = dn;
> > +
> > + err = devm_reset_controller_register(&pdev->dev, &ctx-
> > >reset_ctrl);
> > + if (err)
> > + dev_err(&pdev->dev, "could not register reset
> > controller\n");
> > + pr_info("%s:%d\n", __func__, __LINE__);
> > + return err;
> > +err_cpu:
> > + of_node_put(syscon_np);
> > + dev_err(&pdev->dev, "No cpu syscon map\n");
> > + return PTR_ERR(cpu_ctrl);
> > +err_gcb:
> > + of_node_put(syscon_np);
> > + dev_err(&pdev->dev, "No gcb syscon map\n");
> > + return PTR_ERR(gcb_ctrl);
>
> It would be normal to put the dev_err() before the goto, set err =
> PTR_ERR() and then goto out;
OK. I will change that.
>
>
> > +}
> > +
> > +static int mchp_sparx5_reset_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct mchp_reset_context *ctx;
> > +
> > + pr_info("%s:%d\n", __func__, __LINE__);
>
> More left over debug.
Yes. That will have to go.
>
> > + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> > + if (!ctx)
> > + return -ENOMEM;
> > + ctx->dev = dev;
> > + return mchp_sparx5_reset_config(pdev, ctx);
> > +}
> > +
> > +static const struct of_device_id mchp_sparx5_reset_of_match[] = {
> > + {
> > + .compatible = "microchip,sparx5-switch-reset",
> > + },
> > + { /*sentinel*/ }
> > +};
>
> > +static int __init mchp_sparx5_reset_init(void)
> > +{
> > + return platform_driver_register(&mchp_sparx5_reset_driver);
> > +}
> > +
> > +postcore_initcall(mchp_sparx5_reset_init);
>
> Does it actually need to be postcore? The users of the reset should
> look for -EPROBE_DEFER and try again later. And this then becomes
> just
> a normal driver.
I tried using that, but the SGPIO driver bailed out after 3 DEFER
attempts, so that is why I changed it to use the postcore_initcall.
Maybe it is because the SGPIO driver is a builtin_platform_driver?
>
> Andrew
Re: [PATCH v2 0/7] Rid W=1 warnings in Ethernet
On Wed, 13 Jan 2021, Jakub Kicinski wrote: > On Wed, 13 Jan 2021 16:41:16 + Lee Jones wrote: > > Resending the stragglers again. > > > > > > This set is part of a larger effort attempting to clean-up W=1 > > > > kernel builds, which are currently overwhelmingly riddled with > > > > niggly little warnings. > > > > > > > > v2: > > > > - Squashed IBM patches > > > > - Fixed real issue in SMSC > > - Added Andrew's Reviewed-by tags on remainder > > Does not apply, please rebase on net-next/master. These are based on Tuesday's next/master. I just rebased them now with no issue. What conflict are you seeing? -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
arch/sh/kernel/cpu/sh2a/clock-sh7203.c:29:32: sparse: sparse: incorrect type in argument 1 (different base types)
Hi Luc,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 65f0d2414b7079556fbbcc070b3d1c9f9587606d
commit: e5fc436f06eef54ef512ea55a9db8eb9f2e76959 sparse: use static inline for
__chk_{user,io}_ptr()
date: 5 months ago
config: sh-randconfig-s032-20210114 (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-208-g46a52ca4-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e5fc436f06eef54ef512ea55a9db8eb9f2e76959
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e5fc436f06eef54ef512ea55a9db8eb9f2e76959
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=sh
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> arch/sh/kernel/cpu/sh2a/clock-sh7203.c:29:32: sparse: sparse: incorrect type
>> in argument 1 (different base types) @@ expected void const volatile
>> [noderef] __iomem *ptr @@ got unsigned int @@
arch/sh/kernel/cpu/sh2a/clock-sh7203.c:29:32: sparse: expected void
const volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh2a/clock-sh7203.c:29:32: sparse: got unsigned int
arch/sh/kernel/cpu/sh2a/clock-sh7203.c:38:20: sparse: sparse: incorrect type
in argument 1 (different base types) @@ expected void const volatile
[noderef] __iomem *ptr @@ got unsigned int @@
arch/sh/kernel/cpu/sh2a/clock-sh7203.c:38:20: sparse: expected void
const volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh2a/clock-sh7203.c:38:20: sparse: got unsigned int
arch/sh/kernel/cpu/sh2a/clock-sh7203.c:48:20: sparse: sparse: incorrect type
in argument 1 (different base types) @@ expected void const volatile
[noderef] __iomem *ptr @@ got unsigned int @@
arch/sh/kernel/cpu/sh2a/clock-sh7203.c:48:20: sparse: expected void
const volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh2a/clock-sh7203.c:48:20: sparse: got unsigned int
--
>> arch/sh/kernel/cpu/sh2a/setup-sh7203.c:348:9: sparse: sparse: incorrect type
>> in argument 1 (different base types) @@ expected void const volatile
>> [noderef] __iomem *ptr @@ got unsigned int @@
arch/sh/kernel/cpu/sh2a/setup-sh7203.c:348:9: sparse: expected void
const volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh2a/setup-sh7203.c:348:9: sparse: got unsigned int
>> arch/sh/kernel/cpu/sh2a/setup-sh7203.c:348:9: sparse: sparse: incorrect type
>> in argument 1 (different base types) @@ expected void const volatile
>> [noderef] __iomem *ptr @@ got unsigned int @@
arch/sh/kernel/cpu/sh2a/setup-sh7203.c:348:9: sparse: expected void
const volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh2a/setup-sh7203.c:348:9: sparse: got unsigned int
arch/sh/kernel/cpu/sh2a/setup-sh7203.c:351:9: sparse: sparse: incorrect type
in argument 1 (different base types) @@ expected void const volatile
[noderef] __iomem *ptr @@ got unsigned int @@
arch/sh/kernel/cpu/sh2a/setup-sh7203.c:351:9: sparse: expected void
const volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh2a/setup-sh7203.c:351:9: sparse: got unsigned int
arch/sh/kernel/cpu/sh2a/setup-sh7203.c:351:9: sparse: sparse: incorrect type
in argument 1 (different base types) @@ expected void const volatile
[noderef] __iomem *ptr @@ got unsigned int @@
arch/sh/kernel/cpu/sh2a/setup-sh7203.c:351:9: sparse: expected void
const volatile [noderef] __iomem *ptr
arch/sh/kernel/cpu/sh2a/setup-sh7203.c:351:9: sparse: got unsigned int
--
>> arch/sh/boards/mach-rsk/devices-rsk7203.c:131:9: sparse: sparse: incorrect
>> type in argument 1 (different base types) @@ expected void const
>> volatile [noderef] __iomem *ptr @@ got unsigned int @@
arch/sh/boards/mach-rsk/devices-rsk7203.c:131:9: sparse: expected void
const volatile [noderef] __iomem *ptr
arch/sh/boards/mach-rsk/devices-rsk7203.c:131:9: sparse: got unsigned int
--
drivers/hid/hidraw.c:389:37: sparse: sparse: incorrect type in initializer
(different address spaces) @@ expected int const *__gu_addr @@ got int
[noderef] __user * @@
drivers/hid/hidraw.c:389:37: sparse: expected int const *__gu_addr
drivers/hid/hidraw.c:389:37: sparse: got int [noderef] __user *
>> drivers/hid/hidraw.c:389:37: sparse: sparse:
[PATCH v3] octeontx2-af: Fix missing check bugs in rvu_cgx.c
From: Yingjie Wang
In rvu_mbox_handler_cgx_mac_addr_get()
and rvu_mbox_handler_cgx_mac_addr_set(),
the msg is expected only from PFs that are mapped to CGX LMACs.
It should be checked before mapping,
so we add the is_cgx_config_permitted() in the functions.
Fixes: 96be2e0da85e ("octeontx2-af: Support for MAC address filters in CGX")
Signed-off-by: Yingjie Wang
---
drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
index d298b9357177..6c6b411e78fd 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cgx.c
@@ -469,6 +469,9 @@ int rvu_mbox_handler_cgx_mac_addr_set(struct rvu *rvu,
int pf = rvu_get_pf(req->hdr.pcifunc);
u8 cgx_id, lmac_id;
+ if (!is_cgx_config_permitted(rvu, req->hdr.pcifunc))
+ return -EPERM;
+
rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_id, &lmac_id);
cgx_lmac_addr_set(cgx_id, lmac_id, req->mac_addr);
@@ -485,6 +488,9 @@ int rvu_mbox_handler_cgx_mac_addr_get(struct rvu *rvu,
int rc = 0, i;
u64 cfg;
+ if (!is_cgx_config_permitted(rvu, req->hdr.pcifunc))
+ return -EPERM;
+
rvu_get_cgx_lmac_id(rvu->pf2cgxlmac_map[pf], &cgx_id, &lmac_id);
rsp->hdr.rc = rc;
--
2.7.4
Re: [PATCH 3/4] configfs: implement committable items
On Thu, Jan 14, 2021 at 12:46 AM Joel Becker wrote:
>
> On Wed, Nov 25, 2020 at 04:22:46PM +0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > This implements configfs committable items. We mostly follow the
> > documentation except that we extend config_group_ops with uncommit_item()
> > callback for reverting the changes made by commit_item().
>
> Woohoo! A long time coming, but thank you for working on the
> implementation!
>
> > Each committable group has two sub-directories: pending and live. New
> > items can only be created in pending/. Attributes can only be modified
> > while the item is in pending/. Once it's ready to be committed, it must
> > be moved over to live/ using the rename() system call. This is when the
> > commit_item() function will be called.
>
> The original API intended for live items to still be modifyable. The
> live/ path forbids mkdir()/rmdir(), but it allows store(). Otherwise,
> items can't be adjusted at all while in use, which is severely limiting.
> Obviously the store() handler must not allow transitions from
> valid-value->invalid-value, but the handler would reject invalid values
> anyway, wouldn't it?
>
> > diff --git a/fs/configfs/file.c b/fs/configfs/file.c
> > index 1f0270229d7b..a20e55fd05e8 100644
> > --- a/fs/configfs/file.c
> > +++ b/fs/configfs/file.c
> > @@ -243,9 +243,17 @@ fill_write_buffer(struct configfs_buffer * buffer,
> > const char __user * buf, size
> > static int
> > flush_write_buffer(struct file *file, struct configfs_buffer *buffer,
> > size_t count)
> > {
> > + struct config_item *parent_item = buffer->item->ci_parent;
> > struct configfs_fragment *frag = to_frag(file);
> > + struct configfs_dirent *sd;
> > int res = -ENOENT;
> >
> > + if (parent_item && parent_item->ci_dentry) {
> > + sd = parent_item->ci_dentry->d_fsdata;
> > + if (sd->s_type & CONFIGFS_GROUP_LIVE)
> > + return -EPERM;
> > + }
> > +
> > down_read(&frag->frag_sem);
> > if (!frag->frag_dead)
> > res = buffer->attr->store(buffer->item, buffer->page, count);
>
> Basically, I would just leave this hunk out.
>
I would make this configurable per-attribute because for the use-case
I need this for we definitely don't want the items to be modifiable
once they're "live".
Bartosz
Re: [PATCH 2/2] compiler.h: Include asm/rwonce.h under ARM64 and ALPHA to fix build errors
Hello! On 13.01.2021 13:57, Tiezhu Yang wrote: When make M=samples/bpf on the Loongson 3A3000 platform which belongs to MIPS arch, there exists many similar build errors about 'asm/rwonce.h' file not found, so include it only under CONFIG_ARM64 and CONFIG_ALPHA due to it exists only in arm64 and alpha arch. CLANG-bpf samples/bpf/xdpsock_kern.o In file included from samples/bpf/xdpsock_kern.c:2: In file included from ./include/linux/bpf.h:9: In file included from ./include/linux/workqueue.h:9: In file included from ./include/linux/timer.h:5: In file included from ./include/linux/list.h:9: In file included from ./include/linux/kernel.h:10: ./include/linux/compiler.h:246:10: fatal error: 'asm/rwonce.h' file not found ^~ 1 error generated. $ find . -name rwonce.h ./include/asm-generic/rwonce.h ./arch/arm64/include/asm/rwonce.h ./arch/alpha/include/asm/rwonce.h Signed-off-by: Tiezhu Yang --- include/linux/compiler.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/linux/compiler.h b/include/linux/compiler.h index b8fe0c2..bdbe759 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -243,6 +243,12 @@ static inline void *offset_to_ptr(const int *off) */ #define prevent_tail_call_optimization() mb() +#ifdef CONFIG_ARM64 Why not #if defined(CONFIG_ALPHA) || defined(CONFIG_ARM64)? #include +#endif + +#ifdef CONFIG_ALPHA +#include +#endif #endif /* __LINUX_COMPILER_H */ MBR, Sergei
[PATCH] mlxsw: pci: switch from 'pci_' to 'dma_' API
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.
When memory is allocated in 'mlxsw_pci_queue_init()' and
'mlxsw_pci_fw_area_init()' GFP_KERNEL can be used because both functions
are already using this flag and no lock is acquired.
When memory is allocated in 'mlxsw_pci_mbox_alloc()' GFP_KERNEL can be used
because it is only called from the probe function and no lock is acquired
in the between.
The call chain is:
--> mlxsw_pci_probe()
--> mlxsw_pci_cmd_init()
--> mlxsw_pci_mbox_alloc()
While at it, also replace the 'dma_set_mask/dma_set_coherent_mask' sequence
by a less verbose 'dma_set_mask_and_coherent() call.
@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL
@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE
@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE
@@
@@
-PCI_DMA_NONE
+DMA_NONE
@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(&e1->dev, e2, e3, GFP_)
@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(&e1->dev, e2, e3, e4, e5)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(&e1->dev, e2, e3, e4)
@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(&e1->dev, e2)
@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(&e1->dev, e2)
@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(&e1->dev, e2)
Signed-off-by: Christophe JAILLET
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
https://marc.info/?l=kernel-janitors&m=158745678307186&w=4
---
drivers/net/ethernet/mellanox/mlxsw/pci.c | 56 ++-
1 file changed, 25 insertions(+), 31 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.c
b/drivers/net/ethernet/mellanox/mlxsw/pci.c
index 4eeae8d78006..d0052537e627 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
@@ -323,8 +323,8 @@ static int mlxsw_pci_wqe_frag_map(struct mlxsw_pci
*mlxsw_pci, char *wqe,
struct pci_dev *pdev = mlxsw_pci->pdev;
dma_addr_t mapaddr;
- mapaddr = pci_map_single(pdev, frag_data, frag_len, direction);
- if (unlikely(pci_dma_mapping_error(pdev, mapaddr))) {
+ mapaddr = dma_map_single(&pdev->dev, frag_data, frag_len, direction);
+ if (unlikely(dma_mapping_error(&pdev->dev, mapaddr))) {
dev_err_ratelimited(&pdev->dev, "failed to dma map tx frag\n");
return -EIO;
}
@@ -342,7 +342,7 @@ static void mlxsw_pci_wqe_frag_unmap(struct mlxsw_pci
*mlxsw_pci, char *wqe,
if (!frag_len)
return;
- pci_unmap_single(pdev, mapaddr, frag_len, direction);
+ dma_unmap_single(&pdev->dev, mapaddr, frag_len, direction);
}
static int mlxsw_pci_rdq_skb_alloc(struct mlxsw_pci *mlxsw_pci,
@@ -858,9 +858,9 @@ static int mlxsw_pci_queue_init(struct mlxsw_pci
*mlxsw_pci, char *mbox,
tasklet_setup(&q->tasklet, q_ops->tasklet);
mem_item->size = MLXSW_PCI_AQ_SIZE;
- mem_item->buf = pci_alloc_consistent(mlxsw_pci->pdev,
-mem_item->size,
-&mem_item->mapaddr);
+ mem_item->buf = dma_alloc_coherent(&mlxsw_pci->pdev->dev,
+ mem_item->size, &mem_item->mapaddr,
+ GFP_KERNEL);
if (!mem_item->buf)
return -ENOMEM;
@@ -890,8 +890,8 @@ static int mlxsw_pci_que
Re: [PATCH][next] media: i2c: fix spelling mistakes: "enpoint" -> "endpoint"
Hi,
On Wed 13 Jan 21, 10:05, Colin King wrote:
> From: Colin Ian King
>
> There are two spelling mistakes in dev_err messages. Fix these.
Thanks for the patch!
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> Signed-off-by: Colin Ian King
> ---
> drivers/media/i2c/ov5648.c | 2 +-
> drivers/media/i2c/ov8865.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/i2c/ov5648.c b/drivers/media/i2c/ov5648.c
> index 609aa67b54ce..46ad0a539853 100644
> --- a/drivers/media/i2c/ov5648.c
> +++ b/drivers/media/i2c/ov5648.c
> @@ -2453,7 +2453,7 @@ static int ov5648_probe(struct i2c_client *client)
>
> handle = fwnode_graph_get_next_endpoint(dev_fwnode(dev), NULL);
> if (!handle) {
> - dev_err(dev, "unable to find enpoint node\n");
> + dev_err(dev, "unable to find endpoint node\n");
> return -EINVAL;
> }
>
> diff --git a/drivers/media/i2c/ov8865.c b/drivers/media/i2c/ov8865.c
> index fda5a55979aa..fd5be8ef079c 100644
> --- a/drivers/media/i2c/ov8865.c
> +++ b/drivers/media/i2c/ov8865.c
> @@ -2799,7 +2799,7 @@ static int ov8865_probe(struct i2c_client *client)
>
> handle = fwnode_graph_get_next_endpoint(dev_fwnode(dev), NULL);
> if (!handle) {
> - dev_err(dev, "unable to find enpoint node\n");
> + dev_err(dev, "unable to find endpoint node\n");
> return -EINVAL;
> }
>
> --
> 2.29.2
>
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
[PATCH 2/2] perf tools: Add 'cgroup-switches' software event
It counts how often cgroups are changed actually during the context
switches.
# perf stat -a -e context-switches,cgroup-switches -a sleep 1
Performance counter stats for 'system wide':
11,267 context-switches
10,950 cgroup-switches
1.015634369 seconds time elapsed
Signed-off-by: Namhyung Kim
---
tools/include/uapi/linux/perf_event.h | 1 +
tools/perf/util/parse-events.c| 4
tools/perf/util/parse-events.l| 1 +
3 files changed, 6 insertions(+)
diff --git a/tools/include/uapi/linux/perf_event.h
b/tools/include/uapi/linux/perf_event.h
index b95d3c485d27..16559703c49c 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -112,6 +112,7 @@ enum perf_sw_ids {
PERF_COUNT_SW_EMULATION_FAULTS = 8,
PERF_COUNT_SW_DUMMY = 9,
PERF_COUNT_SW_BPF_OUTPUT= 10,
+ PERF_COUNT_SW_CGROUP_SWITCHES = 11,
PERF_COUNT_SW_MAX, /* non-ABI */
};
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 3b273580fb84..f6a5a099e143 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -145,6 +145,10 @@ struct event_symbol event_symbols_sw[PERF_COUNT_SW_MAX] = {
.symbol = "bpf-output",
.alias = "",
},
+ [PERF_COUNT_SW_CGROUP_SWITCHES] = {
+ .symbol = "cgroup-switches",
+ .alias = "",
+ },
};
#define __PERF_EVENT_FIELD(config, name) \
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 9db5097317f4..88f203bb6fab 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -347,6 +347,7 @@ emulation-faults{ return
sym(yyscanner, PERF_TYPE_SOFTWARE, PERF_COUNT_SW_EM
dummy { return sym(yyscanner,
PERF_TYPE_SOFTWARE, PERF_COUNT_SW_DUMMY); }
duration_time { return tool(yyscanner,
PERF_TOOL_DURATION_TIME); }
bpf-output { return sym(yyscanner,
PERF_TYPE_SOFTWARE, PERF_COUNT_SW_BPF_OUTPUT); }
+cgroup-switches{ return sym(yyscanner,
PERF_TYPE_SOFTWARE, PERF_COUNT_SW_CGROUP_SWITCHES); }
/*
* We have to handle the kernel PMU event
cycles-ct/cycles-t/mem-loads/mem-stores separately.
--
2.30.0.284.gd98b1dd5eaa7-goog
[PATCH 1/2] perf core: Add PERF_COUNT_SW_CGROUP_SWITCHES event
This patch adds a new software event to count context switches
involving cgroup switches. So it's counted only if cgroups of
previous and next tasks are different. Note that it only checks the
cgroups in the perf_event subsystem. For cgroup v2, it shouldn't
matter anyway.
One can argue that we can do this by using existing sched_switch event
with eBPF. But some systems might not have eBPF for some reason so
I'd like to add this as a simple way.
Suggested-by: Peter Zijlstra
Signed-off-by: Namhyung Kim
---
include/linux/perf_event.h | 38 +++--
include/uapi/linux/perf_event.h | 1 +
2 files changed, 18 insertions(+), 21 deletions(-)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 9a38f579bc76..304ef42d42d1 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1174,30 +1174,24 @@ DECLARE_PER_CPU(struct pt_regs, __perf_regs[4]);
* which is guaranteed by us not actually scheduling inside other swevents
* because those disable preemption.
*/
-static __always_inline void
-perf_sw_event_sched(u32 event_id, u64 nr, u64 addr)
+static __always_inline void __perf_sw_event_sched(u32 event_id, u64 nr, u64
addr)
{
- if (static_key_false(&perf_swevent_enabled[event_id])) {
- struct pt_regs *regs = this_cpu_ptr(&__perf_regs[0]);
+ struct pt_regs *regs = this_cpu_ptr(&__perf_regs[0]);
- perf_fetch_caller_regs(regs);
- ___perf_sw_event(event_id, nr, regs, addr);
- }
+ perf_fetch_caller_regs(regs);
+ ___perf_sw_event(event_id, nr, regs, addr);
}
extern struct static_key_false perf_sched_events;
-static __always_inline bool
-perf_sw_migrate_enabled(void)
+static __always_inline bool __perf_sw_enabled(int swevt)
{
- if
(static_key_false(&perf_swevent_enabled[PERF_COUNT_SW_CPU_MIGRATIONS]))
- return true;
- return false;
+ return static_key_false(&perf_swevent_enabled[swevt]);
}
static inline void perf_event_task_migrate(struct task_struct *task)
{
- if (perf_sw_migrate_enabled())
+ if (__perf_sw_enabled(PERF_COUNT_SW_CPU_MIGRATIONS))
task->sched_migrated = 1;
}
@@ -1207,11 +1201,9 @@ static inline void perf_event_task_sched_in(struct
task_struct *prev,
if (static_branch_unlikely(&perf_sched_events))
__perf_event_task_sched_in(prev, task);
- if (perf_sw_migrate_enabled() && task->sched_migrated) {
- struct pt_regs *regs = this_cpu_ptr(&__perf_regs[0]);
-
- perf_fetch_caller_regs(regs);
- ___perf_sw_event(PERF_COUNT_SW_CPU_MIGRATIONS, 1, regs, 0);
+ if (__perf_sw_enabled(PERF_COUNT_SW_CPU_MIGRATIONS) &&
+ task->sched_migrated) {
+ __perf_sw_event_sched(PERF_COUNT_SW_CPU_MIGRATIONS, 1, 0);
task->sched_migrated = 0;
}
}
@@ -1219,7 +1211,13 @@ static inline void perf_event_task_sched_in(struct
task_struct *prev,
static inline void perf_event_task_sched_out(struct task_struct *prev,
struct task_struct *next)
{
- perf_sw_event_sched(PERF_COUNT_SW_CONTEXT_SWITCHES, 1, 0);
+ if (__perf_sw_enabled(PERF_COUNT_SW_CONTEXT_SWITCHES))
+ __perf_sw_event_sched(PERF_COUNT_SW_CONTEXT_SWITCHES, 1, 0);
+
+ if (__perf_sw_enabled(PERF_COUNT_SW_CGROUP_SWITCHES) &&
+ (task_css_check(prev, perf_event_cgrp_id, 1)->cgroup !=
+task_css_check(next, perf_event_cgrp_id, 1)->cgroup))
+ __perf_sw_event_sched(PERF_COUNT_SW_CGROUP_SWITCHES, 1, 0);
if (static_branch_unlikely(&perf_sched_events))
__perf_event_task_sched_out(prev, next);
@@ -1475,8 +1473,6 @@ static inline int perf_event_refresh(struct perf_event
*event, int refresh)
static inline void
perf_sw_event(u32 event_id, u64 nr, struct pt_regs *regs, u64 addr){ }
static inline void
-perf_sw_event_sched(u32 event_id, u64 nr, u64 addr){ }
-static inline void
perf_bp_event(struct perf_event *event, void *data){ }
static inline int perf_register_guest_info_callbacks
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index b15e3447cd9f..16b9538ad89b 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -112,6 +112,7 @@ enum perf_sw_ids {
PERF_COUNT_SW_EMULATION_FAULTS = 8,
PERF_COUNT_SW_DUMMY = 9,
PERF_COUNT_SW_BPF_OUTPUT= 10,
+ PERF_COUNT_SW_CGROUP_SWITCHES = 11,
PERF_COUNT_SW_MAX, /* non-ABI */
};
--
2.30.0.284.gd98b1dd5eaa7-goog
Re: linux-next: build warning after merge of the usb tree
On Thu, Jan 14, 2021 at 09:48:56AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 6 Jan 2021 13:12:25 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the usb tree, today's linux-next build (htmldocs) produced
> > this warning:
> >
> > drivers/usb/dwc3/core.h:1259: warning: Function parameter or member
> > 'gadget_max_speed' not described in 'dwc3'
> >
> > Introduced by commit
> >
> > 7c9a2598463a ("usb: dwc3: gadget: Preserve UDC max speed setting")
>
> I am still getting this warning.
Looks like Mauro just sent me a patch for this, will queue it up now,
thanks.
greg k-h
Re: [v2] Old platforms: bring out your dead
On Wed, Jan 13, 2021 at 8:00 PM Krzysztof Hałasa wrote: > Arnd Bergmann writes: > > > For these I received no reply yet. Again, these will stay for the moment > > unless I get a reply, but if anyone has more information, please reply > > here to document the status (adding a few more people to Cc): > > > > * cns3xxx -- added in 2010, last fixed in 2019, probably no users left > > The following is what I sent to you a week ago. I don't say whether > CNS3xxx support should stay or not, of course. > > Subject: Re: cns3xxx PCIe domain support > > Arnd Bergmann writes: > > > For the cns3xxx case, I wonder if anyone actually cares. If > > there are still users, the treewide change would make it trivial > > to set it up right, while backporting would be harder. I noticed > > that openwrt removed cns3xxx support in August with the > > explanation that the platform is not used much anymore, > > and I suspect that any users outside of openwrt stopped updating > > their kernels long ago. > > I'm still using CNS3xxx-based Gateworks' boards (Laguna), with some > custom patch set, but the last kernels are over 2 years old. I have some > plan to update, but the probability it will happen very soon is rather > low. I guess I will test and, if needed, fix it when the time comes. > > I'm not using them with OpenWrt, though. > They are basically a platform for (the old, parallel, not express) > mini-PCI cards and similar stuff. Nothing connected to the Internet etc. Hi Krzysztof, Thanks for your reply. I think I misremembered it from when you originally said this in the other thread and thought you meant you were unlikely to ever do it, not just for doing it soon. No need to rush things then by removing it prematurely then, but it might help if you could point to a git tree with your last working patches in case someone else has a Laguna and wants to update it to a more recent kernel before you do. Arnd
Re: [RESEND PATCH v5 2/2] PCI: sprd: Add support for Unisoc SoCs' PCIe controller
On Thu, Jan 14, 2021 at 04:29:28PM +0800, Hongtao Wu wrote:
> From: Hongtao Wu
>
> This series adds PCIe controller driver for Unisoc SoCs.
> This controller is based on DesignWare PCIe IP.
>
> Signed-off-by: Hongtao Wu
> ---
> drivers/pci/controller/dwc/Kconfig | 12 ++
> drivers/pci/controller/dwc/Makefile| 1 +
> drivers/pci/controller/dwc/pcie-sprd.c | 293
> +
> 3 files changed, 306 insertions(+)
> create mode 100644 drivers/pci/controller/dwc/pcie-sprd.c
<...>
> +static struct platform_driver sprd_pcie_driver = {
> + .probe = sprd_pcie_probe,
> + .remove = __exit_p(sprd_pcie_remove),
^^ why is that?
> + .driver = {
> + .name = "sprd-pcie",
> + .of_match_table = sprd_pcie_of_match,
> + },
> +};
> +
> +module_platform_driver(sprd_pcie_driver);
> +
> +MODULE_DESCRIPTION("Unisoc PCIe host controller driver");
> +MODULE_LICENSE("GPL v2");
I think that it needs to be "GPL" and not "GPL v2".
Thanks
> --
> 2.7.4
>
arch/arm64/kvm/va_layout.c:249:6: warning: no previous prototype for 'kvm_update_kimg_phys_offset'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 65f0d2414b7079556fbbcc070b3d1c9f9587606d commit: 1db9d9ded771389aae5760d20dd1bac113451b9c KVM: arm64: Add kimg_hyp_va() helper date: 9 weeks ago config: arm64-randconfig-r005-20210113 (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1db9d9ded771389aae5760d20dd1bac113451b9c git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 1db9d9ded771389aae5760d20dd1bac113451b9c # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): arch/arm64/kvm/va_layout.c:138:6: warning: no previous prototype for 'kvm_patch_vector_branch' [-Wmissing-prototypes] 138 | void kvm_patch_vector_branch(struct alt_instr *alt, | ^~~ >> arch/arm64/kvm/va_layout.c:249:6: warning: no previous prototype for >> 'kvm_update_kimg_phys_offset' [-Wmissing-prototypes] 249 | void kvm_update_kimg_phys_offset(struct alt_instr *alt, | ^~~ Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for NVMEM_IMX_OCOTP Depends on NVMEM && (ARCH_MXC || COMPILE_TEST && HAS_IOMEM Selected by - ARM_IMX6Q_CPUFREQ && CPU_FREQ && (ARM || ARM64 && ARCH_MXC && REGULATOR_ANATOP vim +/kvm_update_kimg_phys_offset +249 arch/arm64/kvm/va_layout.c 248 > 249 void kvm_update_kimg_phys_offset(struct alt_instr *alt, --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH -next] media: venus: Mark bufreq_enc with static keyword
Fix the following sparse warning:
drivers/media/platform/qcom/venus/hfi_plat_bufs_v6.c:1242:5: warning: symbol
'bufreq_enc' was not declared. Should it be static?
Signed-off-by: Zou Wei
---
drivers/media/platform/qcom/venus/hfi_plat_bufs_v6.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/hfi_plat_bufs_v6.c
b/drivers/media/platform/qcom/venus/hfi_plat_bufs_v6.c
index 072e349..d43d1a5 100644
--- a/drivers/media/platform/qcom/venus/hfi_plat_bufs_v6.c
+++ b/drivers/media/platform/qcom/venus/hfi_plat_bufs_v6.c
@@ -1239,8 +1239,8 @@ static int bufreq_dec(struct hfi_plat_buffers_params
*params, u32 buftype,
return 0;
}
-int bufreq_enc(struct hfi_plat_buffers_params *params, u32 buftype,
- struct hfi_buffer_requirements *bufreq)
+static int bufreq_enc(struct hfi_plat_buffers_params *params, u32 buftype,
+ struct hfi_buffer_requirements *bufreq)
{
enum hfi_version version = params->version;
struct enc_bufsize_ops *enc_ops;
--
2.6.2
[PATCH 1/1] iommu/vt-d: Consolidate duplicate cache invaliation code
The pasid based IOTLB and devTLB invalidation code is duplicate in
several places. Consolidate them by using the common helpers.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/pasid.c | 18 ++--
drivers/iommu/intel/svm.c | 55 ++---
2 files changed, 11 insertions(+), 62 deletions(-)
diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c
index b92af83b79bd..f26cb6195b2c 100644
--- a/drivers/iommu/intel/pasid.c
+++ b/drivers/iommu/intel/pasid.c
@@ -456,20 +456,6 @@ pasid_cache_invalidation_with_pasid(struct intel_iommu
*iommu,
qi_submit_sync(iommu, &desc, 1, 0);
}
-static void
-iotlb_invalidation_with_pasid(struct intel_iommu *iommu, u16 did, u32 pasid)
-{
- struct qi_desc desc;
-
- desc.qw0 = QI_EIOTLB_PASID(pasid) | QI_EIOTLB_DID(did) |
- QI_EIOTLB_GRAN(QI_GRAN_NONG_PASID) | QI_EIOTLB_TYPE;
- desc.qw1 = 0;
- desc.qw2 = 0;
- desc.qw3 = 0;
-
- qi_submit_sync(iommu, &desc, 1, 0);
-}
-
static void
devtlb_invalidation_with_pasid(struct intel_iommu *iommu,
struct device *dev, u32 pasid)
@@ -514,7 +500,7 @@ void intel_pasid_tear_down_entry(struct intel_iommu *iommu,
struct device *dev,
clflush_cache_range(pte, sizeof(*pte));
pasid_cache_invalidation_with_pasid(iommu, did, pasid);
- iotlb_invalidation_with_pasid(iommu, did, pasid);
+ qi_flush_piotlb(iommu, did, pasid, 0, -1, 0);
/* Device IOTLB doesn't need to be flushed in caching mode. */
if (!cap_caching_mode(iommu->cap))
@@ -530,7 +516,7 @@ static void pasid_flush_caches(struct intel_iommu *iommu,
if (cap_caching_mode(iommu->cap)) {
pasid_cache_invalidation_with_pasid(iommu, did, pasid);
- iotlb_invalidation_with_pasid(iommu, did, pasid);
+ qi_flush_piotlb(iommu, did, pasid, 0, -1, 0);
} else {
iommu_flush_write_buffer(iommu);
}
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 18a9f05df407..033b25886e57 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -123,53 +123,16 @@ static void __flush_svm_range_dev(struct intel_svm *svm,
unsigned long address,
unsigned long pages, int ih)
{
- struct qi_desc desc;
+ struct device_domain_info *info = get_domain_info(sdev->dev);
- if (pages == -1) {
- desc.qw0 = QI_EIOTLB_PASID(svm->pasid) |
- QI_EIOTLB_DID(sdev->did) |
- QI_EIOTLB_GRAN(QI_GRAN_NONG_PASID) |
- QI_EIOTLB_TYPE;
- desc.qw1 = 0;
- } else {
- int mask = ilog2(__roundup_pow_of_two(pages));
-
- desc.qw0 = QI_EIOTLB_PASID(svm->pasid) |
- QI_EIOTLB_DID(sdev->did) |
- QI_EIOTLB_GRAN(QI_GRAN_PSI_PASID) |
- QI_EIOTLB_TYPE;
- desc.qw1 = QI_EIOTLB_ADDR(address) |
- QI_EIOTLB_IH(ih) |
- QI_EIOTLB_AM(mask);
- }
- desc.qw2 = 0;
- desc.qw3 = 0;
- qi_submit_sync(sdev->iommu, &desc, 1, 0);
-
- if (sdev->dev_iotlb) {
- desc.qw0 = QI_DEV_EIOTLB_PASID(svm->pasid) |
- QI_DEV_EIOTLB_SID(sdev->sid) |
- QI_DEV_EIOTLB_QDEP(sdev->qdep) |
- QI_DEIOTLB_TYPE;
- if (pages == -1) {
- desc.qw1 = QI_DEV_EIOTLB_ADDR(-1ULL >> 1) |
- QI_DEV_EIOTLB_SIZE;
- } else if (pages > 1) {
- /* The least significant zero bit indicates the size.
So,
-* for example, an "address" value of 0x12345f000 will
-* flush from 0x12344 to 0x12347 (256KiB). */
- unsigned long last = address + ((unsigned long)(pages -
1) << VTD_PAGE_SHIFT);
- unsigned long mask = __rounddown_pow_of_two(address ^
last);
-
- desc.qw1 = QI_DEV_EIOTLB_ADDR((address & ~mask) |
- (mask - 1)) | QI_DEV_EIOTLB_SIZE;
- } else {
- desc.qw1 = QI_DEV_EIOTLB_ADDR(address);
- }
- desc.qw2 = 0;
- desc.qw3 = 0;
- qi_submit_sync(sdev->iommu, &desc, 1, 0);
- }
+ if (WARN_ON(!pages))
+ return;
+
+ qi_flush_piotlb(sdev->iommu, sdev->did, svm->pasid, address, pages, ih);
+ if (info->ats_enabled)
+ qi_flush_dev_iotlb_pasid(sdev->iommu, sdev->sid, info->pfsid,
+svm->pasid, sdev->qdep, address,
+order_base_2(pages));
Re: [PATCH 1/4] tracing: add error_report trace points
On Thu, 14 Jan 2021 at 08:50, Alexander Potapenko wrote:
>
> On Wed, Jan 13, 2021 at 10:10 PM Steven Rostedt wrote:
> >
> > On Wed, 13 Jan 2021 10:16:54 +0100
> > Alexander Potapenko wrote:
> >
> > > +DECLARE_EVENT_CLASS(error_report_template,
> > > + TP_PROTO(const char *error_detector, unsigned long id),
> >
> > Instead of having a random string, as this should be used by a small finite
> > set of subsystems, why not make the above into an enum?
>
> You're probably right.
> I just thought it might be a good idea to minimize the effort needed
> from tools' authors to add these tracepoints to the tools (see the
> following two patches), and leave room for some extensibility (e.g.
> passing bug type together with the tool name etc.)
>
> > > + TP_ARGS(error_detector, id),
> > > + TP_STRUCT__entry(__field(const char *, error_detector)
> > > + __field(unsigned long, id)),
> > > + TP_fast_assign(__entry->error_detector = error_detector;
> > > +__entry->id = id;),
> > > + TP_printk("[%s] %lx", __entry->error_detector,
> >
> > Then the [%s] portion of this could also be just a __print_symbolic().
>
> We'll need to explicitly list the enum values once again in
> __print_symbolic(), right? E.g.:
>
> enum debugging_tool {
We need to use TRACE_DEFINE_ENUM().
> TOOL_KFENCE,
For consistency I would call the enum simply "ERROR_DETECTOR" as well.
(Hypothetically, there could also be an "error detector" that is not a
"debugging tool".)
> TOOL_KASAN,
> ...
> }
>
> TP_printk(__print_symbolic(__entry->error_detector, TOOL_KFENCE,
> TOOL_KASAN, ...),
It takes a list of val -> str. E.g.
__print_symbolic(__entry->error_detector, { TOOL_KFENCE, "KFENCE" }, {
TOOL_KASAN, "KASAN" }).
Looking around the kernel, sometimes this is simplified with macros,
but not sure if it's worth it. Typing the same thing 3 times is fine,
given this list won't grow really fast.
Thanks,
-- Marco
Re: SLUB: percpu partial object count is highly inaccurate, causing some memory wastage and maybe also worse tail latencies?
On Wed, 13 Jan 2021, Jann Horn wrote: > Some brainstorming: > > Maybe you could have an atomic counter in kmem_cache_cpu that tracks > the number of empty frozen pages that are associated with a specific > CPU? So the freeing slowpath would do its cmpxchg_double, and if the The latencies of these functions are so low that any additional counter will have significant performance impacts. An atomic counter would be waay out there. > You could additionally have a plain percpu counter, not tied to the The performance critical counters are already all per cpu. I enhanced the percpu subsystem specifically to support latency critical operations in the fast path of the slab allocators.
Re: [PATCH 07/10] dwc3: document gadget_max_speed
Mauro Carvalho Chehab writes: > This new field was added to struct dwc3_scratchpad_array, but > a documentation for it was missed: > > ../drivers/usb/dwc3/core.h:1259: warning: Function parameter or member > 'gadget_max_speed' not described in 'dwc3' > > Signed-off-by: Mauro Carvalho Chehab Thanks, Mauro. Acked-by: Felipe Balbi -- balbi signature.asc Description: PGP signature
[PATCH] drivers/usb/gadget/udc: Assign boolean values to a bool variable
Fix the following coccicheck warnings: ./drivers/usb/gadget/udc/udc-xilinx.c:1957:2-18: WARNING: Assignment of 0/1 to bool variable. Reported-by: Abaci Robot Signed-off-by: Jiapeng Zhong --- drivers/usb/gadget/udc/udc-xilinx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/udc-xilinx.c b/drivers/usb/gadget/udc/udc-xilinx.c index d5e9d20..77610b5 100644 --- a/drivers/usb/gadget/udc/udc-xilinx.c +++ b/drivers/usb/gadget/udc/udc-xilinx.c @@ -1954,7 +1954,7 @@ static void xudc_nonctrl_ep_handler(struct xusb_udc *udc, u8 epnum, if (intrstatus & (XUSB_STATUS_EP0_BUFF1_COMP_MASK << epnum)) ep->buffer0ready = 0; if (intrstatus & (XUSB_STATUS_EP0_BUFF2_COMP_MASK << epnum)) - ep->buffer1ready = 0; + ep->buffer1ready = false; if (list_empty(&ep->queue)) return; -- 1.8.3.1
Re: [PATCH 00/31] Rid W=1 warnings from Video
On Wed, 13 Jan 2021, Lee Jones wrote: > On Wed, 13 Jan 2021, Sam Ravnborg wrote: > >> Hi Lee, >> >> On Wed, Jan 13, 2021 at 02:49:38PM +, Lee Jones wrote: >> > This set is part of a larger effort attempting to clean-up W=1 >> > kernel builds, which are currently overwhelmingly riddled with >> > niggly little warnings. >> > >> > This patch-set clears all of the W=1 warnings currently residing >> > in drivers/video. >> >> I am sorry to say that I expect most of your nice patches to clash >> with patches that is already present in drm-misc-next. >> >> drivers/video/ are warning free with W=1 in drm-misc-next today. >> >> I do not know why drm-misc-next is not yet pullled into linux-next. > > Well that kinda sucks. What are the chances of that? > > Most of my patches fix issues that have been there for years! We auto-update the for-linux-next and for-linux-next-fixes branches, and they seem to be up-to-date [1]. How recent are the fixes, maybe because of this: [2]? BR, Jani. [1] https://cgit.freedesktop.org/drm/drm-misc [2] http://lore.kernel.org/r/20210114113107.62210...@canb.auug.org.au -- Jani Nikula, Intel Open Source Graphics Center
[PATCH] printk: kmsg_dump: revert msg_print_text() workaround
The old msg_print_text() function only filled up to size-1 bytes of
the buffer. A workaround for this quirky behavior was implemented
with commit c9dccacfccc7 ("printk: Do not lose last line in kmsg
buffer dump").
However, with commit 896fbe20b4e2 ("printk: use the lockless
ringbuffer"), msg_print_text() was replaced by record_print_text(),
which will fill the full buffer. Therefore, the workaround is now
incorrectly assuming less data can fit into the buffer. Revert the
workaround.
Fixes: 896fbe20b4e2 ("printk: use the lockless ringbuffer")
Signed-off-by: John Ogness
---
This patch is on top of
https://lkml.kernel.org/r/20210113164413.1599-1-john.ogn...@linutronix.de
and possibly could be squashed into that patch. However I recommend
keeping them separate since they affect kmsg_dump_get_buffer() in
different ways.
kernel/printk/printk.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 848b56efc9d7..489b9330f7f7 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3433,8 +3433,7 @@ bool kmsg_dump_get_buffer(struct kmsg_dumper *dumper,
bool syslog,
/* move first record forward until length fits into the buffer */
seq = dumper->cur_seq;
- while (l >= size && prb_read_valid_info(prb, seq,
- &info, &line_count)) {
+ while (l > size && prb_read_valid_info(prb, seq, &info, &line_count)) {
if (r.info->seq >= dumper->next_seq)
break;
l -= get_record_print_text_size(&info, line_count, syslog,
time);
--
2.20.1
Re: [PATCH v7 3/7] fixup! media: i2c: rdacm21: Break-out ov10640 initialization
Hi Jacopo,
On Thu, Jan 14, 2021 at 08:52:28AM +0100, Jacopo Mondi wrote:
> On Thu, Jan 14, 2021 at 01:23:25AM +0200, Laurent Pinchart wrote:
> > On Wed, Jan 13, 2021 at 07:55:01PM +0100, Jacopo Mondi wrote:
> > > The embedded OV490 ISP chip provides a secondary SCCB interface and
> > > two GPIO lines to control the connected OV10640 image sensor.
> > >
> > > Break out the OV10640 initialization from the OV490 initialization and
> > > explicitely control the powerdown and reset GPIOs. After the image
> >
> > s/explicitely/explicitly/
> >
> > > sensor has been hard reset, implement a more clear handling of the
> > > secondary SCCB interface to read the image sensor chip ID.
> > >
> > > Signed-off-by: Jacopo Mondi
> > > ---
> > > drivers/media/i2c/rdacm21.c | 75 ++---
> > > 1 file changed, 61 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/rdacm21.c b/drivers/media/i2c/rdacm21.c
> > > index 0428e3209463..944009687de5 100644
> > > --- a/drivers/media/i2c/rdacm21.c
> > > +++ b/drivers/media/i2c/rdacm21.c
> > > @@ -30,11 +30,24 @@
> > > #define OV490_PAGE_HIGH_REG 0xfffd
> > > #define OV490_PAGE_LOW_REG 0xfffe
> > >
> > > +/*
> > > + * The SCCB slave handling is undocumented; the registers naming scheme
> > > is
> > > + * totally arbitrary.
> > > + */
> > > +#define OV490_SCCB_SLAVE_WRITE 0x00
> > > +#define OV490_SCCB_SLAVE_READ0x01
> > > +#define OV490_SCCB_SLAVE0_DIR0x80195000
> > > +#define OV490_SCCB_SLAVE0_ADDR_HIGH 0x80195001
> > > +#define OV490_SCCB_SLAVE0_ADDR_LOW 0x80195002
> > > +
> > > #define OV490_DVP_CTRL3 0x80286009
> > >
> > > #define OV490_ODS_CTRL_FRAME_OUTPUT_EN 0x0c
> > > #define OV490_ODS_CTRL 0x8029d000
> > >
> > > +#define OV490_HOST_CMD 0x808000c0
> > > +#define OV490_HOST_CMD_TRIGGER 0xc1
> > > +
> > > #define OV490_ID_VAL 0x0490
> > > #define OV490_ID(_p, _v) _p) & 0xff) << 8) | ((_v) & 0xff))
> > > #define OV490_PID0x8080300a
> > > @@ -42,12 +55,22 @@
> > > #define OV490_PID_TIMEOUT20
> > > #define OV490_OUTPUT_EN_TIMEOUT 300
> > >
> > > +#define OV490_GPIO0_RESETB 0x01
> >
> > Shouldn't this be named just OV490_GPIO0 ? The fact that it's connected
> > to the RESETB signal of the OV10640 is board-specific, not an OV490
> > intrinsic property.
> >
> > BIT(0) ?
> >
> > > +#define OV490_SPWDN0 0x01
> >
> > Same here.
> >
>
> Correct, I'll fix...
>
> > > +#define OV490_GPIO_SEL0 0x80800050
> > > +#define OV490_GPIO_SEL1 0x80800051
> > > +#define OV490_GPIO_DIRECTION00x80800054
> > > +#define OV490_GPIO_DIRECTION10x80800055
> > > +#define OV490_GPIO_OUTPUT_VALUE0 0x80800058
> > > +#define OV490_GPIO_OUTPUT_VALUE1 0x80800059
> > > +
> > > #define OV490_ISP_HSIZE_LOW 0x80820060
> > > #define OV490_ISP_HSIZE_HIGH 0x80820061
> > > #define OV490_ISP_VSIZE_LOW 0x80820062
> > > #define OV490_ISP_VSIZE_HIGH 0x80820063
> > >
> > > -#define OV10640_ID_LOW 0xa6
> > > +#define OV10640_ID_HIGH 0xa6
> > > +#define OV10640_CHIP_ID 0x300a
> > > #define OV10640_PIXEL_RATE 5500
> > >
> > > struct rdacm21_device {
> > > @@ -306,6 +329,39 @@ static const struct v4l2_subdev_ops
> > > rdacm21_subdev_ops = {
> > > .pad= &rdacm21_subdev_pad_ops,
> > > };
> > >
> > > +static int ov10640_initialize(struct rdacm21_device *dev)
> > > +{
> > > + u8 val;
> > > +
> > > + /* Power-up OV10640 by setting RESETB and PWDNB pins high. */
> > > + ov490_write_reg(dev, OV490_GPIO_SEL0, OV490_GPIO0_RESETB);
> > > + ov490_write_reg(dev, OV490_GPIO_SEL1, OV490_SPWDN0);
> > > + ov490_write_reg(dev, OV490_GPIO_DIRECTION0, OV490_GPIO0_RESETB);
> > > + ov490_write_reg(dev, OV490_GPIO_DIRECTION1, OV490_SPWDN0);
> > > + ov490_write_reg(dev, OV490_GPIO_OUTPUT_VALUE0, OV490_GPIO0_RESETB);
> > > + ov490_write_reg(dev, OV490_GPIO_OUTPUT_VALUE0, OV490_SPWDN0);
> > > + usleep_range(3000, 5000);
> >
> > So the OV490 firmware doesn't handle this ?
>
> Do you mean the delay or the reset of the ov10640 ?
>
> I need the delay here otherwise reading the ov10640 id fails below.
> Same for the reset :)
>
> About reset, it seems it does not... The ov490 settings are loaded
> from an EEPROM but I don't know what it content is, maybe it's just
> about the imaging-related settings ?
I meant the configuration of the GPIOs and the reset of the sensor, yes.
I was just curious, as I was expecting the firmware to handle all the
platform-specific data.
> > > +
> > > + /* Read OV10640 ID to test communications. */
> > > + ov490_write_reg(dev, OV490_SCCB_SLAVE0_DIR, OV490_SCCB_SLAVE_READ);
> > > + ov490_write_reg(dev, OV490_SCCB_SLAVE0_ADDR
Re: [PATCH v2 00/16] introduce generic IOCTL interface for RPMsg channels management
Hi Mathieu, On 1/13/21 9:31 PM, Mathieu Poirier wrote: > Hi Arnaud, > > [...] > >> >> Arnaud Pouliquen (16): >> rpmsg: introduce RPMsg control driver for channel creation >> rpmsg: add RPMsg control API to register service >> rpmsg: add override field in channel info >> rpmsg: ctrl: implement the ioctl function to create device >> rpmsg: ns: initialize channel info override field >> rpmsg: add helper to register the rpmsg ctrl device >> rpmsg: char: clean up rpmsg class >> rpmsg: char: make char rpmsg a rpmsg device without the control part >> rpmsg: char: register RPMsg raw service to the ioctl interface. >> rpmsg: char: allow only one endpoint per device >> rpmsg: char: check destination address is not null >> rpmsg: virtio: use the driver_override in channel creation ops >> rpmsg: virtio: probe the rpmsg_ctl device >> rpmsg: glink: add create and release rpmsg channel ops >> rpmsg: smd: add create and release rpmsg channel ops >> rpmsg: replace rpmsg_chrdev_register_device use >> >> drivers/rpmsg/Kconfig | 8 + >> drivers/rpmsg/Makefile| 1 + >> drivers/rpmsg/qcom_glink_native.c | 96 +++-- >> drivers/rpmsg/qcom_smd.c | 59 +- >> drivers/rpmsg/rpmsg_char.c| 246 ++- >> drivers/rpmsg/rpmsg_ctrl.c| 320 ++ >> drivers/rpmsg/rpmsg_internal.h| 14 -- >> drivers/rpmsg/rpmsg_ns.c | 1 + >> drivers/rpmsg/virtio_rpmsg_bus.c | 38 +++- >> include/linux/rpmsg.h | 40 >> include/uapi/linux/rpmsg.h| 14 ++ >> 11 files changed, 606 insertions(+), 231 deletions(-) >> create mode 100644 drivers/rpmsg/rpmsg_ctrl.c > > I am finally coming around to review this set. I see that you already had an > extensive conversation with Bjorn - did you want me to have a look as well or > should I wait for the next revision? Based on Bjorn first feedback, my understanding is that the management based on create/destroy channel does not match with the QCOM RPMsg backend implementation. I think this is the blocking point of my V2 implementation. Before sending a new revision i would hope that we have a roundtable discussion to clarify the direction to move forward, to avoid sending useless revisions. As discussed in [1], there are different alternatives, that probably depend on the features we expect to support. I tried to sum-up the requirement I have in mind in [1]. The 2 main directions I can see are: - rework the rpmsg_char to match with all rpmsg backend (V2 implementation) to be honest i don't know how to move forward in this direction as QCOM and virtio backends are rather different. - not modify the rpmsg_char but create the rpmsg_ctrl (and perhaps also a rpmsg_raw for a /dev/rpmsg data interface) that would use the create/destroy channel such as the rpmsg ns (V1 implementation). one advantage of this solution is that this does not impact QCOM drivers. one drawback is that we duplicate the code. [1] https://patchwork.kernel.org/project/linux-remoteproc/patch/20201222105726.16906-5-arnaud.pouliq...@foss.st.com/ [2] https://patchwork.kernel.org/project/linux-remoteproc/list/?series=327277 Thanks, Arnaud > > Thanks, > Mathieu > >> >> -- >> 2.17.1 >>
[PATCH] fs/cifs: Replace one-element array with flexible-array member.
Fix the following coccicheck warning:
./fs/cifs/smb2pdu.h:1711:8-16: WARNING use flexible-array
member instead(https://www.kernel.org/doc/html/latest/
process/deprecated.html#zero-length-and-one-element-arrays)
./fs/cifs/smb2pdu.h:1509:8-14: WARNING use flexible-array
member instead(https://www.kernel.org/doc/html/latest/
process/deprecated.html#zero-length-and-one-element-arrays)
./fs/cifs/smb2pdu.h:1486:8-14: WARNING use flexible-array
member instead(https://www.kernel.org/doc/html/latest/
process/deprecated.html#zero-length-and-one-element-arrays)
./fs/cifs/smb2pdu.h:1478:8-14: WARNING use flexible-array
member instead(https://www.kernel.org/doc/html/latest/
process/deprecated.html#zero-length-and-one-element-arrays)
./fs/cifs/smb2pdu.h:1437:8-14: WARNING use flexible-array
member instead(https://www.kernel.org/doc/html/latest/process
/deprecated.html#zero-length-and-one-element-arrays)
./fs/cifs/smb2pdu.h:1429:8-14: WARNING use flexible-array
member instead(https://www.kernel.org/doc/html/latest/
process/deprecated.html#zero-length-and-one-element-arrays)
./fs/cifs/smb2pdu.h:1389:26-31: WARNING use flexible-array
member instead(https://www.kernel.org/doc/html/latest/process
/deprecated.html#zero-length-and-one-element-arrays)
./fs/cifs/smb2pdu.h:1389:26-31: WARNING use flexible-array
member instead(https://www.kernel.org/doc/html/latest/process
/deprecated.html#zero-length-and-one-element-arrays)
./fs/cifs/smb2pdu.h:1366:6-12: WARNING use flexible-array
member instead(https://www.kernel.org/doc/html/latest/process
/deprecated.html#zero-length-and-one-element-arrays)
./fs/cifs/smb2pdu.h:1330:8-14: WARNING use flexible-array
member instead(https://www.kernel.org/doc/html/latest/process
/deprecated.html#zero-length-and-one-element-arrays)
./fs/cifs/smb2pdu.h:1319:8-14: WARNING use flexible-array
member instead(https://www.kernel.org/doc/html/latest/process
/deprecated.html#zero-length-and-one-element-arrays)
./fs/cifs/smb2pdu.h:1299:8-14: WARNING use flexible-array
member instead(https://www.kernel.org/doc/html/latest/process
/deprecated.html#zero-length-and-one-element-arrays)
./fs/cifs/smb2pdu.h:1284:8-14: WARNING use flexible-array
member instead(https://www.kernel.org/doc/html/latest/process
/deprecated.html#zero-length-and-one-element-arrays)
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Zhong
---
fs/cifs/smb2pdu.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/fs/cifs/smb2pdu.h b/fs/cifs/smb2pdu.h
index 204a622..7c9ac5d 100644
--- a/fs/cifs/smb2pdu.h
+++ b/fs/cifs/smb2pdu.h
@@ -1289,7 +1289,7 @@ struct smb2_read_plain_req {
__le32 RemainingBytes;
__le16 ReadChannelInfoOffset;
__le16 ReadChannelInfoLength;
- __u8 Buffer[1];
+ __u8 Buffer[];
} __packed;
/* Read flags */
@@ -1304,7 +1304,7 @@ struct smb2_read_rsp {
__le32 DataLength;
__le32 DataRemaining;
__u32 Flags;
- __u8 Buffer[1];
+ __u8 Buffer[];
} __packed;
/* For write request Flags field below the following flags are defined: */
@@ -1324,7 +1324,7 @@ struct smb2_write_req {
__le16 WriteChannelInfoOffset;
__le16 WriteChannelInfoLength;
__le32 Flags;
- __u8 Buffer[1];
+ __u8 Buffer[];
} __packed;
struct smb2_write_rsp {
@@ -1335,7 +1335,7 @@ struct smb2_write_rsp {
__le32 DataLength;
__le32 DataRemaining;
__u32 Reserved2;
- __u8 Buffer[1];
+ __u8 Buffer[];
} __packed;
/* notify flags */
@@ -1371,7 +1371,7 @@ struct smb2_change_notify_rsp {
__le16 StructureSize; /* Must be 9 */
__le16 OutputBufferOffset;
__le32 OutputBufferLength;
- __u8Buffer[1]; /* array of file notify structs */
+ __u8Buffer[]; /* array of file notify structs */
} __packed;
#define SMB2_LOCKFLAG_SHARED_LOCK 0x0001
@@ -1394,7 +1394,7 @@ struct smb2_lock_req {
__u64 PersistentFileId; /* opaque endianness */
__u64 VolatileFileId; /* opaque endianness */
/* Followed by at least one */
- struct smb2_lock_element locks[1];
+ struct smb2_lock_element locks[];
} __packed;
struct smb2_lock_rsp {
@@ -1434,7 +1434,7 @@ struct smb2_query_directory_req {
__le16 FileNameOffset;
__le16 FileNameLength;
__le32 OutputBufferLength;
- __u8 Buffer[1];
+ __u8 Buffer[];
} __packed;
struct smb2_query_directory_rsp {
@@ -1442,7 +1442,7 @@ struct smb2_query_directory_rsp {
__le16 StructureSize; /* Must be 9 */
__le16 OutputBufferOffset;
__le32 OutputBufferLength;
- __u8 Buffer[1];
+ __u8 Buffer[];
} __packed;
/* Possible InfoType values */
@@ -1483,7 +1483,7 @@ struct smb2_query_info_req {
__le32 Flags;
__u64 PersistentFileId; /* opaque endianness */
__u64 VolatileFileId; /* opaque endianness */
- __u8 Buffer[1];
+ __u8 Buffer[];
} __pac
[PATCH] fs/cifs: Assign boolean values to a bool variable
Fix the following coccicheck warnings: ./fs/cifs/connect.c:3386:2-21: WARNING: Assignment of 0/1 to bool variable. Reported-by: Abaci Robot Signed-off-by: Jiapeng Zhong --- fs/cifs/connect.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c index b9df855..8fbb5ea 100644 --- a/fs/cifs/connect.c +++ b/fs/cifs/connect.c @@ -2195,7 +2195,7 @@ static int match_tcon(struct cifs_tcon *tcon, struct smb3_fs_context *ctx) if (ses->server->capabilities & SMB2_GLOBAL_CAP_DIRECTORY_LEASING) tcon->nohandlecache = ctx->nohandlecache; else - tcon->nohandlecache = 1; + tcon->nohandlecache = true; tcon->nodelete = ctx->nodelete; tcon->local_lease = ctx->local_lease; INIT_LIST_HEAD(&tcon->pending_opens); -- 1.8.3.1
Re: [RFC PATCH v3 6/6] of: Add plumbing for restricted DMA pool
On Wed, Jan 13, 2021 at 7:48 AM Florian Fainelli wrote:
>
> On 1/5/21 7:41 PM, Claire Chang wrote:
> > If a device is not behind an IOMMU, we look up the device node and set
> > up the restricted DMA when the restricted-dma-pool is presented.
> >
> > Signed-off-by: Claire Chang
> > ---
>
> [snip]
>
> > +int of_dma_set_restricted_buffer(struct device *dev)
> > +{
> > + struct device_node *node;
> > + int count, i;
> > +
> > + if (!dev->of_node)
> > + return 0;
> > +
> > + count = of_property_count_elems_of_size(dev->of_node, "memory-region",
> > + sizeof(phandle));
>
> You could have an early check for count < 0, along with an error
> message, if that is deemed useful.
>
> > + for (i = 0; i < count; i++) {
> > + node = of_parse_phandle(dev->of_node, "memory-region", i);
> > + if (of_device_is_compatible(node, "restricted-dma-pool"))
>
> And you may want to add here an of_device_is_available(node). A platform
> that provides the Device Tree firmware and try to support multiple
> different SoCs may try to determine if an IOMMU is present, and if it
> is, it could be marking the restriced-dma-pool region with a 'status =
> "disabled"' property, or any variant of that scheme.
This function is called only when there is no IOMMU present (check in
drivers/of/device.c). I can still add of_device_is_available(node)
here if you think it's helpful.
>
> > + return of_reserved_mem_device_init_by_idx(
> > + dev, dev->of_node, i);
>
> This does not seem to be supporting more than one memory region, did not
> you want something like instead:
>
> ret = of_reserved_mem_device_init_by_idx(...);
> if (ret)
> return ret;
>
Yes. This implement only supports one restriced-dma-pool memory region
with the assumption that there is only one memory region with the
compatible string, restricted-dma-pool, in the dts. IIUC, it's similar
to shared-dma-pool.
> > + }
> > +
> > + return 0;
> > +}
> > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > index aedfaaafd3e7..e2c7409956ab 100644
> > --- a/drivers/of/device.c
> > +++ b/drivers/of/device.c
> > @@ -182,6 +182,10 @@ int of_dma_configure_id(struct device *dev, struct
> > device_node *np,
> > arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
> >
> > dev->dma_range_map = map;
> > +
> > + if (!iommu)
> > + return of_dma_set_restricted_buffer(dev);
> > +
> > return 0;
> > }
> > EXPORT_SYMBOL_GPL(of_dma_configure_id);
> > diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
> > index d9e6a324de0a..28a2dfa197ba 100644
> > --- a/drivers/of/of_private.h
> > +++ b/drivers/of/of_private.h
> > @@ -161,12 +161,17 @@ struct bus_dma_region;
> > #if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_HAS_DMA)
> > int of_dma_get_range(struct device_node *np,
> > const struct bus_dma_region **map);
> > +int of_dma_set_restricted_buffer(struct device *dev);
> > #else
> > static inline int of_dma_get_range(struct device_node *np,
> > const struct bus_dma_region **map)
> > {
> > return -ENODEV;
> > }
> > +static inline int of_dma_get_restricted_buffer(struct device *dev)
> > +{
> > + return -ENODEV;
> > +}
> > #endif
> >
> > #endif /* _LINUX_OF_PRIVATE_H */
> >
>
>
> --
> Florian
Re: [PATCH v2 1/2] rtc: pcf2127: Disable Power-On Reset Override
On 14.01.21 09:05, Uwe Kleine-König wrote:
On Wed, Jan 13, 2021 at 12:27:41PM +0100, Philipp Rosenberger wrote:
To resume normal operation after a total power loss (no or empty
battery) the "Power-On Reset Override (PORO)" facility needs to be
disabled.
As the oscillator may take a long time (200 ms to 2 s) to resume normal
operation. The default behaviour is to use the PORO facility.
I'd write instead: The register reset value sets PORO enabled and the
data sheet recommends setting it to disabled for normal operation.
Sounds good, I will rephrase it.
In my eyes having a reset default value that is unsuitable for
production use is just another bad design choice of this chip. At least
now this is known and can be somewhat fixed in software. :-\
Yes, had my fair share of WTF moments with this chip.
But with the PORO active no interrupts are generated on the interrupt
pin (INT).
This sentence about no interrupts is your observation, or does this base
on some authoritative source (datasheet, FAE or similar)?
Yes this is only may observation. I tested this with the OM13513
demoboard with PCF2127 and pcf2129. So I should rephrase it to something
like this:
Some testes suggests that no interrupts are generated on the interrupt
pin if the PORP is active.
Signed-off-by: Philipp Rosenberger
---
drivers/rtc/rtc-pcf2127.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
index 39a7b5116aa4..378b1ce812d6 100644
--- a/drivers/rtc/rtc-pcf2127.c
+++ b/drivers/rtc/rtc-pcf2127.c
@@ -26,6 +26,7 @@
/* Control register 1 */
#define PCF2127_REG_CTRL1 0x00
+#define PCF2127_BIT_CTRL1_POR_OVRD BIT(3)
#define PCF2127_BIT_CTRL1_TSF1BIT(4)
/* Control register 2 */
#define PCF2127_REG_CTRL2 0x01
@@ -612,6 +613,23 @@ static int pcf2127_probe(struct device *dev, struct regmap
*regmap,
ret = devm_rtc_nvmem_register(pcf2127->rtc, &nvmem_cfg);
}
+ /*
+* The "Power-On Reset Override" facility prevents the RTC to do a reset
+* after power on. For normal operation the PORO must be disabled.
+*/
+ regmap_clear_bits(pcf2127->regmap, PCF2127_REG_CTRL1,
+ PCF2127_BIT_CTRL1_POR_OVRD);
+ /*
+* If the PORO can't be disabled, just move on. The RTC should
+* work fine, but functions like watchdog and alarm interrupts might
+* not work. There will be no interrupt generated on the interrupt pin.
+*/
+ ret = regmap_test_bits(pcf2127->regmap, PCF2127_REG_CTRL1,
PCF2127_BIT_CTRL1_POR_OVRD);
+ if (ret <= 0) {
+ dev_err(dev, "%s: can't disable PORO (ctrl1).\n", __func__);
+ dev_warn(dev, "Watchdog and alarm functions might not work
properly\n");
I would not emit two messages here. Also including __func__ isn't so
nice IMHO. (Great for debugging, but not in production code IMHO.)
Yes, I dislike the style of the messages in this module. I just thought
to keep it consistent.
I'm thinking of rewriting this driver as MFD driver. We use the CLKOUT
for some products. So maybe a RTC, watchdog and clock driver on top of
an MFD. But I'm not sure if it is really a good idea. The behavior of
the chip to disable the watchdog when reading ctrl2 (i think it was)
giving me a headache.
We should consider a Cc: to stable.
Yes, this is a good idea. I need to apply this to 5.4 anyway, as we
develop a product with 5.4.
Best regards
Uwe
Thanks and Best Regards,
Philipp
[PATCH] fs/cifs: Simplify bool comparisoni.
Fix the follow coccicheck warnings:
./fs/cifs/connect.c: WARNING: Comparison of 0/1 to bool variable
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Zhong
---
fs/cifs/connect.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index b9df855..b7869a2 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2628,7 +2628,7 @@ void reset_cifs_unix_caps(unsigned int xid, struct
cifs_tcon *tcon,
} else if (ctx)
tcon->unix_ext = 1; /* Unix Extensions supported */
- if (tcon->unix_ext == 0) {
+ if (!tcon->unix_ext) {
cifs_dbg(FYI, "Unix extensions disabled so not set on
reconnect\n");
return;
}
@@ -3740,7 +3740,7 @@ static void delayed_free(struct rcu_head *p)
if (!ses->binding) {
ses->capabilities = server->capabilities;
- if (linuxExtEnabled == 0)
+ if (!linuxExtEnabled)
ses->capabilities &= (~server->vals->cap_unix);
if (ses->auth_key.response) {
--
1.8.3.1
Re: [PATCH 00/31] Rid W=1 warnings from Video
On Thu, Jan 14, 2021 at 10:04 AM Jani Nikula wrote: > > On Wed, 13 Jan 2021, Lee Jones wrote: > > On Wed, 13 Jan 2021, Sam Ravnborg wrote: > > > >> Hi Lee, > >> > >> On Wed, Jan 13, 2021 at 02:49:38PM +, Lee Jones wrote: > >> > This set is part of a larger effort attempting to clean-up W=1 > >> > kernel builds, which are currently overwhelmingly riddled with > >> > niggly little warnings. > >> > > >> > This patch-set clears all of the W=1 warnings currently residing > >> > in drivers/video. > >> > >> I am sorry to say that I expect most of your nice patches to clash > >> with patches that is already present in drm-misc-next. > >> > >> drivers/video/ are warning free with W=1 in drm-misc-next today. > >> > >> I do not know why drm-misc-next is not yet pullled into linux-next. > > > > Well that kinda sucks. What are the chances of that? > > > > Most of my patches fix issues that have been there for years! I planned to go through them all today, let's see what's still needed. > We auto-update the for-linux-next and for-linux-next-fixes branches, and > they seem to be up-to-date [1]. It only happened last week instead of right after -rc1 due to some confusion, but it should have been in linux-next for a few days already. > How recent are the fixes, maybe because of this: [2]? > > BR, > Jani. > > > [1] https://cgit.freedesktop.org/drm/drm-misc > [2] http://lore.kernel.org/r/20210114113107.62210...@canb.auug.org.au Patch for that just got committted, so this shouldn't be too big a window for drm-misc-next to be excluded should have been very small. -Daniel > > -- > Jani Nikula, Intel Open Source Graphics Center > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool
On Wed, Jan 13, 2021 at 8:42 PM Christoph Hellwig wrote:
>
> > +#ifdef CONFIG_SWIOTLB
> > + struct io_tlb_mem *dma_io_tlb_mem;
> > #endif
>
> Please add a new config option for this code instead of always building
> it when swiotlb is enabled.
>
> > +static int swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t
> > start,
> > +size_t size)
>
> Can you split the refactoring in swiotlb.c into one or more prep
> patches?
>
> > +static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
> > + struct device *dev)
> > +{
> > + struct io_tlb_mem *mem = rmem->priv;
> > + int ret;
> > +
> > + if (dev->dma_io_tlb_mem)
> > + return -EBUSY;
> > +
> > + if (!mem) {
> > + mem = kzalloc(sizeof(*mem), GFP_KERNEL);
> > + if (!mem)
> > + return -ENOMEM;
>
> What is the calling convention here that allows for a NULL and non-NULL
> private data?
Since multiple devices can share the same pool, the private data,
io_tlb_mem struct, will be initialized by the first device attached to
it.
This is similar to rmem_dma_device_init() in kernel/dma/coherent.c.
I'll add a comment for it in next version.
Re: Question on workqueue: Manually break affinity on hotplug
On Thu, Jan 14, 2021 at 08:03:23AM +, Zhang, Qiang wrote:
> Hello Peter
>
> Excuse me, I have some questions for you, about a description of this change:
>
> ''Don't rely on the scheduler to force break affinity for us -- it will
> stop doing that for per-cpu-kthreads."
>
> this mean when cpuhotplug, scheduler do not change affinity for
> per-cpu-kthread's task, if we not active setting affinity?
> but if per-cpu-kthread's task is not run state, when wake up, will reset
> it's affinity, this is done automatically.
>
> or is it, this place modified to fit the new one hotplug mechanism which
> ("sched/hotplug: Consolidate task migration on CPU unplug")?
https://lkml.kernel.org/r/20201214155457.3430-1-jiangshan...@gmail.com
https://lkml.kernel.org/r/20201218170919.2950-1-jiangshan...@gmail.com
https://lkml.kernel.org/r/20201226025117.2770-1-jiangshan...@gmail.com
https://lkml.kernel.org/r/2021052638.2417-1-jiangshan...@gmail.com
https://lkml.kernel.org/r/20210112144344.850850...@infradead.org
Re: [PATCH] Documentation/llvm: Add a section about supported architectures
On Thu, Jan 14, 2021 at 3:23 AM Nathan Chancellor wrote: > > A clean "make -skj24 htmldocs" takes me a little over three minutes or > so on my Ryzen 9 3900X. Just to give some perspective. Oh, wow, that's something... Thanks a lot for adding this: Reviewed-by: Miguel Ojeda Cheers, Miguel
[PATCH 1/1] iommu/vt-d: Add qi_submit trace event
This adds a new trace event to track the submissions of requests to the
invalidation queue. This event will provide the information like:
- IOMMU name
- Invalidation type
- Descriptor raw data
A sample output like:
| qi_submit: iotlb_inv dmar1: 0x100e2 0x0 0x0 0x0
| qi_submit: dev_tlb_inv dmar1: 0x13 0x7001 0x0 0x0
| qi_submit: iotlb_inv dmar2: 0x800f2 0xf9a5 0x0 0x0
This will be helpful for queued invalidation related debugging.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel/dmar.c | 3 +++
include/trace/events/intel_iommu.h | 37 ++
2 files changed, 40 insertions(+)
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 004feaed3c72..bd51f33642e0 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "../irq_remapping.h"
@@ -1307,6 +1308,8 @@ int qi_submit_sync(struct intel_iommu *iommu, struct
qi_desc *desc,
offset = ((index + i) % QI_LENGTH) << shift;
memcpy(qi->desc + offset, &desc[i], 1 << shift);
qi->desc_status[(index + i) % QI_LENGTH] = QI_IN_USE;
+ trace_qi_submit(iommu, desc[i].qw0, desc[i].qw1,
+ desc[i].qw2, desc[i].qw3);
}
qi->desc_status[wait_index] = QI_IN_USE;
diff --git a/include/trace/events/intel_iommu.h
b/include/trace/events/intel_iommu.h
index 112bd06487bf..aad2ff0c1e2e 100644
--- a/include/trace/events/intel_iommu.h
+++ b/include/trace/events/intel_iommu.h
@@ -135,6 +135,43 @@ DEFINE_EVENT(dma_map_sg, bounce_map_sg,
struct scatterlist *sg),
TP_ARGS(dev, index, total, sg)
);
+
+TRACE_EVENT(qi_submit,
+ TP_PROTO(struct intel_iommu *iommu, u64 qw0, u64 qw1, u64 qw2, u64 qw3),
+
+ TP_ARGS(iommu, qw0, qw1, qw2, qw3),
+
+ TP_STRUCT__entry(
+ __field(u64, qw0)
+ __field(u64, qw1)
+ __field(u64, qw2)
+ __field(u64, qw3)
+ __string(iommu, iommu->name)
+ ),
+
+ TP_fast_assign(
+ __assign_str(iommu, iommu->name);
+ __entry->qw0 = qw0;
+ __entry->qw1 = qw1;
+ __entry->qw2 = qw2;
+ __entry->qw3 = qw3;
+ ),
+
+ TP_printk("%s %s: 0x%llx 0x%llx 0x%llx 0x%llx",
+ __print_symbolic(__entry->qw0 & 0xf,
+ { QI_CC_TYPE,"cc_inv" },
+ { QI_IOTLB_TYPE, "iotlb_inv" },
+ { QI_DIOTLB_TYPE,"dev_tlb_inv" },
+ { QI_IEC_TYPE, "iec_inv" },
+ { QI_IWD_TYPE, "inv_wait" },
+ { QI_EIOTLB_TYPE,"p_iotlb_inv" },
+ { QI_PC_TYPE,"pc_inv" },
+ { QI_DEIOTLB_TYPE, "p_dev_tlb_inv" },
+ { QI_PGRP_RESP_TYPE, "page_grp_resp" }),
+ __get_str(iommu),
+ __entry->qw0, __entry->qw1, __entry->qw2, __entry->qw3
+ )
+);
#endif /* _TRACE_INTEL_IOMMU_H */
/* This part must be outside protection */
--
2.25.1
Re: [PATCH 1/2] PCI/ASPM: Disable ASPM until its LTR and L1ss state is restored
On Thu, Jan 14, 2021 at 7:54 AM Bjorn Helgaas wrote: > > On Wed, Jan 13, 2021 at 01:16:05PM +1100, Victor Ding wrote: > > On Wed, Jan 13, 2021 at 9:32 AM Bjorn Helgaas wrote: > > > On Tue, Jan 12, 2021 at 04:02:04AM +, Victor Ding wrote: > > > > Right after powering up, the device may have ASPM enabled; however, > > > > its LTR and/or L1ss controls may not be in the desired states; hence, > > > > the device may enter L1.2 undesirably and cause resume performance > > > > penalty. This is especially problematic if ASPM related control > > > > registers are modified before a suspension. > > > > > > s/L1ss/L1SS/ (several occurrences) to match existing usage. > > > > > I'll update it in the next version. > > > > > > > Therefore, ASPM should disabled until its LTR and L1ss states are > > > > fully restored. > > > > > > > > Signed-off-by: Victor Ding > > > > --- > > > > > > > > drivers/pci/pci.c | 11 +++ > > > > drivers/pci/pci.h | 2 ++ > > > > drivers/pci/pcie/aspm.c | 2 +- > > > > 3 files changed, 14 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > > > > index eb323af34f1e..428de433f2e6 100644 > > > > --- a/drivers/pci/pci.c > > > > +++ b/drivers/pci/pci.c > > > > @@ -1660,6 +1660,17 @@ void pci_restore_state(struct pci_dev *dev) > > > > if (!dev->state_saved) > > > > return; > > > > > > > > + /* > > > > + * Right after powering up, the device may have ASPM enabled; > > > > > > I think this could be stated more precisely. "Right after powering > > > up," ASPM should be *disabled* because ASPM Control in the Link > > > Control register powers up as zero (disabled). > > > > > Good suggestion; I'll reword in the next version. > > However, ASPM should be *disabled* for the opposite reason - ASPM Control > > in the Link Control register *may* power as non-zero (enabled). > > (More answered in the next section) > > > > > > > + * however, its LTR and/or L1ss controls may not be in the desired > > > > + * states; as a result, the device may enter L1.2 undesirably and > > > > + * cause resume performance penalty. > > > > + * Therefore, ASPM is disabled until its LTR and L1ss states are > > > > + * fully restored. > > > > + * (enabling ASPM is part of pci_restore_pcie_state) > > > > > > If we're enabling L1.2 before LTR has been configured, that's > > > definitely a bug. But I don't see how that happens. The current code > > > looks like: > > > > > > pci_restore_state > > > pci_restore_ltr_state > > > pci_write_config_word(dev, ltr + PCI_LTR_MAX_SNOOP_LAT, *cap++) > > > pci_write_config_word(dev, ltr + PCI_LTR_MAX_NOSNOOP_LAT, *cap++) > > > pci_restore_aspm_l1ss_state > > > pci_write_config_dword(dev, aspm_l1ss + PCI_L1SS_CTL1, *cap++) > > > pci_restore_pcie_state > > > pcie_capability_write_word(dev, PCI_EXP_LNKCTL, cap[i++]) > > > > > > We *do* restore PCI_L1SS_CTL1, which contains "ASPM L1.2 Enable", > > > before we restore PCI_EXP_LNKCTL, which contains "ASPM Control", but I > > > don't think "ASPM L1.2 Enable" by itself should be enough to allow > > > hardware to enter L1.2. > > > > > > Reading PCIe r5.0, sec 5.5.1, it seems like hardware should ignore the > > > PCI_L1SS_CTL1 bits unless ASPM L1 entry is enabled in PCI_EXP_LNKCTL. > > > > > > What am I missing? > > > > > Correct; however, PCI_EXP_LNKCTL may power up as non-zero, i.e. has > > ASPM Control enabled. BIOS may set PCI_EXP_LNKCTL (and > > PCI_L1SS_CTL1) before Kernel takes control. When BIOS does so, there > > is a brief period between powering up and Kernel restoring LTR state > > that L1.2 is enabled but LTR isn't configured. > > IIUC you're saying that ASPM Control powers up as zero, but BIOS > enables ASPM before transferring control to the OS. That makes sense, > but I wouldn't describe that as "the device powering up with ASPM > enabled." > Correct. > > If BIOS enables L1SS (specifically, if it enables L1.2) when LTR > hasn't been configured, that sounds like a BIOS defect. > Very good point. I'll withdraw this patch then.
Re: [PATCH 2/2] mmc: sdhci-pci-gli: Disable ASPM during a suspension
On Thu, Jan 14, 2021 at 8:48 AM Bjorn Helgaas wrote: > > [+cc Rafael, suspend/resume expert] > > On Wed, Jan 13, 2021 at 01:16:23PM +1100, Victor Ding wrote: > > On Wed, Jan 13, 2021 at 9:38 AM Bjorn Helgaas wrote: > > > On Tue, Jan 12, 2021 at 04:02:05AM +, Victor Ding wrote: > > > > GL9750 has a 3100us PortTPowerOnTime; however, it enters L1.2 after > > > > only ~4us inactivity per PCIe trace. During a suspend/resume process, > > > > PCI access operations are frequently longer than 4us apart. > > > > Therefore, the device frequently enters and leaves L1.2 during this > > > > process, causing longer than desirable suspend/resume time. The total > > > > time cost due to this L1.2 exit latency could add up to ~200ms. > > > > > > > > Considering that PCI access operations are fairly close to each other > > > > (though sometimes > 4us), the actual time the device could stay in > > > > L1.2 is negligible. Therefore, the little power-saving benefit from > > > > ASPM during suspend/resume does not overweight the performance > > > > degradation caused by long L1.2 exit latency. > > > > > > > > Therefore, this patch proposes to disable ASPM during a suspend/resume > > > > process. > > > > > > This sounds like an interesting idea, but it doesn't seem like > > > anything that's really device-dependent. Drivers should not need to > > > be involved in PCI configuration at this level, and they shouldn't > > > read/write registers like PCI_EXP_LNKCTL directly. > > > > > > If we need to disable ASPM during suspend, I'd rather do it in the PCI > > > core so all devices can benefit and drivers don't need to worry about > > > it. > > > > > Good point. In theory all devices could encounter this issue, and it > > more-likely occurs on those with low entry timer but high exit latency. > > GL9750 is the only one I have access to that has such characteristics. > > > > I think we should have ASPM disabled during suspend, or at least part > > of the suspend process*, mainly for two reasons: > > 1. Power saving is expected to be little. During suspend/resume, we > > frequently access PCI registers, making it unlikely to stay in low > > power states; > > 2. It could cause performance degradation. Unfortunate timing could > > put the device into low power states and wake it up very soon after; > > resulting noticeable delays. > > * By "part if the suspend process", I refer [suspend/resume]_noirq, where > > there are frequent PCI register accesses and suffers most from this issue. > > > > Ideally, the entry time could be tune so that it is long enough that the > > device would not go into low power states during suspend; however, it > > may not be feasible mainly because: > > 1. Hardware limitations; > > 2. The best timing for suspend/resume may not be the best timing for other > > tasks. Considering suspend/resume is a rare task, we probably do not > > want to sacrifice other tasks; > > 3. If the goal is to avoid entering low power states during suspend, it > > might > > be better just to disable it. > > > > What do you think? > > I think we should look at disabling ASPM for all devices during > suspend. I really don't want to put this kind of gunk in individual > drivers. If we *have* to put something in drivers, it should be using > interfaces like pci_disable_link_state() instead of writing > PCI_EXP_LNKCTL directly. > Agreed. > > I *would* be interested in more details about this issue you're seeing > with GS9750, though. It will help the case for a core change if we > can open a bugzilla.kernel.org issue with some of the details like the > L1 exit latency (from "lspci -vv") and details of the activities that > lead to these delays. Typical L1 exit latencies are <100us, so to see > 200ms of delay would mean ~2000 L1.2 exits, which is higher than I > would expect. > Sorry that I misread the PCIe specs and the trace results. It was PortTPowerOnTime (Port T_POWER_ON) which added up to ~200ms. GL9750's PortTPowerOnTime is 3100us or 3.1ms, and I saw up to 60 occurrences during resume. I've created https://bugzilla.kernel.org/show_bug.cgi?id=211187 We can continue the discussion there. > > > > > Signed-off-by: Victor Ding > > > > --- > > > > > > > > drivers/mmc/host/sdhci-pci-core.c | 2 +- > > > > drivers/mmc/host/sdhci-pci-gli.c | 46 +-- > > > > drivers/mmc/host/sdhci-pci.h | 1 + > > > > 3 files changed, 46 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/drivers/mmc/host/sdhci-pci-core.c > > > > b/drivers/mmc/host/sdhci-pci-core.c > > > > index 9552708846ca..fd7544a498c0 100644 > > > > --- a/drivers/mmc/host/sdhci-pci-core.c > > > > +++ b/drivers/mmc/host/sdhci-pci-core.c > > > > @@ -67,7 +67,7 @@ static int sdhci_pci_init_wakeup(struct > > > > sdhci_pci_chip *chip) > > > > return 0; > > > > } > > > > > > > > -static int sdhci_pci_suspend_host(struct sdhci_pci_chip *chip) > > > > +int sdhci_pci_suspend_host(struct sdhci_pci_chip *chip)
Re: [PATCH v2 2/2] rtc: pcf2127: Run a OTP refresh if not done before
On 14.01.21 09:06, Uwe Kleine-König wrote:
On Wed, Jan 13, 2021 at 12:27:42PM +0100, Philipp Rosenberger wrote:
The datasheet of the PCF2127 states,it is recommended to process an OTP
s/,/, /
ACK
refresh once the power is up and the oscillator is operating stable. The
OTP refresh takes less than 100 ms to complete.
Signed-off-by: Philipp Rosenberger
---
drivers/rtc/rtc-pcf2127.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
index 378b1ce812d6..ca56dba64e79 100644
--- a/drivers/rtc/rtc-pcf2127.c
+++ b/drivers/rtc/rtc-pcf2127.c
@@ -58,6 +58,9 @@
#define PCF2127_REG_ALARM_DM 0x0D
#define PCF2127_REG_ALARM_DW 0x0E
#define PCF2127_BIT_ALARM_AE BIT(7)
+/* CLKOUT control register */
+#define PCF2127_REG_CLKOUT 0x0f
+#define PCF2127_BIT_CLKOUT_OTPRBIT(5)
/* Watchdog registers */
#define PCF2127_REG_WD_CTL0x10
#define PCF2127_BIT_WD_CTL_TF0BIT(0)
@@ -630,6 +633,19 @@ static int pcf2127_probe(struct device *dev, struct regmap
*regmap,
dev_warn(dev, "Watchdog and alarm functions might not work
properly\n");
}
+ /*
+* Set the OTP refresh bit unconditionally. If an OTP refresh was
+* already done the bit is already set and will not rerun the refresh
+* operation.
+*/
+ ret = regmap_set_bits(pcf2127->regmap, PCF2127_REG_CLKOUT,
+ PCF2127_BIT_CLKOUT_OTPR);
+ if (ret < 0) {
+ dev_err(dev, "%s: OTP refresh (clkout_ctrl) failed.\n",
__func__);
+ return ret;
+ }
+ msleep(100);
This unconditional sleep isn't so nice. Maybe it makes sense to only do
this when the chip reports a power loss?
Right, will change that
Best regards
Uwe
Best Regards,
Philipp
Re: [PATCH 0/3] Fix broken references at next-20210114 due to yaml conversion
On Thu, Jan 14, 2021 at 07:25:57AM +0100, Mauro Carvalho Chehab wrote: > Three new broken references were added between next-20210113 and > next-20210114, due to yaml conversion. > > Address them. > > Please add those patches at the same tree as the respective > conversion changesets were added. I've taken the USB patches here, thanks. greg k-h
Re: [PATCH v2 2/2] perf tools: Add documentation for 'perf irq' command
On 14.01.2021 10:48, Bixuan Cui wrote: > Add documentation for 'perf irq' command. > > Signed-off-by: Bixuan Cui > --- > tools/perf/Documentation/perf-irq.txt | 58 +++ > tools/perf/command-list.txt | 1 + > 2 files changed, 59 insertions(+) > create mode 100644 tools/perf/Documentation/perf-irq.txt > + > +OPTIONS for 'perf irq report' > + > + > +--cpus:: > + Show just entries with activities for the given CPUs. perf report mode already has -C,--cpu option so it makes sense to reuse the option for perf irq report. Regards, Alexei
Re: [PATCH v3] tty: make pl011 serial port driver support 485 mode
On Thu, Jan 14, 2021 at 05:07:33PM +0800, zhangqiumi...@huawei.com wrote: > From: Qiumiao Zhang > > make pl011 serial port support 485 mode full duplex communication > > --- > Changes in v3: > -Fix busy loop forever in pl011_tx_empty > -Move the definition of cr into uart_amba_port > -run checkpatch with no error or warning > > Changes in v2: > -Fix two compilation errors > > drivers/tty/serial/amba-pl011.c | 32 > 1 file changed, 32 insertions(+) Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch does not have a Signed-off-by: line. Please read the kernel file, Documentation/SubmittingPatches and resend it after adding that line. Note, the line needs to be in the body of the email, before the patch, not at the bottom of the patch or in the email signature. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
Re: [PATCH v2] kbuild: check the minimum compiler version in Kconfig
On Thu, Jan 14, 2021 at 4:55 PM Ilie Halip wrote: > > Hi Masahiro, > > > + #elif defined(__INTEL_COMPILER) > > + /* How to get the version of intel compiler? */ > > + ICC 0 0 0 > > According to Intel documentation[1], this should do the trick: > > ICC __INTEL_COMPILER __INTEL_COMPILER_UPDATE > __INTEL_COMPILER_BUILD_DATE > > I don't have the compiler installed, but I tested this on godbolt[2] and > looks fine to me. What do you think? > > [1] > https://software.intel.com/content/www/us/en/develop/documentation/cpp-compiler-developer-guide-and-reference/top/compiler-reference/macros/additional-predefined-macros.html > [2] https://godbolt.org/z/E5PE6f > > I.H. Thanks. The following is the result from godbolt (except the beta releases of 21.1.*) version__INTEL_COMPILER __INTEL_COMPILER_UPDATE 13.0.1 1300 (unsupported) 16.0.3 1600 3 17.0.0 1700 0 18.0.0 1800 0 19.0.0 1900 0 19.0.1 1900 0 Presumably, the version string xx.yy.zz corresponds to __INTEL_COMPILER=xxyy __INTEL_COMPILER_UPDATE=zz The output from 19.0.1 does not make sense, though. BTW, when I tried ICC a few years ago, I could not build the kernel with it. -- Best Regards Masahiro Yamada
Re: [PATCH] mm: memblock: remove return value of memblock_free_all()
On 14.01.21 08:08, Daeseok Youn wrote:
> No one checks the return value of memblock_free_all().
> Make the return value void.
>
> memblock_free_all() is used on mem_init() for each
> architecture, and the total count of freed pages will be added
> to _totalram_pages variable by calling totalram_pages_add().
>
> so do not need to return total count of freed pages.
>
> Signed-off-by: Daeseok Youn
> ---
> include/linux/memblock.h | 2 +-
> mm/memblock.c| 6 +-
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 9c5cc95c7cee..076fda398dff 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -117,7 +117,7 @@ int memblock_mark_mirror(phys_addr_t base, phys_addr_t
> size);
> int memblock_mark_nomap(phys_addr_t base, phys_addr_t size);
> int memblock_clear_nomap(phys_addr_t base, phys_addr_t size);
>
> -unsigned long memblock_free_all(void);
> +void memblock_free_all(void);
> void reset_node_managed_pages(pg_data_t *pgdat);
> void reset_all_zones_managed_pages(void);
> void memblock_enforce_memory_reserved_overlap(void);
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 40ca30bfa387..2a2b1fe4b659 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -2074,10 +2074,8 @@ void __init reset_all_zones_managed_pages(void)
>
> /**
> * memblock_free_all - release free pages to the buddy allocator
> - *
> - * Return: the number of pages actually released.
> */
> -unsigned long __init memblock_free_all(void)
> +void __init memblock_free_all(void)
> {
> unsigned long pages;
>
> @@ -2086,8 +2084,6 @@ unsigned long __init memblock_free_all(void)
>
> pages = free_low_memory_core_early();
> totalram_pages_add(pages);
> -
> - return pages;
> }
>
> #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_ARCH_KEEP_MEMBLOCK)
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
Re: [PATCH] x86/lib: don't use MMX before FPU initialization
On Tue, Jan 12, 2021 at 01:09:23AM +0100, Borislav Petkov wrote:
> On Mon, Dec 28, 2020 at 05:06:31PM +0100, Krzysztof Mazur wrote:
> > When enabled, the MMX 3DNow! optimized memcpy() is used very early,
> > even before FPU is initialized. It worked fine, but commit
> > 7ad816762f9bf89e940e618ea40c43138b479e10 ("x86/fpu: Reset MXCSR
> > to default in kernel_fpu_begin()") broke that. After that commit
> > the kernel crashes just after "Booting the kernel." message.
>
> Have you figured out in the meantime what exactly is causing the
> breakage?
>
> Does it boot if you comment out
>
> + if (boot_cpu_has(X86_FEATURE_FPU))
> + asm volatile ("fninit");
>
> in kernel_fpu_begin()?
>
> I'm guessing K7 doesn't have X86_FEATURE_XMM so the LDMXCSR won't
> matter...
K7 supports both XMM and FXSR:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall
and the Linux 5.10 boots fine with:
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index eb86a2b831b1..08e5c5bea599 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -141,8 +141,10 @@ void kernel_fpu_begin(void)
}
__cpu_invalidate_fpregs_state();
+#if 0
if (boot_cpu_has(X86_FEATURE_XMM))
ldmxcsr(MXCSR_DEFAULT);
+#endif
if (boot_cpu_has(X86_FEATURE_FPU))
asm volatile ("fninit");
So, I'm guessing that the K7 does not like ldmxcsr(), when FXSR
or/and XMM are not enabled in CR4 (in fpu__init_cpu_generic()).
I verified that by adding kernel_fpu_begin()+kernel_fpu_end()
pair, before and after cr4_set_bits() in fpu__init_cpu_generic()
(on a kernel with disabled early MMX-optimized memcpy).
The kernel with kernel_fpu_begin() after cr4_set_bits():
diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index 701f196d7c68..6d5db9107411 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -25,6 +25,9 @@ static void fpu__init_cpu_generic(void)
if (cr4_mask)
cr4_set_bits(cr4_mask);
+ kernel_fpu_begin();
+ kernel_fpu_end();
+
cr0 = read_cr0();
cr0 &= ~(X86_CR0_TS|X86_CR0_EM); /* clear TS and EM */
if (!boot_cpu_has(X86_FEATURE_FPU))
boots fine, but the kernel with kernel_fpu_begin() before
cr4_set_bits():
diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
index 701f196d7c68..fcf3e6fbd3f8 100644
--- a/arch/x86/kernel/fpu/init.c
+++ b/arch/x86/kernel/fpu/init.c
@@ -22,6 +22,9 @@ static void fpu__init_cpu_generic(void)
cr4_mask |= X86_CR4_OSFXSR;
if (boot_cpu_has(X86_FEATURE_XMM))
cr4_mask |= X86_CR4_OSXMMEXCPT;
+
+ kernel_fpu_begin();
+ kernel_fpu_end();
if (cr4_mask)
cr4_set_bits(cr4_mask);
crashes.
So the breakage is caused by using ldmxcsr(MXCSR_DEFAULT)
before X86_CR4_OSFXSR or/and X86_CR4_OSXMMEXCPT are set
in CR4.
So there are at least two alternative approaches (to disabling
MMX-optimized memcpy early):
a) initialize FXSR/XMM bits in CR4 very early, before first memcpy()
b) replacing boot_cpu_has(X86_FEATURE_XMM) in kernel_fpu_begin()
by something that is not enabled before CR4 is initialized.
This approach also comes with a runtime penalty, because
if kernel requires XMM, boot_cpu_has(X86_FEATURE_XMM) is
optimized out.
Best regards,
Krzysiek
Re: [PATCH] drivers/usb/gadget/udc: Assign boolean values to a bool variable
Jiapeng Zhong writes: > Fix the following coccicheck warnings: > > ./drivers/usb/gadget/udc/udc-xilinx.c:1957:2-18: WARNING: > Assignment of 0/1 to bool variable. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Zhong Acked-by: Felipe Balbi -- balbi signature.asc Description: PGP signature
Re: [PATCH] HID: hid-input: avoid splitting keyboard, system and consumer controls
Hi Dmitry,
On Thu, Jan 14, 2021 at 7:24 AM Dmitry Torokhov
wrote:
>
> A typical USB keyboard usually splits its keys into several reports:
>
> - one for the basic alphanumeric keys, modifier keys, F keys, six pack
> keys and keypad. This report's application is normally listed as
> GenericDesktop.Keyboard
> - a GenericDesktop.SystemControl report for the system control keys, such
> as power and sleep
> - Consumer.ConsumerControl report for multimedia (forward, rewind,
> play/pause, mute, etc) and other extended keys.
> - additional output, vendor specific, and feature reports
>
> Splitting each report into a separate input device is wasteful and even
> hurts userspace as it makes it harder to determine the true capabilities
> (set of available keys) of a keyboard, so let's adjust application
> matching to merge system control and consumer control reports with
> keyboard report, if one has already been processed.
>
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/hid/hid-input.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index f797659cb9d9..df45d8d07dc2 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1851,6 +1851,16 @@ static struct hid_input
> *hidinput_match_application(struct hid_report *report)
> list_for_each_entry(hidinput, &hid->inputs, list) {
> if (hidinput->application == report->application)
> return hidinput;
> +
> + /*
> +* Keep SystemControl and ConsumerControl applications
> together
> +* with the main keyboard, if present.
> +*/
> + if ((report->application == HID_GD_SYSTEM_CONTROL ||
> +report->application == HID_CP_CONSUMER_CONTROL) &&
> + hidinput->application == HID_GD_KEYBOARD) {
I am not fundamentally against the patch, but I think that if the
device exposes first a HID_CP_CONSUMER_CONTROL and then a
HID_GD_KEYBOARD we will end up with 2 different input nodes. We likely
need to "convert" HID_GD_SYSTEM_CONTROL and HID_CP_CONSUMER_CONTROL to
HID_GD_KEYBOARD when creating the hidinput.
Cheers,
Benjamin
> + return hidinput;
> + }
> }
>
> return NULL;
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
>
>
> --
> Dmitry
>
Re: riscv+KASAN does not boot
On Thu, Jan 14, 2021 at 5:57 AM Palmer Dabbelt wrote: > > On Fri, 25 Dec 2020 09:13:23 PST (-0800), dvyu...@google.com wrote: > > On Fri, Dec 25, 2020 at 5:58 PM Andreas Schwab > > wrote: > >> > >> On Dez 25 2020, Dmitry Vyukov wrote: > >> > >> > qemu-system-riscv64 \ > >> > -machine virt -bios default -smp 1 -m 2G \ > >> > -device virtio-blk-device,drive=hd0 \ > >> > -drive file=buildroot-riscv64.ext4,if=none,format=raw,id=hd0 \ > >> > -kernel arch/riscv/boot/Image \ > >> > -nographic \ > >> > -device virtio-rng-device,rng=rng0 -object > >> > rng-random,filename=/dev/urandom,id=rng0 \ > >> > -netdev user,id=net0,host=10.0.2.10,hostfwd=tcp::10022-:22 -device > >> > virtio-net-device,netdev=net0 \ > >> > -append "root=/dev/vda earlyprintk=serial console=ttyS0 oops=panic > >> > panic_on_warn=1 panic=86400" > >> > >> Do you get more output with earlycon=sbi? > > > > Hi Andreas, > > > > For defconfig+kvm_guest.config+ scripts/config -e KASAN -e > > KASAN_INLINE it actually gave me more output: > > > > > > OpenSBI v0.7 > >_ _ > > / __ \ / | _ \_ _| > > | | | |_ __ ___ _ __ | (___ | |_) || | > > | | | | '_ \ / _ \ '_ \ \___ \| _ < | | > > | |__| | |_) | __/ | | |) | |_) || |_ > > \/| .__/ \___|_| |_|_/|/_| > > | | > > |_| > > > > Platform Name : QEMU Virt Machine > > Platform HART Features : RV64ACDFIMSU > > Current Hart : 0 > > Firmware Base : 0x8000 > > Firmware Size : 132 KB > > Runtime SBI Version: 0.2 > > > > MIDELEG : 0x0222 > > MEDELEG : 0xb109 > > PMP0: 0x8000-0x8003 (A) > > PMP1: 0x-0x (A,R,W,X) > > [0.00] Linux version 5.10.0-01370-g71c5f03154ac > > (dvyu...@dvyukov-desk.muc.corp.google.com) (riscv64-linux-gnu-gcc > > (Debian 10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #17 > > SMP Fri Dec 25 18:10:12 CET 2020 > > [0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020 > > [0.00] earlycon: sbi0 at I/O port 0x0 (options '') > > [0.00] printk: bootconsole [sbi0] enabled > > [0.00] efi: UEFI not found. > > [0.00] Zone ranges: > > [0.00] DMA32[mem 0x8020-0x] > > [0.00] Normal empty > > [0.00] Movable zone start for each node > > [0.00] Early memory node ranges > > [0.00] node 0: [mem 0x8020-0x] > > [0.00] Initmem setup node 0 [mem > > 0x8020-0x] > > [0.00] SBI specification v0.2 detected > > [0.00] SBI implementation ID=0x1 Version=0x7 > > [0.00] SBI v0.2 TIME extension detected > > [0.00] SBI v0.2 IPI extension detected > > [0.00] SBI v0.2 RFENCE extension detected > > [0.00] software IO TLB: mapped [mem > > 0xfa3f9000-0xfe3f9000] (64MB) > > [0.00] Unable to handle kernel paging request at virtual > > address dfc81004 > > [0.00] Oops [#1] > > [0.00] Modules linked in: > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > > 5.10.0-01370-g71c5f03154ac #17 > > [0.00] epc: ffe00042e3e4 ra : ffe000c0462c sp : > > ffe001603ea0 > > [0.00] gp : ffe0016e3c60 tp : ffe00160cd40 t0 : > > dfc81004 > > [0.00] t1 : ffe000e0a838 t2 : s0 : > > ffe001603f50 > > [0.00] s1 : ffe0016e50a8 a0 : dfc81004 a1 : > > > > [0.00] a2 : 0ffc a3 : dfc82000 a4 : > > > > [0.00] a5 : 3e8c6001 a6 : ffe000e0a820 a7 : > > 0900 > > [0.00] s2 : dfc82000 s3 : dfc8 s4 : > > 0001 > > [0.00] s5 : ffe0016e5108 s6 : f000 s7 : > > dfc81004 > > [0.00] s8 : 0080 s9 : s10: > > ffe07a119000 > > [0.00] s11: ffc0 t3 : ffe0016eb908 t4 : > > 0001 > > [0.00] t5 : ffc4001c150a t6 : ffe001603be8 > > [0.00] status: 0100 badaddr: dfc81004 > > cause: 000f > > [0.00] random: get_random_bytes called from > > oops_exit+0x30/0x58 with crng_init=0 > > [0.00] ---[ end trace ]--- > > [0.00] Kernel panic - not syncing: Fatal exception > > [0.00] ---[ end Kernel panic - not syncing: Fatal exception ]--- > > > > > > But I first tried with a the kernel image I had in the dir, I think it > > was this config (no KASAN): > > https://gist.githubusercontent.com/dvyukov/b2b62beccf80493781ab03b41430e616/raw/62e673cff08a8a41656d2871b8a37f74b00f509f/gistfile1.txt > > > > and earlycon=sbi did not change anything (no output after OpenSBI). > > So potentially there are 2 different pr
Re: [PATCH] mt76: Fix queue ID variable types after mcu queue split
On 2021-01-11 09:06, Kalle Valo wrote:
> Lorenzo Bianconi writes:
>
>>> Clang warns in both mt7615 and mt7915:
>>>
>>> drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:271:9: warning: implicit
>>> conversion from enumeration type 'enum mt76_mcuq_id' to different
>>> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
>>> txq = MT_MCUQ_FWDL;
>>> ~ ^~~~
>>> drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:278:9: warning: implicit
>>> conversion from enumeration type 'enum mt76_mcuq_id' to different
>>> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
>>> txq = MT_MCUQ_WA;
>>> ~ ^~
>>> drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:282:9: warning: implicit
>>> conversion from enumeration type 'enum mt76_mcuq_id' to different
>>> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
>>> txq = MT_MCUQ_WM;
>>> ~ ^~
>>> 3 warnings generated.
>>>
>>> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:238:9: warning: implicit
>>> conversion from enumeration type 'enum mt76_mcuq_id' to different
>>> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
>>> qid = MT_MCUQ_WM;
>>> ~ ^~
>>> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:240:9: warning: implicit
>>> conversion from enumeration type 'enum mt76_mcuq_id' to different
>>> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
>>> qid = MT_MCUQ_FWDL;
>>> ~ ^~~~
>>> 2 warnings generated.
>>>
>>> Use the proper type for the queue ID variables to fix these warnings.
>>> Additionally, rename the txq variable in mt7915_mcu_send_message to be
>>> more neutral like mt7615_mcu_send_message.
>>>
>>> Fixes: e637763b606b ("mt76: move mcu queues to mt76_dev q_mcu array")
>>> Link: https://github.com/ClangBuiltLinux/linux/issues/1229
>>> Signed-off-by: Nathan Chancellor
>>
>> Acked-by: Lorenzo Bianconi
>
> I see that Felix already applied this, but as this is a regression
> starting from v5.11-rc1 I think it should be applied to
> wireless-drivers. Felix, can you drop this from your tree so that I
> could apply it to wireless-drivers?
Sure, will do.
- Felix
[PATCH v2 0/3] Adding the Sparx5 Switch Reset Driver
This series provides the Microchip Sparx5 Switch Reset Driver The Sparx5 Switch SoC has a number of components that can be reset individually, but at least the Switch Core needs to be in a well defined state at power on, when any of the Sparx5 drivers starts to access the Switch Core, this reset driver is available. The reset driver is loaded early via the postcore_initcall interface, and will then be available for the other Sparx5 drivers (SGPIO, SwitchDev etc) that are loaded next, and the first of them to be loaded can perform the one-time Switch Core reset that is needed. The driver has protection so that the system busses, DDR controller, PCI-E and ARM A53 CPU and a few other subsystems are not touched by the reset. The Sparx5 Chip Register Model can be browsed at this location: https://github.com/microchip-ung/sparx-5_reginfo History: v1 - v2: Removed debug prints Changed the error handling to save the error code before jumping. Steen Hegelund (3): dt-bindings: reset: microchip sparx5 reset driver bindings reset: mchp: sparx5: add switch reset driver arm64: dts: reset: add microchip sparx5 switch reset driver .../bindings/reset/microchip,rst.yaml | 52 +++ arch/arm64/boot/dts/microchip/sparx5.dtsi | 13 +- drivers/reset/Kconfig | 8 + drivers/reset/Makefile| 1 + drivers/reset/reset-microchip-sparx5.c| 146 ++ 5 files changed, 217 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/reset/microchip,rst.yaml create mode 100644 drivers/reset/reset-microchip-sparx5.c -- 2.29.2
Re: [PATCH] fs/cifs: Replace one-element array with flexible-array member.
Hi Jiapeng, This will change the size returned by sizeof(). Have you checked that this doesn't introduce off-by-one errors in all the sizeof() usage? Cheers, -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)
[PATCH v2 3/3] arm64: dts: reset: add microchip sparx5 switch reset driver
Signed-off-by: Steen Hegelund
---
arch/arm64/boot/dts/microchip/sparx5.dtsi | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi
b/arch/arm64/boot/dts/microchip/sparx5.dtsi
index 380281f312d8..6f0a21c362e3 100644
--- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
@@ -132,9 +132,16 @@ mux: mux-controller {
};
};
- reset@611010008 {
- compatible = "microchip,sparx5-chip-reset";
- reg = <0x6 0x11010008 0x4>;
+ gcb_ctrl: syscon@61101 {
+ compatible = "microchip,sparx5-gcb-syscon", "syscon";
+ reg = <0x6 0x1101 0x1>;
+ };
+
+ reset: reset-controller@0 {
+ compatible = "microchip,sparx5-switch-reset";
+ reg = <0x6 0x0 0x0>;
+ #reset-cells = <1>;
+ syscons = <&cpu_ctrl>,<&gcb_ctrl>;
};
uart0: serial@60010 {
--
2.29.2
[PATCH v2 2/3] reset: mchp: sparx5: add switch reset driver
Signed-off-by: Steen Hegelund
---
drivers/reset/Kconfig | 8 ++
drivers/reset/Makefile | 1 +
drivers/reset/reset-microchip-sparx5.c | 146 +
3 files changed, 155 insertions(+)
create mode 100644 drivers/reset/reset-microchip-sparx5.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 71ab75a46491..05c240c47a8a 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -101,6 +101,14 @@ config RESET_LPC18XX
help
This enables the reset controller driver for NXP LPC18xx/43xx SoCs.
+config RESET_MCHP_SPARX5
+ bool "Microchip Sparx5 reset driver"
+ depends on HAS_IOMEM || COMPILE_TEST
+ default y if SPARX5_SWITCH
+ select MFD_SYSCON
+ help
+ This driver supports switch core reset for the Microchip Sparx5 SoC.
+
config RESET_MESON
tristate "Meson Reset Driver"
depends on ARCH_MESON || COMPILE_TEST
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 1054123fd187..341fd9ab4bf6 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
obj-$(CONFIG_RESET_INTEL_GW) += reset-intel-gw.o
obj-$(CONFIG_RESET_LANTIQ) += reset-lantiq.o
obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
+obj-$(CONFIG_RESET_MCHP_SPARX5) += reset-microchip-sparx5.o
obj-$(CONFIG_RESET_MESON) += reset-meson.o
obj-$(CONFIG_RESET_MESON_AUDIO_ARB) += reset-meson-audio-arb.o
obj-$(CONFIG_RESET_NPCM) += reset-npcm.o
diff --git a/drivers/reset/reset-microchip-sparx5.c
b/drivers/reset/reset-microchip-sparx5.c
new file mode 100644
index ..f5899891356d
--- /dev/null
+++ b/drivers/reset/reset-microchip-sparx5.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch Reset driver
+ *
+ * Copyright (c) 2020 Microchip Technology Inc. and its subsidiaries.
+ *
+ * The Sparx5 Chip Register Model can be browsed at this location:
+ * https://github.com/microchip-ung/sparx-5_reginfo
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PROTECT_REG0x84
+#define PROTECT_BITBIT(10)
+#define SOFT_RESET_REG 0x08
+#define SOFT_RESET_BIT BIT(1)
+
+struct mchp_reset_context {
+ struct device *dev;
+ struct regmap *cpu_ctrl;
+ struct regmap *gcb_ctrl;
+ struct reset_controller_dev reset_ctrl;
+};
+
+static u32 sparx5_read_soft_rst(struct mchp_reset_context *ctx)
+{
+ u32 val;
+
+ regmap_read(ctx->gcb_ctrl, SOFT_RESET_REG, &val);
+ return val;
+}
+
+static int sparx5_switch_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct mchp_reset_context *ctx =
+ container_of(rcdev, struct mchp_reset_context, reset_ctrl);
+ u32 val;
+
+ /* Make sure the core is PROTECTED from reset */
+ regmap_update_bits(ctx->cpu_ctrl, PROTECT_REG, PROTECT_BIT,
PROTECT_BIT);
+
+ /* Start soft reset */
+ regmap_write(ctx->gcb_ctrl, SOFT_RESET_REG, SOFT_RESET_BIT);
+
+ /* Wait for soft reset done */
+ return read_poll_timeout(sparx5_read_soft_rst, val,
+(val & SOFT_RESET_BIT) == 0,
+1, 100, false,
+ctx);
+}
+
+static const struct reset_control_ops sparx5_reset_ops = {
+ .reset = sparx5_switch_reset,
+};
+
+static int mchp_sparx5_reset_config(struct platform_device *pdev,
+ struct mchp_reset_context *ctx)
+{
+ struct device_node *dn = pdev->dev.of_node;
+ struct regmap *cpu_ctrl, *gcb_ctrl;
+ struct device_node *syscon_np;
+ int err;
+
+ syscon_np = of_parse_phandle(dn, "syscons", 0);
+ if (!syscon_np)
+ return -ENODEV;
+ cpu_ctrl = syscon_node_to_regmap(syscon_np);
+ if (IS_ERR(cpu_ctrl)) {
+ err = PTR_ERR(cpu_ctrl);
+ goto syscon_err;
+ }
+ of_node_put(syscon_np);
+
+ syscon_np = of_parse_phandle(dn, "syscons", 1);
+ if (!syscon_np)
+ return -ENODEV;
+ gcb_ctrl = syscon_node_to_regmap(syscon_np);
+ if (IS_ERR(gcb_ctrl)) {
+ err = PTR_ERR(gcb_ctrl);
+ goto syscon_err;
+ }
+ of_node_put(syscon_np);
+
+ ctx->cpu_ctrl = cpu_ctrl;
+ ctx->gcb_ctrl = gcb_ctrl;
+
+ ctx->reset_ctrl.owner = THIS_MODULE;
+ ctx->reset_ctrl.nr_resets = 1;
+ ctx->reset_ctrl.ops = &sparx5_reset_ops;
+ ctx->reset_ctrl.of_node = dn;
+
+ err = devm_reset_controller_register(&pdev->dev, &ctx->reset_ctrl);
+ if (err)
+ dev_err(&pdev->dev, "could not register reset controller\n");
+ return err;
+
+syscon_err:
+ of_node_put(syscon_np);
+ return err;
+}
+
+static int mchp_sparx5_reset_probe(struct platform_device *pdev)
+{
+ s
Re: [PATCH 0/3] usb: dwc2: Fixes and improvements
Hi Guenter, Doug, thanks for having a look at this. On Wed, 2021-01-13 at 19:07 -0800, Guenter Roeck wrote: > On Wed, Jan 13, 2021 at 03:20:55PM -0800, Doug Anderson wrote: > > Hi, > > > [ ... ] > > > > It's been long enough ago that I've forgotten where this was left off, > > but IIRC the 3 patches that you have here are all fine to land (and > > have my Reviewed-by tag). However, I think Guenter was still tracking > > down additional problems. Guenter: does that match your recollection? > > > > It looks like there are still bugs open for this on our public bug tracker: > > > > https://issuetracker.google.com/issues/172208170 > > https://issuetracker.google.com/issues/172216241 > > > > ...but, as Guenter said, I don't think there's anyone actively working on > > them. > > > > I'm not really doing too much with dwc2 these days either and don't > > currently have good HW setup for testing, so for the most part I'll > > leave it to you. I wanted to at least summarize what I remembered, > > though! :-) > > > > The patches in this series still match what I had in my latest test code, > so it makes sense to move forward with them. I don't think I ever found > an acceptable version of the DMA alignment code. As for the alignment code rework, can you recall the underlying issue that warranted it? Regards, Nicolas signature.asc Description: This is a digitally signed message part
[PATCH v2 1/3] dt-bindings: reset: microchip sparx5 reset driver bindings
Signed-off-by: Steen Hegelund
---
.../bindings/reset/microchip,rst.yaml | 52 +++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/microchip,rst.yaml
diff --git a/Documentation/devicetree/bindings/reset/microchip,rst.yaml
b/Documentation/devicetree/bindings/reset/microchip,rst.yaml
new file mode 100644
index ..b5526753e85d
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/microchip,rst.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/reset/microchip,rst.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Microchip Sparx5 Switch Reset Controller
+
+maintainers:
+ - Steen Hegelund
+ - Lars Povlsen
+
+description: |
+ The Microchip Sparx5 Switch provides reset control and implements the
following
+ functions
+- One Time Switch Core Reset (Soft Reset)
+
+properties:
+ $nodename:
+pattern: "^reset-controller@[0-9a-f]+$"
+
+ compatible:
+const: microchip,sparx5-switch-reset
+
+ reg:
+maxItems: 1
+
+ "#reset-cells":
+const: 1
+
+ syscons:
+$ref: "/schemas/types.yaml#/definitions/phandle-array"
+description: Array of syscons used to access reset registers
+minItems: 2
+
+required:
+ - compatible
+ - reg
+ - "#reset-cells"
+ - syscons
+
+additionalProperties: false
+
+examples:
+ - |
+reset: reset-controller@0 {
+compatible = "microchip,sparx5-switch-reset";
+reg = <0x0 0x0>;
+#reset-cells = <1>;
+syscons = <&cpu_ctrl>,<&gcb_ctrl>;
+};
+
--
2.29.2
SLUB: percpu partial object count is highly inaccurate, causing some memory wastage and maybe also worse tail latencies?
On 1/12/21 5:35 PM, Christoph Lameter wrote: > On Tue, 12 Jan 2021, Jann Horn wrote: > >> [This is not something I intend to work on myself. But since I >> stumbled over this issue, I figured I should at least document/report >> it, in case anyone is willing to pick it up.] > > Well yeah all true. There is however a slabinfo tool that has an -s option > to shrink all slabs. > > slabinfo -s > > So you could put that somewhere that executes if the system is > idle or put it into cron or so. Hm this would be similar to recommending a periodical echo > drop_caches operation. We actually discourage from that (and yeah, some tools do that, and we now report those in dmesg). I believe the kernel should respond to memory pressure and not OOM prematurely by itself, including SLUB.
Re: [PATCH v2 3/3] KVM: arm64: Mark the page dirty only if the fault is handled successfully
On 2021/1/13 23:51, Will Deacon wrote:
On Wed, Dec 16, 2020 at 08:28:44PM +0800, Yanan Wang wrote:
We now mark the page dirty and set the bitmap before calling fault handlers
in user_mem_abort(), and we might end up having spurious dirty pages if
update of permissions or mapping has failed.
So, mark the page dirty only if the fault is handled successfully.
Let the guest directly enter again but not return to userspace if we were
trying to recreate the same mapping or only change access permissions
with BBM, which is not permitted in the mapping path.
Signed-off-by: Yanan Wang
---
arch/arm64/kvm/mmu.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 75814a02d189..72e516a10914 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -879,11 +879,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
if (vma_pagesize == PAGE_SIZE && !force_pte)
vma_pagesize = transparent_hugepage_adjust(memslot, hva,
&pfn, &fault_ipa);
- if (writable) {
+ if (writable)
prot |= KVM_PGTABLE_PROT_W;
- kvm_set_pfn_dirty(pfn);
- mark_page_dirty(kvm, gfn);
- }
if (fault_status != FSC_PERM && !device)
clean_dcache_guest_page(pfn, vma_pagesize);
@@ -911,6 +908,19 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
phys_addr_t fault_ipa,
memcache);
}
+ /* Mark the page dirty only if the fault is handled successfully */
+ if (writable && !ret) {
+ kvm_set_pfn_dirty(pfn);
+ mark_page_dirty(kvm, gfn);
+ }
+
+ /* Let the guest directly enter again if we were trying to recreate the
+* same mapping or only change access permissions with BBM, which is not
+* permitted in the mapping path.
+*/
+ if (ret == -EAGAIN)
+ ret = 0;
Maybe just 'return ret != -EAGAIN ? ret : 0;' at the end of the function?
Yes, it's more concise.
