Re: [RFC v2] rcu/tree: Try to invoke_rcu_core() if in_irq() during unlock
On Sun, Aug 18, 2019 at 05:49:48PM -0400, Joel Fernandes (Google) wrote:
> When we're in hard interrupt context in rcu_read_unlock_special(), we
> can still benefit from invoke_rcu_core() doing wake ups of rcuc
> threads when the !use_softirq parameter is passed. This is safe
> to do so because:
>
> 1. We avoid the scheduler deadlock issues thanks to the deferred_qs bit
> introduced in commit 23634ebc1d94 ("rcu: Check for wakeup-safe
> conditions in rcu_read_unlock_special()") by checking for the same in
> this patch.
>
> 2. in_irq() implies in_interrupt() which implies raising softirq will
> not do any wake ups.
>
> The rcuc thread which is awakened will run when the interrupt returns.
>
> We also honor 25102de ("rcu: Only do rcu_read_unlock_special() wakeups
> if expedited") thus doing the rcuc awakening only when none of the
> following are true:
> 1. Critical section is blocking an expedited GP.
> 2. A nohz_full CPU.
> If neither of these cases are true (exp == false), then the "else" block
> will run to do the irq_work stuff.
>
> This commit is based on a partial revert of d143b3d1cd89 ("rcu: Simplify
> rcu_read_unlock_special() deferred wakeups") with an additional in_irq()
> check added.
>
> Signed-off-by: Joel Fernandes (Google)
OK, I will bite... If it is safe to wake up an rcuc kthread, why
is it not safe to do raise_softirq()?
And from the nit department, looks like some whitespace damage on the
comments.
Thanx, Paul
> ---
> v1->v2: Some minor character encoding issues in changelog corrected.
>
> Note that I am still testing this patch, but I sent an early RFC for your
> feedback. Thanks!
>
> kernel/rcu/tree_plugin.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 2defc7fe74c3..f4b3055026dc 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -621,6 +621,11 @@ static void rcu_read_unlock_special(struct task_struct
> *t)
> // Using softirq, safe to awaken, and we get
> // no help from enabling irqs, unlike bh/preempt.
> raise_softirq_irqoff(RCU_SOFTIRQ);
> + } else if (exp && in_irq() && !use_softirq &&
> +!t->rcu_read_unlock_special.b.deferred_qs) {
> + // Safe to awaken rcuc kthread which will be
> + // scheduled in from the interrupt return path.
> + invoke_rcu_core();
> } else {
> // Enabling BH or preempt does reschedule, so...
> // Also if no expediting or NO_HZ_FULL, slow is OK.
> --
> 2.23.0.rc1.153.gdeed80330f-goog
>
Re: [PATCH 2/2] arm64: dts: allwinner: h6: Introduce Tanix TX6 board
Hi, On Sun, 18 Aug 2019 at 21:00, Jernej Škrabec wrote: > > Dne nedelja, 18. avgust 2019 ob 20:42:49 CEST je kbuild test robot napisal(a): > > Hi Jernej, > > > > Thank you for the patch! Yet something to improve: > > > > [auto build test ERROR on linus/master] > > [cannot apply to v5.3-rc4 next-20190816] > > [if your patch is applied to the wrong git tree, please drop us a note to > > help improve the system] > > > > url: > > https://github.com/0day-ci/linux/commits/Jernej-Skrabec/dt-bindings-arm-sun > > xi-Add-compatible-for-Tanix-TX6-board/20190819-002034 config: > > arm64-defconfig (attached as .config) > > compiler: aarch64-linux-gcc (GCC) 7.4.0 > > reproduce: > > wget > > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > > ~/bin/make.cross chmod +x ~/bin/make.cross > > # save the attached .config to linux build tree > > GCC_VERSION=7.4.0 make.cross ARCH=arm64 > > > > If you fix the issue, kindly add following tag > > Reported-by: kbuild test robot > > > > All errors (new ones prefixed by >>): > > >> Error: arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts:83.1-6 Label > > >> or path r_ir not found FATAL ERROR: Syntax error parsing input tree > > Strange, Allwinner tree has commit, which introduces r_ir node: > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/? > h=sunxi/dt-for-5.4=9267811aad3524c857cf2e16bbadd8c569e15ab9 > > Maybe kbuild test robot tree doesn't have it? Yes Kbuild is on v5.3-rc4 vs the IR patch is planned for 5.4. Regards, Clément > > Best regards, > Jernej > > > > > --- > > 0-DAY kernel test infrastructureOpen Source Technology > > Center https://lists.01.org/pipermail/kbuild-all Intel > > Corporation > > > > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v9 01/22] pinctrl: tegra: Fix write barrier placement in pmx_writel
On Fri, Aug 16, 2019 at 9:42 PM Sowjanya Komatineni wrote: > > pmx_writel uses writel which inserts write barrier before the > register write. > > This patch has fix to replace writel with writel_relaxed followed > by a readback and memory barrier to ensure write operation is > completed for successful pinctrl change. > > Acked-by: Thierry Reding > Reviewed-by: Dmitry Osipenko > Signed-off-by: Sowjanya Komatineni Took out the previous patches and applied this instead. Yours, Linus Walleij
Re: [PATCH v9 02/22] pinctrl: tegra: Flush pinctrl writes during resume
On Fri, Aug 16, 2019 at 9:42 PM Sowjanya Komatineni wrote: > This patch adds pinctrl register read to flush all the prior pinctrl > writes and then adds barrier for pinctrl register read to complete > during resume to make sure all pinctrl changes are effective. > > Acked-by: Thierry Reding > Reviewed-by: Dmitry Osipenko > Signed-off-by: Sowjanya Komatineni Patch applied. Yours, Linus Walleij
Re: [PATCH v2] wimax/i2400m: fix a memory leak bug
This driver should be orphaned. While I can’t certainly say nobody is using it, the HW has not been sold for years and it hasn’t been brought to current LK standards. If your assesment is the code shall not be used, it’s then another argument towards disconnecting it. > On Aug 18, 2019, at 14:12, David Miller wrote: > > From: Wenwen Wang > Date: Thu, 15 Aug 2019 15:29:51 -0500 > >> In i2400m_barker_db_init(), 'options_orig' is allocated through kstrdup() >> to hold the original command line options. Then, the options are parsed. >> However, if an error occurs during the parsing process, 'options_orig' is >> not deallocated, leading to a memory leak bug. To fix this issue, free >> 'options_orig' before returning the error. >> >> Signed-off-by: Wenwen Wang > > Applied, but... looking at the rest of this file I hope nobody is actually > running this code.
Re: [PATCH 2/4] x86/vmware: Add a header file for hypercall definitions
On 8/18/19 10:19 PM, Borislav Petkov wrote: On Sun, Aug 18, 2019 at 04:33:14PM +0200, Thomas Hellström (VMware) wrote: From: Thomas Hellstrom This is intended to be used by drivers using the backdoor, and we follow the kvm example using alternatives self-patching to choose between vmcall, vmmcall and inl instructions. diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index 998c2cc08363..69cecc3bc9cb 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -232,6 +232,8 @@ #define X86_FEATURE_VMMCALL ( 8*32+15) /* Prefer VMMCALL to VMCALL */ #define X86_FEATURE_XENPV ( 8*32+16) /* "" Xen paravirtual guest */ #define X86_FEATURE_EPT_AD( 8*32+17) /* Intel Extended Page Table access-dirty bit */ +#define X86_FEATURE_VMW_VMCALL ( 8*32+18) /* VMware prefers VMCALL hypercall instruction */ +#define X86_FEATURE_VMW_VMMCALL( 8*32+19) /* VMware prefers VMMCALL hypercall instruction */ Those are not set anywhere in the patchset. Please send them with their user. Thanks for reviewing. Hmm, That hunk appears to have been lost. I'll restore in v2. Then, there already is X86_FEATURE_VMMCALL which you can use too, I'd guess. Unfortunately we can't use it, because it's unconditionally set on AMD even if the VMware hypervisor doesn't support it (by version or by configuration). I was thinking of having the VMware platform code clear it if vmmcall wasn't supported but that would most probably conflict with other hypervisors using the vmmouse driver, still using the old "inl" interface for the vmmouse backdoor, but otherwise requiring vmmcall for other hypercalls. Also, I don't see a reason to show the synthetic bit in /proc/cpuinfo so when you define it, add "": #define X86_FEATURE_VMW_VMCALL ( 8*32+18) /* "" VMware prefers VMCALL hypercall instruction */ ^ | | this here. Ah. I wasn't aware of that. I'll add. Thanks. Thomas Thx.
Re: [RFC v2] rcu/tree: Try to invoke_rcu_core() if in_irq() during unlock
On Sun, Aug 18, 2019 at 03:12:10PM -0700, Paul E. McKenney wrote:
> On Sun, Aug 18, 2019 at 05:49:48PM -0400, Joel Fernandes (Google) wrote:
> > When we're in hard interrupt context in rcu_read_unlock_special(), we
> > can still benefit from invoke_rcu_core() doing wake ups of rcuc
> > threads when the !use_softirq parameter is passed. This is safe
> > to do so because:
> >
> > 1. We avoid the scheduler deadlock issues thanks to the deferred_qs bit
> > introduced in commit 23634ebc1d94 ("rcu: Check for wakeup-safe
> > conditions in rcu_read_unlock_special()") by checking for the same in
> > this patch.
> >
> > 2. in_irq() implies in_interrupt() which implies raising softirq will
> > not do any wake ups.
> >
> > The rcuc thread which is awakened will run when the interrupt returns.
> >
> > We also honor 25102de ("rcu: Only do rcu_read_unlock_special() wakeups
> > if expedited") thus doing the rcuc awakening only when none of the
> > following are true:
> > 1. Critical section is blocking an expedited GP.
> > 2. A nohz_full CPU.
> > If neither of these cases are true (exp == false), then the "else" block
> > will run to do the irq_work stuff.
> >
> > This commit is based on a partial revert of d143b3d1cd89 ("rcu: Simplify
> > rcu_read_unlock_special() deferred wakeups") with an additional in_irq()
> > check added.
> >
> > Signed-off-by: Joel Fernandes (Google)
>
> OK, I will bite... If it is safe to wake up an rcuc kthread, why
> is it not safe to do raise_softirq()?
Because raise_softirq should not be done and/or doesn't do anything
if use_softirq == false. In fact, RCU_SOFTIRQ doesn't even existing if
use_softirq == false. The "else if" condition of this patch uses for
use_softirq.
Or, did I miss your point?
> And from the nit department, looks like some whitespace damage on the
> comments.
I will fix all of these in the change log, it was just a quick RFC I sent
with the idea, tagged as RFC and not yet for merging. I should also remove
the comment about " in_irq() implies in_interrupt() which implies raising
softirq" from the changelog since this patch is only concerned with the rcuc
kthread.
thanks!
- Joel
> Thanx, Paul
>
> > ---
> > v1->v2: Some minor character encoding issues in changelog corrected.
> >
> > Note that I am still testing this patch, but I sent an early RFC for your
> > feedback. Thanks!
> >
> > kernel/rcu/tree_plugin.h | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> > index 2defc7fe74c3..f4b3055026dc 100644
> > --- a/kernel/rcu/tree_plugin.h
> > +++ b/kernel/rcu/tree_plugin.h
> > @@ -621,6 +621,11 @@ static void rcu_read_unlock_special(struct task_struct
> > *t)
> > // Using softirq, safe to awaken, and we get
> > // no help from enabling irqs, unlike bh/preempt.
> > raise_softirq_irqoff(RCU_SOFTIRQ);
> > + } else if (exp && in_irq() && !use_softirq &&
> > + !t->rcu_read_unlock_special.b.deferred_qs) {
> > + // Safe to awaken rcuc kthread which will be
> > + // scheduled in from the interrupt return path.
> > + invoke_rcu_core();
> > } else {
> > // Enabling BH or preempt does reschedule, so...
> > // Also if no expediting or NO_HZ_FULL, slow is OK.
> > --
> > 2.23.0.rc1.153.gdeed80330f-goog
> >
>
Re: [RFC v2] rcu/tree: Try to invoke_rcu_core() if in_irq() during unlock
On Sun, Aug 18, 2019 at 06:32:30PM -0400, Joel Fernandes wrote:
> On Sun, Aug 18, 2019 at 03:12:10PM -0700, Paul E. McKenney wrote:
> > On Sun, Aug 18, 2019 at 05:49:48PM -0400, Joel Fernandes (Google) wrote:
> > > When we're in hard interrupt context in rcu_read_unlock_special(), we
> > > can still benefit from invoke_rcu_core() doing wake ups of rcuc
> > > threads when the !use_softirq parameter is passed. This is safe
> > > to do so because:
> > >
> > > 1. We avoid the scheduler deadlock issues thanks to the deferred_qs bit
> > > introduced in commit 23634ebc1d94 ("rcu: Check for wakeup-safe
> > > conditions in rcu_read_unlock_special()") by checking for the same in
> > > this patch.
> > >
> > > 2. in_irq() implies in_interrupt() which implies raising softirq will
> > > not do any wake ups.
> > >
> > > The rcuc thread which is awakened will run when the interrupt returns.
> > >
> > > We also honor 25102de ("rcu: Only do rcu_read_unlock_special() wakeups
> > > if expedited") thus doing the rcuc awakening only when none of the
> > > following are true:
> > > 1. Critical section is blocking an expedited GP.
> > > 2. A nohz_full CPU.
> > > If neither of these cases are true (exp == false), then the "else" block
> > > will run to do the irq_work stuff.
> > >
> > > This commit is based on a partial revert of d143b3d1cd89 ("rcu: Simplify
> > > rcu_read_unlock_special() deferred wakeups") with an additional in_irq()
> > > check added.
> > >
> > > Signed-off-by: Joel Fernandes (Google)
> >
> > OK, I will bite... If it is safe to wake up an rcuc kthread, why
> > is it not safe to do raise_softirq()?
>
> Because raise_softirq should not be done and/or doesn't do anything
> if use_softirq == false. In fact, RCU_SOFTIRQ doesn't even existing if
> use_softirq == false. The "else if" condition of this patch uses for
> use_softirq.
>
> Or, did I miss your point?
>
> > And from the nit department, looks like some whitespace damage on the
> > comments.
>
> I will fix all of these in the change log, it was just a quick RFC I sent
> with the idea, tagged as RFC and not yet for merging. I should also remove
> the comment about " in_irq() implies in_interrupt() which implies raising
> softirq" from the changelog since this patch is only concerned with the rcuc
> kthread.
Ah, I see you mean the comments on the code. Perhaps something went wrong
when I did 'git revert' on the original patch, or some such. Anyway, please
consider this as RFC-grade only. And hopefully I have been writing better
change logs (really trying!!).
thanks,
- Joel
Greetings From Mr. Soumaila Sorgho
-- Greetings From Mr. Soumaila Sorgho I have a Mutual/Beneficial Business Project that would be beneficial to you. I only have two questions to ask of you, if you are interested. 1. Can you handle this project? 2. Can I give you this trust? Please note that the deal requires high level of maturity, honesty and secrecy. This will involve moving some money from my office, on trust to your hands or bank account. Also note that i will do everything to make sure that the money is moved as a purely legitimate fund, so you will not be exposed to any risk. I request for your full co-operation. I will give you details and procedure when I receive your reply, to commence this transaction, I require you to immediately indicate your interest by a return reply. I will be waiting for your response in a timely manner. Contact Email: soumailasor...@yandex.com Best Regard, Mr. Soumaila Sorgho
Re: [BUG] removing and reinserting imx-media causes kernel to explode
On 8/14/19 2:25 AM, Russell King - ARM Linux admin wrote: I just did this: rmmod imx-media modprobe imx-media and was greeted by the below kernel messages. Yes this needs fixing, the CSI needs to check first that it is already registered before going through the ->registered() steps. Posting a patch. I don't think this has been the first issue I found with the iMX media stuff involving a module unload/reload cycle - may I suggest that this is added to the testing regime for this code? Thanks. I do test module unload/reload cycles, but v4l2-async does not support re-registering subdevices unless the subdevice is basically completely removed and re-probed, so there won't be a working media device if only imx-media is reloaded. So I have always unloaded/reloaded all modules for every entity in the graph, i.e.: rmmod imx6_media imx6_media_csi imx6_mipi_csi2 ov5640 video_mux imx_media_common (replace ov5640 with your imx219 sensor). But I'll make sure to test single module unload/reload cycles in the future. But note after applying the patch mentioned above to CSI ->registered() callback, there are list corruption backtraces, see [1]. The root cause is that both media_device_register_entity() and media_entity_pads_init() add the same graph objects for the entity's pads, so duplicate pad objects are added to the media device pads list. Removing the pad object creation in media_device_register_entity() fixes the list corruption. Sending a patch for that also. This is a problem for any entity that sets its ->num_pads to a non-zero value before media_device_register_entity() is called. For example, the following will produce the same list corruption backtrace: rmmod video-mux modprobe video-mux rmmod video-mux Steve [1] rmmod imx6-media modprobe imx6-media rmmod imx6-media [ 249.387953] WARNING: CPU: 2 PID: 843 at lib/list_debug.c:53 __list_del_entry_valid+0xa0/0xdc [ 249.396442] list_del corruption. prev->next should be e8fb0510, but was e93b5914 [ 249.404076] Modules linked in: imx6_media_csi(C) imx6_media(C-) imx6_mipi_csi2(C) bnep dw_hdmi_ahb_audio dw_hdmi_cec ov5640 mux_mmio video_mux mux_core dw_hdmi_imx dw_hdmi coda_vpu cec imx_vdoa videobuf2_vmalloc imx_media_common(C) v4l2_fwnode imx_ldb imxdrm imx_ipu_v3 [last unloaded: imx6_media_csi] [ 249.430956] CPU: 2 PID: 843 Comm: rmmod Tainted: G C 5.3.0-rc4-01115-g62119fd20fda #5 [ 249.440115] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 249.446689] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 249.454462] [] (show_stack) from [] (dump_stack+0xd8/0x110) [ 249.461804] [] (dump_stack) from [] (__warn+0xe0/0x10c) [ 249.468789] [] (__warn) from [] (warn_slowpath_fmt+0x44/0x6c) [ 249.476301] [] (warn_slowpath_fmt) from [] (__list_del_entry_valid+0xa0/0xdc) [ 249.485207] [] (__list_del_entry_valid) from [] (media_gobj_destroy.part.4+0x30/0x64) [ 249.494802] [] (media_gobj_destroy.part.4) from [] (__media_device_unregister_entity+0xa8/0xcc) [ 249.505259] [] (__media_device_unregister_entity) from [] (media_device_unregister_entity+0x2c/0x38) [ 249.516157] [] (media_device_unregister_entity) from [] (v4l2_device_unregister_subdev+0x90/0xb4) [ 249.526793] [] (v4l2_device_unregister_subdev) from [] (v4l2_async_cleanup+0x10/0x3c) [ 249.536382] [] (v4l2_async_cleanup) from [] (v4l2_async_notifier_unbind_all_subdevs+0x9c/0x10c) [ 249.546840] [] (v4l2_async_notifier_unbind_all_subdevs) from [] (v4l2_async_notifier_unbind_all_subdevs+0x6c/0x10c) [ 249.559035] [] (v4l2_async_notifier_unbind_all_subdevs) from [] (__v4l2_async_notifier_unregister.part.4+0xc/0x44) [ 249.571140] [] (__v4l2_async_notifier_unregister.part.4) from [] (v4l2_async_notifier_unregister+0x30/0x50) [ 249.582665] [] (v4l2_async_notifier_unregister) from [] (imx_media_remove+0x20/0x54 [imx6_media]) [ 249.593389] [] (imx_media_remove [imx6_media]) from [] (platform_drv_remove+0x20/0x40) [ 249.603068] [] (platform_drv_remove) from [] (device_release_driver_internal+0xdc/0x1ac) [ 249.612917] [] (device_release_driver_internal) from [] (driver_detach+0x44/0x80) [ 249.622164] [] (driver_detach) from [] (bus_remove_driver+0x5c/0xd8) [ 249.630287] [] (bus_remove_driver) from [] (sys_delete_module+0x17c/0x20c) [ 249.638926] [] (sys_delete_module) from [] (ret_fast_syscall+0x0/0x28) [ 249.647205] Exception stack(0xe90d5fa8 to 0xe90d5ff0) [ 249.652278] 5fa0: beed5d6c 0003 01401134 0800 4f13b6f4 2002 [ 249.660475] 5fc0: beed5d6c 0003 beed5b80 0081 beed5e78 0001 014010f8 [ 249.668669] 5fe0: 0003b2c4 beed5b4c 0001f248 4f1012dc [ 249.673859] irq event stamp: 4113 [ 249.677267] hardirqs last enabled at (4131): [] console_unlock+0x408/0x5f8 [ 249.685125] hardirqs last disabled at (4138): [] console_unlock+0x88/0x5f8 [ 249.692970] softirqs last enabled at (4154): [] __do_softirq+0x360/0x524 [ 249.700735] softirqs last disabled
[no subject]
Hello My name is Joe Akaba I am a lawyer by profession. I wish to offer you the next of kin to my client. You will inherit the sum of ($8.5 Million) dollars my client left in the bank before his death. My client is a citizen of your country who died in auto crash with his wife and only son. I will be entitled with 50% of the total fund while 50% will be for you. Please contact my private email here for more details:joeakab...@gmail.com Many thanks in advance, Mr.Joe Akaba
[PATCH v4] lsilogic mpt fusion: mptctl: Fixed race condition in mptctl.ko concerning mptctl_id variable among parallel functions variable among parallel functions
Certain functions in the driver, such as mptctl_do_fw_download() and
mptctl_do_mpt_command(), rely on the instance of mptctl_id, which does the
id-ing. There is race condition possible when these functions operate in
concurrency. Via, mutexes and global/local variable setting, the functions
are mutually signalled to cooperate.
Signed-off-by: Mark Balantzyan
---
Changelog v2
Lacked a version number but added properly terminated else condition at
(former) line 2300.
Changelog v3
Fixes "return -EAGAIN" lines which were erroneously tabbed as if to be guarded
by "if" conditions lying above them.
Changelog v4
Removes a pair of needless mutexes in init() function, allows for checking of
NULL
condition outside of race-fixing mutexes in functions mptctl_do_mpt_command(),
mptctl_do_fw_command, and mptctl_hp_hostinfo().
drivers/message/fusion/mptctl.c | 59 -
1 file changed, 43 insertions(+), 16 deletions(-)
diff --git a/drivers/message/fusion/mptctl.c b/drivers/message/fusion/mptctl.c
index 4470630d..21af0ee8 100644
--- a/drivers/message/fusion/mptctl.c
+++ b/drivers/message/fusion/mptctl.c
@@ -816,12 +816,17 @@ mptctl_do_fw_download(int ioc, char __user *ufwbuf,
size_t fwlen)
/* Valid device. Get a message frame and construct the FW
download message.
*/
- if ((mf = mpt_get_msg_frame(mptctl_id, iocp)) == NULL)
+ mutex_lock(_mutex);
+ mf = mpt_get_msg_frame(mptctl_id, iocp);
+ mutex_unlock(_mutex);
+ if (mf == NULL) {
return -EAGAIN;
+ }
}
-
+ mutex_lock(_mutex);
dctlprintk(iocp, printk(MYIOC_s_DEBUG_FMT
"mptctl_do_fwdl called. mptctl_id = %xh.\n", iocp->name,
mptctl_id));
+ mutex_unlock(_mutex);
dctlprintk(iocp, printk(MYIOC_s_DEBUG_FMT "DbG: kfwdl.bufp = %p\n",
iocp->name, ufwbuf));
dctlprintk(iocp, printk(MYIOC_s_DEBUG_FMT "DbG: kfwdl.fwlen = %d\n",
@@ -943,7 +948,9 @@ mptctl_do_fw_download(int ioc, char __user *ufwbuf, size_t
fwlen)
ReplyMsg = NULL;
SET_MGMT_MSG_CONTEXT(iocp->ioctl_cmds.msg_context, dlmsg->MsgContext);
INITIALIZE_MGMT_STATUS(iocp->ioctl_cmds.status)
+ mutex_lock(_mutex);
mpt_put_msg_frame(mptctl_id, iocp, mf);
+ mutex_lock(_mutex);
/* Now wait for the command to complete */
retry_wait:
@@ -1889,8 +1896,12 @@ mptctl_do_mpt_command (struct mpt_ioctl_command karg,
void __user *mfPtr)
/* Get a free request frame and save the message context.
*/
-if ((mf = mpt_get_msg_frame(mptctl_id, ioc)) == NULL)
-return -EAGAIN;
+ mutex_lock(_mutex);
+ mf = mpt_get_msg_frame(mptctl_id, ioc);
+ mutex_unlock(_mutex);
+ if (mf == NULL) {
+ return -EAGAIN;
+ }
hdr = (MPIHeader_t *) mf;
msgContext = le32_to_cpu(hdr->MsgContext);
@@ -2271,11 +2282,14 @@ mptctl_do_mpt_command (struct mpt_ioctl_command karg,
void __user *mfPtr)
DBG_DUMP_TM_REQUEST_FRAME(ioc, (u32 *)mf);
if ((ioc->facts.IOCCapabilities &
MPI_IOCFACTS_CAPABILITY_HIGH_PRI_Q) &&
- (ioc->facts.MsgVersion >= MPI_VERSION_01_05))
+ (ioc->facts.MsgVersion >= MPI_VERSION_01_05)) {
+ mutex_lock(_mutex);
mpt_put_msg_frame_hi_pri(mptctl_id, ioc, mf);
- else {
- rc =mpt_send_handshake_request(mptctl_id, ioc,
- sizeof(SCSITaskMgmt_t), (u32*)mf, CAN_SLEEP);
+ mutex_unlock(_mutex);
+ } else {
+ mutex_lock(_mutex);
+ rc = mpt_send_handshake_request(mptctl_id, ioc,
sizeof(SCSITaskMgmt_t), (u32 *)mf, CAN_SLEEP);
+ mutex_unlock(_mutex);
if (rc != 0) {
dfailprintk(ioc, printk(MYIOC_s_ERR_FMT
"send_handshake FAILED! (ioc %p, mf %p)\n",
@@ -2287,8 +2301,11 @@ mptctl_do_mpt_command (struct mpt_ioctl_command karg,
void __user *mfPtr)
}
}
- } else
+ } else {
+ mutex_lock(_mutex);
mpt_put_msg_frame(mptctl_id, ioc, mf);
+ mutex_unlock(_mutex);
+ }
/* Now wait for the command to complete */
timeout = (karg.timeout > 0) ? karg.timeout : MPT_IOCTL_DEFAULT_TIMEOUT;
@@ -2563,7 +2580,10 @@ mptctl_hp_hostinfo(unsigned long arg, unsigned int
data_size)
/*
* Gather ISTWI(Industry Standard Two Wire Interface) Data
*/
- if ((mf = mpt_get_msg_frame(mptctl_id, ioc)) == NULL) {
+ mutex_lock(_mutex);
+ mf = mpt_get_msg_frame(mptctl_id, ioc);
+ mutex_unlock(_mutex);
+ if (mf == NULL) {
dfailprintk(ioc,
Re: [PATCH v3] lsilogic mpt fusion: mptctl: Fixed race condition around mptctl_id variable using mutexes
Hi Julian, all, I submitted a patch v4 following Julian's review. A function such as "mptctl_do_mpt_command" I don't think is a setup function and so the race condition (likelihood) remains. Again, this was mainly concerning the usage of "mptctl_id" variable in the driver. My objective was just to make it as safe as possible and improve it. Please accept my patch v4 should it suffice. Thank you, Mark
[PATCH] media: saa7134: keep demod i2c gate open on Medion 7134
Medion 7134 has two i2c eeproms on the same i2c bus sharing the same bus
addresses: the first one for SAA7134 chip config and the second one behind
TDA10046 DVB-T demod chip i2c gate storing its firmware.
The TV tuner on this board is not behind this i2c gate.
Due to the bus conflict described above, the card PCI SVID / SSID sometimes
gets garbled after a reboot, which makes it necessary to specify the card
model manually as an insmod option in order for it to be detected reliably.
To avoid this, let's just leave the gate permanently open so the eeprom
chips won't clash.
The demod firmware load is done with its i2c gate open anyway so it is not
affected by this change.
Signed-off-by: Maciej S. Szmigiero
---
drivers/media/pci/saa7134/saa7134-dvb.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/media/pci/saa7134/saa7134-dvb.c
b/drivers/media/pci/saa7134/saa7134-dvb.c
index eb8377a95023..ace019ef6784 100644
--- a/drivers/media/pci/saa7134/saa7134-dvb.c
+++ b/drivers/media/pci/saa7134/saa7134-dvb.c
@@ -1264,6 +1264,20 @@ static int dvb_init(struct saa7134_dev *dev)
_cardbus,
>i2c_adap);
if (fe0->dvb.frontend) {
+ /*
+* The TV tuner on this board is actually NOT
+* behind the demod i2c gate.
+* However, the demod eeprom is indeed there and it
+* conflicts with the SAA7134 chip config eeprom
+* if the i2c gate is closed (since they have same
+* bus addresses) resulting in card PCI SVID / SSID
+* being garbage after a reboot from time to time.
+*
+* Let's just leave the gate permanently open -
+* saa7134_i2c_eeprom_md7134_gate() will open it for
+* us at probe time if it was closed for some reason.
+*/
+ fe0->dvb.frontend->ops.i2c_gate_ctrl = NULL;
dvb_attach(simple_tuner_attach, fe0->dvb.frontend,
>i2c_adap, medion_cardbus.tuner_address,
TUNER_PHILIPS_FMD1216ME_MK3);
Re: [RFC v2] rcu/tree: Try to invoke_rcu_core() if in_irq() during unlock
On Sun, Aug 18, 2019 at 06:35:11PM -0400, Joel Fernandes wrote:
> On Sun, Aug 18, 2019 at 06:32:30PM -0400, Joel Fernandes wrote:
> > On Sun, Aug 18, 2019 at 03:12:10PM -0700, Paul E. McKenney wrote:
> > > On Sun, Aug 18, 2019 at 05:49:48PM -0400, Joel Fernandes (Google) wrote:
> > > > When we're in hard interrupt context in rcu_read_unlock_special(), we
> > > > can still benefit from invoke_rcu_core() doing wake ups of rcuc
> > > > threads when the !use_softirq parameter is passed. This is safe
> > > > to do so because:
> > > >
> > > > 1. We avoid the scheduler deadlock issues thanks to the deferred_qs bit
> > > > introduced in commit 23634ebc1d94 ("rcu: Check for wakeup-safe
> > > > conditions in rcu_read_unlock_special()") by checking for the same in
> > > > this patch.
> > > >
> > > > 2. in_irq() implies in_interrupt() which implies raising softirq will
> > > > not do any wake ups.
> > > >
> > > > The rcuc thread which is awakened will run when the interrupt returns.
> > > >
> > > > We also honor 25102de ("rcu: Only do rcu_read_unlock_special() wakeups
> > > > if expedited") thus doing the rcuc awakening only when none of the
> > > > following are true:
> > > > 1. Critical section is blocking an expedited GP.
> > > > 2. A nohz_full CPU.
> > > > If neither of these cases are true (exp == false), then the "else" block
> > > > will run to do the irq_work stuff.
> > > >
> > > > This commit is based on a partial revert of d143b3d1cd89 ("rcu: Simplify
> > > > rcu_read_unlock_special() deferred wakeups") with an additional in_irq()
> > > > check added.
> > > >
> > > > Signed-off-by: Joel Fernandes (Google)
> > >
> > > OK, I will bite... If it is safe to wake up an rcuc kthread, why
> > > is it not safe to do raise_softirq()?
> >
> > Because raise_softirq should not be done and/or doesn't do anything
> > if use_softirq == false. In fact, RCU_SOFTIRQ doesn't even existing if
> > use_softirq == false. The "else if" condition of this patch uses for
> > use_softirq.
> >
> > Or, did I miss your point?
I am concerned that added "else if" condition might not be sufficient
to eliminate all possible cases of the caller holding a scheduler lock,
which could result in deadlock in the ensuing wakeup. Might be me missing
something, but such deadlocks have been a recurring problem in the past.
Also, your commit log's point #2 is "in_irq() implies in_interrupt()
which implies raising softirq will not do any wake ups." This mention
of softirq seems a bit odd, given that we are going to wake up a rcuc
kthread. Of course, this did nothing to quell my suspicions. ;-)
Thanx, Paul
> > > And from the nit department, looks like some whitespace damage on the
> > > comments.
> >
> > I will fix all of these in the change log, it was just a quick RFC I sent
> > with the idea, tagged as RFC and not yet for merging. I should also remove
> > the comment about " in_irq() implies in_interrupt() which implies raising
> > softirq" from the changelog since this patch is only concerned with the rcuc
> > kthread.
>
> Ah, I see you mean the comments on the code. Perhaps something went wrong
> when I did 'git revert' on the original patch, or some such. Anyway, please
> consider this as RFC-grade only. And hopefully I have been writing better
> change logs (really trying!!).
>
> thanks,
>
> - Joel
>
Re: [RFC v2] rcu/tree: Try to invoke_rcu_core() if in_irq() during unlock
On Sun, Aug 18, 2019 at 04:31:35PM -0700, Paul E. McKenney wrote:
> On Sun, Aug 18, 2019 at 06:35:11PM -0400, Joel Fernandes wrote:
> > On Sun, Aug 18, 2019 at 06:32:30PM -0400, Joel Fernandes wrote:
> > > On Sun, Aug 18, 2019 at 03:12:10PM -0700, Paul E. McKenney wrote:
> > > > On Sun, Aug 18, 2019 at 05:49:48PM -0400, Joel Fernandes (Google) wrote:
> > > > > When we're in hard interrupt context in rcu_read_unlock_special(), we
> > > > > can still benefit from invoke_rcu_core() doing wake ups of rcuc
> > > > > threads when the !use_softirq parameter is passed. This is safe
> > > > > to do so because:
> > > > >
> > > > > 1. We avoid the scheduler deadlock issues thanks to the deferred_qs
> > > > > bit
> > > > > introduced in commit 23634ebc1d94 ("rcu: Check for wakeup-safe
> > > > > conditions in rcu_read_unlock_special()") by checking for the same in
> > > > > this patch.
> > > > >
> > > > > 2. in_irq() implies in_interrupt() which implies raising softirq will
> > > > > not do any wake ups.
> > > > >
> > > > > The rcuc thread which is awakened will run when the interrupt returns.
> > > > >
> > > > > We also honor 25102de ("rcu: Only do rcu_read_unlock_special() wakeups
> > > > > if expedited") thus doing the rcuc awakening only when none of the
> > > > > following are true:
> > > > > 1. Critical section is blocking an expedited GP.
> > > > > 2. A nohz_full CPU.
> > > > > If neither of these cases are true (exp == false), then the "else"
> > > > > block
> > > > > will run to do the irq_work stuff.
> > > > >
> > > > > This commit is based on a partial revert of d143b3d1cd89 ("rcu:
> > > > > Simplify
> > > > > rcu_read_unlock_special() deferred wakeups") with an additional
> > > > > in_irq()
> > > > > check added.
> > > > >
> > > > > Signed-off-by: Joel Fernandes (Google)
> > > >
> > > > OK, I will bite... If it is safe to wake up an rcuc kthread, why
> > > > is it not safe to do raise_softirq()?
> > >
> > > Because raise_softirq should not be done and/or doesn't do anything
> > > if use_softirq == false. In fact, RCU_SOFTIRQ doesn't even existing if
> > > use_softirq == false. The "else if" condition of this patch uses for
> > > use_softirq.
> > >
> > > Or, did I miss your point?
>
> I am concerned that added "else if" condition might not be sufficient
> to eliminate all possible cases of the caller holding a scheduler lock,
> which could result in deadlock in the ensuing wakeup. Might be me missing
> something, but such deadlocks have been a recurring problem in the past.
I thought that was the whole point of the
rcu_read_unlock_special.b.deferred_qs bit that was introduced in
23634ebc1d94. We are checking that bit in the "else if" here as well. So this
should be no less immune to scheduler deadlocks any more than the preceding
"else if" where we are checking this bit.
> Also, your commit log's point #2 is "in_irq() implies in_interrupt()
> which implies raising softirq will not do any wake ups." This mention
> of softirq seems a bit odd, given that we are going to wake up a rcuc
> kthread. Of course, this did nothing to quell my suspicions. ;-)
Yes, I should delete this #2 from the changelog since it is not very relevant
(I feel now). My point with #2 was that even if were to raise a softirq
(which we are not), a scheduler wakeup of ksoftirqd is impossible in this
path anyway since in_irq() implies in_interrupt().
thanks,
- Joel
> Thanx, Paul
>
> > > > And from the nit department, looks like some whitespace damage on the
> > > > comments.
> > >
> > > I will fix all of these in the change log, it was just a quick RFC I sent
> > > with the idea, tagged as RFC and not yet for merging. I should also remove
> > > the comment about " in_irq() implies in_interrupt() which implies raising
> > > softirq" from the changelog since this patch is only concerned with the
> > > rcuc
> > > kthread.
> >
> > Ah, I see you mean the comments on the code. Perhaps something went wrong
> > when I did 'git revert' on the original patch, or some such. Anyway, please
> > consider this as RFC-grade only. And hopefully I have been writing better
> > change logs (really trying!!).
> >
> > thanks,
> >
> > - Joel
> >
linux-next: manual merge of the ext4 tree with the fscrypt tree
Hi all,
Today's linux-next merge of the ext4 tree got a conflict in:
fs/ext4/ioctl.c
between commit:
29b3692e6dbf ("ext4: wire up new fscrypt ioctls")
from the fscrypt tree and commits:
b0c013e2928d ("ext4: add a new ioctl EXT4_IOC_CLEAR_ES_CACHE")
1ad3ea6e0a69 ("ext4: add a new ioctl EXT4_IOC_GETSTATE")
bb5835edcdf8 ("ext4: add new ioctl EXT4_IOC_GET_ES_CACHE")
from the ext4 tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc fs/ext4/ioctl.c
index fe5a4b13f939,d6242b7b8718..
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@@ -1115,31 -1183,33 +1183,58 @@@ resizefs_out
case EXT4_IOC_GET_ENCRYPTION_POLICY:
return fscrypt_ioctl_get_policy(filp, (void __user *)arg);
+ case FS_IOC_GET_ENCRYPTION_POLICY_EX:
+ if (!ext4_has_feature_encrypt(sb))
+ return -EOPNOTSUPP;
+ return fscrypt_ioctl_get_policy_ex(filp, (void __user *)arg);
+
+ case FS_IOC_ADD_ENCRYPTION_KEY:
+ if (!ext4_has_feature_encrypt(sb))
+ return -EOPNOTSUPP;
+ return fscrypt_ioctl_add_key(filp, (void __user *)arg);
+
+ case FS_IOC_REMOVE_ENCRYPTION_KEY:
+ if (!ext4_has_feature_encrypt(sb))
+ return -EOPNOTSUPP;
+ return fscrypt_ioctl_remove_key(filp, (void __user *)arg);
+
+ case FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS:
+ if (!ext4_has_feature_encrypt(sb))
+ return -EOPNOTSUPP;
+ return fscrypt_ioctl_remove_key_all_users(filp,
+(void __user *)arg);
+ case FS_IOC_GET_ENCRYPTION_KEY_STATUS:
+ if (!ext4_has_feature_encrypt(sb))
+ return -EOPNOTSUPP;
+ return fscrypt_ioctl_get_key_status(filp, (void __user *)arg);
+
+ case EXT4_IOC_CLEAR_ES_CACHE:
+ {
+ if (!inode_owner_or_capable(inode))
+ return -EACCES;
+ ext4_clear_inode_es(inode);
+ return 0;
+ }
+
+ case EXT4_IOC_GETSTATE:
+ {
+ __u32 state = 0;
+
+ if (ext4_test_inode_state(inode, EXT4_STATE_EXT_PRECACHED))
+ state |= EXT4_STATE_FLAG_EXT_PRECACHED;
+ if (ext4_test_inode_state(inode, EXT4_STATE_NEW))
+ state |= EXT4_STATE_FLAG_NEW;
+ if (ext4_test_inode_state(inode, EXT4_STATE_NEWENTRY))
+ state |= EXT4_STATE_FLAG_NEWENTRY;
+ if (ext4_test_inode_state(inode, EXT4_STATE_DA_ALLOC_CLOSE))
+ state |= EXT4_STATE_FLAG_DA_ALLOC_CLOSE;
+
+ return put_user(state, (__u32 __user *) arg);
+ }
+
+ case EXT4_IOC_GET_ES_CACHE:
+ return ext4_ioctl_get_es_cache(filp, arg);
+
case EXT4_IOC_FSGETXATTR:
{
struct fsxattr fa;
@@@ -1256,13 -1326,11 +1351,16 @@@ long ext4_compat_ioctl(struct file *fil
case EXT4_IOC_SET_ENCRYPTION_POLICY:
case EXT4_IOC_GET_ENCRYPTION_PWSALT:
case EXT4_IOC_GET_ENCRYPTION_POLICY:
+ case FS_IOC_GET_ENCRYPTION_POLICY_EX:
+ case FS_IOC_ADD_ENCRYPTION_KEY:
+ case FS_IOC_REMOVE_ENCRYPTION_KEY:
+ case FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS:
+ case FS_IOC_GET_ENCRYPTION_KEY_STATUS:
case EXT4_IOC_SHUTDOWN:
case FS_IOC_GETFSMAP:
+ case EXT4_IOC_CLEAR_ES_CACHE:
+ case EXT4_IOC_GETSTATE:
+ case EXT4_IOC_GET_ES_CACHE:
break;
default:
return -ENOIOCTLCMD;
--
Cheers,
Stephen Rothwell
pgp9PpneVW8uk.pgp
Description: OpenPGP digital signature
Re: [PATCH v2] toshiba: Add correct printk log level while emitting error log
On Sun, 2019-08-18 at 13:04 +0530, Rishi Gupta wrote:
> The printk functions are invoked without specifying required
> log level when printing error messages. This commit replaces
> all direct uses of printk with their corresponding pr_err/info/debug
> variant.
Mostly I wonder if CONFIG_TOSHIBA needs to exist anymore.
Does this driver need to be in kernel at all?
So two options below:
Option 1: If it does still need to exist:
> diff --git a/drivers/char/toshiba.c b/drivers/char/toshiba.c
[]
> @@ -373,7 +373,7 @@ static int tosh_get_machine_id(void __iomem *bios)
> value. This has been verified on a Satellite Pro 430CDT,
> Tecra 750CDT, Tecra 780DVD and Satellite 310CDT. */
> #if TOSH_DEBUG
Please remove all references to TOSH_DEBUG
and the #ifdef and #endif
> - printk("toshiba: debugging ID ebx=0x%04x\n", regs.ebx);
> + pr_debug("toshiba: debugging ID ebx=0x%04x\n", regs.ebx);
> #endif
> bx = 0xe6f5;
>
> @@ -417,7 +417,7 @@ static int tosh_probe(void)
>
> for (i=0;i<7;i++) {
> if (readb(bios+0xe010+i)!=signature[i]) {
> - printk("toshiba: not a supported Toshiba laptop\n");
> + pr_err("toshiba: not a supported Toshiba laptop\n");
> iounmap(bios);
> return -ENODEV;
> }
>
And add and use #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
and remove the embedded "toshiba: " prefix from formats.
---
diff --git a/drivers/char/toshiba.c b/drivers/char/toshiba.c
index 0bdc602f0d48..1fd9db56d6d1 100644
--- a/drivers/char/toshiba.c
+++ b/drivers/char/toshiba.c
@@ -43,8 +43,9 @@
* the Copyright (Computer Programs) Regulations 1992 (S.I. 1992 No.3233).
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#define TOSH_VERSION "1.11 26/9/2001"
-#define TOSH_DEBUG 0
#include
#include
@@ -372,9 +373,9 @@ static int tosh_get_machine_id(void __iomem *bios)
a different value! For the time being I will just fudge the
value. This has been verified on a Satellite Pro 430CDT,
Tecra 750CDT, Tecra 780DVD and Satellite 310CDT. */
-#if TOSH_DEBUG
- printk("toshiba: debugging ID ebx=0x%04x\n", regs.ebx);
-#endif
+
+ pr_debug("debugging ID ebx=0x%04x\n", regs.ebx);
+
bx = 0xe6f5;
sh /* now twiddle with our pointer a bit */
@@ -417,7 +418,7 @@ static int tosh_probe(void)
for (i=0;i<7;i++) {
if (readb(bios+0xe010+i)!=signature[i]) {
- printk("toshiba: not a supported Toshiba laptop\n");
+ pr_notice("not a supported Toshiba laptop\n");
iounmap(bios);
return -ENODEV;
}
@@ -433,7 +434,7 @@ static int tosh_probe(void)
/* if this is not a Toshiba laptop carry flag is set and ah=0x86 */
if ((flag==1) || ((regs.eax & 0xff00)==0x8600)) {
- printk("toshiba: not a supported Toshiba laptop\n");
+ pr_notice("not a supported Toshiba laptop\n");
iounmap(bios);
return -ENODEV;
}
@@ -486,7 +487,7 @@ static int __init toshiba_init(void)
if (tosh_probe())
return -ENODEV;
- printk(KERN_INFO "Toshiba System Management Mode driver v" TOSH_VERSION
"\n");
+ pr_info("Toshiba System Management Mode driver v" TOSH_VERSION "\n");
/* set the port to use for Fn status if not specified as a parameter */
if (tosh_fn==0x00)
---
Option 2: And if it's really dead hardware maybe:
---
arch/x86/Kconfig| 16 --
drivers/char/Makefile | 1 -
drivers/char/toshiba.c | 523
drivers/platform/x86/toshiba_acpi.c | 1 -
drivers/video/fbdev/neofb.c | 27 --
include/linux/toshiba.h | 15 --
6 files changed, 583 deletions(-)
delete mode 100644 drivers/char/toshiba.c
delete mode 100644 include/linux/toshiba.h
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d685677d90f0..f35cdb6e5a77 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1252,22 +1252,6 @@ config X86_VSYSCALL_EMULATION
Disabling this option saves about 7K of kernel size and
possibly 4K of additional runtime pagetable memory.
-config TOSHIBA
- tristate "Toshiba Laptop support"
- depends on X86_32
- ---help---
- This adds a driver to safely access the System Management Mode of
- the CPU on Toshiba portables with a genuine Toshiba BIOS. It does
- not work on models with a Phoenix BIOS. The System Management Mode
- is used to set the BIOS and power saving options on Toshiba portables.
-
- For information on utilities to make use of this driver see the
- Toshiba Linux utilities web site at:
-
linux-next: manual merge of the fsverity tree with the ext4 tree
Hi all,
Today's linux-next merge of the fsverity tree got a conflict in:
fs/ext4/ioctl.c
between commits:
b0c013e2928d ("ext4: add a new ioctl EXT4_IOC_CLEAR_ES_CACHE")
1ad3ea6e0a69 ("ext4: add a new ioctl EXT4_IOC_GETSTATE")
bb5835edcdf8 ("ext4: add new ioctl EXT4_IOC_GET_ES_CACHE")
from the ext4 tree and commit:
c93d8f885809 ("ext4: add basic fs-verity support")
from the fsverity tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/ext4/ioctl.c
index e0d1c05b9409,ce811df71690..
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@@ -1351,16 -1242,10 +1362,18 @@@ long ext4_compat_ioctl(struct file *fil
case EXT4_IOC_SET_ENCRYPTION_POLICY:
case EXT4_IOC_GET_ENCRYPTION_PWSALT:
case EXT4_IOC_GET_ENCRYPTION_POLICY:
+ case FS_IOC_GET_ENCRYPTION_POLICY_EX:
+ case FS_IOC_ADD_ENCRYPTION_KEY:
+ case FS_IOC_REMOVE_ENCRYPTION_KEY:
+ case FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS:
+ case FS_IOC_GET_ENCRYPTION_KEY_STATUS:
case EXT4_IOC_SHUTDOWN:
case FS_IOC_GETFSMAP:
+ case EXT4_IOC_CLEAR_ES_CACHE:
+ case EXT4_IOC_GETSTATE:
+ case EXT4_IOC_GET_ES_CACHE:
+ case FS_IOC_ENABLE_VERITY:
+ case FS_IOC_MEASURE_VERITY:
break;
default:
return -ENOIOCTLCMD;
pgpY_8o6eih9Z.pgp
Description: OpenPGP digital signature
Re: [PATCH v6 1/4] dt-bindings: net: phy: Add subnode for LED configuration
On Fri, Aug 16, 2019 at 03:04:11PM -0700, Matthias Kaehlcke wrote:
> On Fri, Aug 16, 2019 at 10:13:38PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > Please Cc led mailing lists on led issues.
>
> sorry for missing this
>
> > On Tue 2019-08-13 12:11:44, Matthias Kaehlcke wrote:
> > > The LED behavior of some Ethernet PHYs is configurable. Add an
> > > optional 'leds' subnode with a child node for each LED to be
> > > configured. The binding aims to be compatible with the common
> > > LED binding (see devicetree/bindings/leds/common.txt).
> > >
> > > A LED can be configured to be:
> > >
> > > - 'on' when a link is active, some PHYs allow configuration for
> > > certain link speeds
> > > speeds
> > > - 'off'
> > > - blink on RX/TX activity, some PHYs allow configuration for
> > > certain link speeds
> > >
> > > For the configuration to be effective it needs to be supported by
> > > the hardware and the corresponding PHY driver.
> > >
> > > Suggested-by: Andrew Lunn
> > > Signed-off-by: Matthias Kaehlcke
> >
> > > @@ -173,5 +217,20 @@ examples:
> > > reset-gpios = < 4 1>;
> > > reset-assert-us = <1000>;
> > > reset-deassert-us = <2000>;
> > > +
> > > +leds {
> > > +#address-cells = <1>;
> > > +#size-cells = <0>;
> > > +
> > > +led@0 {
> > > +reg = <0>;
> > > +linux,default-trigger = "phy-link-1g";
> > > +};
> >
> > Because this affects us.
> >
> > Is the LED software controllable?
>
> it might be for certain PHYs, integration with the LED framework is
> not part of this series.
>
> > Or can it do limited subset of triggers you listed?
>
> it depends on the PHY. The one in this series (RTL8211E) only supports
> a limited subset of the listed triggers.
Hi Pavel
At the moment, there is no integration with the LED
subsystem. However, i would like to be prepared for it in the
future. It will also require some extensions to the LED subsystem.
These triggers are hardware triggers. We would need to add support for
LED trigger offload to the hardware, not have Linux blink the LED in
software. Plus we need per LED triggers, not only global triggers.
Most Ethernet PHYs also allow on/off state to be set, so they could be
software controllable, and support the generic triggers Linux has.
It has been on my mind to do this for a while, but i've never had the
time. It should also be applicable to other subsystems which have
hardware to blink LEDs. Some serial ports can control LEDs for Rx/Tx
and flow control. Maybe disk/RAID controllers are configuration how
they blink there LEDs?
Andrew
Re: [PATCH v2] arm: dts: rockchip: fix vcc_host_5v regulator for usb3 host
Hi Heiko,
On 2019/8/16 下午8:24, Heiko Stuebner wrote:
Hi Kever, TL,
[added TL Lim for clarification]
Am Donnerstag, 15. August 2019, 10:12:52 CEST schrieb Kever Yang:
According to rock64 schemetic V2 and V3, the VCC_HOST_5V output is
controlled by USB_20_HOST_DRV, which is the same as VCC_HOST1_5V.
The v1 schematics I have do reference the GPIO0_A0 as controlling this
supply, so the big question would be how to handle the different versions.
Because adding this would probably break v1 boards in this function.
@TL: where v1 boards also sold or were they only used during development?
I have check this with TL when I make this patch, the V1 hardware was
never sold and only V2/V3
are available on the market.
Thanks,
- Kever
If this were the case, we could just apply the patch, not caring about
v1 boards, but if v1 boards were also sold to customers there would be
more of a problem.
Thanks
Heiko
Signed-off-by: Kever Yang
---
Changes in v2:
- remove enable-active-high property
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index 7cfd5ca6cc85..62936b432f9a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -34,10 +34,9 @@
vcc_host_5v: vcc-host-5v-regulator {
compatible = "regulator-fixed";
- enable-active-high;
- gpio = < RK_PA0 GPIO_ACTIVE_HIGH>;
+ gpio = < RK_PA2 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
- pinctrl-0 = <_host_drv>;
+ pinctrl-0 = <_host_drv>;
regulator-name = "vcc_host_5v";
regulator-always-on;
regulator-boot-on;
@@ -320,12 +319,6 @@
rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO _pull_none>;
};
};
-
- usb3 {
- usb30_host_drv: usb30-host-drv {
- rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO _pull_none>;
- };
- };
};
{
Re: [PATCH v6 4/4] net: phy: realtek: Add LED configuration support for RTL8211E
> Yes, I believe the integration is neccessary. Using same binding is > neccessary for that, but not sufficient. For example, we need > compatible trigger names, too. Hi Pavel Please could you explain what you mean by compatible trigger names? > So... I'd really like to see proper integration is possible before we > merge this. Please let me turn that around. What do you see as being impossible at the moment? What do we need to convince you about? Thanks Andrew
linux-next: manual merge of the fsverity tree with the f2fs tree
Hi all,
Today's linux-next merge of the fsverity tree got a conflict in:
fs/f2fs/file.c
between commits:
d9a94abb3380 ("f2fs: support FS_IOC_{GET,SET}FSLABEL")
546155f73637 ("f2fs: Support case-insensitive file name lookups")
from the f2fs tree and commit:
95ae251fe828 ("f2fs: add fs-verity support")
from the fsverity tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/f2fs/file.c
index 32e2cf9d4b07,838bfeecbd86..
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@@ -1721,7 -1721,7 +1729,8 @@@ static const struct
FS_ENCRYPT_FL | \
FS_INLINE_DATA_FL | \
FS_NOCOW_FL | \
- FS_CASEFOLD_FL)
++ FS_CASEFOLD_FL |\
+ FS_VERITY_FL)
#define F2FS_SETTABLE_FS_FL ( \
FS_SYNC_FL |\
@@@ -3125,77 -3088,34 +3136,101 @@@ static int f2fs_ioc_resize_fs(struct fi
return ret;
}
+static int f2fs_get_volume_name(struct file *filp, unsigned long arg)
+{
+ struct inode *inode = file_inode(filp);
+ struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+ char *vbuf;
+ int count;
+ int err = 0;
+
+ vbuf = f2fs_kzalloc(sbi, MAX_VOLUME_NAME, GFP_KERNEL);
+ if (!vbuf)
+ return -ENOMEM;
+
+ down_read(>sb_lock);
+ count = utf16s_to_utf8s(sbi->raw_super->volume_name,
+ ARRAY_SIZE(sbi->raw_super->volume_name),
+ UTF16_LITTLE_ENDIAN, vbuf, MAX_VOLUME_NAME);
+ up_read(>sb_lock);
+
+ if (copy_to_user((char __user *)arg, vbuf,
+ min(FSLABEL_MAX, count)))
+ err = -EFAULT;
+
+ kvfree(vbuf);
+ return err;
+}
+
+static int f2fs_set_volume_name(struct file *filp, unsigned long arg)
+{
+ struct inode *inode = file_inode(filp);
+ struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
+ char *vbuf;
+ int err = 0;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ vbuf = strndup_user((const char __user *)arg, FSLABEL_MAX);
+ if (IS_ERR(vbuf))
+ return PTR_ERR(vbuf);
+
+ err = mnt_want_write_file(filp);
+ if (err)
+ goto out;
+
+ down_write(>sb_lock);
+
+ memset(sbi->raw_super->volume_name, 0,
+ sizeof(sbi->raw_super->volume_name));
+ utf8s_to_utf16s(vbuf, strlen(vbuf), UTF16_LITTLE_ENDIAN,
+ sbi->raw_super->volume_name,
+ ARRAY_SIZE(sbi->raw_super->volume_name));
+
+ err = f2fs_commit_super(sbi, false);
+
+ up_write(>sb_lock);
+
+ mnt_drop_write_file(filp);
+out:
+ kfree(vbuf);
+ return err;
+}
+
+ static int f2fs_ioc_enable_verity(struct file *filp, unsigned long arg)
+ {
+ struct inode *inode = file_inode(filp);
+
+ f2fs_update_time(F2FS_I_SB(inode), REQ_TIME);
+
+ if (!f2fs_sb_has_verity(F2FS_I_SB(inode))) {
+ f2fs_warn(F2FS_I_SB(inode),
+ "Can't enable fs-verity on inode %lu: the verity
feature is not enabled on this filesystem.\n",
+ inode->i_ino);
+ return -EOPNOTSUPP;
+ }
+
+ return fsverity_ioctl_enable(filp, (const void __user *)arg);
+ }
+
+ static int f2fs_ioc_measure_verity(struct file *filp, unsigned long arg)
+ {
+ if (!f2fs_sb_has_verity(F2FS_I_SB(file_inode(filp
+ return -EOPNOTSUPP;
+
+ return fsverity_ioctl_measure(filp, (void __user *)arg);
+ }
+
long f2fs_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
+ int ret;
+
if (unlikely(f2fs_cp_error(F2FS_I_SB(file_inode(filp)
return -EIO;
+ ret = f2fs_is_checkpoint_ready(F2FS_I_SB(file_inode(filp)));
+ if (ret)
+ return ret;
switch (cmd) {
case F2FS_IOC_GETFLAGS:
@@@ -3260,10 -3170,10 +3295,14 @@@
return f2fs_ioc_precache_extents(filp, arg);
case F2FS_IOC_RESIZE_FS:
return f2fs_ioc_resize_fs(filp, arg);
+ case F2FS_IOC_GET_VOLUME_NAME:
+ return f2fs_get_volume_name(filp, arg);
+ case F2FS_IOC_SET_VOLUME_NAME:
+ return f2fs_set_volume_name(filp, arg);
+ case FS_IOC_ENABLE_VERITY:
+ return f2fs_ioc_enable_verity(filp, arg);
+ case FS_IOC_MEASURE_VERITY:
+ return f2fs_ioc_measure_verity(filp, arg);
default:
return -ENOTTY;
}
@@@ -3378,8 -3288,8 +3417,10 @@@ long
[GIT PULL] FPGA Manager (late) change for 5.3-rc6
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mdf/linux-fpga.git/ tags/fpga-fixes-for-5.3 for you to fetch changes up to dec43da46f63eb71f519d963ba6832838e4262a3: fpga: altera-ps-spi: Fix getting of optional confd gpio (2019-08-18 17:40:02 -0700) FPGA Manager fixes for 5.3 A single fix for the altera-ps-spi driver that fixes the behavior when the driver receives -EPROBE_DEFER when trying to obtain a GPIO desc. Signed-off-by: Moritz Fischer Phil Reid (1): fpga: altera-ps-spi: Fix getting of optional confd gpio drivers/fpga/altera-ps-spi.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-)
Re: [PATCH V1 1/1] serial: 8250_pci: Add F81504A series Support
Hi, Andy Shevchenko 於 2019/8/16 下午 07:26 寫道: On Fri, Aug 16, 2019 at 01:27:29PM +0800, Ji-Ze Hong (Peter Hong) wrote: Fintek F81504A/508A/512A is PCIE to 4/8/12 UARTs device. It's support IO/MMIO/PCIE conf to access all functions. The old F81504/508/512 is only support IO. We have 8250_fintek. Isn't it a right place to add these? The 8250_fintek implements PNP device with id PNP0501. Should I also implements PCIe device in this file? -- With Best Regards, Peter Hong
Re: Why the edge-triggered mode doesn't work for epoll file descriptor?
On Sun, Aug 18, 2019 at 12:36 AM Heiher wrote:
>
> Hello,
>
> I've added a pipe file descriptor (fd1) to an epoll (fd3) with
> EPOLLOUT in edge-triggered mode, and then added the fd3 to another
> epoll (fd4) with EPOLLIN in edge-triggered too.
>
> Next, waiting for fd4 without timeout. When fd1 to be writable, i
> think epoll_wait(fd4, ...) only return once, because all file
> descriptors are added in edge-triggered mode.
>
> But, the actual result is returns many and many times until do once
> eopll_wait(fd3, ...).
>
> #include
> #include
> #include
>
> int
> main (int argc, char *argv[])
> {
> int efd[2];
> struct epoll_event e;
>
> efd[0] = epoll_create (1);
> if (efd[0] < 0)
> return -1;
>
> efd[1] = epoll_create (1);
> if (efd[1] < 0)
> return -2;
>
> e.events = EPOLLIN | EPOLLET;
> e.data.u64 = 1;
> if (epoll_ctl (efd[0], EPOLL_CTL_ADD, efd[1], ) < 0)
> return -3;
>
> e.events = EPOLLOUT | EPOLLET;
> e.data.u64 = 2;
> if (epoll_ctl (efd[1], EPOLL_CTL_ADD, 1, ) < 0)
> return -4;
>
> for (;;) {
> struct epoll_event events[16];
> int nfds;
>
> nfds = epoll_wait (efd[0], events, 16, -1);
> printf ("nfds: %d\n", nfds);
> }
>
> close (efd[1]);
> close (efd[0]);
>
> return 0;
> }
>
> --
> Best regards!
> Hev
> https://hev.cc
Is this behavior correct? any help?
--
Best regards!
Hev
https://hev.cc
RE: [PATCH] clk: imx8mn: fix int pll clk gate
Hi Stephen,
> Subject: Re: [PATCH] clk: imx8mn: fix int pll clk gate
>
> Quoting peng@nxp.com (2019-08-13 18:53:12)
> > From: Peng Fan
> >
> > To Frac pll, the gate shift is 13, however to Int PLL the gate shift
> > is 11.
> >
> > Cc:
> > Fixes: 96d6392b54db ("clk: imx: Add support for i.MX8MN clock driver")
> > Signed-off-by: Peng Fan
> > Reviewed-by: Jacky Bai
> > ---
>
> This is a fix for a change in -next. Why is stable Cced?
Sorry, that was added by mistaken. Should I resend v2 to drop it?
Thanks,
Peng.
Re: [PATCH] iio: adc: sc27xx: Change to polling mode to read data
On Mon, 19 Aug 2019 at 03:27, Jonathan Cameron wrote: > > On Mon, 12 Aug 2019 10:37:44 +0800 > Baolin Wang wrote: > > > On Sun, 11 Aug 2019 at 16:03, Jonathan Cameron wrote: > > > > > > On Tue, 6 Aug 2019 15:39:45 +0800 > > > Baolin Wang wrote: > > > > > > > Hi Jonathan, > > > > > > > > On Mon, 5 Aug 2019 at 21:50, Jonathan Cameron wrote: > > > > > > > > > > On Mon, 29 Jul 2019 10:19:48 +0800 > > > > > Baolin Wang wrote: > > > > > > > > > > > Hi Jonathan, > > > > > > > > > > > > On Sun, 28 Jul 2019 at 01:27, Jonathan Cameron > > > > > > wrote: > > > > > > > > > > > > > > On Thu, 25 Jul 2019 14:33:50 +0800 > > > > > > > Baolin Wang wrote: > > > > > > > > > > > > > > > From: Freeman Liu > > > > > > > > > > > > > > > > On Spreadtrum platform, the headphone will read one ADC channel > > > > > > > > multiple > > > > > > > > times to identify the headphone type, and the headphone > > > > > > > > identification is > > > > > > > > sensitive of the ADC reading time. And we found it will take > > > > > > > > longer time > > > > > > > > to reading ADC data by using interrupt mode comparing with the > > > > > > > > polling > > > > > > > > mode, thus we should change to polling mode to improve the > > > > > > > > efficiency > > > > > > > > of reading data, which can identify the headphone type > > > > > > > > successfully. > > > > > > > > > > > > > > > > Signed-off-by: Freeman Liu > > > > > > > > Signed-off-by: Baolin Wang > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > My concerns with this sort of approach is that we may be > > > > > > > sacrificing power > > > > > > > efficiency for some usecases to support one demanding one. > > > > > > > > > > > > > > The maximum sleep time is 1 second (I think) which is probably > > > > > > > too long > > > > > > > to poll a register for in general. > > > > > > > > > > > > 1 second is the timeout time, that means something wrong when > > > > > > reading > > > > > > the data taking 1 second, and we will poll the register status every > > > > > > 500 us. > > > > > > From the testing, polling mode takes less time than interrupt mode > > > > > > when reading ADC data multiple times, so polling mode did not > > > > > > sacrifice power > > > > > > efficiency. > > > > > > > > > > Hmm. I'll go with a probably on that, depends on interrupt response > > > > > latency etc so isn't entirely obvious. Faster response doesn't > > > > > necessarily > > > > > mean lower power. > > > > > > > > > > > > > > > > > > Is there some way we can bound that time and perhaps switch > > > > > > > between > > > > > > > interrupt and polling modes depending on how long we expect to > > > > > > > wait? > > > > > > > > > > > > I do not think the interrupt mode is needed any more, since the ADC > > > > > > reading is so fast enough usually. Thanks. > > > > > The reason for interrupts in such devices is usually precisely the > > > > > opposite. > > > > > > > > > > You do it because things are slow enough that you can go to sleep > > > > > for a long time before the interrupt occurs. > > > > > > > > > > So question becomes whether there are circumstances in which we are > > > > > running with long timescales and would benefit from using interrupts. > > > > > > > > From our testing, the ADC version time is usually about 100us, it will > > > > be faster to get data if we poll every 50us in this case. But if we > > > > change to use interrupt mode, it will take millisecond level time to > > > > get data. That will cause problems for those time sensitive scenarios, > > > > like headphone detection, that's the main reason we can not use > > > > interrupt mode. > > > > > > > > For those non-time-sensitive scenarios, yes, I agree with you, the > > > > interrupt mode will get a better power efficiency. But ADC driver can > > > > not know what scenarios asked by consumers, so changing to polling > > > > mode seems the easiest way to solve the problem, and we've applied > > > > this patch in our downstream kernel for a while, we did not see any > > > > other problem. > > > > > > > > Thanks for your comments. > > > > > > OK. It's not ideal but sometimes such is life ;) > > > > Thanks for your understanding :) > > > > > > > > So last question - fix or not? If a fix, can I have a fixes tag > > > please. > > > > This is a bigger patch, I am afraid it can not be merged into stable > > kernel, and original code can work at most scenarios. So I think no > > need add stable tag for this patch. Thanks. > > > Fair enough. Needed a bit of merge effort as crossed with a generic > cleanup patch it seems. > > Anyhow, hopefully I got it right. I checked you are right. > > Pushed out as testing for the autobuilders to play with it. Thanks. -- Baolin Wang Best Regards
Re: [RFC v2] rcu/tree: Try to invoke_rcu_core() if in_irq() during unlock
On Sun, Aug 18, 2019 at 07:38:39PM -0400, Joel Fernandes wrote:
> On Sun, Aug 18, 2019 at 04:31:35PM -0700, Paul E. McKenney wrote:
> > On Sun, Aug 18, 2019 at 06:35:11PM -0400, Joel Fernandes wrote:
> > > On Sun, Aug 18, 2019 at 06:32:30PM -0400, Joel Fernandes wrote:
> > > > On Sun, Aug 18, 2019 at 03:12:10PM -0700, Paul E. McKenney wrote:
> > > > > On Sun, Aug 18, 2019 at 05:49:48PM -0400, Joel Fernandes (Google)
> > > > > wrote:
> > > > > > When we're in hard interrupt context in rcu_read_unlock_special(),
> > > > > > we
> > > > > > can still benefit from invoke_rcu_core() doing wake ups of rcuc
> > > > > > threads when the !use_softirq parameter is passed. This is safe
> > > > > > to do so because:
> > > > > >
> > > > > > 1. We avoid the scheduler deadlock issues thanks to the deferred_qs
> > > > > > bit
> > > > > > introduced in commit 23634ebc1d94 ("rcu: Check for wakeup-safe
> > > > > > conditions in rcu_read_unlock_special()") by checking for the same
> > > > > > in
> > > > > > this patch.
> > > > > >
> > > > > > 2. in_irq() implies in_interrupt() which implies raising softirq
> > > > > > will
> > > > > > not do any wake ups.
> > > > > >
> > > > > > The rcuc thread which is awakened will run when the interrupt
> > > > > > returns.
> > > > > >
> > > > > > We also honor 25102de ("rcu: Only do rcu_read_unlock_special()
> > > > > > wakeups
> > > > > > if expedited") thus doing the rcuc awakening only when none of the
> > > > > > following are true:
> > > > > > 1. Critical section is blocking an expedited GP.
> > > > > > 2. A nohz_full CPU.
> > > > > > If neither of these cases are true (exp == false), then the "else"
> > > > > > block
> > > > > > will run to do the irq_work stuff.
> > > > > >
> > > > > > This commit is based on a partial revert of d143b3d1cd89 ("rcu:
> > > > > > Simplify
> > > > > > rcu_read_unlock_special() deferred wakeups") with an additional
> > > > > > in_irq()
> > > > > > check added.
> > > > > >
> > > > > > Signed-off-by: Joel Fernandes (Google)
> > > > >
> > > > > OK, I will bite... If it is safe to wake up an rcuc kthread, why
> > > > > is it not safe to do raise_softirq()?
> > > >
> > > > Because raise_softirq should not be done and/or doesn't do anything
> > > > if use_softirq == false. In fact, RCU_SOFTIRQ doesn't even existing if
> > > > use_softirq == false. The "else if" condition of this patch uses for
> > > > use_softirq.
> > > >
> > > > Or, did I miss your point?
> >
> > I am concerned that added "else if" condition might not be sufficient
> > to eliminate all possible cases of the caller holding a scheduler lock,
> > which could result in deadlock in the ensuing wakeup. Might be me missing
> > something, but such deadlocks have been a recurring problem in the past.
>
> I thought that was the whole point of the
> rcu_read_unlock_special.b.deferred_qs bit that was introduced in
> 23634ebc1d94. We are checking that bit in the "else if" here as well. So this
> should be no less immune to scheduler deadlocks any more than the preceding
> "else if" where we are checking this bit.
I would have much more confidence in a line of reasoning that led to
"immune to scheduler deadlocks" than one that led to "no less immune to
scheduler deadlocks". ;-)
> > Also, your commit log's point #2 is "in_irq() implies in_interrupt()
> > which implies raising softirq will not do any wake ups." This mention
> > of softirq seems a bit odd, given that we are going to wake up a rcuc
> > kthread. Of course, this did nothing to quell my suspicions. ;-)
>
> Yes, I should delete this #2 from the changelog since it is not very relevant
> (I feel now). My point with #2 was that even if were to raise a softirq
> (which we are not), a scheduler wakeup of ksoftirqd is impossible in this
> path anyway since in_irq() implies in_interrupt().
Please! Could you also add a first-principles explanation of why
the added condition is immune from scheduler deadlocks?
Thanx, Paul
Re: [PATCH linux-next] qcom: qcs404: remove COMPILE_TEST from CONFIG_INTERCONNECT_QCOM_QCS404
On 2019/8/18 9:09, Stephen Boyd wrote: > Quoting Mao Wenan (2019-08-15 00:48:48) >> There is one compilation error when CONFIG_INTERCONNECT_QCOM_QCS404=y and >> CONFIG_INTERCONNECT_QCOM_SMD_RPM=y, as well as CONFIG_COMPILE_TEST=y, >> but CONFIG_QCOM_SMD_RPM is not set, logs as below: >> >> drivers/interconnect/qcom/smd-rpm.o: In function `qcom_icc_rpm_smd_send': >> smd-rpm.c:(.text+0xe4): undefined reference to `qcom_rpm_smd_write' >> Makefile:1071: recipe for target 'vmlinux' failed >> make: *** [vmlinux] Error 1 >> >> This is because >> INTERCONNECT_QCOM_QCS404 depends on QCOM_SMD_RPM || COMPILE_TEST. >> Here CONFIG_COMPILE_TEST=y, so CONFIG_INTERCONNECT_QCOM_SMD_RPM >> is selected. If CONFIG_QCOM_SMD_RPM is not set, then >> qcom_rpm_smd_write() is not defined, and compilation error happen. >> Fix this by removing COMPILE_TEST from CONFIG_INTERCONNECT_QCOM_QCS404. > > Can you fix the actual problem with compile testing this driver vs. just > removing the possibility to compile test. Otherwise it gives up on > the spirit of the idea of COMPILE_TEST. yes, I have already tried to move COMPILE_TEST to INTERCONNECT_QCOM, config INTERCONNECT_QCOM bool "Qualcomm Network-on-Chip interconnect drivers" - depends on ARCH_QCOM + depends on ARCH_QCOM || COMPILE_TEST help Support for Qualcomm's Network-on-Chip interconnect hardware. > > > . >
[PATCH v2] arch : arm : add a criteria for pfn_valid
From: Zhaoyang Huang
pfn_valid can be wrong when parsing a invalid pfn whose phys address
exceeds BITS_PER_LONG as the MSB will be trimed when shifted.
Signed-off-by: Zhaoyang Huang
---
arch/arm/mm/init.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index c2daabb..cc769fa 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -177,6 +177,11 @@ static void __init zone_sizes_init(unsigned long min,
unsigned long max_low,
#ifdef CONFIG_HAVE_ARCH_PFN_VALID
int pfn_valid(unsigned long pfn)
{
+ phys_addr_t addr = __pfn_to_phys(pfn);
+
+ if (__phys_to_pfn(addr) != pfn)
+ return 0;
+
return memblock_is_map_memory(__pfn_to_phys(pfn));
}
EXPORT_SYMBOL(pfn_valid);
--
1.9.1
Re: [RFC V2 06/11] soc: mediatek: add MT8183 dvfsrc support
On Mon, 2019-06-10 at 14:00 -0700, Ryan Case wrote:
Hi Ryan,
Sorry for late reply.
> Hi Henry,
>
> On Tue, Apr 30, 2019 at 2:45 AM Henry Chen wrote:
> >
> > Add dvfsrc driver for MT8183
> >
> > Signed-off-by: Henry Chen
> > ---
> > drivers/soc/mediatek/Kconfig | 15 ++
> > drivers/soc/mediatek/Makefile | 1 +
> > drivers/soc/mediatek/mtk-dvfsrc.c | 347
> > ++
> > include/soc/mediatek/mtk_dvfsrc.h | 22 +++
> > 4 files changed, 385 insertions(+)
> > create mode 100644 drivers/soc/mediatek/mtk-dvfsrc.c
> > create mode 100644 include/soc/mediatek/mtk_dvfsrc.h
> >
> > diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> > index 17bd759..2721fd6 100644
> > --- a/drivers/soc/mediatek/Kconfig
> > +++ b/drivers/soc/mediatek/Kconfig
> > @@ -24,6 +24,21 @@ config MTK_INFRACFG
> > INFRACFG controller contains various infrastructure registers not
> > directly associated to any device.
> >
> > +config MTK_DVFSRC
> > + bool "MediaTek DVFSRC Support"
> > + depends on ARCH_MEDIATEK
> > + default ARCH_MEDIATEK
> > + select MTK_INFRACFG
> > + select PM_GENERIC_DOMAINS if PM
> > + depends on MTK_SCPSYS
> > + help
> > + Say yes here to add support for the MediaTek DVFSRC (dynamic
> > voltage
> > + and frequency scaling resource collector) found
> > + on different MediaTek SoCs. The DVFSRC is a proprietary
> > + hardware which is used to collect all the requests from
> > + system and turn into the decision of minimum Vcore voltage
> > + and minimum DRAM frequency to fulfill those requests.
> > +
> > config MTK_PMIC_WRAP
> > tristate "MediaTek PMIC Wrapper Support"
> > depends on RESET_CONTROLLER
> > diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> > index b9dbad6..cd9d63f 100644
> > --- a/drivers/soc/mediatek/Makefile
> > +++ b/drivers/soc/mediatek/Makefile
> > @@ -1,4 +1,5 @@
> > obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
> > +obj-$(CONFIG_MTK_DVFSRC) += mtk-dvfsrc.o
> > obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o mtk-scpsys-ext.o
> > obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> > obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> > diff --git a/drivers/soc/mediatek/mtk-dvfsrc.c
> > b/drivers/soc/mediatek/mtk-dvfsrc.c
> > new file mode 100644
> > index 000..e54a654
> > --- /dev/null
> > +++ b/drivers/soc/mediatek/mtk-dvfsrc.c
> > @@ -0,0 +1,347 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018 MediaTek Inc.
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include "mtk-scpsys.h"
> > +
> > +#define DVFSRC_IDLE0x00
> > +#define DVFSRC_GET_TARGET_LEVEL(x) (((x) >> 0) & 0x)
> > +#define DVFSRC_GET_CURRENT_LEVEL(x)(((x) >> 16) & 0x)
> > +
> > +#define MT8183_DVFSRC_OPP_LP4 0
> > +#define MT8183_DVFSRC_OPP_LP4X 1
> > +#define MT8183_DVFSRC_OPP_LP3 2
> > +
> > +struct dvfsrc_opp {
> > + u32 vcore_opp;
> > + u32 dram_opp;
> > +};
> > +
> > +struct dvfsrc_domain {
> > + u32 id;
> > + u32 state;
> > +};
> > +
> > +struct mtk_dvfsrc;
> > +struct dvfsrc_soc_data {
> > + const int *regs;
> > + u32 num_opp;
> > + u32 num_domains;
> > + const struct dvfsrc_opp **opps;
> > + struct dvfsrc_domain *domains;
> > + int (*get_target_level)(struct mtk_dvfsrc *dvfsrc);
> > + int (*get_current_level)(struct mtk_dvfsrc *dvfsrc);
> > + void (*set_dram_bw)(struct mtk_dvfsrc *dvfsrc, u64 bw);
> > + void (*set_opp_level)(struct mtk_dvfsrc *dvfsrc, u32 level);
> > +};
> > +
> > +struct mtk_dvfsrc {
> > + struct device *dev;
> > + struct clk *clk_dvfsrc;
> > + const struct dvfsrc_soc_data *dvd;
> > + int dram_type;
> > + void __iomem *regs;
> > + struct mutex lock;
> > + struct notifier_block scpsys_notifier;
> > +};
> > +
> > +static u32 dvfsrc_read(struct mtk_dvfsrc *dvfs, u32 offset)
> > +{
> > + return readl(dvfs->regs + dvfs->dvd->regs[offset]);
> > +}
> > +
> > +static void dvfsrc_write(struct mtk_dvfsrc *dvfs, u32 offset, u32 val)
> > +{
> > + writel(val, dvfs->regs + dvfs->dvd->regs[offset]);
> > +}
> > +
> > +enum dvfsrc_regs {
> > + DVFSRC_SW_REQ,
> > + DVFSRC_LEVEL,
> > + DVFSRC_SW_BW_0,
> > + DVFSRC_LAST,
> > +};
> > +
> > +static const int mt8183_regs[] = {
> > + [DVFSRC_SW_REQ] = 0x4,
> > + [DVFSRC_LEVEL] =0xDC,
> > + [DVFSRC_SW_BW_0] = 0x160,
> > + [DVFSRC_LAST] = 0x308,
> > +};
> > +
> > +static bool dvfsrc_is_idle(struct mtk_dvfsrc *dvfsrc)
> > +{
> > + if (!dvfsrc->dvd->get_target_level)
> > + return true;
> > +
> > + return dvfsrc->dvd->get_target_level(dvfsrc)
[PATCH] sock: fix potential memory leak in proto_register()
If protocols registered exceeded PROTO_INUSE_NR, prot will be
added to proto_list, but no available bit left for prot in
proto_inuse_idx.
Signed-off-by: zhanglin
---
net/core/sock.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index bc3512f230a3..25388d429f6a 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -3139,16 +3139,17 @@ static __init int net_inuse_init(void)
core_initcall(net_inuse_init);
-static void assign_proto_idx(struct proto *prot)
+static int assign_proto_idx(struct proto *prot)
{
prot->inuse_idx = find_first_zero_bit(proto_inuse_idx, PROTO_INUSE_NR);
if (unlikely(prot->inuse_idx == PROTO_INUSE_NR - 1)) {
pr_err("PROTO_INUSE_NR exhausted\n");
- return;
+ return -ENOSPC;
}
set_bit(prot->inuse_idx, proto_inuse_idx);
+ return 0;
}
static void release_proto_idx(struct proto *prot)
@@ -3243,18 +3244,24 @@ int proto_register(struct proto *prot, int alloc_slab)
}
mutex_lock(_list_mutex);
+ if (assign_proto_idx(prot)) {
+ mutex_unlock(_list_mutex);
+ goto out_free_timewait_sock_slab_name;
+ }
list_add(>node, _list);
- assign_proto_idx(prot);
mutex_unlock(_list_mutex);
return 0;
out_free_timewait_sock_slab_name:
- kfree(prot->twsk_prot->twsk_slab_name);
+ if (alloc_slab && prot->twsk_prot)
+ kfree(prot->twsk_prot->twsk_slab_name);
out_free_request_sock_slab:
- req_prot_cleanup(prot->rsk_prot);
+ if (alloc_slab) {
+ req_prot_cleanup(prot->rsk_prot);
- kmem_cache_destroy(prot->slab);
- prot->slab = NULL;
+ kmem_cache_destroy(prot->slab);
+ prot->slab = NULL;
+ }
out:
return -ENOBUFS;
}
--
2.17.1
KMSAN: uninit-value in gp8psk_power_ctrl
Hello, syzbot found the following crash on: HEAD commit:f75e4cfe kmsan: use kmsan_handle_urb() in urb.c git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=158867eea0 kernel config: https://syzkaller.appspot.com/x/.config?x=602468164ccdc30a dashboard link: https://syzkaller.appspot.com/bug?extid=fa2759b292234f21d29f compiler: clang version 9.0.0 (/home/glider/llvm/clang 06d00afa61eef8f7f501ebdb4e8612ea43ec2d78) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13688dbaa0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10595a5aa0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+fa2759b292234f21d...@syzkaller.appspotmail.com usb 1-1: config 0 has an invalid interface number: 130 but max is 0 usb 1-1: config 0 has no interface number 0 usb 1-1: New USB device found, idVendor=09c0, idProduct=0206, bcdDevice=ce.c9 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-1: config 0 descriptor?? dvb-usb: found a 'Genpix SkyWalker-2 DVB-S receiver' in warm state. gp8psk: usb in 128 operation failed. == BUG: KMSAN: uninit-value in gp8psk_power_ctrl+0x33e/0xca0 drivers/media/usb/dvb-usb/gp8psk.c:193 CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622 __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310 gp8psk_power_ctrl+0x33e/0xca0 drivers/media/usb/dvb-usb/gp8psk.c:193 dvb_usb_device_power_ctrl drivers/media/usb/dvb-usb/dvb-usb-init.c:226 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:160 [inline] dvb_usb_device_init+0x15ad/0x2cc0 drivers/media/usb/dvb-usb/dvb-usb-init.c:277 gp8psk_usb_probe+0xa2/0x190 drivers/media/usb/dvb-usb/gp8psk.c:307 usb_probe_interface+0xd66/0x1320 drivers/usb/core/driver.c:361 really_probe+0xdae/0x1d80 drivers/base/dd.c:513 driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454 __device_attach+0x454/0x730 drivers/base/dd.c:844 device_initial_probe+0x4a/0x60 drivers/base/dd.c:891 bus_probe_device+0x137/0x390 drivers/base/bus.c:514 device_add+0x288d/0x30e0 drivers/base/core.c:2106 usb_set_configuration+0x30dc/0x3750 drivers/usb/core/message.c:2027 generic_probe+0xe7/0x280 drivers/usb/core/generic.c:210 usb_probe_device+0x14c/0x200 drivers/usb/core/driver.c:266 really_probe+0xdae/0x1d80 drivers/base/dd.c:513 driver_probe_device+0x1b3/0x4f0 drivers/base/dd.c:671 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:778 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454 __device_attach+0x454/0x730 drivers/base/dd.c:844 device_initial_probe+0x4a/0x60 drivers/base/dd.c:891 bus_probe_device+0x137/0x390 drivers/base/bus.c:514 device_add+0x288d/0x30e0 drivers/base/core.c:2106 usb_new_device+0x23e5/0x2ff0 drivers/usb/core/hub.c:2534 hub_port_connect drivers/usb/core/hub.c:5089 [inline] hub_port_connect_change drivers/usb/core/hub.c:5204 [inline] port_event drivers/usb/core/hub.c:5350 [inline] hub_event+0x48d1/0x7290 drivers/usb/core/hub.c:5432 process_one_work+0x1572/0x1f00 kernel/workqueue.c:2269 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415 kthread+0x4b5/0x4f0 kernel/kthread.c:254 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355 Local variable description: status@gp8psk_power_ctrl Variable was created at: gp8psk_power_ctrl+0x63/0xca0 drivers/media/usb/dvb-usb/gp8psk.c:188 dvb_usb_device_power_ctrl drivers/media/usb/dvb-usb/dvb-usb-init.c:226 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:160 [inline] dvb_usb_device_init+0x15ad/0x2cc0 drivers/media/usb/dvb-usb/dvb-usb-init.c:277 == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [RFC V2 08/11] dt-bindings: interconnect: add MT8183 interconnect dt-bindings
Hi Rob,
Sorry for late reply.
On Wed, 2019-05-01 at 15:27 -0500, Rob Herring wrote:
> On Tue, Apr 30, 2019 at 04:51:02PM +0800, Henry Chen wrote:
> > Add interconnect provider dt-bindings for MT8183.
> >
> > Signed-off-by: Henry Chen
> > ---
> > .../bindings/interconnect/mtk,mt8183.txt | 24
> > ++
> > 1 file changed, 24 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/interconnect/mtk,mt8183.txt
> >
> > diff --git a/Documentation/devicetree/bindings/interconnect/mtk,mt8183.txt
> > b/Documentation/devicetree/bindings/interconnect/mtk,mt8183.txt
> > new file mode 100644
> > index 000..1cf1841
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/interconnect/mtk,mt8183.txt
> > @@ -0,0 +1,24 @@
> > +Mediatek MT8183 interconnect binding
>
> This should be part of the dvfsrc binding.
ok, will add these into dvfsrc binding.
>
> > +
> > +MT8183 interconnect providers support dram bandwidth requirements. The
> > provider
> > +is able to communicate with the DVFSRC and send the dram bandwidth to it.
> > +Provider nodes must reside within an DVFSRC device node.
> > +
> > +Required properties :
> > +- compatible : shall contain only one of the following:
> > + "mediatek,mt8183-emi-icc"
> > +- #interconnect-cells : should contain 1
> > +
> > +Examples:
> > +
> > +dvfsrc@10012000 {
> > + compatible = "mediatek,mt8183-dvfsrc";
> > + reg = <0 0x10012000 0 0x1000>;
> > + clocks = < CLK_INFRA_DVFSRC>;
> > + clock-names = "dvfsrc";
> > + ddr_emi: interconnect {
> > + compatible = "mediatek,mt8183-emi-icc";
> > + #interconnect-cells = <1>;
>
> No need for a child node here. Just move #interconnect-cells to the
> parent.
Ihave tried and it cannot work if move "#interconnect-cells" to the
parent.
The provider nodes must reside within an DVFSRC device node.
>
> Rob
Re: [RFC v2] rcu/tree: Try to invoke_rcu_core() if in_irq() during unlock
On Sun, Aug 18, 2019 at 06:21:53PM -0700, Paul E. McKenney wrote:
> On Sun, Aug 18, 2019 at 07:38:39PM -0400, Joel Fernandes wrote:
> > On Sun, Aug 18, 2019 at 04:31:35PM -0700, Paul E. McKenney wrote:
> > > On Sun, Aug 18, 2019 at 06:35:11PM -0400, Joel Fernandes wrote:
> > > > On Sun, Aug 18, 2019 at 06:32:30PM -0400, Joel Fernandes wrote:
> > > > > On Sun, Aug 18, 2019 at 03:12:10PM -0700, Paul E. McKenney wrote:
> > > > > > On Sun, Aug 18, 2019 at 05:49:48PM -0400, Joel Fernandes (Google)
> > > > > > wrote:
> > > > > > > When we're in hard interrupt context in
> > > > > > > rcu_read_unlock_special(), we
> > > > > > > can still benefit from invoke_rcu_core() doing wake ups of rcuc
> > > > > > > threads when the !use_softirq parameter is passed. This is safe
> > > > > > > to do so because:
> > > > > > >
> > > > > > > 1. We avoid the scheduler deadlock issues thanks to the
> > > > > > > deferred_qs bit
> > > > > > > introduced in commit 23634ebc1d94 ("rcu: Check for wakeup-safe
> > > > > > > conditions in rcu_read_unlock_special()") by checking for the
> > > > > > > same in
> > > > > > > this patch.
> > > > > > >
> > > > > > > 2. in_irq() implies in_interrupt() which implies raising softirq
> > > > > > > will
> > > > > > > not do any wake ups.
> > > > > > >
> > > > > > > The rcuc thread which is awakened will run when the interrupt
> > > > > > > returns.
> > > > > > >
> > > > > > > We also honor 25102de ("rcu: Only do rcu_read_unlock_special()
> > > > > > > wakeups
> > > > > > > if expedited") thus doing the rcuc awakening only when none of the
> > > > > > > following are true:
> > > > > > > 1. Critical section is blocking an expedited GP.
> > > > > > > 2. A nohz_full CPU.
> > > > > > > If neither of these cases are true (exp == false), then the
> > > > > > > "else" block
> > > > > > > will run to do the irq_work stuff.
> > > > > > >
> > > > > > > This commit is based on a partial revert of d143b3d1cd89 ("rcu:
> > > > > > > Simplify
> > > > > > > rcu_read_unlock_special() deferred wakeups") with an additional
> > > > > > > in_irq()
> > > > > > > check added.
> > > > > > >
> > > > > > > Signed-off-by: Joel Fernandes (Google)
> > > > > >
> > > > > > OK, I will bite... If it is safe to wake up an rcuc kthread, why
> > > > > > is it not safe to do raise_softirq()?
> > > > >
> > > > > Because raise_softirq should not be done and/or doesn't do anything
> > > > > if use_softirq == false. In fact, RCU_SOFTIRQ doesn't even existing if
> > > > > use_softirq == false. The "else if" condition of this patch uses for
> > > > > use_softirq.
> > > > >
> > > > > Or, did I miss your point?
> > >
> > > I am concerned that added "else if" condition might not be sufficient
> > > to eliminate all possible cases of the caller holding a scheduler lock,
> > > which could result in deadlock in the ensuing wakeup. Might be me missing
> > > something, but such deadlocks have been a recurring problem in the past.
> >
> > I thought that was the whole point of the
> > rcu_read_unlock_special.b.deferred_qs bit that was introduced in
> > 23634ebc1d94. We are checking that bit in the "else if" here as well. So
> > this
> > should be no less immune to scheduler deadlocks any more than the preceding
> > "else if" where we are checking this bit.
>
> I would have much more confidence in a line of reasoning that led to
> "immune to scheduler deadlocks" than one that led to "no less immune to
> scheduler deadlocks". ;-)
That is fair :-D But let me explain,
What I meant is, if we are saying that this solution has a scheduler
deadlock, then that would almost certainly imply that the existing code has
scheduler deadlock issue. Since the existing code uses the same technique
(using the deferred_qs bit in the union) to prevent the deadlock we were
discussing a few months back. If that is indeed the case, it is good to be
discussing this since we can discuss if the existing code needs any fixing as
well.
> > > Also, your commit log's point #2 is "in_irq() implies in_interrupt()
> > > which implies raising softirq will not do any wake ups." This mention
> > > of softirq seems a bit odd, given that we are going to wake up a rcuc
> > > kthread. Of course, this did nothing to quell my suspicions. ;-)
> >
> > Yes, I should delete this #2 from the changelog since it is not very
> > relevant
> > (I feel now). My point with #2 was that even if were to raise a softirq
> > (which we are not), a scheduler wakeup of ksoftirqd is impossible in this
> > path anyway since in_irq() implies in_interrupt().
>
> Please! Could you also add a first-principles explanation of why
> the added condition is immune from scheduler deadlocks?
Sure I can add an example in the change log, however I was thinking of this
example which you mentioned:
https://lore.kernel.org/lkml/20190627173831.gw26...@linux.ibm.com/
previous_reader()
{
rcu_read_lock();
do_something(); /* Preemption happened
Re: [RFC V2 09/11] dt-bindings: interconnect: Add header for interconnect node
On Wed, 2019-05-01 at 15:28 -0500, Rob Herring wrote: > On Tue, Apr 30, 2019 at 04:51:03PM +0800, Henry Chen wrote: > > Add header file for mt8183 interconnect node that could be shared between > > the interconeect provider driver and Device Tree source files. > > > > Signed-off-by: Henry Chen > > --- > > include/dt-bindings/interconnect/mtk,mt8183.h | 18 ++ > > 1 file changed, 18 insertions(+) > > create mode 100644 include/dt-bindings/interconnect/mtk,mt8183.h > > This goes with the binding patch. ok, will merged into previous patch 08.
[PATCH v2] arch : arm : add a criteria for pfn_valid
From: Zhaoyang Huang
pfn_valid can be wrong when parsing a invalid pfn whose phys address
exceeds BITS_PER_LONG as the MSB will be trimed when shifted.
Signed-off-by: Zhaoyang Huang
---
v2: use __pfn_to_phys/__phys_to_pfn instead of max_pfn as the criteria
---
arch/arm/mm/init.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index c2daabb..cc769fa 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -177,6 +177,11 @@ static void __init zone_sizes_init(unsigned long min,
unsigned long max_low,
#ifdef CONFIG_HAVE_ARCH_PFN_VALID
int pfn_valid(unsigned long pfn)
{
+ phys_addr_t addr = __pfn_to_phys(pfn);
+
+ if (__phys_to_pfn(addr) != pfn)
+ return 0;
+
return memblock_is_map_memory(__pfn_to_phys(pfn));
}
EXPORT_SYMBOL(pfn_valid);
--
1.9.1
Re: [RFC v2] rcu/tree: Try to invoke_rcu_core() if in_irq() during unlock
On Sun, Aug 18, 2019 at 09:41:43PM -0400, Joel Fernandes wrote:
> On Sun, Aug 18, 2019 at 06:21:53PM -0700, Paul E. McKenney wrote:
[snip]
> > > > Also, your commit log's point #2 is "in_irq() implies in_interrupt()
> > > > which implies raising softirq will not do any wake ups." This mention
> > > > of softirq seems a bit odd, given that we are going to wake up a rcuc
> > > > kthread. Of course, this did nothing to quell my suspicions. ;-)
> > >
> > > Yes, I should delete this #2 from the changelog since it is not very
> > > relevant
> > > (I feel now). My point with #2 was that even if were to raise a softirq
> > > (which we are not), a scheduler wakeup of ksoftirqd is impossible in this
> > > path anyway since in_irq() implies in_interrupt().
> >
> > Please! Could you also add a first-principles explanation of why
> > the added condition is immune from scheduler deadlocks?
>
> Sure I can add an example in the change log, however I was thinking of this
> example which you mentioned:
> https://lore.kernel.org/lkml/20190627173831.gw26...@linux.ibm.com/
>
> previous_reader()
> {
> rcu_read_lock();
> do_something(); /* Preemption happened here. */
> local_irq_disable(); /* Cannot be the scheduler! */
> do_something_else();
> rcu_read_unlock(); /* Must defer QS, task still queued. */
> do_some_other_thing();
> local_irq_enable();
> }
>
> current_reader() /* QS from previous_reader() is still deferred. */
> {
> local_irq_disable(); /* Might be the scheduler. */
> do_whatever();
> rcu_read_lock();
> do_whatever_else();
> rcu_read_unlock(); /* Must still defer reporting QS. */
> do_whatever_comes_to_mind();
> local_irq_enable();
> }
>
> One modification of the example could be, previous_reader() could also do:
> previous_reader()
> {
> rcu_read_lock();
> do_something_that_takes_really_long(); /* causes need_qs in
> the
> unlock_special_union to be set */
> local_irq_disable(); /* Cannot be the scheduler! */
> do_something_else();
> rcu_read_unlock(); /* Must defer QS, task still queued. */
> do_some_other_thing();
> local_irq_enable();
> }
The point you were making in that thread being, current_reader() ->
rcu_read_unlock() -> rcu_read_unlock_special() would not do any wakeups
because previous_reader() sets the deferred_qs bit.
Anyway, I will add all of this into the changelog.
thanks,
- Joel
Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On 2019年08月16日 14:39, Borislav Petkov wrote: On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: The first three patches are the changes under x86/acrn, which adds the required APIs for the driver and reports the X2APIC caps. The remaining patches add the ACRN driver module, which accepts the ioctl from user-space and then communicate with the low-level ACRN hypervisor by using hypercall. I have a problem with that: you're adding interfaces to arch/x86/ and its users go into staging. Why? Why not directly put the driver where it belongs, clean it up properly and submit it like everything else is submitted? Thanks for your reply and the concern. After taking a look at several driver examples(gma500, android), it seems that they are firstly added into drivers/staging/XXX and then moved to drivers/XXX after the driver becomes mature. So we refer to this method to upstream ACRN driver part. If the new driver can also be added by skipping the staging approach, we will refine it and then submit it in normal process. I don't want to have stuff in arch/x86/ which is used solely by code in staging and the latter is lingering there indefinitely because no one is cleaning it up... The ACRN driver will be the only user of the added APIs in x86/acrn. Without the APIs in x86/acrn, the driver can't add the driver-specifc upcall notification ISR or call the hypercall. Not sure whether it can be sent in two patch sets? The first is to add the required APIs for ACRN driver. The second is to add the ACRN driver Thanks Yakui
Re: [RFC V2 10/11] interconnect: mediatek: Add mt8183 interconnect provider driver
Hi Georgi,
Sorry for late reply.
On Tue, 2019-05-14 at 09:43 +0300, Georgi Djakov wrote:
> Hi Henry,
>
> On 4/30/19 11:51, Henry Chen wrote:
> > Introduce Mediatek MT8183 specific provider driver using the
> > interconnect framework.
> >
> > Signed-off-by: Henry Chen
> > ---
> > drivers/interconnect/Kconfig | 1 +
> > drivers/interconnect/Makefile | 1 +
> > drivers/interconnect/mediatek/Kconfig | 13 ++
> > drivers/interconnect/mediatek/Makefile | 5 +
> > drivers/interconnect/mediatek/mt8183.c | 223
> > +
> > 5 files changed, 243 insertions(+)
> > create mode 100644 drivers/interconnect/mediatek/Kconfig
> > create mode 100644 drivers/interconnect/mediatek/Makefile
> > create mode 100644 drivers/interconnect/mediatek/mt8183.c
> >
> > diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
> > index 07a8276..ac41ea6 100644
> > --- a/drivers/interconnect/Kconfig
> > +++ b/drivers/interconnect/Kconfig
> > @@ -11,5 +11,6 @@ menuconfig INTERCONNECT
> > if INTERCONNECT
> >
> > source "drivers/interconnect/qcom/Kconfig"
> > +source "drivers/interconnect/mediatek/Kconfig"
> >
> > endif
> > diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
> > index 28f2ab0..253f24a3 100644
> > --- a/drivers/interconnect/Makefile
> > +++ b/drivers/interconnect/Makefile
> > @@ -4,3 +4,4 @@ icc-core-objs := core.o
> >
> > obj-$(CONFIG_INTERCONNECT) += icc-core.o
> > obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/
> > +obj-$(CONFIG_INTERCONNECT_MTK) += mediatek/
> > diff --git a/drivers/interconnect/mediatek/Kconfig
> > b/drivers/interconnect/mediatek/Kconfig
> > new file mode 100644
> > index 000..0686494
> > --- /dev/null
> > +++ b/drivers/interconnect/mediatek/Kconfig
> > @@ -0,0 +1,13 @@
> > +config INTERCONNECT_MTK
> > + bool "Mediatek Network-on-Chip interconnect drivers"
> > + depends on ARCH_MEDIATEK
> > + help
> > + Support for Mediatek's Network-on-Chip interconnect hardware.
> > +
> > +config INTERCONNECT_MTK_MT8183
> > + tristate "Mediatek MT8183 interconnect driver"
> > + depends on INTERCONNECT_MTK
> > + depends on (MTK_DVFSRC && OF)
> > + help
> > + This is a driver for the Mediatek Network-on-Chip on mt8183-based
> > + platforms.
> > diff --git a/drivers/interconnect/mediatek/Makefile
> > b/drivers/interconnect/mediatek/Makefile
> > new file mode 100644
> > index 000..a39ceee
> > --- /dev/null
> > +++ b/drivers/interconnect/mediatek/Makefile
> > @@ -0,0 +1,5 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +mtk-mt8183-objs:= mt8183.o
> > +
> > +obj-$(CONFIG_INTERCONNECT_MTK_MT8183) += mtk-mt8183.o
> > \ No newline at end of file
> > diff --git a/drivers/interconnect/mediatek/mt8183.c
> > b/drivers/interconnect/mediatek/mt8183.c
> > new file mode 100644
> > index 000..38ffe0b
> > --- /dev/null
> > +++ b/drivers/interconnect/mediatek/mt8183.c
> > @@ -0,0 +1,223 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2019, The Linux Foundation. All rights reserved.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
>
> This is not needed.
ok, thanks.
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define MT8183_MAX_LINKS 6
> > +
> > +/**
> > + * struct mtk_icc_node - Mediatek specific interconnect nodes
> > + * @name: the node name used in debugfs
> > + * @ep: true if the node is an end point.
> > + * @id: a unique node identifier
> > + * @links: an array of nodes where we can go next while traversing
> > + * @num_links: the total number of @links
> > + * @buswidth: width of the interconnect between a node and the bus
>
> Maybe mention the units?
ok, I will add it.
>
> > + * @sum_avg: current sum aggregate value of all avg bw requests
> > + * @max_peak: current max aggregate value of all peak bw requests
>
> units?
>
> > + */
> > +struct mtk_icc_node {
> > + unsigned char *name;
> > + bool ep;
> > + u16 id;
> > + u16 links[MT8183_MAX_LINKS];
> > + u16 num_links;
> > + u16 buswidth;
> > + u64 sum_avg;
> > + u64 max_peak;
> > +};
> > +
> > +struct mtk_icc_desc {
> > + struct mtk_icc_node **nodes;
> > + size_t num_nodes;
> > +};
> > +
> > +#define DEFINE_MNODE(_name, _id, _buswidth, _ep, _numlinks, ...) \
>
> We can drop the _numlinks and..
ok, thank you for the advice.
>
> > + static struct mtk_icc_node _name = {\
> > + .name = #_name, \
> > + .id = _id, \
> > + .buswidth = _buswidth, \
> > + .ep = _ep, \
> > + .num_links = _numlinks, \
>
> ..just use.num_links = ARRAY_SIZE(((int[]){
Re: [PATCH 2/2] clk: Add support for AST2600 SoC
On Fri, 16 Aug 2019 at 17:14, Stephen Boyd wrote:
>
> Quoting Joel Stanley (2019-08-16 08:58:06)
> > diff --git a/drivers/clk/clk-ast2600.c b/drivers/clk/clk-ast2600.c
> > new file mode 100644
> > index ..083d5299238c
> > --- /dev/null
> > +++ b/drivers/clk/clk-ast2600.c
> > @@ -0,0 +1,701 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +// Copyright IBM Corp
> > +// Copyright ASPEED Technology
> > +
> [...]
> > +#define ASPEED_DPLL_PARAM 0x260
> > +
> > +#define ASPEED_G6_STRAP1 0x500
> > +
> > +/* Globally visible clocks */
> > +static DEFINE_SPINLOCK(aspeed_clk_lock);
>
> I guess we can be guaranteed that the two drivers aren't compiled into
> the same image? Otherwise this will alias with clk-aspeed.c and make
> kallsyms annoying to use.
I will change the name.
>
> > +
> > +/* Keeps track of all clocks */
> > +static struct clk_hw_onecell_data *aspeed_g6_clk_data;
> > +
> > +static void __iomem *scu_g6_base;
> > +
> > +static const struct aspeed_gate_data aspeed_g6_gates[] = {
> > + /* clk rst name
> > parent flags */
> > + [ASPEED_CLK_GATE_MCLK] = { 0, -1, "mclk-gate",
> > "mpll", CLK_IS_CRITICAL }, /* SDRAM */
>
> Please document CLK_IS_CRITICAL usage. I guess it's memory so never turn
> it off?
Yes.
I added some comments and removed some uses that I didn't know the
reason for. We can add them back later if required, with the
reasoning.
> > +static const char * const vclk_parent_names[] = {
>
> Can you use the new way of specifying clk parents instead of just using
> strings?
How does this work? I had a browse of the APIs in clk-provider.h and
it appeared the functions all take char *s still.
> > + hw = clk_hw_register_fixed_factor(NULL, "ahb", "hpll", 0, 1,
> > axi_div * ahb_div);
>
> There aren't checks for if these things fail. I guess it doesn't matter
> and just let it fail hard?
I think that's sensible here. If the system has run out of memory this
early on then there's not going to be much that works.
Thanks for the review. I've fixed all of the style issues you
mentioned, but would appreciate some guidance on the parent API.
Cheers,
Joel
Re: [PATCH RESEND v4 5/9] KVM: VMX: Add init/set/get functions for SPP
On Fri, Aug 16, 2019 at 11:19:46AM -0700, Jim Mattson wrote: > On Fri, Aug 16, 2019 at 6:29 AM Yang Weijiang wrote: > > > Thanks Jim and Sean! Could we add a new flag in kvm to identify if nested > > VM is on > > or off? That would make things easier. When VMLAUNCH is trapped, > > set the flag, if VMXOFF is trapped, clear the flag. > > KVM_GET_NESTED_STATE has the requested information. If > data.vmx.vmxon_pa is anything other than -1, then the vCPU is in VMX > operation. If (flags & KVM_STATE_NESTED_GUEST_MODE), then L2 is > active. Thanks Jim, I'll reference the code and make necessary change in next SPP patch release.
RE: [EXT] Re: [v2 1/3] dt/bindings: clk: Add YAML schemas for LS1028A Display Clock bindings
> -Original Message- > From: Stephen Boyd > Sent: 2019年8月17日 1:47 > To: Mark Rutland ; Michael Turquette > ; Rob Herring ; Shawn Guo > ; Wen He ; > devicet...@vger.kernel.org; linux-...@vger.kernel.org; > linux-de...@linux.nxdi.nxp.com; linux-kernel@vger.kernel.org > Cc: Leo Li ; liviu.du...@arm.com; Wen He > > Subject: [EXT] Re: [v2 1/3] dt/bindings: clk: Add YAML schemas for LS1028A > Display Clock bindings > > Caution: EXT Email > > Quoting Wen He (2019-08-15 03:16:11) > > LS1028A has a clock domain PXLCLK0 used for provide pixel clocks to > > Display output interface. Add a YAML schema for this. > > > > Signed-off-by: Wen He > > --- > > Patch looks good. Please send multi-patch series with a cover letter next time > when you resend and pick up Rob's review. Understand, Thank you for the review. Best Regards, Wen > > > change in v2: > > - Convert bindings to YAML format > >
Re: How to turn scheduler tick on for current nohz_full CPU?
On Tue, Jul 30, 2019 at 10:36:37AM -0700, Paul E. McKenney wrote: > On Tue, Jul 30, 2019 at 06:43:10PM +0200, Frederic Weisbecker wrote: > > On Mon, Jul 29, 2019 at 03:32:38PM -0700, Paul E. McKenney wrote: > > > On Wed, Jul 24, 2019 at 06:12:43PM -0700, Paul E. McKenney wrote: > > > > > > The patch below (which includes your patch) does help considerably. > > > However, it does have some shortcomings: > > > > > > 1.Adds an atomic operation (albeit a cache-local one) to > > > the scheduler fastpath. One approach would be to have > > > a way of testing this bit and clearing it only if set. > > > > > > Another approach would be to instead clear it on the > > > transition to nohz_full userspace or to idle. > > > > Well, the latter would be costly as it is going to restart the tick on every > > user -> kernel transitions. > > You lost me on this one. I would be turning off RCU's request to > maintain the tick on transition to nohz_full userspace or to idle. > Why would the tick get turned on by a later user->kernel transition? > > > > 2.There are a lot of other places in the kernel that are in > > > need of this bit being set. I am therefore considering making > > > multi_cpu_stop() or its callers set this bit on all CPUs upon > > > entry and clear it upon exit. While in this state, it is > > > likely necessary to disable clearing this bit. Or it would > > > be necessary to make multi_cpu_stop() repeat clearing the bit > > > every so often. > > > > > > As it stands, I have CPU hotplug removal operations taking > > > more than 400 seconds. > > > > > > 3.It was tempting to ask for this bit to be tracked on a per-task > > > basis, but from what I can see that adds at least as much > > > complexity as it removes. > > > > Yeah I forgot to answer, you can use tick_dep_set_task() for that. > > Ah, good, that would remove my need to clear things on the scheduler > fastpaths. My guess is that I use both the per-CPU and the per-task > variant in different places, but testing will tell! ;-) And after a few bug fixes (one key fix for an embarrassing bug from Joel), this now passes 14-hour rcutorture on the scenario that used to get RCU CPU stall warnings once or twice per hour. Though still not material for the upcoming merge window. Thank you, everyone! Thanx, Paul
Re: [PATCH V2 04/10] cpufreq: powerpc_cbe: Switch to QoS requests instead of cpufreq notifier
On 09-08-19, 11:01, Rafael J. Wysocki wrote: > On Fri, Aug 9, 2019 at 4:34 AM Viresh Kumar wrote: > > > > On 23-07-19, 11:44, Viresh Kumar wrote: > > > The cpufreq core now takes the min/max frequency constraints via QoS > > > requests and the CPUFREQ_ADJUST notifier shall get removed later on. > > > > > > Switch over to using the QoS request for maximum frequency constraint > > > for ppc_cbe_cpufreq driver. > > > > > > Signed-off-by: Viresh Kumar > > > --- > > > drivers/cpufreq/ppc_cbe_cpufreq.c | 19 +- > > > drivers/cpufreq/ppc_cbe_cpufreq.h | 8 +++ > > > drivers/cpufreq/ppc_cbe_cpufreq_pmi.c | 96 +-- > > > 3 files changed, 86 insertions(+), 37 deletions(-) > > > > -8<- > > If you do it this way, Patchwork will not pick up the patch. > > Please send afresh with "[Update]" or bumped up version number in the > subject (or both). Okay, will take care of this in future. Was away on holidays and so the late reply. Thanks. -- viresh
Re: [PATCH v2 2/2] PCI: pciehp: Prevent deadlock on disconnect
On 8/12/2019 10:31 AM, Mika Westerberg wrote:
> +int pciehp_card_present_or_link_active(struct controller *ctrl)
> {
> - return pciehp_card_present(ctrl) || pciehp_check_link_active(ctrl);
> + int ret;
> +
> + ret = pciehp_card_present(ctrl);
> + if (ret)
> + return ret;
> +
> + return pciehp_check_link_active(ctrl);
The semantics of this function changed here. Before it was checking for
either presence detect bit or link active bit. Now, it is looking to
have both set.
There are PCI controllers that won't report presence detect correctly,
but still report link active.
I think you want
if (ret < 0)
return ret;
here to match the previous behavior while still handling device removal.
Re: [RFC v2] rcu/tree: Try to invoke_rcu_core() if in_irq() during unlock
On Sun, Aug 18, 2019 at 09:46:23PM -0400, Joel Fernandes wrote:
> On Sun, Aug 18, 2019 at 09:41:43PM -0400, Joel Fernandes wrote:
> > On Sun, Aug 18, 2019 at 06:21:53PM -0700, Paul E. McKenney wrote:
> [snip]
> > > > > Also, your commit log's point #2 is "in_irq() implies in_interrupt()
> > > > > which implies raising softirq will not do any wake ups." This mention
> > > > > of softirq seems a bit odd, given that we are going to wake up a rcuc
> > > > > kthread. Of course, this did nothing to quell my suspicions. ;-)
> > > >
> > > > Yes, I should delete this #2 from the changelog since it is not very
> > > > relevant
> > > > (I feel now). My point with #2 was that even if were to raise a softirq
> > > > (which we are not), a scheduler wakeup of ksoftirqd is impossible in
> > > > this
> > > > path anyway since in_irq() implies in_interrupt().
> > >
> > > Please! Could you also add a first-principles explanation of why
> > > the added condition is immune from scheduler deadlocks?
> >
> > Sure I can add an example in the change log, however I was thinking of this
> > example which you mentioned:
> > https://lore.kernel.org/lkml/20190627173831.gw26...@linux.ibm.com/
> >
> > previous_reader()
> > {
> > rcu_read_lock();
> > do_something(); /* Preemption happened here. */
> > local_irq_disable(); /* Cannot be the scheduler! */
> > do_something_else();
> > rcu_read_unlock(); /* Must defer QS, task still queued. */
> > do_some_other_thing();
> > local_irq_enable();
> > }
> >
> > current_reader() /* QS from previous_reader() is still deferred. */
> > {
> > local_irq_disable(); /* Might be the scheduler. */
> > do_whatever();
> > rcu_read_lock();
> > do_whatever_else();
> > rcu_read_unlock(); /* Must still defer reporting QS. */
> > do_whatever_comes_to_mind();
> > local_irq_enable();
> > }
> >
> > One modification of the example could be, previous_reader() could also do:
> > previous_reader()
> > {
> > rcu_read_lock();
> > do_something_that_takes_really_long(); /* causes need_qs in
> > the
> > unlock_special_union to be set */
> > local_irq_disable(); /* Cannot be the scheduler! */
> > do_something_else();
> > rcu_read_unlock(); /* Must defer QS, task still queued. */
> > do_some_other_thing();
> > local_irq_enable();
> > }
>
> The point you were making in that thread being, current_reader() ->
> rcu_read_unlock() -> rcu_read_unlock_special() would not do any wakeups
> because previous_reader() sets the deferred_qs bit.
>
> Anyway, I will add all of this into the changelog.
Examples are good, but what makes it so that there are no examples of
its being unsafe?
And a few questions along the way, some quick quiz, some more serious.
Would it be safe if it checked in_interrupt() instead of in_irq()?
If not, should the in_interrupt() in the "if" condition preceding the
added "else if" be changed to in_irq()? Would it make sense to add an
"|| !irqs_were_disabled" do your new "else if" condition? Would the
body of the "else if" actually be executed in current mainline?
In an attempt to be at least a little constructive, I am doing some
testing of this patch overnight, along with a WARN_ON_ONCE() to see if
that invoke_rcu_core() is ever reached.
Thanx, Paul
Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On 2019年08月16日 15:03, Greg KH wrote: On Fri, Aug 16, 2019 at 08:39:25AM +0200, Borislav Petkov wrote: On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: The first three patches are the changes under x86/acrn, which adds the required APIs for the driver and reports the X2APIC caps. The remaining patches add the ACRN driver module, which accepts the ioctl from user-space and then communicate with the low-level ACRN hypervisor by using hypercall. I have a problem with that: you're adding interfaces to arch/x86/ and its users go into staging. Why? Why not directly put the driver where it belongs, clean it up properly and submit it like everything else is submitted? I don't want to have stuff in arch/x86/ which is used solely by code in staging and the latter is lingering there indefinitely because no one is cleaning it up... I agree, stuff in drivers/staging/ must be self-contained, with no changes outside of the code's subdirectory needed in order for it to work. That way it is trivial for us to delete it when it never gets cleaned up :) Thanks for pointing out the rule of drivers/staging. The acrn staging driver is one self-contained driver. But it has some dependency on arch/x86/acrn and need to call the APIs in arch/x86/acrn. If there is no driver, the API without user had better not be added. If API is not added, the driver can't be compiled correctly. The ACRN driver is one new driver. Maybe it will have some bugs and not be mature. So we want to add the driver as the staging. What is the better approach to handle such scenario? You never say _why_ this should go into drivers/staging/, nor do you have a TODO file like all other staging code that explains exactly what needs to be done to get it out of there. Ok. The TODO file will be added in next version. thanks, greg k-h
[GIT] Networking
1) Fix jmp to 1st instruction in x64 JIT, from Alexei Starovoitov. 2) Severl kTLS fixes in mlx5 driver, from Tariq Toukan. 3) Fix severe performance regression due to lack of SKB coalescing of fragments during local delivery, from Guillaume Nault. 4) Error path memory leak in sch_taprio, from Ivan Khoronzhuk. 5) Fix batched events in skbedit packet action, from Roman Mashak. 6) Propagate VLAN TX offload to hw_enc_features in bond and team drivers, from Yue Haibing. 7) RXRPC local endpoint refcounting fix and read after free in rxrpc_queue_local(), from David Howells. 8) Fix endian bug in ibmveth multicast list handling, from Thomas Falcon. 9) Oops, make nlmsg_parse() wrap around the correct function, __nlmsg_parse not __nla_parse(). Fix from David Ahern. 10) Memleak in sctp_scend_reset_streams(), fro Zheng Bin. 11) Fix memory leak in cxgb4, from Wenwen Wang. 12) Yet another race in AF_PACKET, from Eric Dumazet. 13) Fix false detection of retransmit failures in tipc, from Tuong Lien. 14) Use after free in ravb_tstamp_skb, from Tho Vu. Please pull, thanks a lot! The following changes since commit 33920f1ec5bf47c5c0a1d2113989bdd9dfb3fae9: Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2019-08-06 17:11:59 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git for you to fetch changes up to cfef46d692efd852a0da6803f920cc756eea2855: ravb: Fix use-after-free ravb_tstamp_skb (2019-08-18 14:19:14 -0700) Alexei Starovoitov (2): bpf: fix x64 JIT code generation for jmp to 1st insn selftests/bpf: tests for jmp to 1st insn Anders Roxell (1): selftests: net: tcp_fastopen_backup_key.sh: fix shellcheck issue Andrii Nakryiko (2): libbpf: fix erroneous multi-closing of BTF FD libbpf: set BTF FD for prog only when there is supported .BTF.ext data André Draszik (1): net: phy: at803x: stop switching phy delay config needlessly Aya Levin (3): net/mlx5e: Fix false negative indication on tx reporter CQE recovery net/mlx5e: Fix error flow of CQE recovery on tx reporter net/mlx5e: Remove redundant check in CQE recovery flow of tx reporter Balakrishna Godavarthi (1): Bluetooth: btqca: Reset download type to default Chen-Yu Tsai (1): net: dsa: Check existence of .port_mdb_add callback before calling it Chris Packham (1): tipc: initialise addr_trail_end when setting node addresses Claire Chang (1): Bluetooth: btqca: release_firmware after qca_inject_cmd_complete_event Daniel Borkmann (3): Merge branch 'bpf-bpftool-pinning-error-msg' sock: make cookie generation global instead of per netns bpf: sync bpf.h to tools infrastructure David Ahern (2): netdevsim: Restore per-network namespace accounting for fib entries netlink: Fix nlmsg_parse as a wrapper for strict message parsing David Howells (5): rxrpc: Fix local endpoint refcounting rxrpc: Don't bother generating maxSkew in the ACK packet rxrpc: Fix local refcounting rxrpc: Fix local endpoint replacement rxrpc: Fix read-after-free in rxrpc_queue_local() David S. Miller (12): Merge tag 'batadv-net-for-davem-20190808' of git://git.open-mesh.org/linux-merge Merge branch 'skbedit-batch-fixes' Merge tag 'rxrpc-fixes-20190809' of git://git.kernel.org/.../dhowells/linux-fs Merge branch 'Fix-collisions-in-socket-cookie-generation' Merge tag 'mlx5-fixes-2019-08-08' of git://git.kernel.org/.../saeed/linux Merge git://git.kernel.org/.../bpf/bpf Merge tag 'mlx5-fixes-2019-08-15' of git://git.kernel.org/.../saeed/linux Merge git://git.kernel.org/.../pablo/nf Merge tag 'rxrpc-fixes-20190814' of git://git.kernel.org/.../dhowells/linux-fs Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth Merge branch 'bnxt_en-Bug-fixes' Merge branch 'flow_offload-hardware-priority-fixes' Denis Efremov (2): MAINTAINERS: PHY LIBRARY: Update files in the record MAINTAINERS: r8169: Update path to the driver Dexuan Cui (1): hv_netvsc: Fix a warning of suspicious RCU usage Dirk Morris (1): netfilter: conntrack: Use consistent ct id hash calculation Eran Ben Elisha (1): net/mlx5e: Fix compatibility issue with ethtool flash device Eric Dumazet (1): net/packet: fix race in tpacket_snd() Fabian Henneke (1): Bluetooth: hidp: Let hidp_send_message return number of queued bytes Florian Westphal (2): selftests: netfilter: extend flowtable test script for ipsec netfilter: nf_flow_table: fix offload for flows that are subject to xfrm Fuqian Huang (1): net: tundra: tsi108: use spin_lock_irqsave instead of spin_lock_irq in IRQ context Guillaume Nault (1): inet: frags: re-introduce skb coalescing for local delivery Harish Bandi
[PATCH v2] mtd: rawnand: Fix a memory leak bug
In nand_scan_bbt(), a temporary buffer 'buf' is allocated through
vmalloc(). However, if check_create() fails, 'buf' is not deallocated,
leading to a memory leak bug. To fix this issue, free 'buf' before
returning the error.
Signed-off-by: Wenwen Wang
---
drivers/mtd/nand/raw/nand_bbt.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_bbt.c b/drivers/mtd/nand/raw/nand_bbt.c
index 2ef15ef..96045d6 100644
--- a/drivers/mtd/nand/raw/nand_bbt.c
+++ b/drivers/mtd/nand/raw/nand_bbt.c
@@ -1232,7 +1232,7 @@ static int nand_scan_bbt(struct nand_chip *this, struct
nand_bbt_descr *bd)
if (!td) {
if ((res = nand_memory_bbt(this, bd))) {
pr_err("nand_bbt: can't scan flash and build the
RAM-based BBT\n");
- goto err;
+ goto err_free_bbt;
}
return 0;
}
@@ -1245,7 +1245,7 @@ static int nand_scan_bbt(struct nand_chip *this, struct
nand_bbt_descr *bd)
buf = vmalloc(len);
if (!buf) {
res = -ENOMEM;
- goto err;
+ goto err_free_bbt;
}
/* Is the bbt at a given page? */
@@ -1258,7 +1258,7 @@ static int nand_scan_bbt(struct nand_chip *this, struct
nand_bbt_descr *bd)
res = check_create(this, buf, bd);
if (res)
- goto err;
+ goto err_free_buf;
/* Prevent the bbt regions from erasing / writing */
mark_bbt_region(this, td);
@@ -1268,7 +1268,9 @@ static int nand_scan_bbt(struct nand_chip *this, struct
nand_bbt_descr *bd)
vfree(buf);
return 0;
-err:
+err_free_buf:
+ vfree(buf);
+err_free_bbt:
kfree(this->bbt);
this->bbt = NULL;
return res;
--
2.7.4
Re: [PATCH v2 0/3] HID: intel-ish-hid: support s2idle and s3 in ish_suspend()
On Thu, 2019-08-08 at 18:21 +0800, Zhang Lixu wrote: > Currently, the NO_D3 flag is set in ish_probe(), the intel-ish-ipc > driver > puts the ISH into D0i3 when system enter both suspend-to-idle(S0ix) > and > suspend-to-mem(S3). These patches are to put the ISH into D3 when > system > enter S3 and put the ISH into D0i3 when system enter S0ix. > > I tested these patches on the following platforms: > ISH 5.2: ICL > ISH 5.0: CNL CFL WHL CML > ISH 4.0: GLK > ISH 3.0: KBL > > Test steps: > * Run the IIO Sensor tool to read the accel_3d sensor data > * Run cmd "echo mem > /sys/power/state" to suspend-to-mem > * Press the keyboard to wake up OS. > * Check if the tool can get the sensor data after OS resume. > * Run cmd "echo freeze > /sys/power/state" to suspend-to-idle > * Press the keyboard to wake up OS. > * Check if the tool can get the sensor data after OS resume. > > Test results: > The tool can get the accel_3d sensor data after resuming from both > suspend-to-mem and suspend-to-idle. > > Changes from v1: > * Fix the indentation issue > * Elaborate the reason to remove the NO_D3 flag > * Split the PATCH v1 to three changes, and try to minimize the lines > change > > Zhang Lixu (3): > HID: intel-ish-hid: ipc: set NO_D3 flag only when needed > HID: intel-ish-hid: ipc: make ish suspend paths clear > HID: intel-ish-hid: ipc: check the NO_D3 flag to distinguish resume > paths > For the series: Acked-by: Srinivas Pandruvada > drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 + > drivers/hid/intel-ish-hid/ipc/ipc.c | 2 +- > drivers/hid/intel-ish-hid/ipc/pci-ish.c | 95 +++-- > > 3 files changed, 61 insertions(+), 37 deletions(-) >
[PATCH v12 05/12] mailbox: mediatek: cmdq: support mt8183 gce function
add mt8183 compatible name for supporting gce function
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/mailbox/mtk-cmdq-mailbox.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index 8fddd26288e8..69daaadc3a5f 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -539,6 +539,7 @@ static const struct dev_pm_ops cmdq_pm_ops = {
static const struct of_device_id cmdq_of_ids[] = {
{.compatible = "mediatek,mt8173-gce", .data = (void *)16},
+ {.compatible = "mediatek,mt8183-gce", .data = (void *)24},
{}
};
--
2.18.0
[PATCH v12 03/12] dt-binding: gce: add binding for gce client reg property
cmdq driver provide a function that get the relationship of sub system number from device node for client. add specification for #subsys-cells, mediatek,gce-client-reg. Signed-off-by: Bibby Hsieh Reviewed-by: Rob Herring --- .../devicetree/bindings/mailbox/mtk-gce.txt | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 1f7f8f2a3f49..7b13787ab13d 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -25,8 +25,16 @@ Required properties: Required properties for a client device: - mboxes: Client use mailbox to communicate with GCE, it should have this property and list of phandle, mailbox specifiers. -- mediatek,gce-subsys: u32, specify the sub-system id which is corresponding - to the register address. +Optional properties for a client device: +- mediatek,gce-client-reg: Specify the sub-system id which is corresponding + to the register address, it should have this property and list of phandle, + sub-system specifiers. + < subsys_number start_offset size> + phandle: Label name of a gce node. + subsys_number: specify the sub-system id which is corresponding + to the register address. + start_offset: the start offset of register address that GCE can access. + size: the total size of register address that GCE can access. Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h' or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, event ids. @@ -48,9 +56,9 @@ Example for a client device: compatible = "mediatek,mt8173-mmsys"; mboxes = < 0 CMDQ_THR_PRIO_LOWEST 1>, < 1 CMDQ_THR_PRIO_LOWEST 1>; - mediatek,gce-subsys = ; mutex-event-eof = ; - + mediatek,gce-client-reg = < SUBSYS_1400 0x3000 0x1000>, + < SUBSYS_1401 0x2000 0x100>; ... }; -- 2.18.0
[PATCH v12 08/12] soc: mediatek: cmdq: change the type of input parameter
According to the cmdq hardware design, the subsys is u8,
the offset is u16 and the event id is u16.
This patch changes the type of subsys, offset and event id
to the correct type.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 10 +-
include/linux/soc/mediatek/mtk-cmdq.h | 10 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 082b8978651e..7aa0517ff2f3 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -136,7 +136,7 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt,
enum cmdq_code code,
return 0;
}
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
{
u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
(subsys << CMDQ_SUBSYS_SHIFT);
@@ -145,8 +145,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32
offset, u32 value)
}
EXPORT_SYMBOL(cmdq_pkt_write);
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
- u32 offset, u32 value, u32 mask)
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value, u32 mask)
{
u32 offset_mask = offset;
int err = 0;
@@ -161,7 +161,7 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event)
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
u32 arg_b;
@@ -181,7 +181,7 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event)
}
EXPORT_SYMBOL(cmdq_pkt_wfe);
-int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u32 event)
+int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
{
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 39d813dde4b4..9618debb9ceb 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -66,7 +66,7 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt);
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value);
/**
* cmdq_pkt_write_mask() - append write command with mask to the CMDQ packet
@@ -78,8 +78,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32
offset, u32 value);
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
- u32 offset, u32 value, u32 mask);
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value, u32 mask);
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
@@ -88,7 +88,7 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event);
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
/**
* cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
@@ -97,7 +97,7 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event);
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u32 event);
+int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
/**
* cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
--
2.18.0
[PATCH v12 04/12] mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data
The interrupt mask and thread number has positive correlation,
so we move the CMDQ_IRQ_MASK into cmdq driver data and calculate
it by thread number.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/mailbox/mtk-cmdq-mailbox.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index 00d5219094e5..8fddd26288e8 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -18,7 +18,6 @@
#include
#define CMDQ_OP_CODE_MASK (0xff << CMDQ_OP_CODE_SHIFT)
-#define CMDQ_IRQ_MASK 0x
#define CMDQ_NUM_CMD(t)(t->cmd_buf_size /
CMDQ_INST_SIZE)
#define CMDQ_CURR_IRQ_STATUS 0x10
@@ -72,6 +71,7 @@ struct cmdq {
void __iomem*base;
u32 irq;
u32 thread_nr;
+ u32 irq_mask;
struct cmdq_thread *thread;
struct clk *clock;
boolsuspended;
@@ -285,11 +285,11 @@ static irqreturn_t cmdq_irq_handler(int irq, void *dev)
unsigned long irq_status, flags = 0L;
int bit;
- irq_status = readl(cmdq->base + CMDQ_CURR_IRQ_STATUS) & CMDQ_IRQ_MASK;
- if (!(irq_status ^ CMDQ_IRQ_MASK))
+ irq_status = readl(cmdq->base + CMDQ_CURR_IRQ_STATUS) & cmdq->irq_mask;
+ if (!(irq_status ^ cmdq->irq_mask))
return IRQ_NONE;
- for_each_clear_bit(bit, _status, fls(CMDQ_IRQ_MASK)) {
+ for_each_clear_bit(bit, _status, cmdq->thread_nr) {
struct cmdq_thread *thread = >thread[bit];
spin_lock_irqsave(>chan->lock, flags);
@@ -473,6 +473,9 @@ static int cmdq_probe(struct platform_device *pdev)
dev_err(dev, "failed to get irq\n");
return -EINVAL;
}
+
+ cmdq->thread_nr = (u32)(unsigned long)of_device_get_match_data(dev);
+ cmdq->irq_mask = GENMASK(cmdq->thread_nr - 1, 0);
err = devm_request_irq(dev, cmdq->irq, cmdq_irq_handler, IRQF_SHARED,
"mtk_cmdq", cmdq);
if (err < 0) {
@@ -489,7 +492,6 @@ static int cmdq_probe(struct platform_device *pdev)
return PTR_ERR(cmdq->clock);
}
- cmdq->thread_nr = (u32)(unsigned long)of_device_get_match_data(dev);
cmdq->mbox.dev = dev;
cmdq->mbox.chans = devm_kcalloc(dev, cmdq->thread_nr,
sizeof(*cmdq->mbox.chans), GFP_KERNEL);
--
2.18.0
[PATCH v12 06/12] soc: mediatek: cmdq: clear the event in cmdq initial flow
GCE hardware stored event information in own internal sysram,
if the initial value in those sysram is not zero value
it will cause a situation that gce can wait the event immediately
after client ask gce to wait event but not really trigger the
corresponding hardware.
In order to make sure that the wait event function is
exactly correct, we need to clear the sysram value in
cmdq initial flow.
Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver")
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/mailbox/mtk-cmdq-mailbox.c | 5 +
include/linux/mailbox/mtk-cmdq-mailbox.h | 2 ++
include/linux/soc/mediatek/mtk-cmdq.h| 3 ---
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index 69daaadc3a5f..9a6ce9f5a7db 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -21,6 +21,7 @@
#define CMDQ_NUM_CMD(t)(t->cmd_buf_size /
CMDQ_INST_SIZE)
#define CMDQ_CURR_IRQ_STATUS 0x10
+#define CMDQ_SYNC_TOKEN_UPDATE 0x68
#define CMDQ_THR_SLOT_CYCLES 0x30
#define CMDQ_THR_BASE 0x100
#define CMDQ_THR_SIZE 0x80
@@ -104,8 +105,12 @@ static void cmdq_thread_resume(struct cmdq_thread *thread)
static void cmdq_init(struct cmdq *cmdq)
{
+ int i;
+
WARN_ON(clk_enable(cmdq->clock) < 0);
writel(CMDQ_THR_ACTIVE_SLOT_CYCLES, cmdq->base + CMDQ_THR_SLOT_CYCLES);
+ for (i = 0; i <= CMDQ_MAX_EVENT; i++)
+ writel(i, cmdq->base + CMDQ_SYNC_TOKEN_UPDATE);
clk_disable(cmdq->clock);
}
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index ccb73422c2fa..911475da7a53 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -19,6 +19,8 @@
#define CMDQ_WFE_UPDATEBIT(31)
#define CMDQ_WFE_WAIT BIT(15)
#define CMDQ_WFE_WAIT_VALUE0x1
+/** cmdq event maximum */
+#define CMDQ_MAX_EVENT 0x3ff
/*
* CMDQ_CODE_MASK:
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 54ade13a9b15..4e8899972db4 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -13,9 +13,6 @@
#define CMDQ_NO_TIMEOUT0xu
-/** cmdq event maximum */
-#define CMDQ_MAX_EVENT 0x3ff
-
struct cmdq_pkt;
struct cmdq_client {
--
2.18.0
[PATCH v12 12/12] arm64: dts: add gce node for mt8183
add gce device node for mt8183
Signed-off-by: Bibby Hsieh
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 08274bfcebd8..a81c995bbea9 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
/ {
compatible = "mediatek,mt8183";
@@ -212,6 +213,15 @@
clock-names = "spi", "wrap";
};
+ gce: mailbox@10238000 {
+ compatible = "mediatek,mt8183-gce";
+ reg = <0 0x10238000 0 0x4000>;
+ interrupts = ;
+ #mbox-cells = <3>;
+ clocks = < CLK_INFRA_GCE>;
+ clock-names = "gce";
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt8183-uart",
"mediatek,mt6577-uart";
--
2.18.0
[PATCH v12 09/12] soc: mediatek: cmdq: define the instruction struct
Define an instruction structure for gce driver to append command.
This structure can make the client's code more readability.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 105 +++
include/linux/mailbox/mtk-cmdq-mailbox.h | 2 +
2 files changed, 73 insertions(+), 34 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 7aa0517ff2f3..e1e41914ed7a 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -9,12 +9,24 @@
#include
#include
-#define CMDQ_ARG_A_WRITE_MASK 0x
#define CMDQ_WRITE_ENABLE_MASK BIT(0)
#define CMDQ_EOC_IRQ_ENBIT(0)
#define CMDQ_EOC_CMD ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
<< 32 | CMDQ_EOC_IRQ_EN)
+struct cmdq_instruction {
+ union {
+ u32 value;
+ u32 mask;
+ };
+ union {
+ u16 offset;
+ u16 event;
+ };
+ u8 subsys;
+ u8 op;
+};
+
static void cmdq_client_timeout(struct timer_list *t)
{
struct cmdq_client *client = from_timer(client, t, timer);
@@ -110,10 +122,8 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
}
EXPORT_SYMBOL(cmdq_pkt_destroy);
-static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
- u32 arg_a, u32 arg_b)
+static struct cmdq_instruction *cmdq_pkt_append_command(struct cmdq_pkt *pkt)
{
- u64 *cmd_ptr;
if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
/*
@@ -127,81 +137,108 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt,
enum cmdq_code code,
pkt->cmd_buf_size += CMDQ_INST_SIZE;
WARN_ONCE(1, "%s: buffer size %u is too small !\n",
__func__, (u32)pkt->buf_size);
- return -ENOMEM;
+ return NULL;
}
- cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
- (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
+
pkt->cmd_buf_size += CMDQ_INST_SIZE;
- return 0;
+ return pkt->va_base + pkt->cmd_buf_size - CMDQ_INST_SIZE;
}
int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
{
- u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
- (subsys << CMDQ_SUBSYS_SHIFT);
+ struct cmdq_instruction *inst;
+
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_WRITE;
+ inst->value = value;
+ inst->offset = offset;
+ inst->subsys = subsys;
- return cmdq_pkt_append_command(pkt, CMDQ_CODE_WRITE, arg_a, value);
+ return 0;
}
EXPORT_SYMBOL(cmdq_pkt_write);
int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask)
{
- u32 offset_mask = offset;
- int err = 0;
+ struct cmdq_instruction *inst;
+ u16 offset_mask = offset;
if (mask != 0x) {
- err = cmdq_pkt_append_command(pkt, CMDQ_CODE_MASK, 0, ~mask);
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_MASK;
+ inst->mask = ~mask;
offset_mask |= CMDQ_WRITE_ENABLE_MASK;
}
- err |= cmdq_pkt_write(pkt, value, subsys, offset_mask);
- return err;
+ return cmdq_pkt_write(pkt, subsys, offset_mask, value);
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
- u32 arg_b;
+ struct cmdq_instruction *inst;
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
- /*
-* WFE arg_b
-* bit 0-11: wait value
-* bit 15: 1 - wait, 0 - no wait
-* bit 16-27: update value
-* bit 31: 1 - update, 0 - no update
-*/
- arg_b = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_WFE;
+ inst->value = CMDQ_WFE_OPTION;
+ inst->event = event;
- return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event, arg_b);
+ return 0;
}
EXPORT_SYMBOL(cmdq_pkt_wfe);
int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
{
+ struct cmdq_instruction *inst;
+
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
- return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event,
- CMDQ_WFE_UPDATE);
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_WFE;
+ inst->value = CMDQ_WFE_UPDATE;
+ inst->event = event;
+
+ return 0;
[PATCH v12 01/12] dt-binding: gce: remove thread-num property
"thread-num" is an unused property so we remove it from example. Signed-off-by: Bibby Hsieh Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 7d72b21c9e94..cfe40b01d164 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -39,7 +39,6 @@ Example: interrupts = ; clocks = < CLK_INFRA_GCE>; clock-names = "gce"; - thread-num = CMDQ_THR_MAX_COUNT; #mbox-cells = <3>; }; -- 2.18.0
[PATCH v12 00/12] support gce on mt8183 platform
Changes since v11: - correct some data type to avoid type conversion. Changes since v10: - remove subsys-cell from gce device node - use of_parse_phandle_with_fixed_args instead of of_parse_phandle_with_args Changes since v8 and v9: - change the error return code in cmdq_dev_get_client_reg() Changes since v7: - remove the memory allocation out of cmdq_dev_get_client_reg() - rebase onto 5.2-rc1 Changes since v6: - remove cmdq_dev_get_event function and gce event property - separate some changes to indepentent patch - change the binding document related to gce-client-reg property Changes since v5: - fix typo - remove gce-event-name form the dt-binding - add reasons in commit message Changes since v4: - refine the architecture of the packet encoder function - refine the gce enevt property - change the patch's title Changes since v3: - fix a typo in dt-binding and dtsi - cast the return value to right format Changes since v2: - according to CK's review comment, change the property name and refine the parameter - change the patch's title - remove unused property from dt-binding and dts Changes since v1: - add prefix "cmdq" in the commit subject - add dt-binding document for get event and subsys function - add fix up tag in fixup patch - fix up some coding style (alignment) MTK will support gce function on mt8183 platform. dt-binding: gce: add gce header file for mt8183 mailbox: mediatek: cmdq: support mt8183 gce function arm64: dts: add gce node for mt8183 Besides above patches, we refine gce driver on those patches. soc: mediatek: cmdq: reorder the parameter soc: mediatek: cmdq: change the type of input parameter mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data soc: mediatek: cmdq: clear the event in cmdq initial flow In order to enhance the convenience of gce usage, we add new helper functions and refine the method of instruction combining. dt-binding: gce: remove thread-num property dt-binding: gce: add binding for gce client reg property soc: mediatek: cmdq: define the instruction struct soc: mediatek: cmdq: add polling function soc: mediatek: cmdq: add cmdq_dev_get_client_reg function Bibby Hsieh (12): dt-binding: gce: remove thread-num property dt-binding: gce: add gce header file for mt8183 dt-binding: gce: add binding for gce client reg property mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data mailbox: mediatek: cmdq: support mt8183 gce function soc: mediatek: cmdq: clear the event in cmdq initial flow soc: mediatek: cmdq: reorder the parameter soc: mediatek: cmdq: change the type of input parameter soc: mediatek: cmdq: define the instruction struct soc: mediatek: cmdq: add polling function soc: mediatek: cmdq: add cmdq_dev_get_client_reg function arm64: dts: add gce node for mt8183 .../devicetree/bindings/mailbox/mtk-gce.txt | 23 ++- arch/arm64/boot/dts/mediatek/mt8183.dtsi | 10 + drivers/mailbox/mtk-cmdq-mailbox.c| 18 +- drivers/soc/mediatek/mtk-cmdq-helper.c| 172 + include/dt-bindings/gce/mt8183-gce.h | 177 ++ include/linux/mailbox/mtk-cmdq-mailbox.h | 5 + include/linux/soc/mediatek/mtk-cmdq.h | 53 +- 7 files changed, 396 insertions(+), 62 deletions(-) create mode 100644 include/dt-bindings/gce/mt8183-gce.h -- 2.18.0
[PATCH v12 02/12] dt-binding: gce: add gce header file for mt8183
Add documentation for the mt8183 gce. Add gce header file defined the gce hardware event, subsys number and constant for mt8183. Signed-off-by: Bibby Hsieh Reviewed-by: Rob Herring --- .../devicetree/bindings/mailbox/mtk-gce.txt | 6 +- include/dt-bindings/gce/mt8183-gce.h | 177 ++ 2 files changed, 180 insertions(+), 3 deletions(-) create mode 100644 include/dt-bindings/gce/mt8183-gce.h diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index cfe40b01d164..1f7f8f2a3f49 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -9,7 +9,7 @@ CMDQ driver uses mailbox framework for communication. Please refer to mailbox.txt for generic information about mailbox device-tree bindings. Required properties: -- compatible: Must be "mediatek,mt8173-gce" +- compatible: can be "mediatek,mt8173-gce" or "mediatek,mt8183-gce" - reg: Address range of the GCE unit - interrupts: The interrupt signal from the GCE block - clock: Clocks according to the common clock binding @@ -28,8 +28,8 @@ Required properties for a client device: - mediatek,gce-subsys: u32, specify the sub-system id which is corresponding to the register address. -Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h'. Such as -sub-system ids, thread priority, event ids. +Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h' +or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, event ids. Example: diff --git a/include/dt-bindings/gce/mt8183-gce.h b/include/dt-bindings/gce/mt8183-gce.h new file mode 100644 index ..aeb95154fac2 --- /dev/null +++ b/include/dt-bindings/gce/mt8183-gce.h @@ -0,0 +1,177 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (c) 2019 MediaTek Inc. + * Author: Bibby Hsieh + * + */ + +#ifndef _DT_BINDINGS_GCE_MT8183_H +#define _DT_BINDINGS_GCE_MT8183_H + +#define CMDQ_NO_TIMEOUT0x + +#define CMDQ_THR_MAX_COUNT 24 + +/* GCE HW thread priority */ +#define CMDQ_THR_PRIO_LOWEST 0 +#define CMDQ_THR_PRIO_HIGHEST 1 + +/* GCE SUBSYS */ +#define SUBSYS_13000 +#define SUBSYS_14001 +#define SUBSYS_14012 +#define SUBSYS_14023 +#define SUBSYS_15024 +#define SUBSYS_18805 +#define SUBSYS_18816 +#define SUBSYS_18827 +#define SUBSYS_18838 +#define SUBSYS_18849 +#define SUBSYS_100010 +#define SUBSYS_100111 +#define SUBSYS_100212 +#define SUBSYS_100313 +#define SUBSYS_100414 +#define SUBSYS_100515 +#define SUBSYS_102016 +#define SUBSYS_102817 +#define SUBSYS_170018 +#define SUBSYS_170119 +#define SUBSYS_170220 +#define SUBSYS_170321 +#define SUBSYS_180022 +#define SUBSYS_180123 +#define SUBSYS_180224 +#define SUBSYS_180425 +#define SUBSYS_180526 +#define SUBSYS_180827 +#define SUBSYS_180a28 +#define SUBSYS_180b29 + +#define CMDQ_EVENT_DISP_RDMA0_SOF 0 +#define CMDQ_EVENT_DISP_RDMA1_SOF 1 +#define CMDQ_EVENT_MDP_RDMA0_SOF 2 +#define CMDQ_EVENT_MDP_RSZ0_SOF 4 +#define CMDQ_EVENT_MDP_RSZ1_SOF 5 +#define CMDQ_EVENT_MDP_TDSHP_SOF 6 +#define CMDQ_EVENT_MDP_WROT0_SOF 7 +#define CMDQ_EVENT_MDP_WDMA0_SOF 8 +#define CMDQ_EVENT_DISP_OVL0_SOF 9 +#define CMDQ_EVENT_DISP_OVL0_2L_SOF10 +#define CMDQ_EVENT_DISP_OVL1_2L_SOF11 +#define CMDQ_EVENT_DISP_WDMA0_SOF 12 +#define CMDQ_EVENT_DISP_COLOR0_SOF 13 +#define CMDQ_EVENT_DISP_CCORR0_SOF 14 +#define CMDQ_EVENT_DISP_AAL0_SOF 15 +#define CMDQ_EVENT_DISP_GAMMA0_SOF 16 +#define CMDQ_EVENT_DISP_DITHER0_SOF17 +#define CMDQ_EVENT_DISP_PWM0_SOF 18 +#define CMDQ_EVENT_DISP_DSI0_SOF 19 +#define CMDQ_EVENT_DISP_DPI0_SOF
[PATCH v12 10/12] soc: mediatek: cmdq: add polling function
add polling function in cmdq helper functions
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 28
include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
include/linux/soc/mediatek/mtk-cmdq.h| 15 +
3 files changed, 44 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index e1e41914ed7a..340a92a254e5 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -220,6 +220,34 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
}
EXPORT_SYMBOL(cmdq_pkt_clear_event);
+int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value, u32 mask)
+{
+ struct cmdq_instruction *inst;
+
+ if (mask != 0x) {
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_MASK;
+ inst->value = ~mask;
+ offset = offset | 0x1;
+ }
+
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_POLL;
+ inst->value = value;
+ inst->offset = offset;
+ inst->subsys = subsys;
+
+ return 0;
+}
+EXPORT_SYMBOL(cmdq_pkt_poll);
+
static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
struct cmdq_instruction *inst;
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index c8adedefaf42..9e3502945bc1 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -46,6 +46,7 @@
enum cmdq_code {
CMDQ_CODE_MASK = 0x02,
CMDQ_CODE_WRITE = 0x04,
+ CMDQ_CODE_POLL = 0x08,
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 9618debb9ceb..a345870a6d10 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -99,6 +99,21 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
*/
int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
+/**
+ * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
+ * execute an instruction that wait for a specified hardware
+ * register to check for the value. All GCE hardware
+ * threads will be blocked by this instruction.
+ * @pkt: the CMDQ packet
+ * @subsys:the CMDQ sub system code
+ * @offset:register offset from CMDQ sub system
+ * @value: the specified target register value
+ * @mask: the specified target register mask
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value, u32 mask);
/**
* cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
* packet and call back at the end of done packet
--
2.18.0
[PATCH v12 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
GCE cannot know the register base address, this function
can help cmdq client to get the cmdq_client_reg structure.
Signed-off-by: Bibby Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++
include/linux/soc/mediatek/mtk-cmdq.h | 21 +++
2 files changed, 50 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 340a92a254e5..1bed07362b7a 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -27,6 +27,35 @@ struct cmdq_instruction {
u8 op;
};
+int cmdq_dev_get_client_reg(struct device *dev,
+ struct cmdq_client_reg *client_reg, int idx)
+{
+ struct of_phandle_args spec;
+ int err;
+
+ if (!client_reg)
+ return -ENOENT;
+
+ err = of_parse_phandle_with_fixed_args(dev->of_node,
+ "mediatek,gce-client-reg",
+ 3, idx, );
+ if (err < 0) {
+ dev_err(dev,
+ "error %d can't parse gce-client-reg property (%d)",
+ err, idx);
+
+ return err;
+ }
+
+ client_reg->subsys = (u8)spec.args[0];
+ client_reg->offset = (u16)spec.args[1];
+ client_reg->size = (u16)spec.args[2];
+ of_node_put(spec.np);
+
+ return 0;
+}
+EXPORT_SYMBOL(cmdq_dev_get_client_reg);
+
static void cmdq_client_timeout(struct timer_list *t)
{
struct cmdq_client *client = from_timer(client, t, timer);
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index a345870a6d10..6215d4fc4ba3 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -15,6 +15,12 @@
struct cmdq_pkt;
+struct cmdq_client_reg {
+ u8 subsys;
+ u16 offset;
+ u16 size;
+};
+
struct cmdq_client {
spinlock_t lock;
u32 pkt_cnt;
@@ -24,6 +30,21 @@ struct cmdq_client {
u32 timeout_ms; /* in unit of microsecond */
};
+/**
+ * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
+ *node of CMDQ client
+ * @dev: device of CMDQ mailbox clienti
+ * @client_reg: CMDQ client reg pointer
+ * @idx: the index of desired reg
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Help CMDQ client pasing the cmdq client reg
+ * from the device node of CMDQ client.
+ */
+int cmdq_dev_get_client_reg(struct device *dev,
+ struct cmdq_client_reg *client_reg, int idx);
+
/**
* cmdq_mbox_create() - create CMDQ mailbox client and channel
* @dev: device of CMDQ mailbox client
--
2.18.0
[PATCH v12 07/12] soc: mediatek: cmdq: reorder the parameter
The order of gce instructions is [subsys offset value]
so reorder the parameter of cmdq_pkt_write_mask
and cmdq_pkt_write function.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 6 +++---
include/linux/soc/mediatek/mtk-cmdq.h | 10 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index ff9fef5a032b..082b8978651e 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -136,7 +136,7 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt,
enum cmdq_code code,
return 0;
}
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset)
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
{
u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
(subsys << CMDQ_SUBSYS_SHIFT);
@@ -145,8 +145,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32
subsys, u32 offset)
}
EXPORT_SYMBOL(cmdq_pkt_write);
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value,
- u32 subsys, u32 offset, u32 mask)
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
+ u32 offset, u32 value, u32 mask)
{
u32 offset_mask = offset;
int err = 0;
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 4e8899972db4..39d813dde4b4 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -60,26 +60,26 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt);
/**
* cmdq_pkt_write() - append write command to the CMDQ packet
* @pkt: the CMDQ packet
- * @value: the specified target register value
* @subsys:the CMDQ sub system code
* @offset:register offset from CMDQ sub system
+ * @value: the specified target register value
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset);
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
/**
* cmdq_pkt_write_mask() - append write command with mask to the CMDQ packet
* @pkt: the CMDQ packet
- * @value: the specified target register value
* @subsys:the CMDQ sub system code
* @offset:register offset from CMDQ sub system
+ * @value: the specified target register value
* @mask: the specified target register mask
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value,
- u32 subsys, u32 offset, u32 mask);
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
+ u32 offset, u32 value, u32 mask);
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
--
2.18.0
Re: [PATCH v2] kbuild: Require W=1 for -Wimplicit-fallthrough with clang
On Mon, Aug 19, 2019 at 3:43 AM Nathan Chancellor wrote: > > On Mon, Aug 19, 2019 at 01:43:08AM +0900, Masahiro Yamada wrote: > > Hi. > > > > On Fri, Aug 16, 2019 at 7:59 AM Nathan Huckleberry wrote: > > > > > > Clang is updating to support -Wimplicit-fallthrough on C > > > https://reviews.llvm.org/D64838. Since clang does not > > > support the comment version of fallthrough annotations > > > this update causes an additional 50k warnings. Most > > > of these warnings (>49k) are duplicates from header files. > > > > > > This patch is intended to be reverted after the warnings > > > have been cleaned up. > > > > > > Signed-off-by: Nathan Huckleberry > > > Suggested-by: Nathan Chancellor > > > Reviewed-by: Nathan Chancellor > > > --- > > > Changes v1->v2 > > > * Move code to preexisting ifdef > > > scripts/Makefile.extrawarn | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn > > > index a74ce2e3c33e..95973a1ee999 100644 > > > --- a/scripts/Makefile.extrawarn > > > +++ b/scripts/Makefile.extrawarn > > > @@ -70,5 +70,6 @@ KBUILD_CFLAGS += -Wno-initializer-overrides > > > KBUILD_CFLAGS += -Wno-format > > > KBUILD_CFLAGS += -Wno-sign-compare > > > KBUILD_CFLAGS += -Wno-format-zero-length > > > +KBUILD_CFLAGS += $(call cc-option,-Wno-implicit-fallthrough) > > > endif > > > endif > > > -- > > > 2.23.0.rc1.153.gdeed80330f-goog > > > > > > > > > Perhaps, is the following even cleaner? > > > > > > > > diff --git a/Makefile b/Makefile > > index 1b23f95db176..cebc6bf5372e 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -751,6 +751,9 @@ else > > # These warnings generated too much noise in a regular build. > > # Use make W=1 to enable them (see scripts/Makefile.extrawarn) > > KBUILD_CFLAGS += -Wno-unused-but-set-variable > > + > > +# Warn about unmarked fall-throughs in switch statement. > > +KBUILD_CFLAGS += $(call cc-option,-Wimplicit-fallthrough,) > > endif > > > > KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable) > > @@ -845,9 +848,6 @@ NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) > > -print-file-name=include) > > # warn about C99 declaration after statement > > KBUILD_CFLAGS += -Wdeclaration-after-statement > > > > -# Warn about unmarked fall-throughs in switch statement. > > -KBUILD_CFLAGS += $(call cc-option,-Wimplicit-fallthrough,) > > - > > # Variable Length Arrays (VLAs) should not be used anywhere in the kernel > > KBUILD_CFLAGS += -Wvla > > > > > > > > -- > > Best Regards > > Masahiro Yamada > > I like this more than anything suggested so far. I think a comment > should be added regarding why this is only enabled for GCC right now but > that is pretty easy to revert once we have figured out the right course > of action. Agree. This is well-explained in the commit log, but adding a short comment will be nice. BTW, I personally like the traditional comment version of fallthrough annotations. Is there a plan for Clang to support it as well as the attribute? Thanks. -- Best Regards Masahiro Yamada
oops on cdrom eject
I mentioned this on irc and I'll probably dig into a bit further. Fedora 30, 5.1.18 was fine, 5.2.9 oops on CD eject with the below. Dave. [10384.391028] FAT-fs (sdc1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. [10385.221284] ISO 9660 Extensions: Microsoft Joliet Level 3 [10385.351758] ISOFS: changing to secondary root [10408.030879] VFS: busy inodes on changed media or resized disk sr0 [10408.338449] WARNING: CPU: 0 PID: 3026 at fs/block_dev.c:1868 __blkdev_put+0x1c0/0x1e0 [10408.338451] Modules linked in: nls_utf8 vfat fat isofs rfcomm fuse xt_CHECKSUM xt_MASQUERADE tun bridge stp llc nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables bnep sunrpc snd_hda_codec_analog snd_hda_codec_generic arc4 rt2800pci rt2800mmio rt2800lib ledtrig_audio rt2x00pci rt2x00mmio coretemp rt2x00lib mac80211 iTCO_wdt iTCO_vendor_support kvm snd_hda_intel snd_hda_codec uvcvideo snd_hda_core btusb videobuf2_vmalloc irqbypass btrtl videobuf2_memops snd_hwdep videobuf2_v4l2 snd_seq btbcm videobuf2_common btintel cfg80211 snd_seq_device bluetooth videodev snd_pcm ir_rc6_decoder rc_rc6_mce mceusb joydev media snd_timer snd soundcore [10408.338501] eeprom_93cx6 ecdh_generic i2c_i801 rfkill lpc_ich ecc pcc_cpufreq acpi_cpufreq binfmt_misc nouveau mxm_wmi wmi i2c_algo_bit serio_raw firewire_ohci drm_kms_helper firewire_core ata_generic pata_acpi ttm crc_itu_t drm r8169 video uas usb_storage [10408.338519] CPU: 0 PID: 3026 Comm: umount Not tainted 5.2.8-200.fc30.x86_64 #1 [10408.338520] Hardware name: HP-Pavilion FK936AA-ABG IQ518a/EVE, BIOS 5.0607/10/2008 [10408.338523] RIP: 0010:__blkdev_put+0x1c0/0x1e0 [10408.338525] Code: 41 5e 41 5f c3 49 8b 85 d8 03 00 00 48 8b 40 08 48 85 c0 0f 84 49 ff ff ff 8b 74 24 04 4c 89 ef e8 45 5c 8c 00 e9 38 ff ff ff <0f> 0b e9 97 fe ff ff e8 04 79 16 00 eb 9d e8 2d 31 da ff 66 66 2e [10408.338527] RSP: 0018:b547c37cbe40 EFLAGS: 00010202 [10408.338529] RAX: RBX: 8bc06474f0c0 RCX: [10408.338530] RDX: 0002 RSI: 0081 RDI: 8bc06474f0d8 [10408.338531] RBP: 8bc05faf4800 R08: 0001 R09: 8bc06bb294b0 [10408.338533] R10: 045b0f50 R11: R12: 8bc06474f0d8 [10408.338534] R13: 8bc064ef2800 R14: 8bbffe1fa5dc R15: [10408.338536] FS: 7fb3d486a080() GS:8bc06ba0() knlGS: [10408.338537] CS: 0010 DS: ES: CR0: 80050033 [10408.338539] CR2: 55c47e137d00 CR3: be11c000 CR4: 06f0 [10408.338540] Call Trace: [10408.338549] deactivate_locked_super+0x36/0x70 [10408.338552] cleanup_mnt+0x3f/0x70 [10408.338555] task_work_run+0x87/0xa0 [10408.338559] exit_to_usermode_loop+0xc2/0xd0 [10408.338562] do_syscall_64+0x183/0x1a0 [10408.338566] ? page_fault+0x8/0x30 [10408.338568] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [10408.338571] RIP: 0033:0x7fb3d4ab433b [10408.338574] Code: 4b 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 90 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1d 4b 0c 00 f7 d8 64 89 01 48 [10408.338575] RSP: 002b:7ffed4ca5ae8 EFLAGS: 0246 ORIG_RAX: 00a6 [10408.338577] RAX: RBX: 7fb3d4be01c4 RCX: 7fb3d4ab433b [10408.338578] RDX: 00323131315f3832 RSI: RDI: 55ab43d30630 [10408.338580] RBP: 55ab43d30420 R08: R09: 7fb3d4af55a0 [10408.338581] R10: 64656d2f6e75722f R11: 0246 R12: 55ab43d30630 [10408.338582] R13: R14: 55ab43d30518 R15: 55ab43d30e60 [10408.338585] ---[ end trace 0c7c3cb099ae73de ]---
linux-5.3.0-rc5: new build warning
Hi, I've just built 5.3.0-rc5 and a warning that I do not recall having seen before was emitted: ... HOSTCC scripts/extract-cert HOSTCC /mnt/kernel/linux/tools/objtool/fixdep.o HOSTLD arch/x86/tools/relocs HOSTLD /mnt/kernel/linux/tools/objtool/fixdep-in.o LINK /mnt/kernel/linux/tools/objtool/fixdep CC /mnt/kernel/linux/tools/objtool/builtin-check.o CC /mnt/kernel/linux/tools/objtool/builtin-orc.o GEN /mnt/kernel/linux/tools/objtool/arch/x86/lib/inat-tables.c awk: arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape sequence `\:' is not a known regexp operator awk: arch/x86/tools/gen-insn-attr-x86.awk:350: (FILENAME=arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape sequence `\&' is not a known regexp operator CC /mnt/kernel/linux/tools/objtool/exec-cmd.o CC /mnt/kernel/linux/tools/objtool/check.o CC /mnt/kernel/linux/tools/objtool/arch/x86/decode.o CC /mnt/kernel/linux/tools/objtool/orc_gen.o CC /mnt/kernel/linux/tools/objtool/help.o CC /mnt/kernel/linux/tools/objtool/orc_dump.o CC /mnt/kernel/linux/tools/objtool/pager.o ... Happy to test the fix, but please cc me as I'm not subscribed Chris
Re: [PATCH v12 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
Hi, Bibby:
On Mon, 2019-08-19 at 10:53 +0800, Bibby Hsieh wrote:
> GCE cannot know the register base address, this function
> can help cmdq client to get the cmdq_client_reg structure.
Reviewed-by: CK Hu
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++
> include/linux/soc/mediatek/mtk-cmdq.h | 21 +++
> 2 files changed, 50 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 340a92a254e5..1bed07362b7a 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -27,6 +27,35 @@ struct cmdq_instruction {
> u8 op;
> };
>
> +int cmdq_dev_get_client_reg(struct device *dev,
> + struct cmdq_client_reg *client_reg, int idx)
> +{
> + struct of_phandle_args spec;
> + int err;
> +
> + if (!client_reg)
> + return -ENOENT;
> +
> + err = of_parse_phandle_with_fixed_args(dev->of_node,
> +"mediatek,gce-client-reg",
> +3, idx, );
> + if (err < 0) {
> + dev_err(dev,
> + "error %d can't parse gce-client-reg property (%d)",
> + err, idx);
> +
> + return err;
> + }
> +
> + client_reg->subsys = (u8)spec.args[0];
> + client_reg->offset = (u16)spec.args[1];
> + client_reg->size = (u16)spec.args[2];
> + of_node_put(spec.np);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(cmdq_dev_get_client_reg);
> +
> static void cmdq_client_timeout(struct timer_list *t)
> {
> struct cmdq_client *client = from_timer(client, t, timer);
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index a345870a6d10..6215d4fc4ba3 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -15,6 +15,12 @@
>
> struct cmdq_pkt;
>
> +struct cmdq_client_reg {
> + u8 subsys;
> + u16 offset;
> + u16 size;
> +};
> +
> struct cmdq_client {
> spinlock_t lock;
> u32 pkt_cnt;
> @@ -24,6 +30,21 @@ struct cmdq_client {
> u32 timeout_ms; /* in unit of microsecond */
> };
>
> +/**
> + * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
> + * node of CMDQ client
> + * @dev: device of CMDQ mailbox clienti
> + * @client_reg: CMDQ client reg pointer
> + * @idx: the index of desired reg
> + *
> + * Return: 0 for success; else the error code is returned
> + *
> + * Help CMDQ client pasing the cmdq client reg
> + * from the device node of CMDQ client.
> + */
> +int cmdq_dev_get_client_reg(struct device *dev,
> + struct cmdq_client_reg *client_reg, int idx);
> +
> /**
> * cmdq_mbox_create() - create CMDQ mailbox client and channel
> * @dev: device of CMDQ mailbox client
[PATCH net-next] r8152: fix accessing skb after napi_gro_receive
Fix accessing skb after napi_gro_receive which is caused by
commit 47922fcde536 ("r8152: support skb_add_rx_frag").
Fixes: 47922fcde536 ("r8152: support skb_add_rx_frag")
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 40d18e866269..b1db6df6f4ab 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2094,10 +2094,10 @@ static int rx_bottom(struct r8152 *tp, int budget)
skb->protocol = eth_type_trans(skb, netdev);
rtl_rx_vlan_tag(rx_desc, skb);
if (work_done < budget) {
- napi_gro_receive(napi, skb);
work_done++;
stats->rx_packets++;
stats->rx_bytes += skb->len;
+ napi_gro_receive(napi, skb);
} else {
__skb_queue_tail(>rx_queue, skb);
}
--
2.21.0
Re: linux-next: build failure after merge of the security tree
Hi all,
On Mon, 12 Aug 2019 10:34:17 -0700 Kees Cook wrote:
>
> On Mon, Aug 12, 2019 at 02:58:23PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the security tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like below.
> >
> > Caused by commit
> >
> > 45d29f9e9b8b ("security: Support early LSMs")
> >
> > I have added the following fix for today:
> >
> > From: Stephen Rothwell
> > Date: Mon, 12 Aug 2019 14:54:20 +1000
> > Subject: [PATCH] early_security_init() needs a stub got !CONFIG_SECURITY
> >
> > An arm multi_v7_defconfig fails like this:
> >
> > init/main.c: In function 'start_kernel':
> > init/main.c:596:2: error: implicit declaration of function
> > 'early_security_init'; did you mean 'security_init'?
> > [-Werror=implicit-function-declaration]
> > early_security_init();
> > ^~~
> > security_init
> >
> > Fixes: 45d29f9e9b8b ("security: Support early LSMs")
> > Signed-off-by: Stephen Rothwell
>
> Acked-by: Kees Cook
>
> -Kees
>
> > ---
> > include/linux/security.h | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/include/linux/security.h b/include/linux/security.h
> > index 807dc0d24982..23e1c3f17d48 100644
> > --- a/include/linux/security.h
> > +++ b/include/linux/security.h
> > @@ -473,6 +473,11 @@ static inline int security_init(void)
> > return 0;
> > }
> >
> > +static inline int early_security_init(void)
> > +{
> > + return 0;
> > +}
> > +
> > static inline int security_binder_set_context_mgr(struct task_struct *mgr)
> > {
> > return 0;
> > --
> > 2.20.1
I am still applying that patch ...
--
Cheers,
Stephen Rothwell
pgpJFs7gyWMlU.pgp
Description: OpenPGP digital signature
Re: [PATCH v2] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
Tony Chuang 於 2019年8月16日 週五 下午6:44寫道：
>
> > From: Jian-Hong Pan
> >
> > There is a mass of jobs between spin lock and unlock in the hardware
> > IRQ which will occupy much time originally. To make system work more
> > efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
> > reduce the time in hardware IRQ.
> >
> > Signed-off-by: Jian-Hong Pan
> > ---
> > v2:
> > Change the spin_lock_irqsave/unlock_irqrestore to spin_lock/unlock in
> > rtw_pci_interrupt_handler. Because the interrupts are already disabled
> > in the hardware interrupt handler.
> >
> > drivers/net/wireless/realtek/rtw88/pci.c | 33 +++-
> > 1 file changed, 27 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/pci.c
> > b/drivers/net/wireless/realtek/rtw88/pci.c
> > index 00ef229552d5..0740140d7e46 100644
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -866,12 +866,28 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> > void *dev)
> > {
> > struct rtw_dev *rtwdev = dev;
> > struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > - u32 irq_status[4];
> >
> > spin_lock(>irq_lock);
> > if (!rtwpci->irq_enabled)
> > goto out;
> >
> > + /* disable RTW PCI interrupt to avoid more interrupts before the end
> > of
> > + * thread function
> > + */
> > + rtw_pci_disable_interrupt(rtwdev, rtwpci);
>
> So basically it's to prevent back-to-back interrupts.
>
> Nothing wrong about it, I just wondering why we don't like
> back-to-back interrupts. Does it means that those interrupts
> fired between irq_handler and threadfin would increase
> much more time to consume them.
1. It is one of the reasons. Besides, the hardware interrupt has
higher priority than soft IRQ. If next hardware interrupt is coming
faster then the soft IRQ (BH), the software IRQ may always become
pended.
2. Keep the data's state until the interrupt is fully dealt.
3. The process of request_threaded_irq is documented:
https://www.kernel.org/doc/htmldocs/kernel-api/API-request-threaded-irq.html
> > +out:
> > + spin_unlock(>irq_lock);
> > +
> > + return IRQ_WAKE_THREAD;
> > +}
> > +
> > +static irqreturn_t rtw_pci_interrupt_threadfn(int irq, void *dev)
> > +{
> > + struct rtw_dev *rtwdev = dev;
> > + struct rtw_pci *rtwpci = (struct rtw_pci *)rtwdev->priv;
> > + unsigned long flags;
> > + u32 irq_status[4];
> > +
> > rtw_pci_irq_recognized(rtwdev, rtwpci, irq_status);
> >
> > if (irq_status[0] & IMR_MGNTDOK)
> > @@ -891,8 +907,11 @@ static irqreturn_t rtw_pci_interrupt_handler(int irq,
> > void *dev)
> > if (irq_status[0] & IMR_ROK)
> > rtw_pci_rx_isr(rtwdev, rtwpci, RTW_RX_QUEUE_MPDU);
> >
> > -out:
> > - spin_unlock(>irq_lock);
> > + /* all of the jobs for this interrupt have been done */
> > + spin_lock_irqsave(>irq_lock, flags);
>
> I suggest to protect the ISRs. Because next patches will require
> to check if the TX DMA path is empty. This means I will also add
> this rtwpci->irq_lock to the TX path, and check if the skb_queue
> does not have any pending SKBs not DMAed successfully.
Ah ... Okay for the TX path
> > + if (rtw_flag_check(rtwdev, RTW_FLAG_RUNNING))
>
> Why check the flag here? Is there any racing or something?
> Otherwise it looks to break the symmetry.
According to backtrace, I notice rtw_pci_stop will be invoked in
rtw_power_off, rtw_core_stop which clears the running state.
rtw_core_stop is invoked by rtw_enter_ips due to IEEE80211_CONF_IDLE.
If the stop command comes between the hardware interrupt and soft IRQ
(BH) and there is no start command again, I think user wants the WiFi
stop instead of becoming start again.
Jian-Hong Pan
Re: [PATCH 1/1] dt-bindings: power/supply/sbs_sbs-battery: Addition of force_load binding Add device tree binding documentation for addition of force_load boolean value to allow loading a battery duri
There is a force load option when loading the driver as a module. This adds the equivalent methodology for the binding path. Though I suppose you could in fact just force load if the gpio detect isn't present. Thats a good idea, just wasn't the existing driver flow. I can't think of any reason why we couldn't do that though. I'll update the patch and resubmit V3 Will add a note about it in the docs Please note I'd submitted this incorrectly when using our patch script last time, it's now correctly part of the combined patch Regards Richard Tresidder Richard Tresidder ** On 17/08/2019 5:14 am, Rob Herring wrote: On Thu, Jul 25, 2019 at 02:50:45PM +0800, Richard Tresidder wrote: Signed-off-by: Richard Tresidder --- Notes: Add device tree binding documentation for addition of force_load boolean value to allow loading a battery during boot even if not present at that time. Accompanying patch to drivers/power/supply/sbs-battery.c submitted to linux...@vger.kernel.org Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt index 4e78e51..187d7bb 100644 --- a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt +++ b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt @@ -15,7 +15,8 @@ Optional properties : after an external change notification. - sbs,battery-detect-gpios : The gpio which signals battery detection and a flag specifying its polarity. - + - sbs,force-load : Allow loading of a hot-pluggable battery when there is no + GPIO detect available and the module is statically built. What's a module? That's Linux specific and nothing to do with the binding. Can't you just force load if sbs,battery-detect-gpios is not present? Rob
[PATCH v2 linux-next] qcom: qcs404: move COMPILE_TEST to INTERCONNECT_QCOM
There is one compilation error when CONFIG_INTERCONNECT_QCOM_QCS404=y and
CONFIG_INTERCONNECT_QCOM_SMD_RPM=y, as well as CONFIG_COMPILE_TEST=y,
but CONFIG_QCOM_SMD_RPM is not set, logs as below:
drivers/interconnect/qcom/smd-rpm.o: In function `qcom_icc_rpm_smd_send':
smd-rpm.c:(.text+0xe4): undefined reference to `qcom_rpm_smd_write'
Makefile:1071: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
This is because
INTERCONNECT_QCOM_QCS404 depends on QCOM_SMD_RPM || COMPILE_TEST.
Here CONFIG_COMPILE_TEST=y, so CONFIG_INTERCONNECT_QCOM_SMD_RPM
is selected. If CONFIG_QCOM_SMD_RPM is not set, then
qcom_rpm_smd_write() is not defined, and compilation error happen.
Fix this by moving COMPILE_TEST from CONFIG_INTERCONNECT_QCOM_QCS404 to
CONFIG_INTERCONNECT_QCOM, qcom's interconnect drivers can be compiled on
different platform.
Fixes: 5e4e6c4d3ae0 ("interconnect: qcom: Add QCS404 interconnect provider
driver")
Signed-off-by: Mao Wenan
---
v2: change subject of patch, and move COMPILE_TEST to INTERCONNECT_QCOM.
drivers/interconnect/qcom/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/interconnect/qcom/Kconfig
b/drivers/interconnect/qcom/Kconfig
index 339e8f1..7207248 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -1,14 +1,14 @@
# SPDX-License-Identifier: GPL-2.0-only
config INTERCONNECT_QCOM
bool "Qualcomm Network-on-Chip interconnect drivers"
- depends on ARCH_QCOM
+ depends on ARCH_QCOM || COMPILE_TEST
help
Support for Qualcomm's Network-on-Chip interconnect hardware.
config INTERCONNECT_QCOM_QCS404
tristate "Qualcomm QCS404 interconnect driver"
depends on INTERCONNECT_QCOM
- depends on QCOM_SMD_RPM || COMPILE_TEST
+ depends on QCOM_SMD_RPM
select INTERCONNECT_QCOM_SMD_RPM
help
This is a driver for the Qualcomm Network-on-Chip on qcs404-based
--
2.7.4
Re: linux-next: build failure after merge of the security tree
Hi James,
On Mon, 19 Aug 2019 13:21:19 +1000 Stephen Rothwell
wrote:
>
> On Mon, 12 Aug 2019 10:34:17 -0700 Kees Cook wrote:
> >
> > On Mon, Aug 12, 2019 at 02:58:23PM +1000, Stephen Rothwell wrote:
> > >
> > > After merging the security tree, today's linux-next build (arm
> > > multi_v7_defconfig) failed like below.
> > >
> > > Caused by commit
> > >
> > > 45d29f9e9b8b ("security: Support early LSMs")
> > >
> > > I have added the following fix for today:
> > >
> > > From: Stephen Rothwell
> > > Date: Mon, 12 Aug 2019 14:54:20 +1000
> > > Subject: [PATCH] early_security_init() needs a stub got !CONFIG_SECURITY
^^^
for
If you do decide to apply this patch, please fix the subject typo, thanks :-)
--
Cheers,
Stephen Rothwell
pgpHsIAp02F6u.pgp
Description: OpenPGP digital signature
Re: [PATCH v7 1/7] driver core: Add support for linking devices during device addition
On 8/15/19 6:50 PM, Saravana Kannan wrote:
> On Wed, Aug 7, 2019 at 7:04 PM Frank Rowand wrote:
>>
>>> Date: Tue, 23 Jul 2019 17:10:54 -0700
>>> Subject: [PATCH v7 1/7] driver core: Add support for linking devices during
>>> device addition
>>> From: Saravana Kannan
>>>
>>> When devices are added, the bus might want to create device links to track
>>> functional dependencies between supplier and consumer devices. This
>>> tracking of supplier-consumer relationship allows optimizing device probe
>>> order and tracking whether all consumers of a supplier are active. The
>>> add_links bus callback is added to support this.
>>
>> Change above to:
>>
>> When devices are added, the bus may create device links to track which
>> suppliers a consumer device depends upon. This
>> tracking of supplier-consumer relationship may be used to defer probing
>> the driver of a consumer device before the driver(s) for its supplier
>> device(s)
>> are probed. It may also be used by a supplier driver to determine if
>> all of its consumers have been successfully probed.
>> The add_links bus callback is added to create the supplier device links
>>
>>>
>>> However, when consumer devices are added, they might not have a supplier
>>> device to link to despite needing mandatory resources/functionality from
>>> one or more suppliers. A waiting_for_suppliers list is created to track
>>> such consumers and retry linking them when new devices get added.
>>
>> Change above to:
>>
>> If a supplier device has not yet been created when the consumer device
>> attempts
>> to link it, the consumer device is added to the wait_for_suppliers list.
>> When supplier devices are created, the supplier device link will be added to
>> the relevant consumer devices on the wait_for_suppliers list.
>>
>
> I'll take these commit text suggestions if we decide to revert the
> entire series at the end of this review.
>
>>>
>>> Signed-off-by: Saravana Kannan
>>> ---
>>> drivers/base/core.c| 83 ++
>>> include/linux/device.h | 14 +++
>>> 2 files changed, 97 insertions(+)
>>>
>>> diff --git a/drivers/base/core.c b/drivers/base/core.c
>>> index da84a73f2ba6..1b4eb221968f 100644
>>> --- a/drivers/base/core.c
>>> +++ b/drivers/base/core.c
>>> @@ -44,6 +44,8 @@ early_param("sysfs.deprecated", sysfs_deprecated_setup);
>>> #endif
>>>
>>> /* Device links support. */
>>> +static LIST_HEAD(wait_for_suppliers);
>>> +static DEFINE_MUTEX(wfs_lock);
>>>
>>> #ifdef CONFIG_SRCU
>>> static DEFINE_MUTEX(device_links_lock);
>>> @@ -401,6 +403,51 @@ struct device_link *device_link_add(struct device
>>> *consumer,
>>> }
>>> EXPORT_SYMBOL_GPL(device_link_add);
>>>
>>> +/**
>>
>>> + * device_link_wait_for_supplier - Mark device as waiting for supplier
>>
>> * device_link_wait_for_supplier - Add device to wait_for_suppliers list
>
As a meta-comment, I found this series very hard to understand in the context
of reading the new code for the first time. When I read the code again in
six months or a year or two years it will not be in near term memory and it
will be as if I am reading it for the first time. A lot of my suggestions
for changes of names are in that context -- the current names may be fine
when one has recently read the code, but not so much when trying to read
the whole thing again with a blank mind.
The code also inherits a good deal of complexity because it does not stand
alone in a nice discrete chunk, but instead delicately weaves into a more
complex body of code.
When I was trying to understand the code, I wrote a lot of additional
comments within my reply email to provide myself context, information
about various things, and questions that I needed to answer (or if I
could not answer to then ask you). Then I ended up being able to remove
many of those notes before sending the reply.
> I intentionally chose "Mark device..." because that's a better
> description of the semantics of the function instead of trying to
> describe the implementation. Whether I'm using a linked list or some
> other data structure should not be the one line documentation of a
> function. Unless the function is explicitly about operating on that
> specific data structure.
I agree with the intent of trying to describe the semantics of a function,
especially at the API level where other systems (or drivers) would be using
the function. But for this case the function is at the implementation level
and describing explicitly what it is doing makes this much more readable for
me.
I also find "Mark device" to be vague and not descriptive of what the
intent is.
>
>>
>>
>>> + * @consumer: Consumer device
>>> + *
>>> + * Marks the consumer device as waiting for suppliers to become available.
>>> The
>>> + * consumer device will never be probed until it's unmarked as waiting for
>>> + * suppliers. The caller is responsible for adding the link to the supplier
>>> + * once the supplier device is present.
>>> + *
>>> + *
[PATCH v1 1/2] dt-bindings: phy: intel-emmc-phy: Add new compatible for LGM eMMC PHY
From: Ramuthevar Vadivel Murugan
Add a new compatible to use the host controller driver with the
eMMC PHY on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../bindings/phy/intel-lgm-emmc-phy.yaml | 70 ++
1 file changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/intel-lgm-emmc-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/intel-lgm-emmc-phy.yaml
b/Documentation/devicetree/bindings/phy/intel-lgm-emmc-phy.yaml
new file mode 100644
index ..52156ff091ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel-lgm-emmc-phy.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel-lgm-emmc-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM e-MMC PHY Device Tree Bindings
+
+maintainers:
+ - Rob Herring
+ - Mark Rutland
+
+intel,syscon:
+ $ref: /schemas/types.yaml#definitions/phandle
+ description:
+- |
+ e-MMC phy module connected through chiptop. Phandle to a node that can
+ contain the following properties
+* reg, Access the e-MMC, get the base address from syscon.
+* reset, reset the e-MMC module.
+
+properties:
+ "#phy-cells":
+const: 0
+
+ compatible:
+const: intel,lgm-emmc-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: e-MMC phy module clock
+
+ clock-names:
+items:
+ - const: emmcclk
+
+ resets:
+maxItems: 1
+
+required:
+ - "#phy-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+sysconf: chiptop@e002 {
+compatible = "intel,chiptop-lgm", "syscon";
+reg = <0xe002 0x100>;
+#reset-cells = <1>;
+ };
+
+ - |
+emmc_phy: emmc_phy {
+compatible = "intel,lgm-emmc-phy";
+intel,syscon = <>;
+clocks = <>;
+clock-names = "emmcclk";
+#phy-cells = <0>;
+};
+
+...
--
2.11.0
[PATCH v1 2/2] phy: intel-lgm-emmc: Add support for eMMC PHY
From: Ramuthevar Vadivel Murugan
Adds support for eMMC PHY on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/phy/Kconfig| 1 +
drivers/phy/Makefile | 1 +
drivers/phy/intel/Kconfig | 8 ++
drivers/phy/intel/Makefile | 2 +
drivers/phy/intel/phy-intel-emmc.c | 276 +
5 files changed, 288 insertions(+)
create mode 100644 drivers/phy/intel/Kconfig
create mode 100644 drivers/phy/intel/Makefile
create mode 100644 drivers/phy/intel/phy-intel-emmc.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 0263db2ac874..b3ed94b98d9b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -69,5 +69,6 @@ source "drivers/phy/socionext/Kconfig"
source "drivers/phy/st/Kconfig"
source "drivers/phy/tegra/Kconfig"
source "drivers/phy/ti/Kconfig"
+source "drivers/phy/intel/Kconfig"
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 0d9fddc498a6..3f1fc9efbbed 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -19,6 +19,7 @@ obj-y += broadcom/\
cadence/ \
freescale/ \
hisilicon/ \
+ intel/ \
marvell/ \
motorola/\
mscc/\
diff --git a/drivers/phy/intel/Kconfig b/drivers/phy/intel/Kconfig
new file mode 100644
index ..aa34e0fa9824
--- /dev/null
+++ b/drivers/phy/intel/Kconfig
@@ -0,0 +1,8 @@
+#
+# Phy drivers for Intel X86 LGM platform
+#
+config PHY_INTEL_EMMC
+ tristate "Intel EMMC PHY driver"
+ select GENERIC_PHY
+ help
+ Enable this to support the Intel EMMC PHY
diff --git a/drivers/phy/intel/Makefile b/drivers/phy/intel/Makefile
new file mode 100644
index ..6b876a75599d
--- /dev/null
+++ b/drivers/phy/intel/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PHY_INTEL_EMMC)+= phy-intel-emmc.o
diff --git a/drivers/phy/intel/phy-intel-emmc.c
b/drivers/phy/intel/phy-intel-emmc.c
new file mode 100644
index ..2fd4e42f18f8
--- /dev/null
+++ b/drivers/phy/intel/phy-intel-emmc.c
@@ -0,0 +1,276 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel eMMC PHY driver
+ * Copyright (C) 2019 Intel, Corp.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* eMMC phy register definitions */
+#define EMMC_PHYCTRL0_REG 0xa8
+#define DR_TY_MASK GENMASK(30, 28)
+#define DR_TY_50OHM(x) ((~(x) << 28) & DR_TY_MASK)
+#define OTAPDLYENA BIT(14)
+#define OTAPDLYSEL_MASKGENMASK(13, 10)
+#define OTAPDLYSEL_SHIFT(x)(((x) << 10) & OTAPDLYSEL_MASK)
+
+#define EMMC_PHYCTRL1_REG 0xac
+#define PDB_MASK 1
+#define ENDLL_MASK BIT(7)
+#define ENDLL_VAL BIT(7)
+
+#define EMMC_PHYCTRL2_REG 0xb0
+#define FRQSEL_25M 0
+#define FRQSEL_150M3
+#define FRQSEL_MASKGENMASK(24, 22)
+#define FRQSEL_SHIFT(x)((x) << 22)
+
+#define EMMC_PHYSTAT_REG 0xbc
+#define CALDONE_MASK 1
+#define DLLRDY_MASK1
+#define IS_CALDONE(x) x) >> 9) & CALDONE_MASK) == 1)
+#define IS_DLLRDY(x) x) >> 8) & DLLRDY_MASK) == 1)
+
+struct intel_emmc_phy {
+ struct regmap *syscfg;
+ struct clk *emmcclk;
+};
+
+static int intel_emmc_phy_power(struct phy *phy, bool on_off)
+{
+ struct intel_emmc_phy *priv = phy_get_drvdata(phy);
+ unsigned int caldone;
+ unsigned int dllrdy;
+ unsigned int freqsel = 0;
+ unsigned long rate;
+ int ret, quot;
+
+ /*
+* Keep phyctrl_pdb and phyctrl_endll low to allow
+* initialization of CALIO state M/C DFFs
+*/
+ ret = regmap_update_bits(priv->syscfg, EMMC_PHYCTRL1_REG,
+PDB_MASK | ENDLL_MASK, 0);
+ if (ret) {
+ dev_err(>dev, "CALIO power down bar failed: %d\n", ret);
+ return ret;
+ }
+
+ /* Already finish power_off above */
+ if (!on_off)
+ return 0;
+
+ rate = clk_get_rate(priv->emmcclk);
+ quot = DIV_ROUND_CLOSEST(rate, 5000);
+ if (quot > FRQSEL_150M)
+ dev_warn(>dev, "Unsupported rate: %lu\n", rate);
+ freqsel = clamp_t(int, quot, FRQSEL_25M, FRQSEL_150M);
+
+ /*
+* According to the user manual, calpad calibration
+* cycle takes more than 2us without the minimal recommended
+* value, so we may need a little margin here
+*/
+ usleep_range(3, 6);
+ regmap_update_bits(priv->syscfg, EMMC_PHYCTRL1_REG,
Re: [PATCH v4 06/10] modpost: Add modinfo flag to livepatch modules
On Fri, Aug 16, 2019 at 9:43 PM Joe Lawrence wrote: > > On 8/16/19 4:19 AM, Miroslav Benes wrote: > > Hi, > > > >> I cleaned up the build system, and pushed it based on my > >> kbuild tree. > >> > >> Please see: > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git > >> klp-cleanup > > > > This indeed looks much simpler and cleaner (as far as I can judge with my > > limited kbuild knowledge). We just need to remove MODULE_INFO(livepatch, > > "Y") from lib/livepatch/test_klp_convert_mod_a.c to make it compile and > > work (test_klp_convert_mod_a is not a livepatch module, it is just a dummy > > module which is then livepatched by lib/livepatch/test_klp_convert1.c). > > > > Yeah, Masahiro this is great, thanks for reworking this! > > I did tweak one module like Miroslav mentioned and I think a few of the > newly generated files need to be cleaned up as part of "make clean", but > all said, this is a nice improvement. > > Are you targeting the next merge window for your kbuild branch? (This > appears to be what the klp-cleanup branch was based on.) I can review this series from the build system point of view, but I am not familiar enough with live-patching itself. Some possibilities: [1] Merge this series thru the live-patch tree after the kbuild base patches land. This requires one extra development cycle (targeting for 5.5-rc1) but I think this is the official way if you do not rush into it. [2] Create an immutable branch in kbuild tree, and the live-patch tree will use it as the basis for queuing this series. We will have to coordinate the pull request order, but we can merge this feature for 5.4-rc1 [3] Apply this series to my kbuild tree, with proper Acked-by from the livepatch maintainers. I am a little bit uncomfortable with applying patches I do not understand, though... -- Best Regards Masahiro Yamada
Re: [PATCH v4 06/10] modpost: Add modinfo flag to livepatch modules
Hi Joe, On Sat, Aug 17, 2019 at 4:01 AM Joe Lawrence wrote: > > On 8/16/19 8:43 AM, Joe Lawrence wrote: > > On 8/16/19 4:19 AM, Miroslav Benes wrote: > >> Hi, > >> > >>> I cleaned up the build system, and pushed it based on my > >>> kbuild tree. > >>> > >>> Please see: > >>> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git > >>> klp-cleanup > >> > >> This indeed looks much simpler and cleaner (as far as I can judge with my > >> limited kbuild knowledge). We just need to remove MODULE_INFO(livepatch, > >> "Y") from lib/livepatch/test_klp_convert_mod_a.c to make it compile and > >> work (test_klp_convert_mod_a is not a livepatch module, it is just a dummy > >> module which is then livepatched by lib/livepatch/test_klp_convert1.c). > >> > > > > Yeah, Masahiro this is great, thanks for reworking this! > > > > I did tweak one module like Miroslav mentioned and I think a few of the > > newly generated files need to be cleaned up as part of "make clean", but > > all said, this is a nice improvement. > > > > Well actually, now I see this comment in the top-level Makefile: > > # Cleaning is done on three levels. > > # make clean Delete most generated files > > #Leave enough to build external modules > > # make mrproper Delete the current configuration, and all generated > files > # make distclean Remove editor backup files, patch leftover files and > the like > > I didn't realize that we're supposed to be able to still build external > modules after "make clean". If that's the case, then one might want to > build an external klp-module after doing that. Yes. 'make clean' must keep all the build artifacts needed for building external modules. > With that in mind, shouldn't Symbols.list to persist until mrproper? > And I think modules-livepatch could go away during clean, what do you think? > > -- Joe Symbols.list should be kept by the time mrproper is run. So, please add it to MRROPER_FILES instead of CLEAN_FILES. modules.livepatch is a temporary file, so you can add it to CLEAN_FILES. How is this feature supposed to work for external modules? klp-convert receives: "symbols from vmlinux" + "symbols from no-klp in-tree modules" + "symbols from no-klp external modules" ?? BTW, 'Symbols.list' sounds like a file to list out symbols for generic purposes, but in fact, the file format is very specific for the klp-convert tool. Perhaps, is it better to rename it so it infers this is for livepatching? What do you think? -- Best Regards Masahiro Yamada
Re: [PATCH v4 1/3] kasan: support backing vmalloc space with real shadow memory
>> > Instead, share backing space across multiple mappings. Allocate
>> > a backing page the first time a mapping in vmalloc space uses a
>> > particular page of the shadow region. Keep this page around
>> > regardless of whether the mapping is later freed - in the mean time
>> > the page could have become shared by another vmalloc mapping.
>> >
>> > This can in theory lead to unbounded memory growth, but the vmalloc
>> > allocator is pretty good at reusing addresses, so the practical memory
>> > usage grows at first but then stays fairly stable.
>>
>> I guess people having gigabytes of memory don't mind, but I'm concerned
>> about tiny targets with very little amount of memory. I have boards with as
>> little as 32Mbytes of RAM. The shadow region for the linear space already
>> takes one eighth of the RAM. I'd rather avoid keeping unused shadow pages
>> busy.
>
> I think this depends on how much shadow would be in constant use vs what
> would get left unused. If the amount in constant use is sufficiently
> large (or the residue is sufficiently small), then it may not be
> worthwhile to support KASAN_VMALLOC on such small systems.
I'm not unsympathetic to the cause of small-memory systems, but this is
useful as-is for x86, especially for VMAP_STACK. arm64 and s390 have
already been able to make use of it as well. So unless the design is
going to make it difficult to extend to small-memory systems - if it
bakes in concepts or APIs that are going to make things harder - I think
it might be worth merging as is. (pending the fixes for documentation
nits etc that you point out.)
>> Each page of shadow memory represent 8 pages of real memory. Could we use
>> page_ref to count how many pieces of a shadow page are used so that we can
>> free it when the ref count decreases to 0.
I'm not sure how much of a difference it will make, but I'll have a look.
>> > This requires architecture support to actually use: arches must stop
>> > mapping the read-only zero page over portion of the shadow region that
>> > covers the vmalloc space and instead leave it unmapped.
>>
>> Why 'must' ? Couldn't we switch back and forth from the zero page to real
>> page on demand ?
This code as currently written will not work if the architecture maps
the zero page over the portion of the shadow region that covers the
vmalloc space. So it's an implementation 'must' rather than a laws of
the universe 'must'.
We could perhaps map the zero page, but:
- you have to be really careful to get it right. If you accidentally
map the zero page onto memory where you shouldn't, you may permit
memory accesses that you should catch.
We could ameliorate this by taking Mark's suggestion and mapping a
poision page over the vmalloc space instead.
- I'm not sure what benefit is provided by having something mapped vs
leaving a hole, other than making the fault addresses more obvious.
- This gets complex, especially to do swapping correctly with respect
to various architectures' quirks (see e.g. 56eecdb912b5 "mm: Use
ptep/pmdp_set_numa() for updating _PAGE_NUMA bit" - ppc64 at least
requires that set_pte_at is never called on a valid PTE).
>> If the zero page is not mapped for unused vmalloc space, bad memory accesses
>> will Oops on the shadow memory access instead of Oopsing on the real bad
>> access, making it more difficult to locate and identify the issue.
I suppose. It's pretty easy on at least x86 and my draft ppc64
implementation to identify when an access falls into the shadow region
and then to reverse engineer the memory access that was being checked
based on the offset. As Andy points out, the fault handler could do this
automatically.
> I agree this isn't nice, though FWIW this can already happen today for
> bad addresses that fall outside of the usual kernel address space. We
> could make the !KASAN_INLINE checks resilient to this by using
> probe_kernel_read() to check the shadow, and treating unmapped shadow as
> poison.
>
> It's also worth noting that flipping back and forth isn't generally safe
> unless going via an invalid table entry, so there'd still be windows
> where a bad access might not have shadow mapped.
>
> We'd need to reuse the common p4d/pud/pmd/pte tables for unallocated
> regions, or the tables alone would consume significant amounts of memory
> (e..g ~32GiB for arm64 defconfig), and thus we'd need to be able to
> switch all levels between pgd and pte, which is much more complicated.
>
> I strongly suspect that the additional complexity will outweigh the
> benefit.
>
I'm not opposed to this in principle but I am also concerned about the
complexity involved.
Regards,
Daniel
> [...]
>
>> > +#ifdef CONFIG_KASAN_VMALLOC
>> > +static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
>> > +void *unused)
>> > +{
>> > + unsigned long page;
>> > + pte_t pte;
>> > +
>> > + if (likely(!pte_none(*ptep)))
>> > + return 0;
>>
>> Prior
Re: [RFC PATCH 04/15] drivers/acrn: add the basic framework of acrn char device driver
On 2019年08月16日 15:05, Greg KH wrote: On Fri, Aug 16, 2019 at 10:25:45AM +0800, Zhao Yakui wrote: ACRN hypervisor service module is the important middle layer that allows the Linux kernel to communicate with the ACRN hypervisor. It includes the management of virtualized CPU/memory/device/interrupt for other ACRN guest. The user-space applications can use the provided ACRN ioctls to interact with ACRN hypervisor through different hypercalls. Add one basic framework firstly and the following patches will add the corresponding implementations, which includes the management of virtualized CPU/memory/interrupt and the emulation of MMIO/IO/PCI access. The device file of /dev/acrn_hsm can be accessed in user-space to communicate with ACRN module. Co-developed-by: Jason Chen CJ Signed-off-by: Jason Chen CJ Co-developed-by: Jack Ren Signed-off-by: Jack Ren Co-developed-by: Mingqiang Chi Signed-off-by: Mingqiang Chi Co-developed-by: Liu Shuo Signed-off-by: Liu Shuo Signed-off-by: Zhao Yakui --- drivers/staging/Kconfig | 2 + Also, your subject line for all of these patches are wrong, it is not drivers/acrn :( Thanks for the pointing out it. It will be fixed. And you forgot to cc: the staging maintainer :( Do you mean that the maintainer of staging subsystem is also added in the patch commit log? As I have said with NUMEROUS Intel patches in the past, I now refuse to take patches from you all WITHOUT having it signed-off-by someone from the Intel "OTC" group (or whatever the Intel Linux group is called these days). They are a resource you can not ignore, and if you do, you just end up making the rest of the kernel community grumpy by having us do their work for them :( Please work with them. OK. I will work with some peoples in OTC group to prepare the better ACRN driver. greg k-h
Re: [PATCH v2] jffs2: remove C++ style comments from uapi header
On Sun, Jul 14, 2019 at 5:08 PM Richard Weinberger wrote: > > - Ursprüngliche Mail - > > Looks like this trivial patch missed the pull request. > > > > > > My motivation is to make sure UAPI headers > > are really compilable in user-space, > > and now checked by the following commit: > > > > commit d6fc9fcbaa655cff2d2be05e16867d1918f78b85 > > Author: Masahiro Yamada > > Date: Mon Jul 1 09:58:40 2019 +0900 > > > >kbuild: compile-test exported headers to ensure they are self-contained > > > > > > > > Is there a chance for it being merged, > > Sure. I think it is okay to send it for -rc2. > > Thanks, > //richard This patch missed the fixes pull requests. Which version is this targeting for? v5.4-rc1 ? -- Best Regards Masahiro Yamada
Re: [PATCH v2] jffs2: remove C++ style comments from uapi header
On Mon, Jul 29, 2019 at 4:14 PM Richard Weinberger wrote: > > On Sun, Jul 14, 2019 at 10:08 AM Richard Weinberger wrote: > > > > - Ursprüngliche Mail - > > > Looks like this trivial patch missed the pull request. > > > > > > > > > My motivation is to make sure UAPI headers > > > are really compilable in user-space, > > > and now checked by the following commit: > > > > > > commit d6fc9fcbaa655cff2d2be05e16867d1918f78b85 > > > Author: Masahiro Yamada > > > Date: Mon Jul 1 09:58:40 2019 +0900 > > > > > >kbuild: compile-test exported headers to ensure they are self-contained > > > > > > > > > > > > Is there a chance for it being merged, > > Appled. > > -- > Thanks, > //richard I checked next-20190819, but I still do not see this patch. Where has this patch gone? -- Best Regards Masahiro Yamada
Re: [PATCH] staging: media: hantro: Remove call to memset after dma_alloc_coherent
Hi Hans, On Thu, Jul 25, 2019 at 8:50 PM Boris Brezillon wrote: > > On Thu, 25 Jul 2019 08:36:02 +0530 > Hariprasad Kelam wrote: > > > fix below issue reported by coccicheck > > /drivers/staging/media/hantro/hantro_vp8.c:149:16-34: WARNING: > > dma_alloc_coherent use in aux_buf -> cpu already zeroes out memory, so > > memset is not needed > > > > Signed-off-by: Hariprasad Kelam > > Reviewed-by: Boris Brezillon > > > --- > > drivers/staging/media/hantro/hantro_vp8.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/drivers/staging/media/hantro/hantro_vp8.c > > b/drivers/staging/media/hantro/hantro_vp8.c > > index 66c4533..363ddda 100644 > > --- a/drivers/staging/media/hantro/hantro_vp8.c > > +++ b/drivers/staging/media/hantro/hantro_vp8.c > > @@ -151,8 +151,6 @@ int hantro_vp8_dec_init(struct hantro_ctx *ctx) > > if (!aux_buf->cpu) > > return -ENOMEM; > > > > - memset(aux_buf->cpu, 0, aux_buf->size); > > - > > /* > >* Allocate probability table buffer, > >* total 1208 bytes, 4K page is far enough. > Is this something you will pick to your tree? Best regards, Tomasz
[PATCH] .gitignore: ignore modules.order explicitly
The pattern '*.order' was added by commit c6025f4c8bbe ("kbuild: ignore
*.order files") to ignore modules.order files.
I do not see any other user of the '.order' extension.
Ignore 'modules.order' explicitly instead of '*.order'.
Signed-off-by: Masahiro Yamada
---
.gitignore | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gitignore b/.gitignore
index 2030c7a4d2f8..ce2c6348d372 100644
--- a/.gitignore
+++ b/.gitignore
@@ -34,7 +34,6 @@
*.mod.c
*.o
*.o.*
-*.order
*.patch
*.s
*.so
@@ -46,6 +45,7 @@
*.xz
Module.symvers
modules.builtin
+modules.order
#
# Top-level generic files
--
2.17.1
Re: [PATCH] staging: media: hantro: Remove call to memset after dma_alloc_coherent
On Mon, Aug 19, 2019 at 1:17 PM Tomasz Figa wrote: > > Hi Hans, > > On Thu, Jul 25, 2019 at 8:50 PM Boris Brezillon > wrote: > > > > On Thu, 25 Jul 2019 08:36:02 +0530 > > Hariprasad Kelam wrote: > > > > > fix below issue reported by coccicheck > > > /drivers/staging/media/hantro/hantro_vp8.c:149:16-34: WARNING: > > > dma_alloc_coherent use in aux_buf -> cpu already zeroes out memory, so > > > memset is not needed > > > > > > Signed-off-by: Hariprasad Kelam > > > > Reviewed-by: Boris Brezillon > > > > > --- > > > drivers/staging/media/hantro/hantro_vp8.c | 2 -- > > > 1 file changed, 2 deletions(-) > > > > > > diff --git a/drivers/staging/media/hantro/hantro_vp8.c > > > b/drivers/staging/media/hantro/hantro_vp8.c > > > index 66c4533..363ddda 100644 > > > --- a/drivers/staging/media/hantro/hantro_vp8.c > > > +++ b/drivers/staging/media/hantro/hantro_vp8.c > > > @@ -151,8 +151,6 @@ int hantro_vp8_dec_init(struct hantro_ctx *ctx) > > > if (!aux_buf->cpu) > > > return -ENOMEM; > > > > > > - memset(aux_buf->cpu, 0, aux_buf->size); > > > - > > > /* > > >* Allocate probability table buffer, > > >* total 1208 bytes, 4K page is far enough. > > > > Is this something you will pick to your tree? Ah, sorry, this is already applied. Not sure why searching for it the first time didn't show anything. I guess I need to start repeating my searches by default. Sorry for the noise. Best regards, Tomasz
Suspend/Resume Broken on AM43/AM33 Platforms
Hi Stephen, commit 03a3bb7ae63150230c5de645dc95e673ebf17e1a Author: Stephen Boyd Date: Mon Aug 5 16:32:41 2019 -0700 hwrng: core - Freeze khwrng thread during suspend Commit seems to be breaking suspend/resume on TI AM43/AM33 platforms. rtcwake: wakeup from "mem" using /dev/rtc0 at Sun Nov 18 02:12:12 2018 [ 54.033833] PM: suspend entry (deep) [ 54.037741] Filesystems sync: 0.000 seconds [ 54.062730] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 54.071313] OOM killer disabled. [ 54.074572] Freezing remaining freezable tasks ... [ 74.083121] Freezing of tasks failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0): [ 74.092257] hwrng R running task0 289 2 0x0020 [ 74.099511] [] (__schedule) from [] (schedule+0x3c/0xc0) [ 74.106720] [] (schedule) from [] (add_hwgenerator_randomness+0xb0/0x100) [ 74.115358] [] (add_hwgenerator_randomness) from [] (hwrng_fillfn+0xc0/0x14c [rng_core]) [ 74.125356] [] (hwrng_fillfn [rng_core]) from [] (kthread+0x134/0x148) [ 74.133764] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 74.141093] Exception stack(0xec611fb0 to 0xec611ff8) [ 74.146239] 1fa0: [ 74.154478] 1fc0: [ 74.162764] 1fe0: 0013 [ 74.169499] Restarting kernel threads ... done. [ 74.175628] OOM killer enabled. [ 74.178796] Restarting tasks ... done. [ 74.226769] PM: suspend exit rtcwake: write error 1 One task refusing to freeze is the final error i am seeing. - Keerthy
Re: [PATCH] powerpc: remove meaningless KBUILD_ARFLAGS addition
Hi, On Fri, Jul 19, 2019 at 12:43 PM Michael Ellerman wrote: > > Segher Boessenkool writes: > > On Thu, Jul 18, 2019 at 11:19:58AM +0900, Masahiro Yamada wrote: > >> On Thu, Jul 18, 2019 at 1:46 AM Segher Boessenkool > >> wrote: > >> Kbuild always uses thin archives as far as vmlinux is concerned. > >> > >> But, there are some other call-sites. > >> > >> masahiro@pug:~/ref/linux$ git grep '$(AR)' -- :^Documentation :^tools > >> arch/powerpc/boot/Makefile:BOOTAR := $(AR) > >> arch/unicore32/lib/Makefile:$(Q)$(AR) p $(GNU_LIBC_A) $(notdir $@) > $@ > >> arch/unicore32/lib/Makefile:$(Q)$(AR) p $(GNU_LIBGCC_A) $(notdir $@) > > >> $@ > >> lib/raid6/test/Makefile: $(AR) cq $@ $^ > >> scripts/Kbuild.include:ar-option = $(call try-run, $(AR) rc$(1) > >> "$$TMP",$(1),$(2)) > >> scripts/Makefile.build: cmd_ar_builtin = rm -f $@; $(AR) > >> rcSTP$(KBUILD_ARFLAGS) $@ $(real-prereqs) > >> scripts/Makefile.lib: cmd_ar = rm -f $@; $(AR) > >> rcsTP$(KBUILD_ARFLAGS) $@ $(real-prereqs) > >> > >> Probably, you are interested in arch/powerpc/boot/Makefile. > > > > That one seems fine actually. The raid6 one I don't know. > > > > > > My original commit message was > > > > Without this, some versions of GNU ar fail to create > > an archive index if the object files it is packing > > together are of a different object format than ar's > > default format (for example, binutils compiled to > > default to 64-bit, with 32-bit objects). > > > > but I cannot reproduce the problem anymore. Shortly after my patch the > > thin archive code happened to binutils, and that overhauled some other > > things, which might have fixed it already? > > > >> > Yes, I know. This isn't about built-in.[oa], it is about *other* > >> > archives we at least *used to* create. If we *know* we do not anymore, > >> > then this workaround can of course be removed (and good riddance). > >> > >> If it is not about built-in.[oa], > >> which archive are you talking about? > >> > >> Can you pin-point the one? > > > > No, not anymore. Lost in the mists of time, I guess? I think we'll > > just have to file it as "it seems to work fine now". > > Yeah I think so. If someone finds a case it breaks we can fix it then. > > > Thank you (and everyone else) for the time looking at this! > > Likewise. > > cheers So, we agreed to apply this patch, right? Please let me know if there is some improvement that should be get done. -- Best Regards Masahiro Yamada
[PATCH] net/ncsi: add control packet payload to NC-SI commands from netlink
This patch adds support for NCSI_CMD_SEND_CMD netlink command to load packet
data payload (up to 16 bytes) to standard NC-SI commands.
Packet data will be loaded from NCSI_ATTR_DATA attribute similar to NC-SI OEM
commands
Signed-off-by: Ben Wei
---
net/ncsi/internal.h | 7 ---
net/ncsi/ncsi-netlink.c | 9 +
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/net/ncsi/internal.h b/net/ncsi/internal.h index
0b3f0673e1a2..4ff442faf5dc 100644
--- a/net/ncsi/internal.h
+++ b/net/ncsi/internal.h
@@ -328,9 +328,10 @@ struct ncsi_cmd_arg {
unsigned short payload; /* Command packet payload length */
unsigned int req_flags; /* NCSI request properties */
union {
- unsigned char bytes[16]; /* Command packet specific data */
- unsigned short words[8];
- unsigned int dwords[4];
+#define NCSI_MAX_DATA_BYTES 16
+ unsigned char bytes[NCSI_MAX_DATA_BYTES]; /* Command packet
specific data */
+ unsigned short words[NCSI_MAX_DATA_BYTES / sizeof(unsigned
short)];
+ unsigned int dwords[NCSI_MAX_DATA_BYTES / sizeof(unsigned
int)];
};
unsigned char*data; /* NCSI OEM data */
struct genl_info *info; /* Netlink information */
diff --git a/net/ncsi/ncsi-netlink.c b/net/ncsi/ncsi-netlink.c index
8b386d766e7d..7d2a43f30eb1 100644
--- a/net/ncsi/ncsi-netlink.c
+++ b/net/ncsi/ncsi-netlink.c
@@ -459,6 +459,15 @@ static int ncsi_send_cmd_nl(struct sk_buff *msg, struct
genl_info *info)
nca.payload = ntohs(hdr->length);
nca.data = data + sizeof(*hdr);
+ if (nca.payload <= NCSI_MAX_DATA_BYTES) {
+ memcpy(nca.bytes, nca.data, nca.payload);
+ } else {
+ netdev_info(ndp->ndev.dev, "NCSI:payload size %u exceeds max
%u\n",
+ nca.payload, NCSI_MAX_DATA_BYTES);
+ ret = -EINVAL;
+ goto out_netlink;
+ }
+
ret = ncsi_xmit_cmd();
out_netlink:
if (ret != 0) {
--
2.17.1
Re: next/master boot: 254 boots: 16 failed, 231 passed with 4 offline, 1 untried/unknown, 2 conflicts (next-20190726)
On Fri 26 Jul 06:48 PDT 2019, Mark Brown wrote: > On Fri, Jul 26, 2019 at 05:18:01AM -0700, kernelci.org bot wrote: > > The past few versions of -next failed to boot on apq8096-db820c: > > > defconfig: > > gcc-8: > > apq8096-db820c: 1 failed lab > > with an RCU stall towards the end of boot: > > 00:03:40.521336 [ 18.487538] qcom_q6v5_pas adsp-pil: adsp-pil supply px > not found, using dummy regulator > 00:04:01.523104 [ 39.499613] rcu: INFO: rcu_preempt detected stalls on > CPUs/tasks: > 00:04:01.533371 [ 39.499657] rcu: 2-...!: (0 ticks this GP) > idle=9ca/1/0x4000 softirq=1450/1450 fqs=50 > 00:04:01.537544 [ 39.504689] (detected by 0, t=5252 jiffies, g=2425, > q=619) > 00:04:01.541727 [ 39.513539] Task dump for CPU 2: > 00:04:01.547929 [ 39.519096] seq R running task0 > 199198 0x > > Full details and logs at: > > https://kernelci.org/boot/id/5d3aa7ea59b5142ba868890f/ > > The last version that worked was from the 15th and there seem to be > similar issues in mainline since -rc1. As you might have seen this problem has come and gone on the apq8096-db820c and I've finally managed to narrow it down a little bit. The problem first appears on next-20190701, with the introduction of CONFIG_RANDOMIZE_BASE in the defconfig, but after further efforts I've concluded that disabling kpti removes or hides the problem. With kpti=no on the command line I've now successfully booted the db820c 100+ times without problems (a clear improvement from the 75% failure rate with kpti=yes). Unfortunately I'm not yet certain why this is causing issues and I'm also seeing the same rcu stall on SDA845 under certain (erroneous?) conditions (where I don't expect them). Regards, Bjorn
[PATCH] test_bpf: Fix a new clang warning about xor-ing two numbers
r369217 in clang added a new warning about potential misuse of the xor
operator as an exponentiation operator:
../lib/test_bpf.c:870:13: warning: result of '10 ^ 300' is 294; did you
mean '1e300'? [-Wxor-used-as-pow]
{ { 4, 10 ^ 300 }, { 20, 10 ^ 300 } },
~~~^
1e300
../lib/test_bpf.c:870:13: note: replace expression with '0xA ^ 300' to
silence this warning
../lib/test_bpf.c:870:31: warning: result of '10 ^ 300' is 294; did you
mean '1e300'? [-Wxor-used-as-pow]
{ { 4, 10 ^ 300 }, { 20, 10 ^ 300 } },
~~~^
1e300
../lib/test_bpf.c:870:31: note: replace expression with '0xA ^ 300' to
silence this warning
The commit link for this new warning has some good logic behind wanting
to add it but this instance appears to be a false positive. Adopt its
suggestion to silence the warning but not change the code. According to
the differential review link in the clang commit, GCC may eventually
adopt this warning as well.
Link: https://github.com/ClangBuiltLinux/linux/issues/643
Link:
https://github.com/llvm/llvm-project/commit/920890e26812f808a74c60ebc14cc636dac661c1
Signed-off-by: Nathan Chancellor
---
I highly doubt that 1e300 was intented but if it was (or something else
was), please let me know. Commit history wasn't entirely clear on why
this expression was used over just a raw number.
lib/test_bpf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index c41705835cba..5ef3eccee27c 100644
--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -867,7 +867,7 @@ static struct bpf_test tests[] = {
},
CLASSIC,
{ },
- { { 4, 10 ^ 300 }, { 20, 10 ^ 300 } },
+ { { 4, 0xA ^ 300 }, { 20, 0xA ^ 300 } },
},
{
"SPILL_FILL",
--
2.23.0
Re: [PATCH] libfdt: reduce the number of headers included from libfdt_env.h
On Thu, Aug 1, 2019 at 11:30 AM Masahiro Yamada
wrote:
>
> On Tue, Jun 18, 2019 at 1:21 AM Masahiro Yamada
> wrote:
> >
> > Currently, libfdt_env.h includes just for INT_MAX.
> >
> > pulls in a lots of broat.
> >
> > Thanks to commit 54d50897d544 ("linux/kernel.h: split *_MAX and *_MIN
> > macros into "), can be replaced with
> > .
> >
> > This saves including dozens of headers.
> >
> > Signed-off-by: Masahiro Yamada
> > ---
>
> ping?
ping x2.
>
>
> > include/linux/libfdt_env.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/libfdt_env.h b/include/linux/libfdt_env.h
> > index edb0f0c30904..2231eb855e8f 100644
> > --- a/include/linux/libfdt_env.h
> > +++ b/include/linux/libfdt_env.h
> > @@ -2,7 +2,7 @@
> > #ifndef LIBFDT_ENV_H
> > #define LIBFDT_ENV_H
> >
> > -#include /* For INT_MAX */
> > +#include /* For INT_MAX */
> > #include
> >
> > #include
> > --
> > 2.17.1
> >
>
>
> --
> Best Regards
> Masahiro Yamada
--
Best Regards
Masahiro Yamada
Re: [PATCH] riscv: move sifive_l2_cache.c to drivers/soc
On Sun, Aug 18, 2019 at 2:01 PM Christoph Hellwig wrote:
>
> The sifive_l2_cache.c is in no way related to RISC-V architecture
> memory management. It is a little stub driver working around the fact
> that the EDAC maintainers prefer their drivers to be structured in a
> certain way that doesn't fit the SiFive SOCs.
>
> Move the file to drivers/soc and add a Kconfig option for it, as well
> as the whole drivers/soc boilerplate for CONFIG_SOC_SIFIVE.
>
> Fixes: a967a289f169 ("RISC-V: sifive_l2_cache: Add L2 cache controller driver
> for SiFive SoCs")
> Signed-off-by: Christoph Hellwig
> ---
> arch/riscv/mm/Makefile | 1 -
> drivers/edac/Kconfig | 2 +-
> drivers/soc/Kconfig| 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/sifive/Kconfig | 10 ++
> drivers/soc/sifive/Makefile| 4
> .../riscv/mm => drivers/soc/sifive}/sifive_l2_cache.c | 0
> 7 files changed, 17 insertions(+), 2 deletions(-)
> create mode 100644 drivers/soc/sifive/Kconfig
> create mode 100644 drivers/soc/sifive/Makefile
> rename {arch/riscv/mm => drivers/soc/sifive}/sifive_l2_cache.c (100%)
>
> diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
> index 74055e1d6f21..d2101d0741d4 100644
> --- a/arch/riscv/mm/Makefile
> +++ b/arch/riscv/mm/Makefile
> @@ -11,6 +11,5 @@ obj-y += extable.o
> obj-y += ioremap.o
> obj-y += cacheflush.o
> obj-y += context.o
> -obj-y += sifive_l2_cache.o
>
> obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index 200c04ce5b0e..9241b3e7a050 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -462,7 +462,7 @@ config EDAC_ALTERA_SDMMC
>
> config EDAC_SIFIVE
> bool "Sifive platform EDAC driver"
> - depends on EDAC=y && RISCV
> + depends on EDAC=y && SIFIVE_L2
> help
> Support for error detection and correction on the SiFive SoCs.
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 833e04a7835c..1778f8c62861 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -14,6 +14,7 @@ source "drivers/soc/qcom/Kconfig"
> source "drivers/soc/renesas/Kconfig"
> source "drivers/soc/rockchip/Kconfig"
> source "drivers/soc/samsung/Kconfig"
> +source "drivers/soc/sifive/Kconfig"
> source "drivers/soc/sunxi/Kconfig"
> source "drivers/soc/tegra/Kconfig"
> source "drivers/soc/ti/Kconfig"
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 2ec355003524..8b49d782a1ab 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -20,6 +20,7 @@ obj-y += qcom/
> obj-y += renesas/
> obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
> obj-$(CONFIG_SOC_SAMSUNG) += samsung/
> +obj-$(CONFIG_SOC_SIFIVE) += sifive/
> obj-y += sunxi/
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-y += ti/
> diff --git a/drivers/soc/sifive/Kconfig b/drivers/soc/sifive/Kconfig
> new file mode 100644
> index ..9ffb2e8a48cd
> --- /dev/null
> +++ b/drivers/soc/sifive/Kconfig
> @@ -0,0 +1,10 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +if SOC_SIFIVE
> +
> +config SIFIVE_L2
> + tristate "Sifive L2 Cache controller"
> + help
> + Support for the L2 cache controller on SiFive platforms.
> +
> +endif
> diff --git a/drivers/soc/sifive/Makefile b/drivers/soc/sifive/Makefile
> new file mode 100644
> index ..9b4a85558347
> --- /dev/null
> +++ b/drivers/soc/sifive/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_SIFIVE_L2)+= sifive_l2_cache.o
> +
> diff --git a/arch/riscv/mm/sifive_l2_cache.c
> b/drivers/soc/sifive/sifive_l2_cache.c
> similarity index 100%
> rename from arch/riscv/mm/sifive_l2_cache.c
> rename to drivers/soc/sifive/sifive_l2_cache.c
> --
> 2.20.1
>
LGTM.
Reviewed-by: Anup Patel
Regards,
Anup
[PATCH] Kconfig: Fix the reference to the RFD77402 ToF sensor in the 'help' section
This should be RFD77402, not RFD77420.
Signed-off-by: Christophe JAILLET
---
Not sure that the Kconfig prefix is correct. I have choosen it because of
commit 21cf20a84a ("Kconfig: change configuration of srf04 ultrasonic iio
sensor")
---
drivers/iio/proximity/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
index 6b5cce6f1a7b..d53601447da4 100644
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -62,7 +62,7 @@ config RFD77402
tristate "RFD77402 ToF sensor"
depends on I2C
help
- Say Y to build a driver for the RFD77420 Time-of-Flight (distance)
+ Say Y to build a driver for the RFD77402 Time-of-Flight (distance)
sensor module with I2C interface.
To compile this driver as a module, choose M here: the
--
2.20.1
Re: [PATCH] RISC-V: Fix FIXMAP area corruption on RV32 systems
On Sun, Aug 18, 2019 at 11:49 PM Christoph Hellwig wrote: > > > +#define FIXADDR_TOP (VMALLOC_START) > > Nit: no need for the braces, the definitions below don't use it > either. Sure, I will update and send v2 soon. > > > +#ifdef CONFIG_64BIT > > +#define FIXADDR_SIZE PMD_SIZE > > +#else > > +#define FIXADDR_SIZE PGDIR_SIZE > > +#endif > > +#define FIXADDR_START(FIXADDR_TOP - FIXADDR_SIZE) > > + > > /* > > - * Task size is 0x40 for RV64 or 0xb80 for RV32. > > + * Task size is 0x40 for RV64 or 0x9fc0 for RV32. > > * Note that PGDIR_SIZE must evenly divide TASK_SIZE. > > */ > > #ifdef CONFIG_64BIT > > #define TASK_SIZE (PGDIR_SIZE * PTRS_PER_PGD / 2) > > #else > > -#define TASK_SIZE VMALLOC_START > > +#define TASK_SIZE FIXADDR_START > > #endif > > Mentioning the addresses is a little weird. IMHO this would be > a much nicer place to explain the high-level memory layout, including > maybe a little ASCII art. Also we could have one #ifdef CONFIG_64BIT > for both related values. Last but not least instead of saying that > something should be dividable it would be nice to have a BUILD_BUG_ON > to enforce it. > > Either way we are late in the cycle, so I guess this is ok for now: > > Reviewed-by: Christoph Hellwig > > But I'd love to see this area improved a little further as it is full > of mine fields. I agree with you. We also have Sparsemem and KASAN patches which touch virtual memory layout so it's important to have virtual memory layout documented clearly. I can add the required documentation as separate patch. I think the best place to add ASCII art would be asm/pgtable.h where all virtual memory related defines are placed. Suggestions?? Regards, Anup
linux-next: manual merge of the tip tree with the ia64 tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/ia64/include/asm/sn/sn_sal.h
between commit:
cf07cb1ff4ea ("ia64: remove support for the SGI SN2 platform")
from the ia64 tree and commit:
5828efb95bc4 ("efi: ia64: move SAL systab handling out of generic EFI code")
from the tip tree.
I fixed it up (the former removed the code updated by the latter) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpBiD6V7COLo.pgp
Description: OpenPGP digital signature
Re: [PATCH v2] arch : arm : add a criteria for pfn_valid
On Mon, Aug 19, 2019 at 09:36:09AM +0800, Zhaoyang Huang wrote:
> From: Zhaoyang Huang
>
> pfn_valid can be wrong when parsing a invalid pfn whose phys address
> exceeds BITS_PER_LONG as the MSB will be trimed when shifted.
I'd appreciate to see in the changelog that this could be triggered from
userspace via /proc/kpageflags
Otherwise:
Reviewed-by: Mike Rapoport
> Signed-off-by: Zhaoyang Huang
> ---
> arch/arm/mm/init.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index c2daabb..cc769fa 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -177,6 +177,11 @@ static void __init zone_sizes_init(unsigned long min,
> unsigned long max_low,
> #ifdef CONFIG_HAVE_ARCH_PFN_VALID
> int pfn_valid(unsigned long pfn)
> {
> + phys_addr_t addr = __pfn_to_phys(pfn);
> +
> + if (__phys_to_pfn(addr) != pfn)
> + return 0;
> +
> return memblock_is_map_memory(__pfn_to_phys(pfn));
> }
> EXPORT_SYMBOL(pfn_valid);
> --
> 1.9.1
>
--
Sincerely yours,
Mike.
Re: [RFC PATCH 11/15] drivers/acrn: add the support of handling emulated ioreq
On 2019年08月16日 21:39, Dan Carpenter wrote:
On Fri, Aug 16, 2019 at 10:25:52AM +0800, Zhao Yakui wrote:
+int acrn_ioreq_create_client(unsigned short vmid,
+ioreq_handler_t handler,
+void *client_priv,
+char *name)
+{
+ struct acrn_vm *vm;
+ struct ioreq_client *client;
+ int client_id;
+
+ might_sleep();
+
+ vm = find_get_vm(vmid);
+ if (unlikely(!vm || !vm->req_buf)) {
+ pr_err("acrn-ioreq: failed to find vm from vmid %d\n", vmid);
+ put_vm(vm);
+ return -EINVAL;
+ }
+
+ client_id = alloc_client();
+ if (unlikely(client_id < 0)) {
+ pr_err("acrn-ioreq: vm[%d] failed to alloc ioreq client\n",
+ vmid);
+ put_vm(vm);
+ return -EINVAL;
+ }
+
+ client = acrn_ioreq_get_client(client_id);
+ if (unlikely(!client)) {
+ pr_err("failed to get the client.\n");
+ put_vm(vm);
+ return -EINVAL;
Do we need to clean up the alloc_client() allocation?
Thanks for the review.
The function of acrn_iocreq_get_client is used to return the client for
the given client_id. (The ref_count of client is also added). If it is
NULL, it indicates that it is already released in another place.
In the function of acrn_ioreq_create_client, we don't need to clean up
the alloc_client as it always exists in course of creating_client.
regards,
dan carpenter
+ }
+
+ if (handler) {
+ client->handler = handler;
+ client->acrn_create_kthread = true;
+ }
+
+ client->ref_vm = vm;
+ client->vmid = vmid;
+ client->client_priv = client_priv;
+ if (name)
+ strncpy(client->name, name, sizeof(client->name) - 1);
+ rwlock_init(>range_lock);
+ INIT_LIST_HEAD(>range_list);
+ init_waitqueue_head(>wq);
+
+ /* When it is added to ioreq_client_list, the refcnt is increased */
+ spin_lock_bh(>ioreq_client_lock);
+ list_add(>list, >ioreq_client_list);
+ spin_unlock_bh(>ioreq_client_lock);
+
+ pr_info("acrn-ioreq: created ioreq client %d\n", client_id);
+
+ return client_id;
+}
[PATCH] Kconfig: Fix the reference to the IDT77105 Phy driver in the description of ATM_NICSTAR_USE_IDT77105
This should be IDT77105, not IDT77015. Signed-off-by: Christophe JAILLET --- drivers/atm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/atm/Kconfig b/drivers/atm/Kconfig index 2e2efa577437..8c37294f1d1e 100644 --- a/drivers/atm/Kconfig +++ b/drivers/atm/Kconfig @@ -200,7 +200,7 @@ config ATM_NICSTAR_USE_SUNI make the card work). config ATM_NICSTAR_USE_IDT77105 - bool "Use IDT77015 PHY driver (25Mbps)" + bool "Use IDT77105 PHY driver (25Mbps)" depends on ATM_NICSTAR help Support for the PHYsical layer chip in ForeRunner LE25 cards. In -- 2.20.1
