Re: [PATCH v7 3/5] usb: host: ohci-sm501: init genalloc for local memory
On Mon, Jun 24, 2019 at 02:59:16PM +0200, Fredrik Noring wrote: > Hi Christoph, > > > Can you send me the patch formally so that I can queue it up for the > > dma-mapping tree? > > That patch would be detrimental to local memory devices, as previously > discussed, so I would like to suggest a much better approach, as shown below, > where allocations are aligned as required but not necessarily much more than > that. This looks sensible to me. Can you submit it with a proper patch description and split into a separate patch for genalloc vs the user of the new interface?
linux-next: build failure after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/net/wireless/intersil/p54/txrx.c: In function 'p54_rx_data':
drivers/net/wireless/intersil/p54/txrx.c:386:28: error: implicit declaration of
function 'ktime_get_boot_ns'; did you mean 'ktime_get_raw_ns'?
[-Werror=implicit-function-declaration]
rx_status->boottime_ns = ktime_get_boot_ns();
^
ktime_get_raw_ns
Caused by commit
c11c75ec784e ("p54: Support boottime in scan results")
from the wireless-drivers-next tree interacting with commit
9285ec4c8b61 ("timekeeping: Use proper clock specifier names in functions")
from the tip tree.
I have added the following merge fix patch:
From: Stephen Rothwell
Date: Tue, 25 Jun 2019 15:55:36 +1000
Subject: [PATCH] p54: fix up for ktime_get_boot_ns() name change
Signed-off-by: Stephen Rothwell
---
drivers/net/wireless/intersil/p54/txrx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intersil/p54/txrx.c
b/drivers/net/wireless/intersil/p54/txrx.c
index be6968454282..873fea59894f 100644
--- a/drivers/net/wireless/intersil/p54/txrx.c
+++ b/drivers/net/wireless/intersil/p54/txrx.c
@@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct
sk_buff *skb)
fc = ((struct ieee80211_hdr *)skb->data)->frame_control;
if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc))
- rx_status->boottime_ns = ktime_get_boot_ns();
+ rx_status->boottime_ns = ktime_get_boottime_ns();
if (unlikely(priv->hw->conf.flags & IEEE80211_CONF_PS))
p54_pspoll_workaround(priv, skb);
--
2.20.1
--
Cheers,
Stephen Rothwell
pgpd8Vu3HUydV.pgp
Description: OpenPGP digital signature
Re: [PATCH V34 00/29] Lockdown as an LSM
On Mon, 24 Jun 2019, Matthew Garrett wrote: > > We are still not resolved on granularity. Stephen has said he's not sure > > if a useful policy can be constructed with just confidentiality and > > integrity settings. I'd be interested to know JJ and Casey's thoughts on > > lockdown policy flexibility wrt their respective LSMs. > > This implementation provides arbitrary granularity at the LSM level, > though the lockdown LSM itself only provides two levels. Other LSMs > can choose an appropriate level of exposure. Ahh, OK, I only looked at the patchset description and had not looked at V33 yet. This is looking good. -- James Morris
Re: [PATCH v4 0/3] [v4.9.y] coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping
On 25/06/19, 1:51 AM, "Sasha Levin" wrote: > On Tue, Jun 25, 2019 at 02:33:06AM +0530, Ajay Kaher wrote: > > coredump: fix race condition between mmget_not_zero()/get_task_mm() > > and core dumping > > > > [PATCH v4 1/3]: > > Backporting of commit 04f5866e41fb70690e28397487d8bd8eea7d712a upstream. > > > > [PATCH v4 2/3]: > > Extension of commit 04f5866e41fb to fix the race condition between > > get_task_mm() and core dumping for IB->mlx4 and IB->mlx5 drivers. > > > > [PATCH v4 3/3] > > Backporting of commit 59ea6d06cfa9247b586a695c21f94afa7183af74 upstream. > > > > [diff from v3]: > > - added [PATCH v4 3/3] > Why do all the patches have the same subject line? Thanks for catching this. I will correct in next version of these patches, along with review comments if any. > I guess it's correct for the first one, but can you explain what's up > with #2 and #3? > > If the second one isn't upstream, please explain in detail why not and > how 4.9 differs from upstream so that it requires a custom backport. #2 applied to 4.14.y: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.14/infiniband-fix-race-condition-between-infiniband-mlx4-mlx5-driver-and-core-dumping.patch?id=e4041a3f6b569140549fe7b41ed527c5c1e38ec9 And then to 4.9.y (some part as requires). 4.18 and onwards doesn't have mmap_sem locking in mlx4 and mlx5, so no need of #2 in 4.18 and onwards. > The third one just looks like a different patch altogether with a wrong > subject line? #3 was in discussion here (during v1), so added here. > -- > Thanks, > Sasha
Re: [PATCH] kbuild: compile-test global headers to ensure they are self-contained
> > When all header files below include/drm are self-contained it will be a > single line: > > header-test-y += $(all_headers_with_subdir) In reality it will likely be the above, and then a list of header-test-n += foo.h For the header files that we for one or the other reason do not want to make self-contained. It would be nice to have the list of ignored files close to their home and not a full list in one Makefile in include/ > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index 3e630fcaffd1..e2f765e9d1e1 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -67,6 +67,7 @@ extra-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtb,%.dt.yaml, > $(dtb-)) > endif > > # Test self-contained headers > +header-test-y := $(filter-out $(header-test-n), $(header-test-y)) This part should include the logic to filter out duplicates too. I think we may do something wrong if the same header is listed twice. We could also extend this with a check that all files in header-test-n exits. Sam
Re: hard-coded limit on unresolved multicast route cache in ipv4/ipmr.c causes slow, unreliable creation of multicast routes on busy networks
On Tue, Dec 18, 2018 at 09:55:45PM -0800, David Miller wrote: > From: Sukumar Gopalakrishnan > Date: Wed, 19 Dec 2018 10:57:02 +0530 > > > Hi David, > > > > There are two patch for this issue: > >1) Your changes which removes cache_resolve_queue_len > > 2) Hangbin's changes which make cache_resolve_queue_len configurable. > > > > Which one will be chosen for this issue ? > > I do plan to look into this, sorry for taking so long. > > Right now I am overwhelmed preparing for the next merge window and > synchronizing with other developers for that. > > Please be patient. Hi David, Any progress for this issue? Thanks Hangbin
[PATCH] fixdep: check return code of printf() and putchar()
When there is not enough space on your storage device, the build will
fail with 'No space left on device' error message.
The reason is obvious from the message, so you will free up some disk
space, then you will resume the build.
However, sometimes you may still see a mysterious error message:
unterminated call to function 'wildcard': missing ')'.
If you run out of the disk space, fixdep may end up with generating
incomplete .*.cmd files.
For example, if the disk shortage occurs while fixdep is running
print_dep(), the .*.cmd might be truncated like this:
$(wildcard include/config/
When you run 'make' next time, this broken .*.cmd will be included,
then GNU Make will terminate parsing since it is a wrong syntax.
Once this happens, you need to run 'make clean' or delete the broken
.*.cmd file manually.
Even if you do not see any error message, the .*.cmd files after any
error could be potentially incomplete, and unreliable. You may miss
the re-compilation due to missing header dependency.
If printf() cannot output the string for disk shortage or whatever
reason, it returns a negative return code, but currently fixdep does
not check it at all. Consequently, fixdep *successfully* generates a
broken .*.cmd file. Make never notices that since fixdep exits with 0,
which means success.
Given the intended usage of fixdep, it must respect the return code of
not only malloc(), but also printf() and putchar().
This seems a long-standing issue since the introduction of fixdep.
In old days, Kbuild tried to provide an extra safety by letting fixdep
output to a temporary file and renaming it after everything is done:
scripts/basic/fixdep $(depfile) $@ '$(make-cmd)' > $(dot-target).tmp;\
rm -f $(depfile);\
mv -f $(dot-target).tmp $(dot-target).cmd)
It did not avoid the current issue; fixdep created a truncated tmp file
reporting success, so the broken tmp would be renamed to a .*.cmd file.
By propagating the error code to the build system, this problem should
be solved because:
[1] Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special
target"), Make will delete the target automatically on any failure
in the recipe.
[2] Since commit 392885ee82d3 ("kbuild: let fixdep directly write to
.*.cmd files"), .*.cmd file is included only when the corresponding
target already exists.
Signed-off-by: Masahiro Yamada
---
scripts/basic/fixdep.c | 47 +-
1 file changed, 37 insertions(+), 10 deletions(-)
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index facbd603adf6..fea1d58bda68 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -99,6 +99,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -109,6 +110,32 @@ static void usage(void)
exit(1);
}
+/*
+ * In the intended usage of this program, the stdout is redirected to .*.cmd
+ * The return code of printf() and putchar() must be checked to catch any error
+ * like "No space left on device".
+ */
+static void xprintf(const char *format, ...)
+{
+ va_list ap;
+ int ret;
+
+ va_start(ap, format);
+ ret = vprintf(format, ap);
+ if (ret < 0)
+ exit(1);
+ va_end(ap);
+}
+
+static void xputchar(int c)
+{
+ int ret;
+
+ ret = putchar(c);
+ if (ret == EOF)
+ exit(1);
+}
+
/*
* Print out a dependency path from a symbol name
*/
@@ -116,7 +143,7 @@ static void print_dep(const char *m, int slen, const char
*dir)
{
int c, prev_c = '/', i;
- printf("$(wildcard %s/", dir);
+ xprintf("$(wildcard %s/", dir);
for (i = 0; i < slen; i++) {
c = m[i];
if (c == '_')
@@ -124,10 +151,10 @@ static void print_dep(const char *m, int slen, const char
*dir)
else
c = tolower(c);
if (c != '/' || prev_c != '/')
- putchar(c);
+ xputchar(c);
prev_c = c;
}
- printf(".h) \\\n");
+ xprintf(".h) \\\n");
}
struct item {
@@ -324,13 +351,13 @@ static void parse_dep_file(char *m, const char *target)
*/
if (!saw_any_target) {
saw_any_target = 1;
- printf("source_%s := %s\n\n",
- target, m);
- printf("deps_%s := \\\n", target);
+ xprintf("source_%s := %s\n\n",
+ target, m);
+ xprintf("deps_%s := \\\n", target);
}
is_first_dep = 0;
} else {
- printf(" %s
答复: [tip:x86/cpu] x86/cpu: Create Zhaoxin processors architecture support file
On Sun, Jun 23, 2019, Joe Perches wrote:
> > x86/cpu: Create Zhaoxin processors architecture support file
> >
> []
> > diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.c
> []
> > +static void init_zhaoxin_cap(struct cpuinfo_x86 *c)
> > +{
> > + u32 lo, hi;
> > +
> > + /* Test for Extended Feature Flags presence */
> > + if (cpuid_eax(0xC000) >= 0xC001) {
> > + u32 tmp = cpuid_edx(0xC001);
> > +
> > + /* Enable ACE unit, if present and disabled */
> > + if ((tmp & (ACE_PRESENT | ACE_ENABLED)) == ACE_PRESENT) {
>
> trivia:
>
> Perhaps this is more intelligible for humans to read
> and it deduplicates the comment as:
>
> if ((tmp & ACE_PRESENT) && !(tmp & ACE_ENABLED))
>
> The compiler produces the same object code.
>
Thanks for the trivia, I will change this in the next version patch set.
Thanks
TonyWWang-oc
Re: WARNING in mark_lock
On Mon, 24 Jun 2019, syzbot wrote: > Hello, CC++ Peterz > > syzbot found the following crash on: > > HEAD commit:dc636f5d Add linux-next specific files for 20190620 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=162b68b1a0 > kernel config: https://syzkaller.appspot.com/x/.config?x=99c104b0092a557b > dashboard link: https://syzkaller.appspot.com/bug?extid=a861f52659ae2596492b > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=110b24f6a0 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+a861f52659ae25964...@syzkaller.appspotmail.com > > [ cut here ] > DEBUG_LOCKS_WARN_ON(1) > WARNING: CPU: 0 PID: 9968 at kernel/locking/lockdep.c:167 hlock_class > kernel/locking/lockdep.c:167 [inline] > WARNING: CPU: 0 PID: 9968 at kernel/locking/lockdep.c:167 hlock_class > kernel/locking/lockdep.c:156 [inline] > WARNING: CPU: 0 PID: 9968 at kernel/locking/lockdep.c:167 > mark_lock+0x22b/0x11e0 kernel/locking/lockdep.c:3594 > Kernel panic - not syncing: panic_on_warn set ... > CPU: 0 PID: 9968 Comm: syz-executor.2 Not tainted 5.2.0-rc5-next-20190620 #19 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google > 01/01/2011 > Call Trace: > > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x172/0x1f0 lib/dump_stack.c:113 > panic+0x2dc/0x755 kernel/panic.c:219 > __warn.cold+0x20/0x4c kernel/panic.c:576 > report_bug+0x263/0x2b0 lib/bug.c:186 > fixup_bug arch/x86/kernel/traps.c:179 [inline] > fixup_bug arch/x86/kernel/traps.c:174 [inline] > do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272 > do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291 > invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:986 > RIP: 0010:hlock_class kernel/locking/lockdep.c:167 [inline] > RIP: 0010:hlock_class kernel/locking/lockdep.c:156 [inline] > RIP: 0010:mark_lock+0x22b/0x11e0 kernel/locking/lockdep.c:3594 > Code: d0 7c 08 84 d2 0f 85 33 0f 00 00 44 8b 15 4d 14 4a 08 45 85 d2 75 b6 48 > c7 c6 c0 a6 8b 87 48 c7 c7 00 a7 8b 87 e8 ad e6 eb ff <0f> 0b 31 db e9 a8 fe > ff ff 48 c7 c7 80 71 86 8a e8 f0 95 53 00 e9 > RSP: 0018:8880ae809ad0 EFLAGS: 00010082 > RAX: RBX: 0f1d RCX: > RDX: 0001 RSI: 815b37e6 RDI: ed1015d0134c > RBP: 8880ae809b20 R08: 88808662e0c0 R09: fbfff11b3285 > R10: fbfff11b3284 R11: 88d99423 R12: > R13: 88808662e9c8 R14: 004f R15: 000c4f1d > mark_usage kernel/locking/lockdep.c:3485 [inline] > __lock_acquire+0x1e1a/0x4680 kernel/locking/lockdep.c:3839 > lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4418 > __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] > _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159 > try_to_wake_up+0x90/0x1430 kernel/sched/core.c:2000 > wake_up_process+0x10/0x20 kernel/sched/core.c:2114 ^^ > hrtimer_wakeup+0x48/0x60 kernel/time/hrtimer.c:1636 > __run_hrtimer kernel/time/hrtimer.c:1388 [inline] > __hrtimer_run_queues+0x364/0xe40 kernel/time/hrtimer.c:1450 > hrtimer_interrupt+0x314/0x770 kernel/time/hrtimer.c:1508 > local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1041 [inline] > smp_apic_timer_interrupt+0x12a/0x5b0 arch/x86/kernel/apic/apic.c:1066 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:806 > > Kernel Offset: disabled > Rebooting in 86400 seconds.. > > > --- > 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: [x86/hotplug] e1056a25da: WARNING:at_arch/x86/kernel/apic/apic.c:#setup_local_APIC
Rong, On Tue, 25 Jun 2019, Rong Chen wrote: > On 6/22/19 3:08 AM, Thomas Gleixner wrote: > > > > > > on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m > > > 2G > > I cannot reproduce that issue. What's the underlying hardware machine? > > brand: Genuine Intel(R) CPU 000 @ 2.27GHz > model: Westmere-EX > memory: 256G > nr_node: 4 > nr_cpu: 80 Ok. I'll try to find something similar. Can please you rerun that test on that particular configuration with the updated branch? git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/ipi please? Thanks, tglx
Re: linux-next: build failure after merge of the tip tree
Stephen Rothwell writes:
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/net/wireless/intersil/p54/txrx.c: In function 'p54_rx_data':
> drivers/net/wireless/intersil/p54/txrx.c:386:28: error: implicit declaration
> of function 'ktime_get_boot_ns'; did you mean 'ktime_get_raw_ns'?
> [-Werror=implicit-function-declaration]
>rx_status->boottime_ns = ktime_get_boot_ns();
> ^
> ktime_get_raw_ns
>
> Caused by commit
>
> c11c75ec784e ("p54: Support boottime in scan results")
>
> from the wireless-drivers-next tree interacting with commit
>
> 9285ec4c8b61 ("timekeeping: Use proper clock specifier names in functions")
>
> from the tip tree.
>
> I have added the following merge fix patch:
>
> From: Stephen Rothwell
> Date: Tue, 25 Jun 2019 15:55:36 +1000
> Subject: [PATCH] p54: fix up for ktime_get_boot_ns() name change
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/net/wireless/intersil/p54/txrx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intersil/p54/txrx.c
> b/drivers/net/wireless/intersil/p54/txrx.c
> index be6968454282..873fea59894f 100644
> --- a/drivers/net/wireless/intersil/p54/txrx.c
> +++ b/drivers/net/wireless/intersil/p54/txrx.c
> @@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct
> sk_buff *skb)
>
> fc = ((struct ieee80211_hdr *)skb->data)->frame_control;
> if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc))
> - rx_status->boottime_ns = ktime_get_boot_ns();
> + rx_status->boottime_ns = ktime_get_boottime_ns();
Thanks for the report. Any suggestions how to handle this? Or do we let
Linus take care of this?
--
Kalle Valo
Re: linux-next: build failure after merge of the tip tree
On Tue, 25 Jun 2019, Kalle Valo wrote: > Stephen Rothwell writes: > > --- > > drivers/net/wireless/intersil/p54/txrx.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/net/wireless/intersil/p54/txrx.c > > b/drivers/net/wireless/intersil/p54/txrx.c > > index be6968454282..873fea59894f 100644 > > --- a/drivers/net/wireless/intersil/p54/txrx.c > > +++ b/drivers/net/wireless/intersil/p54/txrx.c > > @@ -383,7 +383,7 @@ static int p54_rx_data(struct p54_common *priv, struct > > sk_buff *skb) > > > > fc = ((struct ieee80211_hdr *)skb->data)->frame_control; > > if (ieee80211_is_probe_resp(fc) || ieee80211_is_beacon(fc)) > > - rx_status->boottime_ns = ktime_get_boot_ns(); > > + rx_status->boottime_ns = ktime_get_boottime_ns(); > > Thanks for the report. Any suggestions how to handle this? Or do we let > Linus take care of this? As the core changes which cause this are in tip timers/core, I can just pick that up and be done with it. Ok? Thanks, tglx
Re: [GIT PULL v2] MFD fixes for v5.2
On Tue, 25 Jun 2019, Linus Torvalds wrote: > On Mon, Jun 24, 2019 at 10:34 PM Lee Jones wrote: > > > > Hopefully this is more to your liking. > > I would actually have preferred you to throw the old buggy "fix" away, > and just do the final state. You okayed the follow-up patch, so I took it as-is. > But the end result looks sane, so I pulled it. Sounds good, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] cifs: fix typo in debug message with struct field ia_valid
merged into cifs-2.6.git for-next On Mon, Jun 24, 2019 at 3:25 PM Colin King wrote: > > From: Colin Ian King > > Field ia_valid is being debugged with the field name iavalid, fix this. > > Signed-off-by: Colin Ian King > --- > fs/cifs/inode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c > index d7cc62252634..06a4892e9973 100644 > --- a/fs/cifs/inode.c > +++ b/fs/cifs/inode.c > @@ -2415,7 +2415,7 @@ cifs_setattr_nounix(struct dentry *direntry, struct > iattr *attrs) > > xid = get_xid(); > > - cifs_dbg(FYI, "setattr on file %pd attrs->iavalid 0x%x\n", > + cifs_dbg(FYI, "setattr on file %pd attrs->ia_valid 0x%x\n", > direntry, attrs->ia_valid); > > if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NO_PERM) > -- > 2.20.1 > -- Thanks, Steve
Re: [PATCH v6 0/5] LM36274 Introduction
On Mon, 24 Jun 2019, Dan Murphy wrote: > Lee > > On 6/24/19 9:42 AM, Lee Jones wrote: > > On Wed, 05 Jun 2019, Dan Murphy wrote: > > > > > Hello > > > > > > The v5 patchset missed adding in the new validation code. > > > Patch 1 of the v5 series was squashed into patch 4 of the v5 series. > > > So this will reduce the patchset by 1. > > > > > > Sorry for the extra noise on the patchsets. The change was lost when I > > > converted > > > the patches from the mainline branch to the LED branch. > > > > > > This change was made on top of the branch > > > > > > repo: > > > https://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git > > > branch: ti-lmu-led-drivers > > > > > > > > > Dan Murphy (5): > > >dt-bindings: mfd: Add lm36274 bindings to ti-lmu > > >mfd: ti-lmu: Add LM36274 support to the ti-lmu > > >regulator: lm363x: Add support for LM36274 > > >dt-bindings: leds: Add LED bindings for the LM36274 > > >leds: lm36274: Introduce the TI LM36274 LED driver > > > > > > .../devicetree/bindings/leds/leds-lm36274.txt | 82 + > > > .../devicetree/bindings/mfd/ti-lmu.txt| 54 ++ > > > drivers/leds/Kconfig | 8 + > > > drivers/leds/Makefile | 1 + > > > drivers/leds/leds-lm36274.c | 174 ++ > > > drivers/mfd/Kconfig | 5 +- > > > drivers/mfd/ti-lmu.c | 14 ++ > > > drivers/regulator/Kconfig | 2 +- > > > drivers/regulator/lm363x-regulator.c | 78 +++- > > > include/linux/mfd/ti-lmu-register.h | 23 +++ > > > include/linux/mfd/ti-lmu.h| 4 + > > > 11 files changed, 437 insertions(+), 8 deletions(-) > > > create mode 100644 > > > Documentation/devicetree/bindings/leds/leds-lm36274.txt > > > create mode 100644 drivers/leds/leds-lm36274.c > > Can you finish of satisfying everyone's comments and re-send with all > > the Acks you've collected so far? If you turn this around quickly, > > you might still get into v5.3. > > > > The changes were made by Jacek and I reviewed and tested them > > https://lkml.org/lkml/2019/6/11/455 Ah, this was related to the recent GIT PULL craziness. Thanks for letting me know. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: 答复: [tip:x86/cpu] x86/cpu: Create Zhaoxin processors architecture support file
Tony,
On Tue, 25 Jun 2019, Tony W Wang-oc wrote:
> On Sun, Jun 23, 2019, Joe Perches wrote:
> > > x86/cpu: Create Zhaoxin processors architecture support file
> > >
> > []
> > > diff --git a/arch/x86/kernel/cpu/zhaoxin.c b/arch/x86/kernel/cpu/zhaoxin.c
> > []
> > > +static void init_zhaoxin_cap(struct cpuinfo_x86 *c)
> > > +{
> > > + u32 lo, hi;
> > > +
> > > + /* Test for Extended Feature Flags presence */
> > > + if (cpuid_eax(0xC000) >= 0xC001) {
> > > + u32 tmp = cpuid_edx(0xC001);
> > > +
> > > + /* Enable ACE unit, if present and disabled */
> > > + if ((tmp & (ACE_PRESENT | ACE_ENABLED)) == ACE_PRESENT) {
> >
> > trivia:
> >
> > Perhaps this is more intelligible for humans to read
> > and it deduplicates the comment as:
> >
> > if ((tmp & ACE_PRESENT) && !(tmp & ACE_ENABLED))
> >
> > The compiler produces the same object code.
> >
>
> Thanks for the trivia, I will change this in the next version patch set.
as you might have noticed from the tip bot commit notification mail, your
patch set has been merged into the tip tree and is queued for the 5.3 merge
window. So a new patch set is pointless. If at all then you can send a
delta patch.
Though I have to say, that I prefer the existing check:
> > > + if ((tmp & (ACE_PRESENT | ACE_ENABLED)) == ACE_PRESENT) {
It's pretty clear, but that's really a matter of personal preference. So
from my side there is nothing to do at all.
Thanks,
tglx
Re: [PATCH 7/7] arc: use the generic remapping allocator for coherent DMA allocations
On Mon, Jun 24, 2019 at 07:13:17PM +, Eugeniy Paltsev wrote: > Hi Christoph, > > Yep I've reviewed and tested it for both cases: > - coherent/noncoherent dma > - allocation from atomic_pool/regular allocation > > everything works fine for ARC. Thanks. I've applied the whole series to the dma-mapping for-next branch.
Re: [PATCH v6 7/8] dynamic_debug: add asm-generic implementation for DYNAMIC_DEBUG_RELATIVE_POINTERS
On 24/06/2019 23.53, Nick Desaulniers wrote: > On Thu, Jun 20, 2019 at 1:46 PM Rasmus Villemoes > wrote: >> >> I've pushed them to https://github.com/Villemoes/linux/tree/dyndebug_v6 >> . They rebase pretty cleanly to just about anything you might prefer >> testing on. Enabling it for arm64 or ppc64 is a trivial two-liner >> similar to the x86 patch (and similar to the previous patches for those >> arches). Thanks for volunteering to test this :) > > Compile tested x86_64 allyesconfig > boot tested x86_64 defconfig+CONFIG_DYNAMIC_DEBUG > > (just curious why the Kconfig changes for arm64 or ppc64 aren't > included in this set?) Partly because I can't boot test those and this has proven much more delicate than I thought, partly because none of the maintainers for those arches have weighed in. So I'd rather have the bare minimal land, then send specific individual patches for arm64 and ppc64. >>> Anything I should test at runtime besides a boot >>> test? >> >> Well, apart from booting, I've mostly just tested that the debugfs >> control file is identical before and after enabling relative pointers, > > mainline x86_64 defconfig+CONFIG_DYNAMIC_DEBUG > $ cat /dfs/dynamic_debug/control | wc -l > 2488 > > > mainline x86_64 defconfig+CONFIG_DYNAMIC_DEBUG+this patch series > $ cat /dfs/dynamic_debug/control | wc -l > 2486 > > (seems like maybe 2 are missing? Let me try to collect a diff. Maybe > 2 were removed in this series?) Hm, no pr_debugs should have been added or removed. Perhaps you have a slightly different set of modules loaded? Otherwise there's something odd going on, and a diff would be really nice. It's possible that the order of the lines are different, so you may have to sort them to get a meaningful diff. (A diff is nice extra sanity check even if the line count matches, of course). >> and that enabling/disabling various pr_debug()s by writing to the >> control file takes effect. I should only be changing the format for > > Can you suggest one that's easy to test? The ones in lib/kobject.c are triggered fairly often I think. Thanks, Rasmus
Re: linux-next: build failure after merge of the tip tree
Hi Kalle, On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo wrote: > > Thanks for the report. Any suggestions how to handle this? Or do we let > Linus take care of this? Just let Linus take care of it ... mention it in the pull request ... I guess DaveM needs to know, right? -- Cheers, Stephen Rothwell pgparBFJiBu2s.pgp Description: OpenPGP digital signature
[PATCH] [PATCH v1] ARM: dts: aspeed: Adding Lenovo Hr855xg2 BMC
Initial introduction of Lenovo Hr855xg2 family equipped with
Aspeed 2500 BMC SoC. Hr855xg2 is a x86 server development kit
with a ASPEED ast2500 BMC manufactured by Lenovo.
Specifically, This adds the Hr855xg2 platform device tree file
used by the Hr855xg2 BMC machines.
This also adds an entry of Hr855xg2 device tree file in Makefile
Signed-off-by: Andrew Peng
Signed-off-by: Yonghui Liu
Signed-off-by: Lisa Liu
Signed-off-by: Harry Sung
Signed-off-by: Derek Lin
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/aspeed-bmc-lenovo-hr855xg2.dts | 687 +++
2 files changed, 688 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed-bmc-lenovo-hr855xg2.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index dab2914f..d874777 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1269,6 +1269,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-facebook-cmm.dtb \
aspeed-bmc-facebook-tiogapass.dtb \
aspeed-bmc-intel-s2600wf.dtb \
+ aspeed-bmc-lenovo-hr855xg2.dtb \
aspeed-bmc-opp-lanyang.dtb \
aspeed-bmc-opp-palmetto.dtb \
aspeed-bmc-opp-romulus.dtb \
diff --git a/arch/arm/boot/dts/aspeed-bmc-lenovo-hr855xg2.dts
b/arch/arm/boot/dts/aspeed-bmc-lenovo-hr855xg2.dts
new file mode 100644
index 000..d8dbf3a
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-lenovo-hr855xg2.dts
@@ -0,0 +1,687 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Device Tree file for Lenovo Hr855xg2 platform
+ *
+ * Copyright (C) 2019-present Lenovo
+ */
+
+/dts-v1/;
+
+#include "aspeed-g5.dtsi"
+#include
+
+/ {
+ model = "HR855XG2 BMC";
+ compatible = "lenovo,hr855xg2-bmc", "aspeed,ast2500";
+
+ aliases {
+ i2c14 = _riser1;
+ i2c15 = _riser2;
+ i2c16 = _riser3;
+ i2c17 = _M2;
+ i2c18 = _0;
+ i2c19 = _1;
+ i2c20 = _2;
+ i2c21 = _3;
+ };
+
+ chosen {
+ stdout-path =
+ bootargs = "console=tty0 console=ttyS4,115200 earlyprintk";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x8000 0x2000>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ flash_memory: region@9800 {
+ no-map;
+ reg = <0x9800 0x0010>; /* 1M */
+ };
+
+ gfx_memory: framebuffer {
+ size = <0x0100>;
+ alignment = <0x0100>;
+ compatible = "shared-dma-pool";
+ reusable;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ heartbeat {
+ gpios = < ASPEED_GPIO(C, 7) GPIO_ACTIVE_LOW>;
+ };
+
+ fault {
+ gpios = < ASPEED_GPIO(G, 3) GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = < 0>, < 1>, < 2>, < 3>,
+ < 4>, < 5>, < 6>, < 7>,
+ < 8>, < 9>, < 10>,< 11>,
+ < 12>,< 13>,< 14>;
+ };
+
+ iio-hwmon-battery {
+ compatible = "iio-hwmon";
+ io-channels = < 15>;
+ };
+
+};
+
+ {
+ status = "okay";
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bmc";
+ spi-max-frequency = <5000>;
+#include "openbmc-flash-layout.dtsi"
+ };
+};
+
+_ctrl {
+ status = "okay";
+ memory-region = <_memory>;
+ flash = <>;
+};
+
+_snoop {
+ status = "okay";
+ snoop-ports = <0x80>;
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_txd1_default
+ _rxd1_default>;
+};
+
+ {
+ /* Rear RS-232 connector */
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_txd2_default
+ _rxd2_default
+ _nrts2_default
+ _ndtr2_default
+ _ndsr2_default
+ _ncts2_default
+ _ndcd2_default
+ _nri2_default>;
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_rmii1_default>;
+ use-ncsi;
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_rgmii2_default _mdio2_default>;
+};
+
+{
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_adc0_default
+ _adc1_default
+
[PATCH net-next] net: ipvlan: forward ingress packet to slave's l2 in l3s mode
In ipvlan l3s mode, ingress packet is switched to slave interface and
delivers to l4 stack. This may cause two problems:
1. When slave is in an ns different from master, the behavior of stack
in slave ns may cause confusion for users. For example, iptables, tc,
and other l2/l3 functions are not available for ingress packet.
2. l3s mode is not used for tap device, and cannot support ipvtap. But
in VM or container based VM cases, tap device is a very common device.
In l3s mode's input nf_hook, this patch calles the skb_forward_dev() to
forward ingress packet to slave and uses nf_conntrack_confirm() to make
conntrack work with new mode.
Signed-off-by: Zha Bin
Signed-off-by: Zhiyuan Hou
---
drivers/net/ipvlan/ipvlan.h | 9 -
drivers/net/ipvlan/ipvlan_l3s.c | 16 ++--
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ipvlan/ipvlan.h b/drivers/net/ipvlan/ipvlan.h
index 3837c897832e..48c814e24c3f 100644
--- a/drivers/net/ipvlan/ipvlan.h
+++ b/drivers/net/ipvlan/ipvlan.h
@@ -172,6 +172,14 @@ void ipvlan_link_delete(struct net_device *dev, struct
list_head *head);
void ipvlan_link_setup(struct net_device *dev);
int ipvlan_link_register(struct rtnl_link_ops *ops);
#ifdef CONFIG_IPVLAN_L3S
+
+#include
+
+static inline int ipvlan_confirm_conntrack(struct sk_buff *skb)
+{
+ return nf_conntrack_confirm(skb);
+}
+
int ipvlan_l3s_register(struct ipvl_port *port);
void ipvlan_l3s_unregister(struct ipvl_port *port);
void ipvlan_migrate_l3s_hook(struct net *oldnet, struct net *newnet);
@@ -206,5 +214,4 @@ static inline bool netif_is_ipvlan_port(const struct
net_device *dev)
{
return rcu_access_pointer(dev->rx_handler) == ipvlan_handle_frame;
}
-
#endif /* __IPVLAN_H */
diff --git a/drivers/net/ipvlan/ipvlan_l3s.c b/drivers/net/ipvlan/ipvlan_l3s.c
index 943d26cbf39f..ed210002f593 100644
--- a/drivers/net/ipvlan/ipvlan_l3s.c
+++ b/drivers/net/ipvlan/ipvlan_l3s.c
@@ -95,14 +95,26 @@ static unsigned int ipvlan_nf_input(void *priv, struct
sk_buff *skb,
{
struct ipvl_addr *addr;
unsigned int len;
+ int ret = NF_ACCEPT;
+ bool success;
addr = ipvlan_skb_to_addr(skb, skb->dev);
if (!addr)
goto out;
- skb->dev = addr->master->dev;
len = skb->len + ETH_HLEN;
- ipvlan_count_rx(addr->master, len, true, false);
+
+ ret = ipvlan_confirm_conntrack(skb);
+ if (ret != NF_ACCEPT) {
+ ipvlan_count_rx(addr->master, len, false, false);
+ goto out;
+ }
+
+ skb_push_rcsum(skb, ETH_HLEN);
+ success = dev_forward_skb(addr->master->dev, skb) == NET_RX_SUCCESS;
+ ipvlan_count_rx(addr->master, len, success, false);
+ return NF_STOLEN;
+
out:
return NF_ACCEPT;
}
--
2.18.0
Re: [PATCH] dt-bindings: mfd: Add link to ROHM BD71847 Datasheet
On Thu, 13 Jun 2019, Matti Vaittinen wrote: > ROHM BD71847 PMIC datasheet was published. > Add datasheet link for BD71847 as well. > > Signed-off-by: Matti Vaittinen > --- > Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt | 2 ++ > 1 file changed, 2 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation
On (06/19/19 00:12), John Ogness wrote:
> On 2019-06-18, Sergey Senozhatsky wrote:
> >> + struct prb_reserved_entry e;
> >> + char *s;
> >> +
> >> + s = prb_reserve(, , 32);
> >> + if (s) {
> >> + sprintf(s, "Hello, world!");
> >> + prb_commit();
> >> + }
> >
> > A nit: snprintf().
> >
> > sprintf() is tricky, it may write "slightly more than was
> > anticipated" bytes - all those string_nocheck(" disabled"),
> > error_string("pK-error"), etc.
>
> Agreed. Documentation should show good examples.
In vprintk_emit(), are we going to always reserve 1024-byte
records, since we don't know the size in advance, e.g.
printk("%pS %s\n", regs->ip, current->name)
prb_reserve(, , );
or are we going to run vscnprintf() on a NULL buffer first,
then reserve the exactly required number of bytes and afterwards
vscnprintf(s) -> prb_commit()?
-ss
Re: linux-next: build failure after merge of the tip tree
Stephen Rothwell writes: > On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo wrote: >> >> Thanks for the report. Any suggestions how to handle this? Or do we let >> Linus take care of this? > > Just let Linus take care of it ... mention it in the pull request ... Thanks, I'll do that. > I guess DaveM needs to know, right? Yeah, this commit goes from wireless-drivers-next to net-next and from there to Linus. I'll inform Dave in my pull request. -- Kalle Valo
[PATCH v2] fixdep: check return value of printf() and putchar()
When there is not enough space on your storage device, the build will
fail with 'No space left on device' error message.
The reason is obvious from the message, so you will free up some disk
space, then you will resume the build.
However, sometimes you may still see a mysterious error message:
unterminated call to function 'wildcard': missing ')'.
If you run out of the disk space, fixdep may end up with generating
incomplete .*.cmd files.
For example, if the disk shortage occurs while fixdep is running
print_dep(), the .*.cmd might be truncated like this:
$(wildcard include/config/
When you run 'make' next time, this broken .*.cmd will be included,
then GNU Make will terminate parsing since it is a wrong syntax.
Once this happens, you need to run 'make clean' or delete the broken
.*.cmd file manually.
Even if you do not see any error message, the .*.cmd files after any
error could be potentially incomplete, and unreliable. You may miss
the re-compilation due to missing header dependency.
If printf() cannot output the string for disk shortage or whatever
reason, it returns a negative value, but currently fixdep does not
check it at all. Consequently, fixdep *successfully* generates a
broken .*.cmd file. Make never notices that since fixdep exits with 0,
which means success.
Given the intended usage of fixdep, it must respect the return value
of not only malloc(), but also printf() and putchar().
This seems a long-standing issue since the introduction of fixdep.
In old days, Kbuild tried to provide an extra safety by letting fixdep
output to a temporary file and renaming it after everything is done:
scripts/basic/fixdep $(depfile) $@ '$(make-cmd)' > $(dot-target).tmp;\
rm -f $(depfile);\
mv -f $(dot-target).tmp $(dot-target).cmd)
It did not avoid the current issue; fixdep created a truncated tmp file
reporting success, so the broken tmp would be renamed to a .*.cmd file.
By propagating the error code to the build system, this problem should
be solved because:
[1] Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special
target"), Make will delete the target automatically on any failure
in the recipe.
[2] Since commit 392885ee82d3 ("kbuild: let fixdep directly write to
.*.cmd files"), .*.cmd file is included only when the corresponding
target already exists.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Add prror()
scripts/basic/fixdep.c | 51 +-
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index facbd603adf6..4ac973f2dc8c 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -99,6 +99,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -109,6 +110,36 @@ static void usage(void)
exit(1);
}
+/*
+ * In the intended usage of this program, the stdout is redirected to .*.cmd
+ * The return value of printf() and putchar() must be checked to catch any
+ * error like "No space left on device".
+ */
+static void xprintf(const char *format, ...)
+{
+ va_list ap;
+ int ret;
+
+ va_start(ap, format);
+ ret = vprintf(format, ap);
+ if (ret < 0) {
+ perror("fixdep");
+ exit(1);
+ }
+ va_end(ap);
+}
+
+static void xputchar(int c)
+{
+ int ret;
+
+ ret = putchar(c);
+ if (ret == EOF) {
+ perror("fixdep");
+ exit(1);
+ }
+}
+
/*
* Print out a dependency path from a symbol name
*/
@@ -116,7 +147,7 @@ static void print_dep(const char *m, int slen, const char
*dir)
{
int c, prev_c = '/', i;
- printf("$(wildcard %s/", dir);
+ xprintf("$(wildcard %s/", dir);
for (i = 0; i < slen; i++) {
c = m[i];
if (c == '_')
@@ -124,10 +155,10 @@ static void print_dep(const char *m, int slen, const char
*dir)
else
c = tolower(c);
if (c != '/' || prev_c != '/')
- putchar(c);
+ xputchar(c);
prev_c = c;
}
- printf(".h) \\\n");
+ xprintf(".h) \\\n");
}
struct item {
@@ -324,13 +355,13 @@ static void parse_dep_file(char *m, const char *target)
*/
if (!saw_any_target) {
saw_any_target = 1;
- printf("source_%s := %s\n\n",
- target, m);
- printf("deps_%s := \\\n", target);
+ xprintf("source_%s := %s\n\n",
+ target, m);
+ xprintf("deps_%s := \\\n", target);
}
Re: linux-next: build failure after merge of the tip tree
On Tue, 25 Jun 2019, Stephen Rothwell wrote: > Hi Kalle, > > On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo wrote: > > > > Thanks for the report. Any suggestions how to handle this? Or do we let > > Linus take care of this? > > Just let Linus take care of it ... mention it in the pull request ... I > guess DaveM needs to know, right? Ah. I didn't realize that this is a new commit in Kalle's tree. So yes that's the right thing to do. Thanks, tglx
[tip:timers/core] timekeeping: Boot should be boottime for coarse ns accessor
Commit-ID: d48e0cd8fcaf314175a15d3076d7a1e71bd4e628
Gitweb: https://git.kernel.org/tip/d48e0cd8fcaf314175a15d3076d7a1e71bd4e628
Author: Jason A. Donenfeld
AuthorDate: Mon, 24 Jun 2019 11:15:39 +0200
Committer: Thomas Gleixner
CommitDate: Tue, 25 Jun 2019 08:54:51 +0200
timekeeping: Boot should be boottime for coarse ns accessor
Somewhere in all the patchsets before, this cleanup got lost.
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Thomas Gleixner
Cc: Arnd Bergmann
Link: https://lkml.kernel.org/r/20190624091539.13512-1-ja...@zx2c4.com
---
Documentation/core-api/timekeeping.rst | 2 +-
include/linux/timekeeping.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/core-api/timekeeping.rst
b/Documentation/core-api/timekeeping.rst
index 15fc58e85ef9..20ee447a50f3 100644
--- a/Documentation/core-api/timekeeping.rst
+++ b/Documentation/core-api/timekeeping.rst
@@ -105,7 +105,7 @@ Some additional variants exist for more specialized cases:
ktime_t ktime_get_coarse_clocktai( void )
.. c:function:: u64 ktime_get_coarse_ns( void )
- u64 ktime_get_coarse_boot_ns( void )
+ u64 ktime_get_coarse_boottime_ns( void )
u64 ktime_get_coarse_real_ns( void )
u64 ktime_get_coarse_clocktai_ns( void )
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index dcffc00755f2..b27e2ffa96c1 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -131,7 +131,7 @@ static inline u64 ktime_get_coarse_real_ns(void)
return ktime_to_ns(ktime_get_coarse_real());
}
-static inline u64 ktime_get_coarse_boot_ns(void)
+static inline u64 ktime_get_coarse_boottime_ns(void)
{
return ktime_to_ns(ktime_get_coarse_boottime());
}
[PATCH 2/2] clk: imx8mm: GPT1 clock mux option #5 should be sys_pll1_80m
From: Anson Huang
i.MX8MM's GPT1 clock mux option #5 should be sys_pll1_80m,
NOT sys_pll1_800m, correct it.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx8mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 516e68d..d1a84f7 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -293,7 +293,7 @@ static const char *imx8mm_pwm4_sels[] = {"osc_24m",
"sys_pll2_100m", "sys_pll1_1
"sys_pll3_out", "clk_ext2",
"sys_pll1_80m", "video_pll1_out", };
static const char *imx8mm_gpt1_sels[] = {"osc_24m", "sys_pll2_100m",
"sys_pll1_400m", "sys_pll1_40m",
-"video_pll1_out", "sys_pll1_800m",
"audio_pll1_out", "clk_ext1" };
+"video_pll1_out", "sys_pll1_80m",
"audio_pll1_out", "clk_ext1" };
static const char *imx8mm_wdog_sels[] = {"osc_24m", "sys_pll1_133m",
"sys_pll1_160m", "vpu_pll_out",
"sys_pll2_125m", "sys_pll3_out",
"sys_pll1_80m", "sys_pll2_166m", };
--
2.7.4
[PATCH 1/2] clk: imx8mm: Fix typo of pwm3 clock's mux option #4
From: Anson Huang
i.MX8MM has no sys3_pll2_out clock, PWM3 clock's mux option #4
should be sys_pll3_out, sys3_pll2_out is a typo, fix it.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx8mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 56d53dd..516e68d 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -287,7 +287,7 @@ static const char *imx8mm_pwm2_sels[] = {"osc_24m",
"sys_pll2_100m", "sys_pll1_1
"sys_pll3_out", "clk_ext1",
"sys_pll1_80m", "video_pll1_out", };
static const char *imx8mm_pwm3_sels[] = {"osc_24m", "sys_pll2_100m",
"sys_pll1_160m", "sys_pll1_40m",
-"sys3_pll2_out", "clk_ext2",
"sys_pll1_80m", "video_pll1_out", };
+"sys_pll3_out", "clk_ext2",
"sys_pll1_80m", "video_pll1_out", };
static const char *imx8mm_pwm4_sels[] = {"osc_24m", "sys_pll2_100m",
"sys_pll1_160m", "sys_pll1_40m",
"sys_pll3_out", "clk_ext2",
"sys_pll1_80m", "video_pll1_out", };
--
2.7.4
Re: [RESEND PATCH v2] mtd: spinand: read return badly if the last page has bitflips
Hi liaoweixiong,
On 25.06.19 05:08, Greg KH wrote:
> On Tue, Jun 25, 2019 at 09:02:29AM +0800, liaoweixiong wrote:
>> In case of the last page containing bitflips (ret > 0),
>> spinand_mtd_read() will return that number of bitflips for the last
>> page. But to me it looks like it should instead return max_bitflips like
>> it does when the last page read returns with 0.
>>
>> Signed-off-by: liaoweixiong
>> Reviewed-by: Boris Brezillon
>> Reviewed-by: Frieder Schrempf
>> Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI
>> NANDs")
>> ---
>> drivers/mtd/nand/spi/core.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> for how to do this properly.
>
>
FYI, you should not send the patch to sta...@vger.kernel.org, but
instead, as I said in my other reply, add the tag "Cc:
sta...@vger.kernel.org". See "Option 1" in the document Greg referred to.
Thanks,
Frieder
Recall: [PATCH 2/2] clk: imx8mm: GPT1 clock mux option #5 should be sys_pll1_80m
Jacky Bai would like to recall the message, "[PATCH 2/2] clk: imx8mm: GPT1 clock mux option #5 should be sys_pll1_80m".
RE: [PATCH 2/2] clk: imx8mm: GPT1 clock mux option #5 should be sys_pll1_80m
OK for me.
BR
Jacky Bai
> -Original Message-
> From: anson.hu...@nxp.com [mailto:anson.hu...@nxp.com]
> Sent: Tuesday, June 25, 2019 3:06 PM
> To: mturque...@baylibre.com; sb...@kernel.org; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> Leonard Crestez ; Jacky Bai ;
> Peng Fan ; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Cc: dl-linux-imx
> Subject: [PATCH 2/2] clk: imx8mm: GPT1 clock mux option #5 should be
> sys_pll1_80m
>
> From: Anson Huang
>
> i.MX8MM's GPT1 clock mux option #5 should be sys_pll1_80m, NOT
> sys_pll1_800m, correct it.
>
> Signed-off-by: Anson Huang
> ---
> drivers/clk/imx/clk-imx8mm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
> index 516e68d..d1a84f7 100644
> --- a/drivers/clk/imx/clk-imx8mm.c
> +++ b/drivers/clk/imx/clk-imx8mm.c
> @@ -293,7 +293,7 @@ static const char *imx8mm_pwm4_sels[] =
> {"osc_24m", "sys_pll2_100m", "sys_pll1_1
>"sys_pll3_out", "clk_ext2",
> "sys_pll1_80m",
> "video_pll1_out", };
>
> static const char *imx8mm_gpt1_sels[] = {"osc_24m", "sys_pll2_100m",
> "sys_pll1_400m", "sys_pll1_40m",
> - "video_pll1_out", "sys_pll1_800m",
> "audio_pll1_out", "clk_ext1" };
> + "video_pll1_out", "sys_pll1_80m",
> "audio_pll1_out",
> "clk_ext1" };
>
> static const char *imx8mm_wdog_sels[] = {"osc_24m", "sys_pll1_133m",
> "sys_pll1_160m", "vpu_pll_out",
>"sys_pll2_125m", "sys_pll3_out",
> "sys_pll1_80m",
> "sys_pll2_166m", };
> --
> 2.7.4
RE: [PATCH v4 1/6] dmaengine: fsl-edma: add drvdata for fsl-edma
Okay, will correct it and send v5 after rebase. >On 25-06-19, 16:17, Vinod Koul wrote: > On 14-06-19, 16:17, yibin.g...@nxp.com wrote: > > From: Robin Gong > > > > There are some differences between vf610 and next i.mx7ulp. Put such > > differences into static driver data for distiguish easily at driver > > Typo distiguish > > Though I tried to apply 1-5 it doesnt apply for me, can you rebase and resend > > Thanks > > -- > ~Vinod
Re: [PATCH] nvme-pci: Avoid leak if pci_p2pmem_virt_to_bus() returns null
On Mon, Jun 24, 2019 at 04:57:22PM -0700, Alan Mikhak wrote:
> Modify nvme_alloc_sq_cmds() to call pci_free_p2pmem()
> to free the memory it allocated using pci_alloc_p2pmem()
> in case pci_p2pmem_virt_to_bus() returns null.
>
> Make sure not to call pci_free_p2pmem() if pci_alloc_p2pmem()
> returned null which can happen if CONFIG_PCI_P2PDMA is not
> configured.
Can you
>
> Signed-off-by: Alan Mikhak
> ---
> drivers/nvme/host/pci.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index 524d6bd6d095..5dfa067f6506 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -1456,11 +1456,15 @@ static int nvme_alloc_sq_cmds(struct nvme_dev *dev,
> struct nvme_queue *nvmeq,
>
> if (qid && dev->cmb_use_sqes && (dev->cmbsz & NVME_CMBSZ_SQS)) {
> nvmeq->sq_cmds = pci_alloc_p2pmem(pdev, SQ_SIZE(depth));
> - nvmeq->sq_dma_addr = pci_p2pmem_virt_to_bus(pdev,
> - nvmeq->sq_cmds);
> - if (nvmeq->sq_dma_addr) {
> - set_bit(NVMEQ_SQ_CMB, >flags);
> - return 0;
> + if (nvmeq->sq_cmds) {
> + nvmeq->sq_dma_addr = pci_p2pmem_virt_to_bus(pdev,
> + nvmeq->sq_cmds);
> + if (nvmeq->sq_dma_addr) {
> + set_bit(NVMEQ_SQ_CMB, >flags);
> + return 0;
> + }
> +
> + pci_free_p2pmem(pdev, nvmeq->sq_cmds, SQ_SIZE(depth));
pci_p2pmem_virt_to_bus should only fail when
pci_p2pmem_virt_to_bus failed. That being said I think doing the
error check on pci_alloc_p2pmem instead of relying on
pci_p2pmem_virt_to_bus "passing through" the error seems odd, I'd
rather check the pci_alloc_p2pmem return value directly.
Re: [PATCH] drivers: Adjust scope for CONFIG_HAS_IOMEM before devm_platform_ioremap_resource()
pon., 24 cze 2019 o 20:22 Enrico Weigelt, metux IT consult napisał(a): > > On 24.06.19 12:46, Bartosz Golaszewski wrote: > > >> The patch seems pretty trivial and doesn't change any actual code, so > >> I don't see hard resons for rejecting it. > >> > > > > In its current form it makes the code even less readable. The #ifdef > > should actually be one line lower and touch the comment instead of the > > EXPORT_SYMBOL() related to a different function. > > Okay, that missing newline should be fixed (as well as the extra one > after the #ifdef). Besides that, I don't see any further problems. > Are we sure this even changes something? Does kernel documentation get generated according to current config options? I really think this patch just pollutes the history for now apparent reason. Greg, could you give your opinion on this? Bart
RE: [PATCH] dmaengine: imx-sdma: fix use-after-free on probe error path
Reviewed-by: Robin Gong
> -Original Message-
> From: Sven Van Asbroeck
> Subject: [PATCH] dmaengine: imx-sdma: fix use-after-free on probe error path
>
> If probe() fails anywhere beyond the point where
> sdma_get_firmware() is called, then a kernel oops may occur.
>
> Problematic sequence of events:
> 1. probe() calls sdma_get_firmware(), which schedules the
>firmware callback to run when firmware becomes available,
>using the sdma instance structure as the context 2. probe() encounters an
> error, which deallocates the
>sdma instance structure
> 3. firmware becomes available, firmware callback is
>called with deallocated sdma instance structure 4. use after free - kernel
> oops !
>
> Solution: only attempt to load firmware when we're certain that probe() will
> succeed. This guarantees that the firmware callback's context will remain
> valid.
>
> Note that the remove() path is unaffected by this issue: the firmware loader
> will
> increment the driver module's use count, ensuring that the module cannot be
> unloaded while the firmware callback is pending or running.
>
> To: Robin Gong
> Cc: Vinod Koul
> Cc: Dan Williams
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
> Cc: Fabio Estevam
> Cc: NXP Linux Team
> Cc: dmaeng...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Sven Van Asbroeck
> ---
> drivers/dma/imx-sdma.c | 48 --
> 1 file changed, 27 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index
> 99d9f431ae2c..3f0f41d16e1c 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -2096,27 +2096,6 @@ static int sdma_probe(struct platform_device
> *pdev)
> if (pdata && pdata->script_addrs)
> sdma_add_scripts(sdma, pdata->script_addrs);
>
> - if (pdata) {
> - ret = sdma_get_firmware(sdma, pdata->fw_name);
> - if (ret)
> - dev_warn(>dev, "failed to get firmware from
> platform
> data\n");
> - } else {
> - /*
> - * Because that device tree does not encode ROM script address,
> - * the RAM script in firmware is mandatory for device tree
> - * probe, otherwise it fails.
> - */
> - ret = of_property_read_string(np, "fsl,sdma-ram-script-name",
> - _name);
> - if (ret)
> - dev_warn(>dev, "failed to get firmware name\n");
> - else {
> - ret = sdma_get_firmware(sdma, fw_name);
> - if (ret)
> - dev_warn(>dev, "failed to get firmware
> from device
> tree\n");
> - }
> - }
> -
> sdma->dma_device.dev = >dev;
>
> sdma->dma_device.device_alloc_chan_resources =
> sdma_alloc_chan_resources; @@ -2161,6 +2140,33 @@ static int
> sdma_probe(struct platform_device *pdev)
> of_node_put(spba_bus);
> }
>
> + /*
> + * Kick off firmware loading as the very last step:
> + * attempt to load firmware only if we're not on the error path, because
> + * the firmware callback requires a fully functional and allocated sdma
> + * instance.
> + */
> + if (pdata) {
> + ret = sdma_get_firmware(sdma, pdata->fw_name);
> + if (ret)
> + dev_warn(>dev, "failed to get firmware from
> platform
> data\n");
> + } else {
> + /*
> + * Because that device tree does not encode ROM script address,
> + * the RAM script in firmware is mandatory for device tree
> + * probe, otherwise it fails.
> + */
> + ret = of_property_read_string(np, "fsl,sdma-ram-script-name",
> + _name);
> + if (ret)
> + dev_warn(>dev, "failed to get firmware name\n");
> + else {
> + ret = sdma_get_firmware(sdma, fw_name);
> + if (ret)
> + dev_warn(>dev, "failed to get firmware
> from device
> tree\n");
> + }
> + }
> +
> return 0;
>
> err_register:
> --
> 2.17.1
Re: [RFC PATCH v2 1/2] printk-rb: add a new printk ringbuffer implementation
On (06/25/19 15:45), Sergey Senozhatsky wrote:
> On (06/19/19 00:12), John Ogness wrote:
> > On 2019-06-18, Sergey Senozhatsky wrote:
> > >> +struct prb_reserved_entry e;
> > >> +char *s;
> > >> +
> > >> +s = prb_reserve(, , 32);
> > >> +if (s) {
> > >> +sprintf(s, "Hello, world!");
> > >> +prb_commit();
> > >> +}
> > >
> > > A nit: snprintf().
> > >
> > > sprintf() is tricky, it may write "slightly more than was
> > > anticipated" bytes - all those string_nocheck(" disabled"),
> > > error_string("pK-error"), etc.
> >
> > Agreed. Documentation should show good examples.
>
> In vprintk_emit(), are we going to always reserve 1024-byte
> records, since we don't know the size in advance, e.g.
>
> printk("%pS %s\n", regs->ip, current->name)
> prb_reserve(, , );
>
> or are we going to run vscnprintf() on a NULL buffer first,
> then reserve the exactly required number of bytes and afterwards
> vscnprintf(s) -> prb_commit()?
I'm asking this because, well, if the most common usage
pattern (printk->prb_reserve) will always reserve fixed
size records (aka data blocks), then you _probably_ (??)
can drop the 'variable size records' requirement from prb
design and start looking at records (aka data blocks) as
fixed sized chunks of bytes, which are always located at
fixed offsets.
-ss
Re: [PATCH v2 1/1] staging: media: fix style problem
Hi Aliasgar,
Please state the driver in question in the Subject. So:
[PATCHv2] staging/media/davinci_vpfe: fix style problems
That way it is clear to reviewers which driver is modified.
Also there is no need for '1/1' if there is only one patch.
Regards,
Hans
On 6/21/19 6:34 AM, Aliasgar Surti wrote:
> From: Aliasgar Surti
>
> checkpatch reported "WARNING: line over 80 characters".
> This patch fixes the warning for file davinci_vpfe/dm365_isif.c
>
> Signed-off-by: Aliasgar Surti
> ---
> Changes in v2:
> - Fixed styling as per suggestion in comments
>
> drivers/staging/media/davinci_vpfe/dm365_isif.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/davinci_vpfe/dm365_isif.c
> b/drivers/staging/media/davinci_vpfe/dm365_isif.c
> index 46fd818..e9c8de1 100644
> --- a/drivers/staging/media/davinci_vpfe/dm365_isif.c
> +++ b/drivers/staging/media/davinci_vpfe/dm365_isif.c
> @@ -532,7 +532,8 @@ static int isif_validate_dfc_params(const struct
> vpfe_isif_dfc *dfc)
> #define DM365_ISIF_MAX_CLVSV 0x1fff
> #define DM365_ISIF_MAX_HEIGHT_BLACK_REGION 0x1fff
>
> -static int isif_validate_bclamp_params(const struct vpfe_isif_black_clamp
> *bclamp)
> +static int
> +isif_validate_bclamp_params(const struct vpfe_isif_black_clamp *bclamp)
> {
> int err = -EINVAL;
>
> @@ -593,7 +594,8 @@ isif_validate_raw_params(const struct
> vpfe_isif_raw_config *params)
> return isif_validate_bclamp_params(>bclamp);
> }
>
> -static int isif_set_params(struct v4l2_subdev *sd, const struct
> vpfe_isif_raw_config *params)
> +static int isif_set_params(struct v4l2_subdev *sd,
> +const struct vpfe_isif_raw_config *params)
> {
> struct vpfe_isif_device *isif = v4l2_get_subdevdata(sd);
> int ret = -EINVAL;
>
Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs
On Mon, Jun 24, 2019 at 03:53:04PM -0500, Gustavo A. R. Silva wrote: > Once the C++17 `__attribute__((fallthrough))` is more widely handled by C > compilers, >From what I read that attribute landed in the exact same GCC version as the warning. And last I checked clang wasn't there yet anyway. > static analyzers, and IDEs, we can switch to using that instead. Also, we are > a few I don't give a crap about lousy IDEs. And coverity already supports the attribute and other checkers are open-source and can be easily fixed or ignored. > warnings away (less than five) from being able to enable > -Wimplicit-fallthrough. After > this option has been finally enabled (in v5.3) we can easily go and replace > the comments > to whatever we agree upon. Feh. Still an abomination.
Re: [PATCH 1/1] staging: media: fix style problem
On 6/21/19 8:39 AM, Aliasgar Surti wrote:
> From: Aliasgar Surti
>
> checkpatch reported "WARNING: line over 80 characters".
> This patch fixes the warning for file soc_camera/soc_ov5642.c
FYI: we're not accepting patches for staging/media/soc_camera: these
are obsolete and broken drivers.
Regards,
Hans
>
> Signed-off-by: Aliasgar Surti
> ---
> drivers/staging/media/soc_camera/soc_ov5642.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/soc_camera/soc_ov5642.c
> b/drivers/staging/media/soc_camera/soc_ov5642.c
> index 94696d7..39ae24dc 100644
> --- a/drivers/staging/media/soc_camera/soc_ov5642.c
> +++ b/drivers/staging/media/soc_camera/soc_ov5642.c
> @@ -687,7 +687,8 @@ static int reg_write16(struct i2c_client *client, u16
> reg, u16 val16)
> }
>
> #ifdef CONFIG_VIDEO_ADV_DEBUG
> -static int ov5642_get_register(struct v4l2_subdev *sd, struct
> v4l2_dbg_register *reg)
> +static int ov5642_get_register(struct v4l2_subdev *sd,
> +struct v4l2_dbg_register *reg)
> {
> struct i2c_client *client = v4l2_get_subdevdata(sd);
> int ret;
> @@ -705,7 +706,8 @@ static int ov5642_get_register(struct v4l2_subdev *sd,
> struct v4l2_dbg_register
> return ret;
> }
>
> -static int ov5642_set_register(struct v4l2_subdev *sd, const struct
> v4l2_dbg_register *reg)
> +static int ov5642_set_register(struct v4l2_subdev *sd,
> +const struct v4l2_dbg_register *reg)
> {
> struct i2c_client *client = v4l2_get_subdevdata(sd);
>
>
Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs
On Tue, Jun 25, 2019 at 12:28:23AM +0200, Miguel Ojeda wrote: > On Mon, Jun 24, 2019 at 10:53 PM Gustavo A. R. Silva > wrote: > > > > Once the C++17 `__attribute__((fallthrough))` is more widely handled by C > > compilers, > > static analyzers, and IDEs, we can switch to using that instead. Also, we > > are a few > > warnings away (less than five) from being able to enable > > -Wimplicit-fallthrough. After > > this option has been finally enabled (in v5.3) we can easily go and replace > > the comments > > to whatever we agree upon. > > Indeed -- the decision last year was to wait for a while since not > everyone had support for it. My branch is waiting here: > > https://github.com/ojeda/linux/tree/compiler-attributes-fallthrough > > The good news is that there is some progress. For instance, LLVM is > working on supporting the GNU spelling: > > https://reviews.llvm.org/D63260 > https://bugs.llvm.org/show_bug.cgi?id=37135 > https://github.com/ClangBuiltLinux/linux/issues/235 Can it build a kernel without patches yet? That is, why should I care what LLVM does? > Also note that C2x may get [[fallthrough]]. See N2267 and N2335. At > that point, surely tools/IDEs/analyzers will support it :-) The > question is whether we want to wait that long to replace the comments. #define __fallthrough [[fallthrough]] right?
Re: [RFC PATCH 00/28] Removing struct page from P2PDMA
On Mon, Jun 24, 2019 at 10:10:16AM -0600, Logan Gunthorpe wrote: > Yes, that's correct. The intent was to invert it so the dma_map could > happen at the start of the process so that P2PDMA code could be called > with all the information it needs to make it's decision on how to map; > without having to hook into the mapping process of every driver that > wants to participate. And that just isn't how things work in layering. We need to keep generating the dma addresses in the driver in the receiving end, as there are all kinds of interesting ideas how we do that. E.g. for the Mellanox NICs addressing their own bars is not done by PCIe bus addresses but by relative offsets. And while NVMe has refused to go down that route in the current band aid fix for CMB addressing I suspect it will sooner or later have to do the same to deal with the addressing problems in a multiple PASID world.
Re: [PATCH] perf/x86/intel: Mark expected switch fall-throughs
On Mon, Jun 24, 2019 at 01:57:49PM -0700, Joe Perches wrote: > > Once the C++17 `__attribute__((fallthrough))` is more widely handled by C > > compilers, > I doubt waiting is better. > If the latest compilers catch it, it's > probably good enough. Yeah, I don't see the point either; GCC does it, and that's all I really care about.
Re: [RFC PATCH 00/28] Removing struct page from P2PDMA
On Mon, Jun 24, 2019 at 10:07:56AM -0600, Logan Gunthorpe wrote: > > For one passing a dma_addr_t through the block layer is a layering > > violation, and one that I think will also bite us in practice. > > The host physical to PCIe bus address mapping can have offsets, and > > those offsets absolutely can be different for differnet root ports. > > So with your caller generated dma_addr_t everything works fine with > > a switched setup as the one you are probably testing on, but on a > > sufficiently complicated setup with multiple root ports it can break. > > I don't follow this argument. Yes, I understand PCI Bus offsets and yes > I understand that they only apply beyond the bus they're working with. > But this isn't *that* complicated and it should be the responsibility of > the P2PDMA code to sort out and provide a dma_addr_t for. The dma_addr_t > that's passed through the block layer could be a bus address or it could > be the result of a dma_map_* request (if the transaction is found to go > through an RC) depending on the requirements of the devices being used. You assume all addressing is done by the PCI bus address. If a device is addressing its own BAR there is no reason to use the PCI bus address, as it might have much more intelligent schemes (usually bar + offset). > > > Also duplicating the whole block I/O stack, including hooks all over > > the fast path is pretty much a no-go. > > There was very little duplicate code in the patch set. (Really just the > mapping code). There are a few hooks, but in practice not that many if > we ignore the WARN_ONs. We might be able to work to reduce this further. > The main hooks are: when we skip bouncing, when we skip integrity prep, > when we split, and when we map. And the patchset drops the PCI_P2PDMA > hook when we map. So we're talking about maybe three or four extra ifs > that would likely normally be fast due to the branch predictor. And all of those add code to the block layer fast path.
RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Hi Jassi,
> -Original Message-
> From: Jassi Brar [mailto:jassisinghb...@gmail.com]
> Sent: 2019年6月21日 0:50
> To: Peng Fan
> Cc: Rob Herring ; Mark Rutland
> ; Sudeep Holla ; Florian
> Fainelli ; , Sascha Hauer ;
> dl-linux-imx ; Shawn Guo ;
> feste...@gmail.com; Devicetree List ; Linux
> Kernel Mailing List ;
> linux-arm-ker...@lists.infradead.org; Andre Przywara
> ; van.free...@gmail.com
> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Mon, Jun 3, 2019 at 3:28 AM wrote:
> >
> > From: Peng Fan
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7C1237677cb01044ad714508d6f59f648f%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C636966462272457978sdata=Hzgeu43m5
> ZkeRMtL8Bx
> > gUm3%2B6FBObib1OPHPlSccE%2B0%3Dreserved=0
> >
> > Cc: Andre Przywara
> > Signed-off-by: Peng Fan
> > ---
> >
> > V2:
> > Add interrupts notification support.
> >
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile| 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 190
>
> > include/linux/mailbox/arm-smc-mailbox.h | 10 ++
> > 4 files changed, 209 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode
> > 100644 include/linux/mailbox/arm-smc-mailbox.h
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > 595542bfae85..c3bd0f1ddcd8 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -15,6 +15,13 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > + tristate "Generic ARM smc mailbox"
> > + depends on OF && HAVE_ARM_SMCCC
> > + help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> > config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST diff --git
> > a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> >
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index ..fef6e38d8b98
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,190 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include #include
> > +
> > +#include
> > +#include
> > +
> > +#define ARM_SMC_MBOX_USE_HVC BIT(0)
> > +#define ARM_SMC_MBOX_USB_IRQ BIT(1)
> > +
> IRQ bit is unused (and unnecessary IMO)
This will be removed in next version.
>
> > +struct arm_smc_chan_data {
> > + u32 function_id;
> > + u32 flags;
> > + int irq;
> > +};
> > +
> > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > + struct arm_smccc_mbox_cmd *cmd = data;
> > + struct arm_smccc_res res;
> > + u32 function_id;
> > +
> > + if (chan_data->function_id != UINT_MAX)
> > + function_id = chan_data->function_id;
> > + else
> > + function_id = cmd->a0;
> > +
> Not sure about chan_data->function_id. Why restrict from DT?
> 'a0' is the function_id register, let the user pass func-id via the 'a0' like
> other
> values via 'a[1-7]'
>
>
> > + if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> > + arm_smccc_hvc(function_id, cmd->a1, cmd->a2,
> cmd->a3, cmd->a4,
> > + cmd->a5, cmd->a6, cmd->a7, );
> > + else
> > + arm_smccc_smc(function_id, cmd->a1, cmd->a2,
> cmd->a3, cmd->a4,
> > +
Re: [PATCH] arm64: asid: Optimize cache_flush for SMT
On Mon, 24 Jun 2019 04:40:10 PDT (-0700), mark.rutl...@arm.com wrote:
I'm very confused by this patch. The title says arm64, yet the code is
under arch/csky/, and the code in question refers to HARTs, which IIUC
is RISC-V terminology.
On Mon, Jun 24, 2019 at 12:04:29AM +0800, guo...@kernel.org wrote:
From: Guo Ren
The hardware threads of one core could share the same TLB for SMT+SMP
system. Assume hardware threads number sequence like this:
| 0 1 2 3 | 4 5 6 7 | 8 9 a b | c d e f |
core1 core2 core3 core4
Given this is the Linux logical CPU ID rather than a physical CPU ID,
this assumption is not valid. For example, CPUs may be renumbered across
kexec.
Even if this were a physical CPU ID, this doesn't hold on arm64 (e.g.
due to big.LITTLE).
Current algorithm seems is correct for SMT+SMP, but it'll give some
duplicate local_tlb_flush. Because one hardware threads local_tlb_flush
will also flush other hardware threads' TLB entry in one core TLB.
Does any architecture specification mandate that behaviour?
That isn't true for arm64, I have no idea whether RISC-V mandates that,
and as below it seems this is irrelevant on C-SKY.
There is no event defined by RISC-V that ever requires implementations flush
the TLB of more than one hart at a time. There is also nothing in the
normative text of the RISC-V manuals that allows for any differentiation
between multiple threads on a single core and multiple cores (though I am about
to suggest adding two, against my will :)).
So we can use bitmap to reduce local_tlb_flush for SMT.
C-SKY cores don't support SMT and the patch is no benefit for C-SKY.
As above, this patch is very confusing -- if this doesn't benefit C-SKY,
why modify the C-SKY code?
Thanks,
Mark.
Signed-off-by: Guo Ren
Cc: Catalin Marinas
Cc: Julien Grall
---
arch/csky/include/asm/asid.h | 4
arch/csky/mm/asid.c | 11 ++-
arch/csky/mm/context.c | 2 +-
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/csky/include/asm/asid.h b/arch/csky/include/asm/asid.h
index ac08b0f..f654492 100644
--- a/arch/csky/include/asm/asid.h
+++ b/arch/csky/include/asm/asid.h
@@ -23,6 +23,9 @@ struct asid_info
unsigned intctxt_shift;
/* Callback to locally flush the context. */
void(*flush_cpu_ctxt_cb)(void);
+ /* To reduce duplicate tlb_flush for SMT */
+ unsigned intharts_per_core;
+ unsigned intharts_per_core_mask;
};
#define NUM_ASIDS(info)(1UL << ((info)->bits))
@@ -73,6 +76,7 @@ static inline void asid_check_context(struct asid_info *info,
int asid_allocator_init(struct asid_info *info,
u32 bits, unsigned int asid_per_ctxt,
+ unsigned int harts_per_core,
void (*flush_cpu_ctxt_cb)(void));
#endif
diff --git a/arch/csky/mm/asid.c b/arch/csky/mm/asid.c
index b2e9147..50a983e 100644
--- a/arch/csky/mm/asid.c
+++ b/arch/csky/mm/asid.c
@@ -148,8 +148,13 @@ void asid_new_context(struct asid_info *info, atomic64_t
*pasid,
atomic64_set(pasid, asid);
}
- if (cpumask_test_and_clear_cpu(cpu, >flush_pending))
+ if (cpumask_test_cpu(cpu, >flush_pending)) {
+ unsigned int i;
+ unsigned int harts_base = cpu & info->harts_per_core_mask;
info->flush_cpu_ctxt_cb();
+ for (i = 0; i < info->harts_per_core; i++)
+ cpumask_clear_cpu(harts_base + i, >flush_pending);
+ }
atomic64_set(_asid(info, cpu), asid);
cpumask_set_cpu(cpu, mm_cpumask(mm));
@@ -162,15 +167,19 @@ void asid_new_context(struct asid_info *info, atomic64_t
*pasid,
* @info: Pointer to the asid allocator structure
* @bits: Number of ASIDs available
* @asid_per_ctxt: Number of ASIDs to allocate per-context. ASIDs are
+ * @harts_per_core: Number hardware threads per core, must be 1, 2, 4, 8, 16
...
* allocated contiguously for a given context. This value should be a power of
* 2.
*/
int asid_allocator_init(struct asid_info *info,
u32 bits, unsigned int asid_per_ctxt,
+ unsigned int harts_per_core,
void (*flush_cpu_ctxt_cb)(void))
{
info->bits = bits;
info->ctxt_shift = ilog2(asid_per_ctxt);
+ info->harts_per_core = harts_per_core;
+ info->harts_per_core_mask = ~((1 << ilog2(harts_per_core)) - 1);
info->flush_cpu_ctxt_cb = flush_cpu_ctxt_cb;
/*
* Expect allocation after rollover to fail if we don't have at least
diff --git a/arch/csky/mm/context.c b/arch/csky/mm/context.c
index 0d95bdd..b58523b 100644
--- a/arch/csky/mm/context.c
+++ b/arch/csky/mm/context.c
@@ -30,7 +30,7 @@ static int asids_init(void)
{
BUG_ON(((1 << CONFIG_CPU_ASID_BITS) - 1) <= num_possible_cpus());
- if (asid_allocator_init(_info,
Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file
On Mon, 24 Jun 2019 03:40:07 PDT (-0700), w...@kernel.org wrote: On Thu, Jun 20, 2019 at 05:33:03PM +0800, Guo Ren wrote: On Wed, Jun 19, 2019 at 8:39 PM Will Deacon wrote: > > On Wed, Jun 19, 2019 at 08:18:04PM +0800, Guo Ren wrote: > > On Wed, Jun 19, 2019 at 5:12 PM Will Deacon wrote: > > > This is one place where I'd actually prefer not to go down the route of > > > making the code generic. Context-switching and low-level TLB management > > > is deeply architecture-specific and I worry that by trying to make this > > > code common, we run the real risk of introducing subtle bugs on some > > > architecture every time it is changed. > > "Add generic asid code" and "move arm's into generic" are two things. > > We could do > > first and let architecture's maintainer to choose. > > If I understand the proposal being discussed, it involves basing that > generic ASID allocation code around the arm64 implementation which I don't > necessarily think is a good starting point. ... > > > > Furthermore, the algorithm we use > > > on arm64 is designed to scale to large systems using DVM and may well be > > > too complex and/or sub-optimal for architectures with different system > > > topologies or TLB invalidation mechanisms. > > It's just a asid algorithm not very complex and there is a callback > > for architecture to define their > > own local hart tlb flush. Seems it has nothing with DVM or tlb > > broadcast mechanism. > > I'm pleased that you think the algorithm is not very complex, but I'm also > worried that you might not have fully understood some of its finer details. I understand your concern about my less understanding of asid technology. Here is my short-description of arm64 asid allocator: (If you find anything wrong, please correct me directly, thx :) The complexity mainly comes from the fact that this thing runs concurrently with itself without synchronization on the fast-path. Coupled with the need to use the same ASID for all threads of a task, you end up in fiddly situations where rollover can occur on one CPU whilst another CPU is trying to schedule a thread of a task that already has threads running in userspace. However, it's architecture-specific whether or not you care about that scenario. > The reason I mention DVM and TLB broadcasting is because, depending on > the mechanisms in your architecture relating to those, it may be strictly > required that all concurrently running threads of a process have the same > ASID at any given point in time, or it may be that you really don't care. > > If you don't care, then the arm64 allocator is over-engineered and likely > inefficient for your system. If you do care, then it's worth considering > whether a lock is sufficient around the allocator if you don't expect high > core counts. Another possibility is that you end up using only one ASID and > invalidating the local TLB on every context switch. Yet another design > would be to manage per-cpu ASID pools. FWIW: right now we don't have any implementations that support ASIDs, so we're really not ready to make these sort of decisions because we just don't know what systems are going to look like. While it's a fun intellectual exercise to try to design an allocator that would work acceptably on systems of various shapes, there's no way to test this for performance or correctness right now so I wouldn't be comfortable taking anything. If you're really interested, the right place to start is the RTL https://github.com/chipsalliance/rocket-chip/blob/master/src/main/scala/rocket/TLB.scala#L19 This is essentially the same problem we have for our spinlocks -- maybe start with the TLB before doing a whole new pipeline, though :) I'll keep my system use the same ASID for SMP + IOMMU :P You will want a separate allocator for that: https://lkml.kernel.org/r/20190610184714.6786-2-jean-philippe.bruc...@arm.com Yes, there are two styles of asid allocator: per-cpu ASID (MIPS) or same ASID (ARM). If the CPU couldn't support cache/tlb coherency maintian in hardware, it should use per-cpu ASID style because IPI is expensive and per-cpu ASID style need more software mechanism to improve performance (eg: delay cache flush). From software view the same ASID is clearer and easier to build bigger system with more TLB caches. I think the same ASID style is a more sensible choice for modern processor and let it be one of generic is reasonable. I'm not sure I agree. x86, for example, is better off using a different algorithm for allocating its PCIDs. > So rather than blindly copying the arm64 code, I suggest sitting down and > designing something that fits to your architecture instead. You may end up > with something that is both simpler and more efficient. In fact, riscv folks have discussed a lot about arm's asid allocator and I learned a lot from the discussion: https://lore.kernel.org/linux-riscv/20190327100201.32220-1-anup.pa...@wdc.com/ If you require all threads of the same process to
RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Hi Sudeep,
> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Thu, Jun 20, 2019 at 10:21:09AM +, Peng Fan wrote:
> > Hi Sudeep,
> >
> > > Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
> > >
> > > On Mon, Jun 03, 2019 at 04:30:05PM +0800, peng@nxp.com wrote:
> > > > From: Peng Fan
> > > >
> > > > This mailbox driver implements a mailbox which signals transmitted
> > > > data via an ARM smc (secure monitor call) instruction. The mailbox
> > > > receiver is implemented in firmware and can synchronously return
> > > > data when it returns execution to the non-secure world again.
> > > > An asynchronous receive path is not implemented.
> > > > This allows the usage of a mailbox to trigger firmware actions on
> > > > SoCs which either don't have a separate management processor or on
> > > > which such a core is not available. A user of this mailbox could
> > > > be the SCP interface.
> > > >
> > > > Modified from Andre Przywara's v2 patch https://lore
> > > > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C0
> 1%7
> > > Cpeng.fa
> > > >
> > >
> n%40nxp.com%7C6b37f78032e446be750e08d6f560e707%7C686ea1d3bc2b4
> > > c6fa92cd
> > > >
> > >
> 99c5c301635%7C0%7C0%7C636966193913988679sdata=UNM4MTPs
> > > brqoMqWStEy
> > > > YzzwMEWTmX7hHO3TeNEz%2BOAw%3Dreserved=0
> > > >
> > > > Cc: Andre Przywara
> > > > Signed-off-by: Peng Fan
> > > > ---
> > > >
> > > > V2:
> > > > Add interrupts notification support.
> > > >
> > > > drivers/mailbox/Kconfig | 7 ++
> > > > drivers/mailbox/Makefile| 2 +
> > > > drivers/mailbox/arm-smc-mailbox.c | 190
> > >
> > > > include/linux/mailbox/arm-smc-mailbox.h | 10 ++
> > > > 4 files changed, 209 insertions(+)
> > > > create mode 100644 drivers/mailbox/arm-smc-mailbox.c create
> mode
> > > > 100644 include/linux/mailbox/arm-smc-mailbox.h
> > > >
> > > > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > > > 595542bfae85..c3bd0f1ddcd8 100644
> > > > --- a/drivers/mailbox/Kconfig
> > > > +++ b/drivers/mailbox/Kconfig
> > > > @@ -15,6 +15,13 @@ config ARM_MHU
> > > > The controller has 3 mailbox channels, the last of which can
> > > > be
> > > > used in Secure mode only.
> > > >
> > > > +config ARM_SMC_MBOX
> > > > + tristate "Generic ARM smc mailbox"
> > > > + depends on OF && HAVE_ARM_SMCCC
> > > > + help
> > > > + Generic mailbox driver which uses ARM smc calls to call into
> > > > + firmware for triggering mailboxes.
> > > > +
> > > > config IMX_MBOX
> > > > tristate "i.MX Mailbox"
> > > > depends on ARCH_MXC || COMPILE_TEST
> > > > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > > > c22fad6f696b..93918a84c91b 100644
> > > > --- a/drivers/mailbox/Makefile
> > > > +++ b/drivers/mailbox/Makefile
> > > > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> > > >
> > > > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> > > >
> > > > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > > > +
> > > > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> > > >
> > > > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> > > armada-37xx-rwtm-mailbox.o
> > > > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > > > b/drivers/mailbox/arm-smc-mailbox.c
> > > > new file mode 100644
> > > > index ..fef6e38d8b98
> > > > --- /dev/null
> > > > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > > > @@ -0,0 +1,190 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Copyright (C) 2016,2017 ARM Ltd.
> > > > + * Copyright 2019 NXP
> > > > + */
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include #include
> > > > +
> > > > +#include
> > > > +#include
> > > > +
> > > > +#define ARM_SMC_MBOX_USE_HVC BIT(0)
> > > > +#define ARM_SMC_MBOX_USB_IRQ BIT(1)
> > > > +
> > > > +struct arm_smc_chan_data {
> > > > + u32 function_id;
> > > > + u32 flags;
> > > > + int irq;
> > > > +};
> > > > +
> > > > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > > > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > > > + struct arm_smccc_mbox_cmd *cmd = data;
> > > > + struct arm_smccc_res res;
> > > > + u32 function_id;
> > > > +
> > > > + if (chan_data->function_id != UINT_MAX)
> > > > + function_id = chan_data->function_id;
> > > > + else
> > > > + function_id = cmd->a0;
> > > > +
> > > > + if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> > > > + arm_smccc_hvc(function_id, cmd->a1, cmd->a2, cmd->a3,
> > > cmd->a4,
> > > > + cmd->a5, cmd->a6, cmd->a7, );
> > > > + else
> > > > + arm_smccc_smc(function_id, cmd->a1, cmd->a2, cmd->a3,
> > > cmd->a4,
> > > > + cmd->a5, cmd->a6, cmd->a7, );
> > >
[PATCH] x86/build: add 'set -e' to mkcapflags.sh to delete broken capflags.c
Without 'set -e', shell scripts continue running even after any
error occurs. The missed 'set -e' is a typical bug in shell scripting.
For example, when a disk space shortage occurs while this script is
running, it actually ends up with generating a truncated capflags.c.
Yet, mkcapflags.sh continues running and exits with 0. So, the build
system assumes it has succeeded.
It will not be re-generated in the next invocation of Make since its
timestamp is newer than that of any of the source files.
Add 'set -e' so that any error in this script is caught and propagated
to the build system.
Since 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special target"),
Make automatically deletes the target on any failure. So, the broken
capflags.c will be deleted automatically.
Signed-off-by: Masahiro Yamada
---
arch/x86/kernel/cpu/mkcapflags.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/cpu/mkcapflags.sh
b/arch/x86/kernel/cpu/mkcapflags.sh
index d0dfb892c72f..aed45b8895d5 100644
--- a/arch/x86/kernel/cpu/mkcapflags.sh
+++ b/arch/x86/kernel/cpu/mkcapflags.sh
@@ -4,6 +4,8 @@
# Generate the x86_cap/bug_flags[] arrays from include/asm/cpufeatures.h
#
+set -e
+
IN=$1
OUT=$2
--
2.17.1
[tip:locking/core] x86/jump_label: Make tp_vec_nr static
Commit-ID: bf10c97adbd0dc8fa65c35d5b0c0dc281a68ac8e
Gitweb: https://git.kernel.org/tip/bf10c97adbd0dc8fa65c35d5b0c0dc281a68ac8e
Author: YueHaibing
AuthorDate: Tue, 25 Jun 2019 11:45:48 +0800
Committer: Thomas Gleixner
CommitDate: Tue, 25 Jun 2019 09:22:14 +0200
x86/jump_label: Make tp_vec_nr static
Fix sparse warning:
arch/x86/kernel/jump_label.c:106:5: warning:
symbol 'tp_vec_nr' was not declared. Should it be static?
It's only used in jump_label.c, so make it static.
Fixes: ba54f0c3f7c4 ("x86/jump_label: Batch jump label updates")
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
Signed-off-by: Thomas Gleixner
Cc:
Cc:
Cc:
Cc:
Cc:
Link: https://lkml.kernel.org/r/20190625034548.26392-1-yuehaib...@huawei.com
---
arch/x86/kernel/jump_label.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
index ea13808bf6da..044053235302 100644
--- a/arch/x86/kernel/jump_label.c
+++ b/arch/x86/kernel/jump_label.c
@@ -103,7 +103,7 @@ void arch_jump_label_transform(struct jump_entry *entry,
#define TP_VEC_MAX (PAGE_SIZE / sizeof(struct text_poke_loc))
static struct text_poke_loc tp_vec[TP_VEC_MAX];
-int tp_vec_nr = 0;
+static int tp_vec_nr;
bool arch_jump_label_transform_queue(struct jump_entry *entry,
enum jump_label_type type)
[net/bpf] Re: WARNING in mark_lock
[+bpf list]
On Tue, Jun 25, 2019 at 08:20:56AM +0200, Thomas Gleixner wrote:
> On Mon, 24 Jun 2019, syzbot wrote:
>
> > Hello,
>
> CC++ Peterz
>
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:dc636f5d Add linux-next specific files for 20190620
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=162b68b1a0
> > kernel config: https://syzkaller.appspot.com/x/.config?x=99c104b0092a557b
> > dashboard link: https://syzkaller.appspot.com/bug?extid=a861f52659ae2596492b
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=110b24f6a0
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+a861f52659ae25964...@syzkaller.appspotmail.com
The syz repro looks bpf related, and essentially the same repro is in lots of
other open syzbot reports which I've assigned to the bpf subsystem...
https://lore.kernel.org/lkml/20190624050114.GA30702@sol.localdomain/
{"threaded":true,"repeat":true,"procs":6,"sandbox":"none","fault_call":-1,"tun":true,"netdev":true,"resetnet":true,"cgroups":true,"binfmt_misc":true,"close_fds":true,"tmpdir":true,"segv":true}
bpf$MAP_CREATE(0x0, &(0x7f000280)={0xf, 0x4, 0x4, 0x400, 0x0, 0x1}, 0x3c)
socket$rxrpc(0x21, 0x2, 0x8a)
r0 = socket$inet6_tcp(0xa, 0x1, 0x0)
setsockopt$inet6_tcp_int(r0, 0x6, 0x13, &(0x7fc0)=0x10001, 0x1d4)
connect$inet6(r0, &(0x7f000140), 0x1c)
bpf$MAP_CREATE(0x0, &(0x7f00)={0x5}, 0xfdcb)
bpf$MAP_CREATE(0x2, &(0x7f003000)={0x3, 0x0, 0x77fffb, 0x0, 0x1002000,
0x0}, 0x2c)
setsockopt$inet6_tcp_TCP_ULP(r0, 0x6, 0x1f, &(0x7f40)='tls\x00', 0x4)
Re: [PATCH 18/22] mm: mark DEVICE_PUBLIC as broken
On Thu, Jun 20, 2019 at 09:26:48PM +0200, Michal Hocko wrote: > On Thu 13-06-19 11:43:21, Christoph Hellwig wrote: > > The code hasn't been used since it was added to the tree, and doesn't > > appear to actually be usable. Mark it as BROKEN until either a user > > comes along or we finally give up on it. > > I would go even further and simply remove all the DEVICE_PUBLIC code. I looked into that as I now got the feedback twice. It would create a conflict with another tree cleaning things up around the is_device_private defintion, but otherwise I'd be glad to just remove it. Jason, as this goes through your tree, do you mind the additional conflict?
Re: [PATCH] drivers: Adjust scope for CONFIG_HAS_IOMEM before devm_platform_ioremap_resource()
On Tue, Jun 25, 2019 at 09:10:25AM +0200, Bartosz Golaszewski wrote: > pon., 24 cze 2019 o 20:22 Enrico Weigelt, metux IT consult > napisał(a): > > > > On 24.06.19 12:46, Bartosz Golaszewski wrote: > > > > >> The patch seems pretty trivial and doesn't change any actual code, so > > >> I don't see hard resons for rejecting it. > > >> > > > > > > In its current form it makes the code even less readable. The #ifdef > > > should actually be one line lower and touch the comment instead of the > > > EXPORT_SYMBOL() related to a different function. > > > > Okay, that missing newline should be fixed (as well as the extra one > > after the #ifdef). Besides that, I don't see any further problems. > > > > Are we sure this even changes something? Does kernel documentation get > generated according to current config options? I really think this > patch just pollutes the history for now apparent reason. > > Greg, could you give your opinion on this? Why are you all arguing with a all-but-instinguishable-from-a-bot persona about a patch that I will never apply? greg k-h
RE: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
Hi Jassi
> Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Mon, Jun 3, 2019 at 3:28 AM wrote:
> >
> > From: Peng Fan
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7C1237677cb01044ad714508d6f59f648f%7C686ea1d3bc2b4
> c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C636966462272457978sdata=Hzgeu43m5
> ZkeRMtL8Bx
> > gUm3%2B6FBObib1OPHPlSccE%2B0%3Dreserved=0
> >
> > Cc: Andre Przywara
> > Signed-off-by: Peng Fan
> > ---
> >
> > V2:
> > Add interrupts notification support.
> >
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile| 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 190
>
> > include/linux/mailbox/arm-smc-mailbox.h | 10 ++
> > 4 files changed, 209 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode
> > 100644 include/linux/mailbox/arm-smc-mailbox.h
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> > 595542bfae85..c3bd0f1ddcd8 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -15,6 +15,13 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
> >
> > +config ARM_SMC_MBOX
> > + tristate "Generic ARM smc mailbox"
> > + depends on OF && HAVE_ARM_SMCCC
> > + help
> > + Generic mailbox driver which uses ARM smc calls to call into
> > + firmware for triggering mailboxes.
> > +
> > config IMX_MBOX
> > tristate "i.MX Mailbox"
> > depends on ARCH_MXC || COMPILE_TEST diff --git
> > a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> > c22fad6f696b..93918a84c91b 100644
> > --- a/drivers/mailbox/Makefile
> > +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> >
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> >
> > +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> > +
> > obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> >
> > obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+=
> armada-37xx-rwtm-mailbox.o
> > diff --git a/drivers/mailbox/arm-smc-mailbox.c
> > b/drivers/mailbox/arm-smc-mailbox.c
> > new file mode 100644
> > index ..fef6e38d8b98
> > --- /dev/null
> > +++ b/drivers/mailbox/arm-smc-mailbox.c
> > @@ -0,0 +1,190 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2016,2017 ARM Ltd.
> > + * Copyright 2019 NXP
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include #include
> > +
> > +#include
> > +#include
> > +
> > +#define ARM_SMC_MBOX_USE_HVC BIT(0)
> > +#define ARM_SMC_MBOX_USB_IRQ BIT(1)
> > +
> IRQ bit is unused (and unnecessary IMO)
>
> > +struct arm_smc_chan_data {
> > + u32 function_id;
> > + u32 flags;
> > + int irq;
> > +};
> > +
> > +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> > + struct arm_smc_chan_data *chan_data = link->con_priv;
> > + struct arm_smccc_mbox_cmd *cmd = data;
> > + struct arm_smccc_res res;
> > + u32 function_id;
> > +
> > + if (chan_data->function_id != UINT_MAX)
> > + function_id = chan_data->function_id;
> > + else
> > + function_id = cmd->a0;
> > +
> Not sure about chan_data->function_id. Why restrict from DT?
> 'a0' is the function_id register, let the user pass func-id via the 'a0' like
> other
> values via 'a[1-7]'
Missed to reply this comment.
The firmware driver might not have func-id, such as SCMI/SCPI.
So add an optional func-id to let smc mailbox driver could
use smc SiP func id.
Thanks,
Peng.
>
>
> > + if (chan_data->flags & ARM_SMC_MBOX_USE_HVC)
> > + arm_smccc_hvc(function_id, cmd->a1, cmd->a2,
> cmd->a3, cmd->a4,
> > + cmd->a5, cmd->a6, cmd->a7, );
> > + else
> > + arm_smccc_smc(function_id, cmd->a1, cmd->a2,
> cmd->a3, cmd->a4,
> > + cmd->a5, cmd->a6, cmd->a7, );
> > +
> > + if (chan_data->irq)
> > + return 0;
> > +
> This irq thing seems like oob signalling, that is, a protocol thing.
> And then it provides lesser info via chan_irq_handler (returns NULL)
Re: [PATCH] fsi: sbefifo: Don't fail operations when in SBE IPL state
On Tue, Jun 25, 2019 at 04:35:50AM +, Joel Stanley wrote: > Hi Greg, > > On Mon, 17 Jun 2019 at 05:41, Joel Stanley wrote: > > > > On Mon, 17 Jun 2019 at 02:09, Alistair Popple wrote: > > > > > > On Monday, 21 January 2019 11:15:58 AM AEST Eddie James wrote: > > > > SBE fifo operations should be allowed while the SBE is in any of the > > > > "IPL" states. Operations should succeed in this state. > > > > > > > > Signed-off-by: Eddie James > > > > > > This fixed the problem I was having trying to issue istep operations to > > > the > > > SBE. > > > > > > Tested-by: Alistair Popple > > > > This one slipped through the cracks. > > > > Fixes: 9f4a8a2d7f9d fsi/sbefifo: Add driver for the SBE FIFO > > Reviewed-by: Joel Stanley > > > > Greg, can you please queue this one up for 5.3? > > Ping? I don't see this in my queue at all, sorry. Can someone resend it in a format that I can apply it in with the needed tested-by and reviewed-by added to it? thanks, greg k-h
Re: [patch 0/5] *** DMA based UART driver for AST2500 ***
On Tue, Jun 25, 2019 at 10:30:32AM +0530, sudheer v wrote: > Hi Greg, > When i last submitted patches, i have not added change-logs. > and also used custom debugs instead of kernel dynamic debugs. > So i have resubmitted the patches , considering you have discarded old set. > I want to send any changes suggested from now on wards with versioning > V1,V2...so on. > Is this acceptable for you? or should i submit the patches again as V1 once > again.? No, please resend now as a v3 series, with the information that says what you changed from the previous versions. thanks, greg k-h
[tip:x86/cache] x86/resctrl: Cleanup cbm_ensure_valid()
Commit-ID: 2ef085bd110c5723ca08a522608ac3468dc304bd
Gitweb: https://git.kernel.org/tip/2ef085bd110c5723ca08a522608ac3468dc304bd
Author: Reinette Chatre
AuthorDate: Mon, 24 Jun 2019 13:34:27 -0700
Committer: Thomas Gleixner
CommitDate: Tue, 25 Jun 2019 09:26:11 +0200
x86/resctrl: Cleanup cbm_ensure_valid()
A recent fix to the cbm_ensure_valid() function left some coding style
issues that are now addressed:
- Return a value instead of using a function parameter as input and
output
- Use if (!val) instead of if (val == 0)
- Follow reverse fir tree ordering of variable declarations
Suggested-by: Borislav Petkov
Signed-off-by: Reinette Chatre
Signed-off-by: Thomas Gleixner
Cc: fenghua...@intel.com
Cc: tony.l...@intel.com
Cc: h...@zytor.com
Link:
https://lkml.kernel.org/r/15ba03856f1d944468ee6f44e3fd7aa548293ede.1561408280.git.reinette.cha...@intel.com
---
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index 2f4824793798..bf3034994754 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -2488,21 +2488,21 @@ out_destroy:
* modification to the CBM if the default does not satisfy the
* requirements.
*/
-static void cbm_ensure_valid(u32 *_val, struct rdt_resource *r)
+static u32 cbm_ensure_valid(u32 _val, struct rdt_resource *r)
{
- unsigned long val = *_val;
unsigned int cbm_len = r->cache.cbm_len;
unsigned long first_bit, zero_bit;
+ unsigned long val = _val;
- if (val == 0)
- return;
+ if (!val)
+ return 0;
first_bit = find_first_bit(, cbm_len);
zero_bit = find_next_zero_bit(, cbm_len, first_bit);
/* Clear any remaining bits to ensure contiguous region */
bitmap_clear(, zero_bit, cbm_len - zero_bit);
- *_val = (u32)val;
+ return (u32)val;
}
/*
@@ -2560,7 +2560,7 @@ static int __init_one_rdt_domain(struct rdt_domain *d,
struct rdt_resource *r,
* Force the initial CBM to be valid, user can
* modify the CBM based on system availability.
*/
- cbm_ensure_valid(>new_ctrl, r);
+ d->new_ctrl = cbm_ensure_valid(d->new_ctrl, r);
/*
* Assign the u32 CBM to an unsigned long to ensure that
* bitmap_weight() does not access out-of-bound memory.
Re: RISC-V nommu support v2
On Mon, 24 Jun 2019 06:08:50 PDT (-0700), vladimir.mur...@arm.com wrote: On 6/24/19 12:54 PM, Christoph Hellwig wrote: On Mon, Jun 24, 2019 at 12:47:07PM +0100, Vladimir Murzin wrote: Since you are using binfmt_flat which is kind of 32-bit only I was expecting to see CONFIG_COMPAT (or something similar to that, like ILP32) enabled, yet I could not find it. There is no such thing in RISC-V. I don't know of any 64-bit RISC-V cpu that can actually run 32-bit RISC-V code, although in theory that is possible. There also is nothing like the x86 x32 or mips n32 mode available either for now. But it turns out that with a few fixes to binfmt_flat it can run 64-bit binaries just fine. I sent that series out a while ago, and IIRC you actually commented on it. True, yet my observation was that elf2flt utility assumes that address space cannot exceed 32-bit (for header and absolute relocations). So, from my limited point of view straightforward way to guarantee that would be to build incoming elf in 32-bit mode (it is why I mentioned COMPAT/ILP32). Also one of your patches expressed somewhat related idea "binfmt_flat isn't the right binary format for huge executables to start with" Since you said there is no support for compat/ilp32, probably I'm missing some toolchain magic? Cheers Vladimir To: Christoph Hellwig CC: vladimir.mur...@arm.com CC: Christoph Hellwig CC: Paul Walmsley CC: Damien Le Moal CC: linux-ri...@lists.infradead.org CC: linux...@kvack.org CC: linux-kernel@vger.kernel.org Subject: Re: RISC-V nommu support v2 In-Reply-To: <20190624131633.gb10...@lst.de> On Mon, 24 Jun 2019 06:16:33 PDT (-0700), Christoph Hellwig wrote: On Mon, Jun 24, 2019 at 02:08:50PM +0100, Vladimir Murzin wrote: True, yet my observation was that elf2flt utility assumes that address space cannot exceed 32-bit (for header and absolute relocations). So, from my limited point of view straightforward way to guarantee that would be to build incoming elf in 32-bit mode (it is why I mentioned COMPAT/ILP32). Also one of your patches expressed somewhat related idea "binfmt_flat isn't the right binary format for huge executables to start with" Since you said there is no support for compat/ilp32, probably I'm missing some toolchain magic? There is no magic except for the tiny elf2flt patch, which for now is just in the buildroot repo pointed to in the cover letter (and which I plan to upstream once the kernel support has landed in Linus' tree). We only support 32-bit code and data address spaces, but we otherwise use the normal RISC-V ABI, that is 64-bit longs and pointers. The medlow code model on RISC-V essentially enforces this -- technically it enforces a 32-bit region centered around address 0, but it's not that hard to stay away from negative addresses. That said, as long as elf2flt gives you an error it should be fine because all medlow is going to do is give you a different looking error message.
Re: [PATCH] drivers: Adjust scope for CONFIG_HAS_IOMEM before devm_platform_ioremap_resource()
wt., 25 cze 2019 o 09:30 Greg Kroah-Hartman napisał(a): > > On Tue, Jun 25, 2019 at 09:10:25AM +0200, Bartosz Golaszewski wrote: > > pon., 24 cze 2019 o 20:22 Enrico Weigelt, metux IT consult > > napisał(a): > > > > > > On 24.06.19 12:46, Bartosz Golaszewski wrote: > > > > > > >> The patch seems pretty trivial and doesn't change any actual code, so > > > >> I don't see hard resons for rejecting it. > > > >> > > > > > > > > In its current form it makes the code even less readable. The #ifdef > > > > should actually be one line lower and touch the comment instead of the > > > > EXPORT_SYMBOL() related to a different function. > > > > > > Okay, that missing newline should be fixed (as well as the extra one > > > after the #ifdef). Besides that, I don't see any further problems. > > > > > > > Are we sure this even changes something? Does kernel documentation get > > generated according to current config options? I really think this > > patch just pollutes the history for now apparent reason. > > > > Greg, could you give your opinion on this? > > Why are you all arguing with a all-but-instinguishable-from-a-bot > persona about a patch that I will never apply? > > greg k-h Oh so it's another troll then? Good to know, ignoring from now on. Thanks, Bart
Re: [PATCH v10 09/13] drivers: devfreq: events: add Exynos PPMU new events
On 6/22/19 3:10 PM, Chanwoo Choi wrote:
> Hi,
>
> 2019년 6월 14일 (금) 오후 6:54, Lukasz Luba 님이 작성:
>>
>> Define new performance events supported by Exynos5422 SoC counters.
>> The counters are built-in in Dynamic Memory Controller and provide
>> information regarding memory utilization.
>>
>> Signed-off-by: Lukasz Luba
>> ---
>> drivers/devfreq/event/exynos-ppmu.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/devfreq/event/exynos-ppmu.c
>> b/drivers/devfreq/event/exynos-ppmu.c
>> index c2ea94957501..ce658c262c27 100644
>> --- a/drivers/devfreq/event/exynos-ppmu.c
>> +++ b/drivers/devfreq/event/exynos-ppmu.c
>> @@ -89,6 +89,12 @@ static struct __exynos_ppmu_events {
>> PPMU_EVENT(d1-cpu),
>> PPMU_EVENT(d1-general),
>> PPMU_EVENT(d1-rt),
>> +
>> + /* For Exynos5422 SoC */
>> + PPMU_EVENT(dmc0_0),
>> + PPMU_EVENT(dmc0_1),
>> + PPMU_EVENT(dmc1_0),
>> + PPMU_EVENT(dmc1_1),
>> };
>>
>> static int exynos_ppmu_find_ppmu_id(struct devfreq_event_dev *edev)
>> --
>> 2.17.1
>>
>
> Acked-by: Chanwoo Choi
>
Thank you Chanwoo.
Regards,
Lukasz
Re: [PATCH V10 11/15] arm64: tegra: Add P2U and PCIe controller nodes to Tegra194 DT
On Mon, Jun 24, 2019 at 01:02:06PM +0530, Vidya Sagar wrote:
> On 6/20/2019 4:25 PM, Thierry Reding wrote:
> > On Wed, Jun 12, 2019 at 03:23:35PM +0530, Vidya Sagar wrote:
> > > Add P2U (PIPE to UPHY) and PCIe controller nodes to device tree.
> > > The Tegra194 SoC contains six PCIe controllers and twenty P2U instances
> > > grouped into two different PHY bricks namely High-Speed IO (HSIO-12 P2Us)
> > > and NVIDIA High Speed (NVHS-8 P2Us) respectively.
> > >
> > > Signed-off-by: Vidya Sagar
> > > ---
> > > Changes since [v9]:
> > > * None
> > >
> > > Changes since [v8]:
> > > * None
> > >
> > > Changes since [v7]:
> > > * Replaced 'core_apb' with 'apb' in reset names
> > > * Used macros instead of hardcoded numbers in 'interrupt-map' property
> > > * Aligned 'ranges' entries
> > >
> > > Changes since [v6]:
> > > * Removed properties "nvidia,disable-aspm-states" &
> > > "nvidia,controller-id".
> > > * Modified property "nvidia,bpmp" to include controller-id as well.
> > >
> > > Changes since [v5]:
> > > * Changes 'p2u@' to 'phy@'
> > > * Arranged all PCIe nodes in the order of their addresses
> > >
> > > Changes since [v4]:
> > > * None
> > >
> > > Changes since [v3]:
> > > * None
> > >
> > > Changes since [v2]:
> > > * Included 'hsio' or 'nvhs' in P2U node's label names to reflect which
> > > brick
> > >they belong to
> > > * Removed leading zeros in unit address
> > >
> > > Changes since [v1]:
> > > * Flattened all P2U nodes by removing 'hsio-p2u' and 'nvhs-p2u' super
> > > nodes
> > > * Changed P2U nodes compatible string from 'nvidia,tegra194-phy-p2u' to
> > > 'nvidia,tegra194-p2u'
> > > * Changed reg-name from 'base' to 'ctl'
> > > * Updated all PCIe nodes according to the changes made to DT
> > > documentation file
> > >
> > > arch/arm64/boot/dts/nvidia/tegra194.dtsi | 437 +++
> > > 1 file changed, 437 insertions(+)
> >
> > Applied to for-5.3/arm64/dt, thanks.
> >
> > I did end up sorting the new nodes differently so that they are ordered
> > according to the general rules (sort by unit-address, then
> > alphabetically). That's slightly complicated by the fact that the PCI
> > controllers have registers that seem to be right in the middle of the
> > host1x aperture, so I had to bend the rules a little.
> >
> > Thierry
>
> I see that you moved all PCIe nodes under CBB node. There is an issue with
> that.
> PCIe nodes have apertures defined in both 32-bit region and 64-bit region
> which
> are mentioned through "ranges" property. Apertures defined in 64-bit region
> do not
> fit within "ranges" defined for CBB region which can handle only 32-bit
> "ranges" of
> CBB sub-nodes and ends @ 0x4000. It is because of this reason that I kept
> PCIe
> nodes outside of CBB master node. Do you agree with my understanding? If yes,
> can
> you please move PCIe nodes out of CBB node? (Also in platform dts file)
Yeah, I noticed this discrepancy while doing the final builds and before
pushing things out. I think the problem here is that we restricted the
CBB region to #address-cells = <1> where it really should've been 2
cells for the addresses given the size of the addressable region. I've
reverted my changes for now, but I think eventually we'll want to adjust
CBB to be #address-cells = <2> and maybe even #size-cells = <2> to take
into account the PCIe ranges.
Another possibility might be that PCI is actually on a different "bus"
(i.e. not CBB) in which case it'd be best to model that. But the TRM is
not very clear about the bus hierarchy.
Thierry
>
> Thanks,
> Vidya Sagar
>
> >
> > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > index c77ca211fa8f..feba034f26f0 100644
> > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > @@ -884,6 +884,166 @@
> > > nvidia,interface = <3>;
> > > };
> > > };
> > > +
> > > + p2u_hsio_0: phy@3e1 {
> > > + compatible = "nvidia,tegra194-p2u";
> > > + reg = <0x03e1 0x1>;
> > > + reg-names = "ctl";
> > > +
> > > + #phy-cells = <0>;
> > > + };
> > > +
> > > + p2u_hsio_1: phy@3e2 {
> > > + compatible = "nvidia,tegra194-p2u";
> > > + reg = <0x03e2 0x1>;
> > > + reg-names = "ctl";
> > > +
> > > + #phy-cells = <0>;
> > > + };
> > > +
> > > + p2u_hsio_2: phy@3e3 {
> > > + compatible = "nvidia,tegra194-p2u";
> > > + reg = <0x03e3 0x1>;
> > > + reg-names = "ctl";
> > > +
> > > + #phy-cells = <0>;
> > > + };
> > > +
> > > + p2u_hsio_3: phy@3e4 {
> > > + compatible = "nvidia,tegra194-p2u";
> > > + reg =
[PATCH] x86/build: remove redundant 'clean-files += capflags.c'
All the files added to 'targets' are cleaned. Adding the same file to both 'targets' and 'clean-files' is redundant. Signed-off-by: Masahiro Yamada --- arch/x86/kernel/cpu/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile index 5102bf7c8192..50abae9a72e5 100644 --- a/arch/x86/kernel/cpu/Makefile +++ b/arch/x86/kernel/cpu/Makefile @@ -54,8 +54,7 @@ quiet_cmd_mkcapflags = MKCAP $@ cpufeature = $(src)/../../include/asm/cpufeatures.h -targets += capflags.c $(obj)/capflags.c: $(cpufeature) $(src)/mkcapflags.sh FORCE $(call if_changed,mkcapflags) endif -clean-files += capflags.c +targets += capflags.c -- 2.17.1
Re: [PATCH RFC v2] Convert struct pid count to refcount_t
On Mon, Jun 24, 2019 at 09:10:15PM +0200, Jann Horn wrote:
> That part of the documentation only talks about cases where you have a
> control dependency on the return value of the refcount operation. But
> refcount_inc() does not return a value, so this isn't relevant for
> refcount_inc().
>
> Also, AFAIU, the control dependency mentioned in the documentation has
> to exist *in the caller* - it's just pointing out that if you write
> code like the following, you have a control dependency between the
> refcount operation and the write:
>
> if (refcount_inc_not_zero(>refcount)) {
> WRITE_ONCE(obj->x, y);
> }
>
> For more information on the details of this stuff, try reading the
> section "CONTROL DEPENDENCIES" of Documentation/memory-barriers.txt.
IIRC the argument went as follows:
- if you use refcount_inc(), you've already got a stable object and
have ACQUIRED it otherwise, typically through locking.
- if you use refcount_inc_not_zero(), you have a semi stable object
(RCU), but you still need to ensure any changes to the object happen
after acquiring a reference, and this is where the control dependency
comes in as Jann already explained.
Specifically, it would be bad to allow STOREs to happen before we know
the refcount isn't 0, as that would be a UaF.
Also see the comment in lib/refcount.c.
Re: [PATCH v10 09/13] drivers: devfreq: events: add Exynos PPMU new events
On 19. 6. 25. 오후 4:31, Lukasz Luba wrote:
>
>
> On 6/22/19 3:10 PM, Chanwoo Choi wrote:
>> Hi,
>>
>> 2019년 6월 14일 (금) 오후 6:54, Lukasz Luba 님이 작성:
>>>
>>> Define new performance events supported by Exynos5422 SoC counters.
>>> The counters are built-in in Dynamic Memory Controller and provide
>>> information regarding memory utilization.
>>>
>>> Signed-off-by: Lukasz Luba
>>> ---
>>> drivers/devfreq/event/exynos-ppmu.c | 6 ++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/devfreq/event/exynos-ppmu.c
>>> b/drivers/devfreq/event/exynos-ppmu.c
>>> index c2ea94957501..ce658c262c27 100644
>>> --- a/drivers/devfreq/event/exynos-ppmu.c
>>> +++ b/drivers/devfreq/event/exynos-ppmu.c
>>> @@ -89,6 +89,12 @@ static struct __exynos_ppmu_events {
>>> PPMU_EVENT(d1-cpu),
>>> PPMU_EVENT(d1-general),
>>> PPMU_EVENT(d1-rt),
>>> +
>>> + /* For Exynos5422 SoC */
>>> + PPMU_EVENT(dmc0_0),
>>> + PPMU_EVENT(dmc0_1),
>>> + PPMU_EVENT(dmc1_0),
>>> + PPMU_EVENT(dmc1_1),
>>> };
>>>
>>> static int exynos_ppmu_find_ppmu_id(struct devfreq_event_dev *edev)
>>> --
>>> 2.17.1
>>>
>>
>> Acked-by: Chanwoo Choi
>>
> Thank you Chanwoo.
It[1] was merged to devfreq.git.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git/commit/?h=for-next
--
Best Regards,
Chanwoo Choi
Samsung Electronics
RE: [PATCH net-next 3/3] net: stmmac: Convert to phylink and remove phylib logic
From: Jon Hunter > Any further feedback? I am still seeing this issue on today's -next. Apologies but I was in FTO. Is there any possibility you can just disable the ethX configuration in the rootfs mount and manually configure it after rootfs is done ? I just want to make sure in which conditions this is happening (if in ifdown or ifup). Thanks, Jose Miguel Abreu
nl80211 wlcore regression in next
Hi,
Looks like at least drivers/net/wireless/ti wlcore driver has stopped
working in Linux next with commit 901bb9891855 ("nl80211: require and
validate vendor command policy"). Reverting the commit above makes it
work again.
It fails with the warning below, any ideas what goes wrong?
Regards,
Tony
8<
WARNING: CPU: 0 PID: 21 at net/wireless/core.c:868 wiphy_register+0x85c/0xbd4
[cfg80211]
...
[] (wiphy_register [cfg80211]) from []
(ieee80211_register_hw+0x4e4/0xcd8 [mac80211])
[] (ieee80211_register_hw [mac80211]) from []
(wlcore_nvs_cb+0x758/0xabc [wlcore])
[] (wlcore_nvs_cb [wlcore]) from []
(request_firmware_work_func+0x50/0x8c)
[] (request_firmware_work_func) from []
(process_one_work+0x20c/0x504)
...
Re: [PATCH 1/3] notifier: Fix broken error handling pattern
On Mon, Jun 24, 2019 at 05:21:07PM -0500, Josh Poimboeuf wrote:
> On Mon, Jun 24, 2019 at 11:18:44AM +0200, Peter Zijlstra wrote:
> > The current notifiers have the following error handling pattern all
> > over the place:
> >
> > int nr;
> >
> > ret = __foo_notifier_call_chain(, val_up, v, -1, );
> > if (err & NOTIFIER_STOP_MASK)
>
> s/err/ret/
-ETOOWARM :-)
> > __foo_notifier_call_chain(, val_down, v, nr-1, NULL)
> >
> > And aside from the endless repetition thereof, it is broken. Consider
> > blocking notifiers; both calls take and drop the rwsem, this means
> > that the notifier list can change in between the two calls, making @nr
> > meaningless.
> >
> > Fix this by replacing all the __foo_notifier_call_chain() functions
> > with foo_notifier_call_chain_error() that embeds the above patter, but
> > ensures it is inside a single lock region.
>
> The name "notifier_call_chain_error()" seems confusing, it almost sounds
> like it's notifying an error code. Then again, I can't really think of
> a more reasonably succinct name.
I;m not attached to the name; I very much ran out of ideas and just
typed something.
> > @@ -25,8 +25,23 @@ static int cpu_pm_notify(enum cpu_pm_eve
> > * RCU know this.
> > */
> > rcu_irq_enter_irqson();
> > - ret = __atomic_notifier_call_chain(_pm_notifier_chain, event, NULL,
> > - nr_to_call, nr_calls);
> > + ret = atomic_notifier_call_chain(_pm_notifier_chain, event, NULL);
> > + rcu_irq_exit_irqson();
> > +
> > + return notifier_to_errno(ret);
> > +}
> > +
> > +static int cpu_pm_notify_error(enum cpu_pm_event event_up, enum
> > cpu_pm_event event_down)
> > +{
> > + int ret;
> > +
> > + /*
> > +* __atomic_notifier_call_chain has a RCU read critical section, which
>
> __atomic_notifier_call_chain() no longer exists.
>
> > +* could be disfunctional in cpu idle. Copy RCU_NONIDLE code to let
>
> "dysfunctional"
That's copy paste, I don't think I've read the comment, my bad.
> > @@ -156,43 +169,30 @@ int atomic_notifier_chain_unregister(str
> > }
> > EXPORT_SYMBOL_GPL(atomic_notifier_chain_unregister);
> >
> > -/**
> > - * __atomic_notifier_call_chain - Call functions in an atomic notifier
> > chain
> > - * @nh: Pointer to head of the atomic notifier chain
> > - * @val: Value passed unmodified to notifier function
> > - * @v: Pointer passed unmodified to notifier function
> > - * @nr_to_call: See the comment for notifier_call_chain.
> > - * @nr_calls: See the comment for notifier_call_chain.
> > - *
> > - * Calls each function in a notifier chain in turn. The functions
> > - * run in an atomic context, so they must not block.
> > - * This routine uses RCU to synchronize with changes to the chain.
> > - *
> > - * If the return value of the notifier can be and'ed
> > - * with %NOTIFY_STOP_MASK then atomic_notifier_call_chain()
> > - * will return immediately, with the return value of
> > - * the notifier function which halted execution.
> > - * Otherwise the return value is the return value
> > - * of the last notifier function called.
> > - */
>
> Why remove the useful comment?
Because I delete the whole function ?
Re: [PATCH 01/16] mm: use untagged_addr() for get_user_pages_fast addresses
On Fri, Jun 21, 2019 at 10:39:11AM -0300, Jason Gunthorpe wrote: > > Hmm, this function, and the other, goes on to do: > > if (unlikely(!access_ok((void __user *)start, len))) > return 0; > > and I thought that access_ok takes in the tagged pointer? > > How about re-order it a bit? The patch doesn't really work as-as an misses the main get_user_pages_fast fast path, but I'll add something equivalent.
Re: [PATCH v1 0/6] mm / virtio: Provide support for paravirtual waste page treatment
On 20.06.19 00:32, Alexander Duyck wrote: > This series provides an asynchronous means of hinting to a hypervisor > that a guest page is no longer in use and can have the data associated > with it dropped. To do this I have implemented functionality that allows > for what I am referring to as waste page treatment. > > I have based many of the terms and functionality off of waste water > treatment, the idea for the similarity occurred to me after I had reached > the point of referring to the hints as "bubbles", as the hints used the > same approach as the balloon functionality but would disappear if they > were touched, as a result I started to think of the virtio device as an > aerator. The general idea with all of this is that the guest should be > treating the unused pages so that when they end up heading "downstream" > to either another guest, or back at the host they will not need to be > written to swap. > > When the number of "dirty" pages in a given free_area exceeds our high > water mark, which is currently 32, we will schedule the aeration task to > start going through and scrubbing the zone. While the scrubbing is taking > place a boundary will be defined that we use to seperate the "aerated" > pages from the "dirty" ones. We use the ZONE_AERATION_ACTIVE bit to flag > when these boundaries are in place. I still *detest* the terminology, sorry. Can't you come up with a simpler terminology that makes more sense in the context of operating systems and pages we want to hint to the hypervisor? (that is the only use case you are using it for so far) > > I am leaving a number of things hard-coded such as limiting the lowest > order processed to PAGEBLOCK_ORDER, and have left it up to the guest to > determine what batch size it wants to allocate to process the hints. > > My primary testing has just been to verify the memory is being freed after > allocation by running memhog 32g in the guest and watching the total free > memory via /proc/meminfo on the host. With this I have verified most of > the memory is freed after each iteration. As far as performance I have > been mainly focusing on the will-it-scale/page_fault1 test running with > 16 vcpus. With that I have seen a less than 1% difference between the 1% throughout all benchmarks? Guess that is quite good. > base kernel without these patches, with the patches and virtio-balloon > disabled, and with the patches and virtio-balloon enabled with hinting. > > Changes from the RFC: > Moved aeration requested flag out of aerator and into zone->flags. > Moved boundary out of free_area and into local variables for aeration. > Moved aeration cycle out of interrupt and into workqueue. > Left nr_free as total pages instead of splitting it between raw and aerated. > Combined size and physical address values in virtio ring into one 64b value. > Restructured the patch set to reduce patches from 11 to 6. > I'm planning to look into the details, but will be on PTO for two weeks starting this Saturday (and still have other things to finish first :/ ). > --- > > Alexander Duyck (6): > mm: Adjust shuffle code to allow for future coalescing > mm: Move set/get_pcppage_migratetype to mmzone.h > mm: Use zone and order instead of free area in free_list manipulators > mm: Introduce "aerated" pages > mm: Add logic for separating "aerated" pages from "raw" pages > virtio-balloon: Add support for aerating memory via hinting > > > drivers/virtio/Kconfig |1 > drivers/virtio/virtio_balloon.c | 110 ++ > include/linux/memory_aeration.h | 118 +++ > include/linux/mmzone.h | 113 +-- > include/linux/page-flags.h |8 + > include/uapi/linux/virtio_balloon.h |1 > mm/Kconfig |5 + > mm/Makefile |1 > mm/aeration.c | 270 > +++ > mm/page_alloc.c | 203 ++ > mm/shuffle.c| 24 --- > mm/shuffle.h| 35 + > 12 files changed, 753 insertions(+), 136 deletions(-) > create mode 100644 include/linux/memory_aeration.h > create mode 100644 mm/aeration.c Compared to 17 files changed, 838 insertions(+), 86 deletions(-) create mode 100644 include/linux/memory_aeration.h create mode 100644 mm/aeration.c this looks like a good improvement :) -- Thanks, David / dhildenb
Re: drivers: Adjust scope for CONFIG_HAS_IOMEM before devm_platform_ioremap_resource()
> Why are you all arguing with a all-but-instinguishable-from-a-bot persona I am curious if another meeting at a Linux conference can adjust this view. > about a patch that I will never apply? I hope that you can get into a more constructive mood a bit later for the reconsideration of the position for the preprocessor statement “#ifdef CONFIG_HAS_IOMEM” before a function implementation. Regards, Markus
Re: [PATCH 2/3] module: Fix up module_notifier return values.
On Mon, Jun 24, 2019 at 04:58:10PM -0400, Frank Ch. Eigler wrote: > Hi - > > > > While auditing all module notifiers I noticed a whole bunch of fail > > > wrt the return value. Notifiers have a 'special' return semantics. > > From peterz's comments, the patches, it's not obvious to me how one is > to choose between 0 (NOTIFY_DONE) and 1 (NOTIFY_OK) in the case of a > routine success. I'm not sure either; what I think I choice was: - if I want to completely ignore the callback, use DONE (per the "Don't care" comment). - if we finished the notifier without error, use OK or notifier_from_errno(0). But yes, its a bit of a shit interface.
Re: [PATCH 01/16] mm: use untagged_addr() for get_user_pages_fast addresses
On Fri, Jun 21, 2019 at 10:39:11AM -0300, Jason Gunthorpe wrote: > Hmm, this function, and the other, goes on to do: > > if (unlikely(!access_ok((void __user *)start, len))) > return 0; > > and I thought that access_ok takes in the tagged pointer? > > How about re-order it a bit? Actually.. I we reorder this we'd need to to duplicate a few things due to the zero/negative length checking. Given the feedback from Khalid I'd thus rather skip the reorder for now. If we have a good reason we could add it back, but it would be a bit involved.
Re: [PATCH] get_maintainer: Add --cc option
On Mon, Jun 24, 2019 at 01:42:13PM -0700, Joe Perches wrote:
> On Mon, 2019-06-24 at 22:25 +0200, Peter Zijlstra wrote:
> > I hate it when people cross-post to moderated lists, and
> > this thing just made me do it :-(
>
> Maybe:
That seems to work,
Tested-by: Peter Zijlstra (Intel)
Thanks!
> ---
> scripts/get_maintainer.pl | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index c1c088ef1420..8c2fc22f3a11 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -27,6 +27,7 @@ my $email_usename = 1;
> my $email_maintainer = 1;
> my $email_reviewer = 1;
> my $email_list = 1;
> +my $email_moderated_list = 1;
> my $email_subscriber_list = 0;
> my $email_git_penguin_chiefs = 0;
> my $email_git = 0;
> @@ -248,6 +249,7 @@ if (!GetOptions(
> 'r!' => \$email_reviewer,
> 'n!' => \$email_usename,
> 'l!' => \$email_list,
> + 'moderated!' => \$email_moderated_list,
> 's!' => \$email_subscriber_list,
> 'multiline!' => \$output_multiline,
> 'roles!' => \$output_roles,
> @@ -1023,7 +1025,8 @@ MAINTAINER field selection options:
> --r => include reviewer(s) if any
> --n => include name 'Full Name '
> --l => include list(s) if any
> ---s => include subscriber only list(s) if any
> +--moderated => include moderated lists(s) if any (default: true)
> +--s => include subscriber only list(s) if any (default: false)
> --remove-duplicates => minimize duplicate email names/addresses
> --roles => show roles (status:subsystem, git-signer, list, etc...)
> --rolestats => show roles and statistics (commits/total_commits, %)
> @@ -1313,11 +1316,14 @@ sub add_categories {
> } else {
> if ($email_list) {
> if (!$hash_list_to{lc($list_address)}) {
> - $hash_list_to{lc($list_address)} = 1;
> if ($list_additional =~ m/moderated/) {
> - push(@list_to, [$list_address,
> - "moderated list${list_role}"]);
> + if ($email_moderated_list) {
> + $hash_list_to{lc($list_address)} = 1;
> + push(@list_to, [$list_address,
> + "moderated
> list${list_role}"]);
> + }
> } else {
> + $hash_list_to{lc($list_address)} = 1;
> push(@list_to, [$list_address,
> "open list${list_role}"]);
> }
>
>
RE: stmmac regression on ASUS TinkerBoard
From: Katsuhiro Suzuki > I checked drivers/net/ethernet/stmicro/stmmac/stmmac_main.c and found > stmmac_init_phy() is going to fail if ethernet device node does not > have following property: >- phy-handle >- phy >- phy-device > > This commit broke the device-trees such as TinkerBoard. The mdio > subnode creating a mdio bus is changed to required or still optional? Yeah, with PHYLINK the PHY binding is always required ... How do you want to proceed ? I think DT bindings can never break between releases so I will probably need to cook a patch for stmmac. Thanks, Jose Miguel Abreu
Re: nl80211 wlcore regression in next
On Tue, 2019-06-25 at 00:38 -0700, Tony Lindgren wrote:
> Hi,
>
> Looks like at least drivers/net/wireless/ti wlcore driver has stopped
> working in Linux next with commit 901bb9891855 ("nl80211: require and
> validate vendor command policy"). Reverting the commit above makes it
> work again.
>
> It fails with the warning below, any ideas what goes wrong?
Oops. For some reason, I neglected to check the vendor command usage
beyond hwsim.
The patch below should work?
johannes
diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index 804955d24b30..37ac95940c22 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -177,6 +177,7 @@ static const struct wiphy_vendor_command
wil_nl80211_vendor_commands[] = {
.info.subcmd = QCA_NL80211_VENDOR_SUBCMD_DMG_RF_GET_SECTOR_CFG,
.flags = WIPHY_VENDOR_CMD_NEED_WDEV |
WIPHY_VENDOR_CMD_NEED_RUNNING,
+ .policy = wil_rf_sector_policy,
.doit = wil_rf_sector_get_cfg
},
{
@@ -184,6 +185,7 @@ static const struct wiphy_vendor_command
wil_nl80211_vendor_commands[] = {
.info.subcmd = QCA_NL80211_VENDOR_SUBCMD_DMG_RF_SET_SECTOR_CFG,
.flags = WIPHY_VENDOR_CMD_NEED_WDEV |
WIPHY_VENDOR_CMD_NEED_RUNNING,
+ .policy = wil_rf_sector_policy,
.doit = wil_rf_sector_set_cfg
},
{
@@ -192,6 +194,7 @@ static const struct wiphy_vendor_command
wil_nl80211_vendor_commands[] = {
QCA_NL80211_VENDOR_SUBCMD_DMG_RF_GET_SELECTED_SECTOR,
.flags = WIPHY_VENDOR_CMD_NEED_WDEV |
WIPHY_VENDOR_CMD_NEED_RUNNING,
+ .policy = wil_rf_sector_policy,
.doit = wil_rf_sector_get_selected
},
{
@@ -200,6 +203,7 @@ static const struct wiphy_vendor_command
wil_nl80211_vendor_commands[] = {
QCA_NL80211_VENDOR_SUBCMD_DMG_RF_SET_SELECTED_SECTOR,
.flags = WIPHY_VENDOR_CMD_NEED_WDEV |
WIPHY_VENDOR_CMD_NEED_RUNNING,
+ .policy = wil_rf_sector_policy,
.doit = wil_rf_sector_set_selected
},
};
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
index d493021f6031..30ebadc5e5bb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/vendor.c
@@ -123,6 +123,7 @@ const struct wiphy_vendor_command brcmf_vendor_cmds[] = {
},
.flags = WIPHY_VENDOR_CMD_NEED_WDEV |
WIPHY_VENDOR_CMD_NEED_NETDEV,
+ .policy = VENDOR_CMD_RAW_DATA,
.doit = brcmf_cfg80211_vndr_cmds_dcmd_handler
},
};
diff --git a/drivers/net/wireless/ti/wlcore/vendor_cmd.c
b/drivers/net/wireless/ti/wlcore/vendor_cmd.c
index 75756fb8e7b0..cd82d3580e87 100644
--- a/drivers/net/wireless/ti/wlcore/vendor_cmd.c
+++ b/drivers/net/wireless/ti/wlcore/vendor_cmd.c
@@ -166,6 +166,7 @@ static const struct wiphy_vendor_command
wlcore_vendor_commands[] = {
.flags = WIPHY_VENDOR_CMD_NEED_NETDEV |
WIPHY_VENDOR_CMD_NEED_RUNNING,
.doit = wlcore_vendor_cmd_smart_config_start,
+ .policy = wlcore_vendor_attr_policy,
},
{
.info = {
@@ -175,6 +176,7 @@ static const struct wiphy_vendor_command
wlcore_vendor_commands[] = {
.flags = WIPHY_VENDOR_CMD_NEED_NETDEV |
WIPHY_VENDOR_CMD_NEED_RUNNING,
.doit = wlcore_vendor_cmd_smart_config_stop,
+ .policy = wlcore_vendor_attr_policy,
},
{
.info = {
@@ -184,6 +186,7 @@ static const struct wiphy_vendor_command
wlcore_vendor_commands[] = {
.flags = WIPHY_VENDOR_CMD_NEED_NETDEV |
WIPHY_VENDOR_CMD_NEED_RUNNING,
.doit = wlcore_vendor_cmd_smart_config_set_group_key,
+ .policy = wlcore_vendor_attr_policy,
},
};
Re: [PATCH 04/16] MIPS: use the generic get_user_pages_fast code
On Fri, Jun 21, 2019 at 11:05:42AM -0300, Jason Gunthorpe wrote:
> Today this check is only being done on the get_user_pages_fast() -
> after this patch it is also done for __get_user_pages_fast().
>
> Which means __get_user_pages_fast is now non-functional on a range of
> MIPS CPUs, but that seems OK as far as I can tell, so:
> However, looks to me like this patch is also a bug fix for this:
Yes.
> > - pgdp = pgd_offset(mm, addr);
> > - do {
> > - pgd_t pgd = *pgdp;
> > -
> > - next = pgd_addr_end(addr, end);
> > - if (pgd_none(pgd))
> > - goto slow;
> > - if (!gup_pud_range(pgd, addr, next, gup_flags & FOLL_WRITE,
> > - pages, ))
>
> This is different too, the core code has a p4d layer, but I see that
> whole thing gets NOP'd by the compiler as mips uses pgtable-nop4d.h -
> right?
Exactly.
Re: linux-next: build failure after merge of the tip tree
Thomas Gleixner writes: > On Tue, 25 Jun 2019, Stephen Rothwell wrote: > >> Hi Kalle, >> >> On Tue, 25 Jun 2019 09:23:33 +0300 Kalle Valo wrote: >> > >> > Thanks for the report. Any suggestions how to handle this? Or do we let >> > Linus take care of this? >> >> Just let Linus take care of it ... mention it in the pull request ... I >> guess DaveM needs to know, right? > > Ah. I didn't realize that this is a new commit in Kalle's tree. So yes > that's the right thing to do. Good, I'll do that then. -- Kalle Valo
Re: [PATCH][next] media: vivid: fix potential integer overflow on left shift
Am 24.06.2019 23:58, schrieb Colin King:
> From: Colin Ian King
>
> There is a potential integer overflow when int 2 is left shifted
> as this is evaluated using 32 bit arithmetic but is being used in
> a context that expects an expression of type s64. Fix this by
> shifting 2ULL to avoid a 32 bit overflow.
>
> Addresses-Coverity: ("Unintentional integer overflow")
> Fixes: 8a99e9faa131 ("media: vivid: add HDMI (dis)connect RX emulation")
> Fixes: 79a792dafac6 ("media: vivid: add HDMI (dis)connect TX emulation")
> Signed-off-by: Colin Ian King
> ---
> drivers/media/platform/vivid/vivid-ctrls.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/platform/vivid/vivid-ctrls.c
> b/drivers/media/platform/vivid/vivid-ctrls.c
> index 3e916c8befb7..8f340cfd6993 100644
> --- a/drivers/media/platform/vivid/vivid-ctrls.c
> +++ b/drivers/media/platform/vivid/vivid-ctrls.c
> @@ -1634,8 +1634,8 @@ int vivid_create_controls(struct vivid_dev *dev, bool
> show_ccs_cap,
> 0, V4L2_DV_RGB_RANGE_AUTO);
> dev->ctrl_rx_power_present = v4l2_ctrl_new_std(hdl_vid_cap,
> NULL, V4L2_CID_DV_RX_POWER_PRESENT, 0,
> - (2 << (dev->num_hdmi_inputs - 1)) - 1, 0,
> - (2 << (dev->num_hdmi_inputs - 1)) - 1);
> + (2ULL << (dev->num_hdmi_inputs - 1)) - 1, 0,
> + (2ULL << (dev->num_hdmi_inputs - 1)) - 1);
>
> }
> if (dev->num_hdmi_outputs) {
> @@ -1653,16 +1653,16 @@ int vivid_create_controls(struct vivid_dev *dev, bool
> show_ccs_cap,
> _ctrl_display_present, NULL);
> dev->ctrl_tx_hotplug = v4l2_ctrl_new_std(hdl_vid_out,
> NULL, V4L2_CID_DV_TX_HOTPLUG, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1);
> + (2ULL << (dev->num_hdmi_outputs - 1)) - 1, 0,
> + (2ULL << (dev->num_hdmi_outputs - 1)) - 1);
> dev->ctrl_tx_rxsense = v4l2_ctrl_new_std(hdl_vid_out,
> NULL, V4L2_CID_DV_TX_RXSENSE, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1);
> + (2ULL << (dev->num_hdmi_outputs - 1)) - 1, 0,
> + (2ULL << (dev->num_hdmi_outputs - 1)) - 1);
> dev->ctrl_tx_edid_present = v4l2_ctrl_new_std(hdl_vid_out,
> NULL, V4L2_CID_DV_TX_EDID_PRESENT, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1, 0,
> - (2 << (dev->num_hdmi_outputs - 1)) - 1);
> + (2ULL << (dev->num_hdmi_outputs - 1)) - 1, 0,
> + (2ULL << (dev->num_hdmi_outputs - 1)) - 1);
> }
> if ((dev->has_vid_cap && dev->has_vid_out) ||
> (dev->has_vbi_cap && dev->has_vbi_out))
To make this more readable for humans, it could help to store
(2ULL << (dev->num_hdmi_outputs - 1)) - 1 in an intermediate.
like:
s64 hdmi=(2ULL << (dev->num_hdmi_outputs - 1)) - 1;
dev->ctrl_tx_edid_present = v4l2_ctrl_new_std(hdl_vid_out,
NULL, V4L2_CID_DV_TX_EDID_PRESENT, 0,
hdmi, 0,hdmi);
just my 2 cents,
re,
wh
[tip:timers/vdso] vdso: Remove superfluous #ifdef __KERNEL__ in vdso/datapage.h
Commit-ID: 4d33ebb02c45738296ffde4b8f2089edaf75be1c
Gitweb: https://git.kernel.org/tip/4d33ebb02c45738296ffde4b8f2089edaf75be1c
Author: Catalin Marinas
AuthorDate: Mon, 24 Jun 2019 14:56:24 +0100
Committer: Thomas Gleixner
CommitDate: Tue, 25 Jun 2019 09:43:38 +0200
vdso: Remove superfluous #ifdef __KERNEL__ in vdso/datapage.h
With the move to UAPI headers, such #ifdefs are no longer necessary.
Fixes: 361f8aee9b09 ("vdso: Define standardized vdso_datapage")
Signed-off-by: Catalin Marinas
Cc: Vincenzo Frascino
Cc: linux-a...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
Cc: Will Deacon
Cc: Arnd Bergmann
Cc: Russell King
Cc: Ralf Baechle
Cc: Paul Burton
Cc: Daniel Lezcano
Cc: Mark Salyzyn
Cc: Peter Collingbourne
Cc: Shuah Khan
Cc: Dmitry Safonov <0x7f454...@gmail.com>
Cc: Rasmus Villemoes
Cc: Huw Davies
Cc: Shijith Thotton
Cc: Andre Przywara
Link: https://lkml.kernel.org/r/20190624135624.gb29...@arrakis.emea.arm.com
---
include/vdso/datapage.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/vdso/datapage.h b/include/vdso/datapage.h
index e6eb36c3d54f..2e302c0f41f7 100644
--- a/include/vdso/datapage.h
+++ b/include/vdso/datapage.h
@@ -2,8 +2,6 @@
#ifndef __VDSO_DATAPAGE_H
#define __VDSO_DATAPAGE_H
-#ifdef __KERNEL__
-
#ifndef __ASSEMBLY__
#include
@@ -88,6 +86,4 @@ extern struct vdso_data _vdso_data[CS_BASES]
__attribute__((visibility("hidden")
#endif /* !__ASSEMBLY__ */
-#endif /* __KERNEL__ */
-
#endif /* __VDSO_DATAPAGE_H */
[PATCH v2 0/6] VAG power control improvement for sgtl5000 codec
VAG power control is improved to fit the manual. This fixes as minimum one bug: if customer muxes Headphone to Line-In right after boot w/o playing any sound, the VAG power remains off that leads to poor sound quality from line-in. I.e. after boot: - Connect sound source to Line-In jack; - Connect headphone to HP jack; - Run following commands: $ amixer set 'Headphone' 80% $ amixer set 'Headphone Mux' LINE_IN Also this series includes fixes of non-important bugs in sgtl5000 codec driver. Fix patch formatting in patchset v2. Oleksandr Suvorov (6): ASoC: sgtl5000: Fix definition of VAG Ramp Control ASoC: sgtl5000: add ADC mute control ASoC: sgtl5000: Fix of unmute outputs on probe ASoC: sgtl5000: Fix charge pump source assignment ASoC: Define a set of DAPM pre/post-up events ASoC: sgtl5000: Improve VAG power and mute control include/sound/soc-dapm.h| 2 + sound/soc/codecs/sgtl5000.c | 250 ++-- sound/soc/codecs/sgtl5000.h | 2 +- 3 files changed, 212 insertions(+), 42 deletions(-) -- 2.20.1
[PATCH v2 1/6] ASoC: sgtl5000: Fix definition of VAG Ramp Control
SGTL5000_SMALL_POP is a bit mask, not a value. Usage of correct definition makes device probing code more clear. Signed-off-by: Oleksandr Suvorov --- sound/soc/codecs/sgtl5000.c | 2 +- sound/soc/codecs/sgtl5000.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c index a6a4748c97f9d..5e49523ee0b67 100644 --- a/sound/soc/codecs/sgtl5000.c +++ b/sound/soc/codecs/sgtl5000.c @@ -1296,7 +1296,7 @@ static int sgtl5000_probe(struct snd_soc_component *component) /* enable small pop, introduce 400ms delay in turning off */ snd_soc_component_update_bits(component, SGTL5000_CHIP_REF_CTRL, - SGTL5000_SMALL_POP, 1); + SGTL5000_SMALL_POP, SGTL5000_SMALL_POP); /* disable short cut detector */ snd_soc_component_write(component, SGTL5000_CHIP_SHORT_CTRL, 0); diff --git a/sound/soc/codecs/sgtl5000.h b/sound/soc/codecs/sgtl5000.h index 18cae08bbd3a6..a4bf4bca95bf7 100644 --- a/sound/soc/codecs/sgtl5000.h +++ b/sound/soc/codecs/sgtl5000.h @@ -273,7 +273,7 @@ #define SGTL5000_BIAS_CTRL_MASK0x000e #define SGTL5000_BIAS_CTRL_SHIFT 1 #define SGTL5000_BIAS_CTRL_WIDTH 3 -#define SGTL5000_SMALL_POP 1 +#define SGTL5000_SMALL_POP 0x0001 /* * SGTL5000_CHIP_MIC_CTRL -- 2.20.1
[PATCH v2 6/6] ASoC: sgtl5000: Improve VAG power and mute control
Change VAG power on/off control according to the following algorithm:
- turn VAG power ON on the 1st incoming event.
- keep it ON if there is any active VAG consumer (ADC/DAC/HP/Line-In).
- turn VAG power OFF when there is the latest consumer's pre-down event
come.
- always delay after VAG power OFF to avoid pop.
- delay after VAG power ON if the initiative consumer is Line-In, this
prevents pop during line-in muxing.
Also, according to the manual, to avoid any pops/clicks,
the outputs should be muted during input/output
routing changes.
Signed-off-by: Oleksandr Suvorov
---
sound/soc/codecs/sgtl5000.c | 227 +++-
1 file changed, 195 insertions(+), 32 deletions(-)
diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index ee1e4bf613227..acfbd5cdf936e 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -31,6 +31,13 @@
#define SGTL5000_DAP_REG_OFFSET0x0100
#define SGTL5000_MAX_REG_OFFSET0x013A
+/* Delay for the VAG ramp up */
+#define SGTL5000_VAG_POWERUP_DELAY 500 /* ms */
+/* Delay for the VAG ramp down */
+#define SGTL5000_VAG_POWERDOWN_DELAY 500 /* ms */
+
+#define SGTL5000_OUTPUTS_MUTE (SGTL5000_HP_MUTE | SGTL5000_LINE_OUT_MUTE)
+
/* default value of sgtl5000 registers */
static const struct reg_default sgtl5000_reg_defaults[] = {
{ SGTL5000_CHIP_DIG_POWER, 0x },
@@ -123,6 +130,18 @@ enum {
I2S_SCLK_STRENGTH_HIGH,
};
+enum {
+ HP_POWER_EVENT,
+ DAC_POWER_EVENT,
+ ADC_POWER_EVENT
+};
+
+struct sgtl5000_mute_state {
+ u16 hp_event;
+ u16 dac_event;
+ u16 adc_event;
+};
+
/* sgtl5000 private structure in codec */
struct sgtl5000_priv {
int sysclk; /* sysclk rate */
@@ -137,8 +156,109 @@ struct sgtl5000_priv {
u8 micbias_voltage;
u8 lrclk_strength;
u8 sclk_strength;
+ struct sgtl5000_mute_state mute_state;
};
+static inline int hp_sel_input(struct snd_soc_component *component)
+{
+ return (snd_soc_component_read32(component, SGTL5000_CHIP_ANA_CTRL) &
+ SGTL5000_HP_SEL_MASK) >> SGTL5000_HP_SEL_SHIFT;
+}
+
+static inline u16 mute_output(struct snd_soc_component *component,
+ u16 mute_mask)
+{
+ u16 mute_reg = snd_soc_component_read32(component,
+ SGTL5000_CHIP_ANA_CTRL);
+
+ snd_soc_component_update_bits(component, SGTL5000_CHIP_ANA_CTRL,
+ mute_mask, mute_mask);
+ return mute_reg;
+}
+
+static inline void restore_output(struct snd_soc_component *component,
+ u16 mute_mask, u16 mute_reg)
+{
+ snd_soc_component_update_bits(component, SGTL5000_CHIP_ANA_CTRL,
+ mute_mask, mute_reg);
+}
+
+static void vag_power_on(struct snd_soc_component *component, u32 source)
+{
+ if (snd_soc_component_read32(component, SGTL5000_CHIP_ANA_POWER) &
+ SGTL5000_VAG_POWERUP)
+ return;
+
+ snd_soc_component_update_bits(component, SGTL5000_CHIP_ANA_POWER,
+ SGTL5000_VAG_POWERUP, SGTL5000_VAG_POWERUP);
+
+ /* When VAG powering on to get local loop from Line-In, the sleep
+* is required to avoid loud pop.
+*/
+ if (hp_sel_input(component) == SGTL5000_HP_SEL_LINE_IN &&
+ source == HP_POWER_EVENT)
+ msleep(SGTL5000_VAG_POWERUP_DELAY);
+}
+
+static int vag_power_consumers(struct snd_soc_component *component,
+ u16 ana_pwr_reg, u32 source)
+{
+ int consumers = 0;
+
+ /* count dac/adc consumers unconditional */
+ if (ana_pwr_reg & SGTL5000_DAC_POWERUP)
+ consumers++;
+ if (ana_pwr_reg & SGTL5000_ADC_POWERUP)
+ consumers++;
+
+ /*
+* If the event comes from HP and Line-In is selected,
+* current action is 'DAC to be powered down'.
+* As HP_POWERUP is not set when HP muxed to line-in,
+* we need to keep VAG power ON.
+*/
+ if (source == HP_POWER_EVENT) {
+ if (hp_sel_input(component) == SGTL5000_HP_SEL_LINE_IN)
+ consumers++;
+ } else {
+ if (ana_pwr_reg & SGTL5000_HP_POWERUP)
+ consumers++;
+ }
+
+ return consumers;
+}
+
+static void vag_power_off(struct snd_soc_component *component, u32 source)
+{
+ u16 ana_pwr = snd_soc_component_read32(component,
+SGTL5000_CHIP_ANA_POWER);
+
+ if (!(ana_pwr & SGTL5000_VAG_POWERUP))
+ return;
+
+ /*
+* This function calls when any of VAG power consumers is disappearing.
+* Thus, if there is more than one consumer at the moment, as minimum
+* one consumer will definitely stay after the end of the current
+* event.
+* Don't clear VAG_POWERUP if 2 or more
[PATCH v2 2/6] ASoC: sgtl5000: add ADC mute control
This control mute/unmute the ADC input of SGTL5000
using its CHIP_ANA_CTRL register.
Signed-off-by: Oleksandr Suvorov
---
sound/soc/codecs/sgtl5000.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index 5e49523ee0b67..bb58c997c6914 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -556,6 +556,7 @@ static const struct snd_kcontrol_new
sgtl5000_snd_controls[] = {
SGTL5000_CHIP_ANA_ADC_CTRL,
8, 1, 0, capture_6db_attenuate),
SOC_SINGLE("Capture ZC Switch", SGTL5000_CHIP_ANA_CTRL, 1, 1, 0),
+ SOC_SINGLE("Capture Switch", SGTL5000_CHIP_ANA_CTRL, 0, 1, 1),
SOC_DOUBLE_TLV("Headphone Playback Volume",
SGTL5000_CHIP_ANA_HP_CTRL,
--
2.20.1
[PATCH v2 3/6] ASoC: sgtl5000: Fix of unmute outputs on probe
To enable "zero cross detect" for ADC/HP, change HP_ZCD_EN/ADC_ZCD_EN bits only instead of writing the whole CHIP_ANA_CTRL register. Signed-off-by: Oleksandr Suvorov --- sound/soc/codecs/sgtl5000.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c index bb58c997c6914..e813a37910af4 100644 --- a/sound/soc/codecs/sgtl5000.c +++ b/sound/soc/codecs/sgtl5000.c @@ -1289,6 +1289,7 @@ static int sgtl5000_probe(struct snd_soc_component *component) int ret; u16 reg; struct sgtl5000_priv *sgtl5000 = snd_soc_component_get_drvdata(component); + unsigned int zcd_mask = SGTL5000_HP_ZCD_EN | SGTL5000_ADC_ZCD_EN; /* power up sgtl5000 */ ret = sgtl5000_set_power_regs(component); @@ -1316,9 +1317,8 @@ static int sgtl5000_probe(struct snd_soc_component *component) 0x1f); snd_soc_component_write(component, SGTL5000_CHIP_PAD_STRENGTH, reg); - snd_soc_component_write(component, SGTL5000_CHIP_ANA_CTRL, - SGTL5000_HP_ZCD_EN | - SGTL5000_ADC_ZCD_EN); + snd_soc_component_update_bits(component, SGTL5000_CHIP_ANA_CTRL, + zcd_mask, zcd_mask); snd_soc_component_update_bits(component, SGTL5000_CHIP_MIC_CTRL, SGTL5000_BIAS_R_MASK, -- 2.20.1
[PATCH v2 4/6] ASoC: sgtl5000: Fix charge pump source assignment
If VDDA != VDDIO and any of them is greater than 3.1V, charge pump
source can be assigned automatically.
Signed-off-by: Oleksandr Suvorov
---
sound/soc/codecs/sgtl5000.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index e813a37910af4..ee1e4bf613227 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -1174,12 +1174,16 @@ static int sgtl5000_set_power_regs(struct
snd_soc_component *component)
SGTL5000_INT_OSC_EN);
/* Enable VDDC charge pump */
ana_pwr |= SGTL5000_VDDC_CHRGPMP_POWERUP;
- } else if (vddio >= 3100 && vdda >= 3100) {
+ } else {
ana_pwr &= ~SGTL5000_VDDC_CHRGPMP_POWERUP;
- /* VDDC use VDDIO rail */
- lreg_ctrl |= SGTL5000_VDDC_ASSN_OVRD;
- lreg_ctrl |= SGTL5000_VDDC_MAN_ASSN_VDDIO <<
- SGTL5000_VDDC_MAN_ASSN_SHIFT;
+ /* if vddio == vdda the source of charge pump should be
+* assigned manually to VDDIO
+*/
+ if (vddio == vdda) {
+ lreg_ctrl |= SGTL5000_VDDC_ASSN_OVRD;
+ lreg_ctrl |= SGTL5000_VDDC_MAN_ASSN_VDDIO <<
+ SGTL5000_VDDC_MAN_ASSN_SHIFT;
+ }
}
snd_soc_component_write(component, SGTL5000_CHIP_LINREG_CTRL,
lreg_ctrl);
--
2.20.1
[PATCH v2 5/6] ASoC: Define a set of DAPM pre/post-up events
Prepare to use SND_SOC_DAPM_PRE_POST_PMU definition to reduce coming code size and make it more readable. Signed-off-by: Oleksandr Suvorov --- include/sound/soc-dapm.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h index c00a0b8ade086..6c66941601307 100644 --- a/include/sound/soc-dapm.h +++ b/include/sound/soc-dapm.h @@ -353,6 +353,8 @@ struct device; #define SND_SOC_DAPM_WILL_PMD 0x80/* called at start of sequence */ #define SND_SOC_DAPM_PRE_POST_PMD \ (SND_SOC_DAPM_PRE_PMD | SND_SOC_DAPM_POST_PMD) +#define SND_SOC_DAPM_PRE_POST_PMU \ + (SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMU) /* convenience event type detection */ #define SND_SOC_DAPM_EVENT_ON(e) \ -- 2.20.1
[tip:timers/vdso] arm64: vdso: Remove unnecessary asm-offsets.c definitions
Commit-ID: b4b12aca00d509a233abd28990194628adcd71e6
Gitweb: https://git.kernel.org/tip/b4b12aca00d509a233abd28990194628adcd71e6
Author: Catalin Marinas
AuthorDate: Mon, 24 Jun 2019 14:58:12 +0100
Committer: Thomas Gleixner
CommitDate: Tue, 25 Jun 2019 09:43:38 +0200
arm64: vdso: Remove unnecessary asm-offsets.c definitions
Since the VDSO code has moved to C from assembly, there is no need to
define and maintain the corresponding asm offsets.
Fixes: 28b1a824a4f4 ("arm64: vdso: Substitute gettimeofday() with C
implementation")
Signed-off-by: Catalin Marinas
Cc: Vincenzo Frascino
Cc: linux-a...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
Cc: Will Deacon
Cc: Arnd Bergmann
Cc: Russell King
Cc: Ralf Baechle
Cc: Paul Burton
Cc: Daniel Lezcano
Cc: Mark Salyzyn
Cc: Peter Collingbourne
Cc: Shuah Khan
Cc: Dmitry Safonov <0x7f454...@gmail.com>
Cc: Rasmus Villemoes
Cc: Huw Davies
Cc: Shijith Thotton
Cc: Andre Przywara
Link: https://lkml.kernel.org/r/20190624135812.gc29...@arrakis.emea.arm.com
---
arch/arm64/kernel/asm-offsets.c | 39 ---
1 file changed, 39 deletions(-)
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index e6f7409a78a4..214685760e1c 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -86,44 +85,6 @@ int main(void)
BLANK();
DEFINE(PREEMPT_DISABLE_OFFSET, PREEMPT_DISABLE_OFFSET);
BLANK();
- DEFINE(CLOCK_REALTIME, CLOCK_REALTIME);
- DEFINE(CLOCK_MONOTONIC, CLOCK_MONOTONIC);
- DEFINE(CLOCK_MONOTONIC_RAW, CLOCK_MONOTONIC_RAW);
- DEFINE(CLOCK_REALTIME_RES, offsetof(struct vdso_data, hrtimer_res));
- DEFINE(CLOCK_REALTIME_COARSE,CLOCK_REALTIME_COARSE);
- DEFINE(CLOCK_MONOTONIC_COARSE,CLOCK_MONOTONIC_COARSE);
- DEFINE(CLOCK_COARSE_RES, LOW_RES_NSEC);
- DEFINE(NSEC_PER_SEC, NSEC_PER_SEC);
- BLANK();
- DEFINE(VDSO_SEQ, offsetof(struct vdso_data, seq));
- DEFINE(VDSO_CLK_MODE,offsetof(struct vdso_data, clock_mode));
- DEFINE(VDSO_CYCLE_LAST, offsetof(struct vdso_data, cycle_last));
- DEFINE(VDSO_MASK,offsetof(struct vdso_data, mask));
- DEFINE(VDSO_MULT,offsetof(struct vdso_data, mult));
- DEFINE(VDSO_SHIFT, offsetof(struct vdso_data, shift));
- DEFINE(VDSO_REALTIME_SEC,offsetof(struct vdso_data,
basetime[CLOCK_REALTIME].sec));
- DEFINE(VDSO_REALTIME_NSEC, offsetof(struct vdso_data,
basetime[CLOCK_REALTIME].nsec));
- DEFINE(VDSO_MONO_SEC,offsetof(struct vdso_data,
basetime[CLOCK_MONOTONIC].sec));
- DEFINE(VDSO_MONO_NSEC, offsetof(struct vdso_data,
basetime[CLOCK_MONOTONIC].nsec));
- DEFINE(VDSO_MONO_RAW_SEC,offsetof(struct vdso_data,
basetime[CLOCK_MONOTONIC_RAW].sec));
- DEFINE(VDSO_MONO_RAW_NSEC, offsetof(struct vdso_data,
basetime[CLOCK_MONOTONIC_RAW].nsec));
- DEFINE(VDSO_BOOTTIME_SEC,offsetof(struct vdso_data,
basetime[CLOCK_BOOTTIME].sec));
- DEFINE(VDSO_BOOTTIME_NSEC, offsetof(struct vdso_data,
basetime[CLOCK_BOOTTIME].nsec));
- DEFINE(VDSO_TAI_SEC, offsetof(struct vdso_data,
basetime[CLOCK_TAI].sec));
- DEFINE(VDSO_TAI_NSEC,offsetof(struct vdso_data,
basetime[CLOCK_TAI].nsec));
- DEFINE(VDSO_RT_COARSE_SEC, offsetof(struct vdso_data,
basetime[CLOCK_REALTIME_COARSE].sec));
- DEFINE(VDSO_RT_COARSE_NSEC, offsetof(struct vdso_data,
basetime[CLOCK_REALTIME_COARSE].nsec));
- DEFINE(VDSO_MONO_COARSE_SEC, offsetof(struct vdso_data,
basetime[CLOCK_MONOTONIC_COARSE].sec));
- DEFINE(VDSO_MONO_COARSE_NSEC,offsetof(struct vdso_data,
basetime[CLOCK_MONOTONIC_COARSE].nsec));
- DEFINE(VDSO_TZ_MINWEST, offsetof(struct vdso_data, tz_minuteswest));
- DEFINE(VDSO_TZ_DSTTIME, offsetof(struct vdso_data, tz_dsttime));
- BLANK();
- DEFINE(TVAL_TV_SEC, offsetof(struct timeval, tv_sec));
- DEFINE(TSPEC_TV_SEC, offsetof(struct timespec, tv_sec));
- BLANK();
- DEFINE(TZ_MINWEST, offsetof(struct timezone, tz_minuteswest));
- DEFINE(TZ_DSTTIME, offsetof(struct timezone, tz_dsttime));
- BLANK();
DEFINE(CPU_BOOT_STACK, offsetof(struct secondary_data, stack));
DEFINE(CPU_BOOT_TASK,offsetof(struct secondary_data, task));
BLANK();
Re: [PATCH 10/16] mm: rename CONFIG_HAVE_GENERIC_GUP to CONFIG_HAVE_FAST_GUP
On Fri, Jun 21, 2019 at 11:28:24AM -0300, Jason Gunthorpe wrote: > On Tue, Jun 11, 2019 at 04:40:56PM +0200, Christoph Hellwig wrote: > > We only support the generic GUP now, so rename the config option to > > be more clear, and always use the mm/Kconfig definition of the > > symbol and select it from the arch Kconfigs. > > Looks OK to me > > Reviewed-by: Jason Gunthorpe > > But could you also roll something like this in to the series? There is > no longer any reason for the special __weak stuff that I can see - > just follow the normal pattern for stubbing config controlled > functions through the header file. Something pretty similar is done later in this series.
Re: stmmac regression on ASUS TinkerBoard
Hi, Am Dienstag, 25. Juni 2019, 09:46:12 CEST schrieb Jose Abreu: > From: Katsuhiro Suzuki > > > I checked drivers/net/ethernet/stmicro/stmmac/stmmac_main.c and found > > stmmac_init_phy() is going to fail if ethernet device node does not > > have following property: > >- phy-handle > >- phy > >- phy-device > > > > This commit broke the device-trees such as TinkerBoard. The mdio > > subnode creating a mdio bus is changed to required or still optional? > > Yeah, with PHYLINK the PHY binding is always required ... > > How do you want to proceed ? I think DT bindings can never break between > releases so I will probably need to cook a patch for stmmac. Correct ... old devicetrees on new kernels should not break. Especially as this affects a big number of boards potentially loosing network support and in the devicetree binding the phy property is also marked as optional. Heiko
Re: [PATCH] time/tick-broadcast: Fix tick_broadcast_offline() lockdep complaint
On Tue, Jun 25, 2019 at 02:43:00AM +0200, Frederic Weisbecker wrote: > Yeah, unfortunately there is no atomic_add_not_zero_return(). There is atomic_fetch_add_unless().
Re: [PATCH v2 04/15] dt-bindings: display: Convert armadeus,st0700-adapt panel to DT schema
On Mon, Jun 24, 2019 at 03:56:38PM -0600, Rob Herring wrote: > Convert the armadeus,st0700-adapt panel binding to DT schema. > > Cc: Thierry Reding > Cc: Sam Ravnborg > Cc: Maxime Ripard > Cc: Laurent Pinchart > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Rob Herring Reviewed-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
[tip:timers/vdso] arm64: compat: No need for pre-ARMv7 barriers on an ARMv8 system
Commit-ID: 53d87b37a2a4a4b6b0c7f8073c4be04022252e26
Gitweb: https://git.kernel.org/tip/53d87b37a2a4a4b6b0c7f8073c4be04022252e26
Author: Catalin Marinas
AuthorDate: Mon, 24 Jun 2019 15:00:19 +0100
Committer: Thomas Gleixner
CommitDate: Tue, 25 Jun 2019 09:43:38 +0200
arm64: compat: No need for pre-ARMv7 barriers on an ARMv8 system
Remove the deprecated (pre-ARMv7) compat barriers as they would not be used
on an ARMv8 system.
Fixes: a7f71a2c8903 ("arm64: compat: Add vDSO")
Signed-off-by: Catalin Marinas
Cc: Vincenzo Frascino
Cc: linux-a...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
Cc: Will Deacon
Cc: Arnd Bergmann
Cc: Russell King
Cc: Ralf Baechle
Cc: Paul Burton
Cc: Daniel Lezcano
Cc: Mark Salyzyn
Cc: Peter Collingbourne
Cc: Shuah Khan
Cc: Dmitry Safonov <0x7f454...@gmail.com>
Cc: Rasmus Villemoes
Cc: Huw Davies
Cc: Shijith Thotton
Cc: Andre Przywara
Link: https://lkml.kernel.org/r/20190624140018.gd29...@arrakis.emea.arm.com
---
arch/arm64/include/asm/vdso/compat_barrier.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arm64/include/asm/vdso/compat_barrier.h
b/arch/arm64/include/asm/vdso/compat_barrier.h
index ea24ea856b07..fb60a88b5ed4 100644
--- a/arch/arm64/include/asm/vdso/compat_barrier.h
+++ b/arch/arm64/include/asm/vdso/compat_barrier.h
@@ -18,14 +18,7 @@
#undef dmb
#endif
-#if __LINUX_ARM_ARCH__ >= 7
#define dmb(option) __asm__ __volatile__ ("dmb " #option : : : "memory")
-#elif __LINUX_ARM_ARCH__ == 6
-#define dmb(x) __asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 5" \
- : : "r" (0) : "memory")
-#else
-#define dmb(x) __asm__ __volatile__ ("" : : : "memory")
-#endif
#if __LINUX_ARM_ARCH__ >= 8
#define aarch32_smp_mb() dmb(ish)
Re: drivers: Adjust scope for CONFIG_HAS_IOMEM before devm_platform_ioremap_resource()
> Oh so it's another troll then? I am just a contributor. > Good to know, ignoring from now on. The opinions can vary for my contributions as usual. I hope that the software development attention can evolve in more positive ways again. Regards, Markus
[tip:timers/vdso] MAINTAINERS: Add entry for the generic VDSO library
Commit-ID: c82d735b3d3f0bbfd49a6a4da96bd27c4ba57eb0 Gitweb: https://git.kernel.org/tip/c82d735b3d3f0bbfd49a6a4da96bd27c4ba57eb0 Author: Thomas Gleixner AuthorDate: Mon, 24 Jun 2019 02:34:24 +0200 Committer: Thomas Gleixner CommitDate: Tue, 25 Jun 2019 09:44:08 +0200 MAINTAINERS: Add entry for the generic VDSO library Assign the following folks in alphabetic order: - Andy for being the VDSO wizard of x86 and in general. He's also the performance monitor of choice and the code in the generic library is heavily influenced by his previous x86 VDSO work. - Thomas for being the dude who has to deal with any form of time(r) nonsense anyway - Vincenzo for being the poor sod who went through all the different architecture implementations in order to unify them. A lot of knowledge gained from VDSO implementation details to the intricacies of taming the build system. Signed-off-by: Thomas Gleixner Cc: Vincenzo Frascino Cc: linux-a...@vger.kernel.org Cc: LAK Cc: linux-m...@vger.kernel.org Cc: linux-kselft...@vger.kernel.org Cc: Catalin Marinas Cc: Will Deacon Cc: Arnd Bergmann Cc: Russell King Cc: Ralf Baechle Cc: Paul Burton Cc: Daniel Lezcano Cc: Mark Salyzyn Cc: Peter Collingbourne Cc: Shuah Khan Cc: Dmitry Safonov <0x7f454...@gmail.com> Cc: Rasmus Villemoes Cc: Huw Davies Cc: Shijith Thotton Cc: Andre Przywara Cc: Dmitry Safonov Cc: Andrei Vagin Cc: Linus Torvalds Cc: Andy Lutomirski Cc: Michael Kelley Cc: Sasha Levin Link: https://lkml.kernel.org/r/alpine.deb.2.21.1906240142000.32...@nanos.tec.linutronix.de --- MAINTAINERS | 12 1 file changed, 12 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index d0ed735994a5..13ece5479167 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6664,6 +6664,18 @@ L: k...@vger.kernel.org S: Supported F: drivers/uio/uio_pci_generic.c +GENERIC VDSO LIBRARY: +M: Andy Lutomirksi +M: Thomas Gleixner +M: Vincenzo Frascino +L: linux-kernel@vger.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/vdso +S: Maintained +F: lib/vdso +F: kernel/time/vsyscall.c +F: include/vdso +F: include/asm-generic/vdso/vsyscall.h + GENWQE (IBM Generic Workqueue Card) M: Frank Haverkamp S: Supported
Linux 4.19.56
I'm announcing the release of the 4.19.56 kernel. All users of the 4.19 kernel series must upgrade. The updated 4.19.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile|4 arch/arc/boot/dts/hsdk.dts |4 arch/arc/include/asm/cmpxchg.h | 14 - arch/arc/mm/tlb.c | 13 - arch/arm/boot/dts/am57xx-idk-common.dtsi|1 arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi | 40 +-- arch/arm/mach-imx/cpuidle-imx6sx.c |3 arch/arm64/Makefile |1 arch/arm64/include/uapi/asm/ptrace.h|8 arch/arm64/kernel/ssbd.c|1 arch/mips/kernel/uprobes.c |3 arch/parisc/math-emu/cnv_float.h|8 arch/powerpc/include/asm/ppc-opcode.h |1 arch/powerpc/mm/mmu_context_book3s64.c | 46 arch/powerpc/net/bpf_jit.h |2 arch/powerpc/net/bpf_jit_comp64.c |8 arch/riscv/mm/fault.c | 13 + arch/s390/include/asm/ap.h | 28 +- arch/s390/include/asm/jump_label.h | 14 - arch/sparc/kernel/mdesc.c |2 arch/sparc/kernel/perf_event.c |4 arch/x86/kernel/cpu/intel_rdt_rdtgroup.c|2 arch/xtensa/kernel/setup.c |3 drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c |3 drivers/dma/sprd-dma.c |2 drivers/fpga/dfl-afu-dma-region.c |2 drivers/fpga/dfl.c | 16 + drivers/gpu/drm/arm/hdlcd_crtc.c| 14 - drivers/gpu/drm/arm/malidp_drv.c| 13 + drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 146 +++--- drivers/hwmon/hwmon.c |2 drivers/hwmon/pmbus/pmbus_core.c| 34 ++- drivers/iio/temperature/mlx90632.c |9 drivers/infiniband/hw/hfi1/chip.c |1 drivers/infiniband/hw/hfi1/fault.c |5 drivers/infiniband/hw/hfi1/user_exp_rcv.c |3 drivers/infiniband/hw/hfi1/verbs.c |2 drivers/infiniband/hw/hfi1/verbs_txreq.c|2 drivers/infiniband/hw/hfi1/verbs_txreq.h|3 drivers/infiniband/hw/qib/qib_verbs.c |2 drivers/infiniband/sw/rdmavt/mr.c |2 drivers/infiniband/sw/rdmavt/qp.c |3 drivers/input/misc/uinput.c | 22 +- drivers/input/mouse/synaptics.c |2 drivers/input/touchscreen/silead.c |1 drivers/mmc/core/core.c |5 drivers/mmc/core/sdio.c | 13 + drivers/mmc/core/sdio_io.c | 77 +++ drivers/mmc/core/sdio_irq.c |4 drivers/mmc/host/sdhci-pci-o2micro.c|5 drivers/net/can/flexcan.c |2 drivers/net/can/xilinx_can.c|2 drivers/net/dsa/mv88e6xxx/chip.c|2 drivers/net/ethernet/hisilicon/hns/hns_ethtool.c|4 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 15 - drivers/net/ipvlan/ipvlan_main.c|2 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 11 + drivers/nvme/host/core.c|3 drivers/nvme/target/io-cmd-bdev.c |1 drivers/parport/share.c |2 drivers/s390/net/qeth_l2_main.c |2 drivers/scsi/smartpqi/smartpqi_init.c |6 drivers/scsi/ufs/ufshcd-pltfrm.c| 11 - drivers/scsi/ufs/ufshcd.c |3 drivers/staging/erofs/erofs_fs.h| 13 - drivers/staging/erofs/internal.h|2 drivers/staging/erofs/super.c | 19 + drivers/usb/chipidea/udc.c | 20 + drivers/usb/host/xhci-ring.c| 15 + drivers/usb/host/xhci.c
Linux 5.1.15
I'm announcing the release of the 5.1.15 kernel. All users of the 5.1 kernel series must upgrade. The updated 5.1.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.1.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arc/boot/dts/hsdk.dts |4 arch/arc/include/asm/cmpxchg.h | 14 - arch/arc/mm/tlb.c | 13 - arch/arm/boot/dts/am57xx-idk-common.dtsi |1 arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi | 40 +-- arch/arm/configs/mvebu_v7_defconfig|1 arch/arm/mach-imx/cpuidle-imx6sx.c |3 arch/arm64/Makefile|1 arch/arm64/include/uapi/asm/ptrace.h |8 arch/arm64/kernel/ssbd.c |1 arch/mips/include/asm/ginvt.h |2 arch/mips/kernel/uprobes.c |3 arch/parisc/math-emu/cnv_float.h |8 arch/powerpc/include/asm/ppc-opcode.h |1 arch/powerpc/mm/mmu_context_book3s64.c | 46 +++ arch/powerpc/net/bpf_jit.h |2 arch/powerpc/net/bpf_jit_comp64.c |8 arch/riscv/mm/fault.c | 13 + arch/sparc/kernel/mdesc.c |2 arch/sparc/kernel/perf_event.c |4 arch/x86/entry/vdso/vclock_gettime.c | 15 + arch/x86/kernel/cpu/resctrl/rdtgroup.c |2 arch/x86/kvm/mmu.c | 16 - arch/xtensa/kernel/setup.c |3 crypto/hmac.c |4 drivers/android/binder.c | 16 + drivers/dma-buf/udmabuf.c |1 drivers/dma/dma-jz4780.c | 32 +- drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c |3 drivers/dma/mediatek/mtk-cqdma.c |4 drivers/dma/sprd-dma.c | 29 +- drivers/fpga/dfl-afu-dma-region.c |2 drivers/fpga/dfl.c | 16 + drivers/fpga/stratix10-soc.c |6 drivers/gpu/drm/arm/hdlcd_crtc.c | 14 - drivers/gpu/drm/arm/malidp_drv.c | 13 - drivers/gpu/drm/i915/intel_display.c | 38 ++- drivers/gpu/drm/vmwgfx/vmwgfx_msg.c| 146 +-- drivers/hwmon/hwmon.c |2 drivers/hwmon/pmbus/pmbus_core.c | 34 ++ drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h|2 drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c | 25 +- drivers/iio/temperature/mlx90632.c |9 drivers/infiniband/hw/hfi1/chip.c | 14 + drivers/infiniband/hw/hfi1/chip.h |1 drivers/infiniband/hw/hfi1/fault.c |5 drivers/infiniband/hw/hfi1/sdma.c |9 drivers/infiniband/hw/hfi1/tid_rdma.c |4 drivers/infiniband/hw/hfi1/user_exp_rcv.c |3 drivers/infiniband/hw/hfi1/user_sdma.c | 12 drivers/infiniband/hw/hfi1/user_sdma.h |1 drivers/infiniband/hw/hfi1/verbs.c |2 drivers/infiniband/hw/hfi1/verbs_txreq.c |2 drivers/infiniband/hw/hfi1/verbs_txreq.h |3 drivers/infiniband/hw/qib/qib_verbs.c |2 drivers/infiniband/sw/rdmavt/mr.c |2 drivers/infiniband/sw/rdmavt/qp.c |3 drivers/input/misc/uinput.c| 22 + drivers/input/mouse/synaptics.c|2 drivers/input/touchscreen/silead.c |1 drivers/misc/habanalabs/memory.c |6 drivers/misc/lkdtm/usercopy.c | 10 drivers/mmc/core/core.c|5 drivers/mmc/core/sdio.c| 13 - drivers/mmc/core/sdio_io.c | 77 ++ drivers/mmc/core/sdio_irq.c
Linux 4.14.130
I'm announcing the release of the 4.14.130 kernel. All users of the 4.14 kernel series must upgrade. The updated 4.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |4 +- arch/arc/boot/dts/hsdk.dts |4 ++ arch/arc/include/asm/cmpxchg.h | 14 ++-- arch/arc/mm/tlb.c| 13 --- arch/arm/boot/dts/am57xx-idk-common.dtsi |1 arch/arm/mach-imx/cpuidle-imx6sx.c |3 + arch/mips/kernel/uprobes.c |3 - arch/parisc/math-emu/cnv_float.h |8 ++-- arch/powerpc/include/asm/ppc-opcode.h|1 arch/powerpc/net/bpf_jit.h |2 - arch/powerpc/net/bpf_jit_comp64.c|8 ++-- arch/sparc/kernel/mdesc.c|2 + arch/sparc/kernel/perf_event.c |4 ++ arch/xtensa/kernel/setup.c |3 + drivers/gpu/drm/arm/hdlcd_crtc.c | 14 drivers/hwmon/hwmon.c|2 - drivers/hwmon/pmbus/pmbus_core.c | 34 ++-- drivers/infiniband/hw/hfi1/chip.c|1 drivers/infiniband/hw/hfi1/user_exp_rcv.c|3 + drivers/infiniband/hw/hfi1/verbs.c |2 - drivers/infiniband/hw/hfi1/verbs_txreq.c |2 - drivers/infiniband/hw/hfi1/verbs_txreq.h |3 + drivers/infiniband/hw/qib/qib_verbs.c|2 - drivers/infiniband/sw/rdmavt/mr.c|2 + drivers/infiniband/sw/rdmavt/qp.c|3 + drivers/input/misc/uinput.c | 22 - drivers/input/mouse/synaptics.c |2 + drivers/mmc/core/sdio.c | 13 +++ drivers/mmc/core/sdio_irq.c |4 ++ drivers/net/can/flexcan.c|2 - drivers/net/dsa/mv88e6xxx/chip.c |2 - drivers/net/ethernet/hisilicon/hns/hns_ethtool.c |4 ++ drivers/net/ethernet/mediatek/mtk_eth_soc.c | 15 - drivers/net/ipvlan/ipvlan_main.c |2 - drivers/net/phy/bcm-phy-lib.c|4 +- drivers/nvme/host/core.c |3 + drivers/parport/share.c |2 + drivers/s390/net/qeth_l2_main.c |2 - drivers/scsi/smartpqi/smartpqi_init.c|6 ++- drivers/scsi/ufs/ufshcd-pltfrm.c | 11 ++ drivers/scsi/ufs/ufshcd.c|3 + drivers/usb/chipidea/udc.c | 20 fs/btrfs/reada.c |5 +++ fs/cifs/smb2maperror.c |2 - include/net/bluetooth/hci_core.h |3 + kernel/trace/trace.c |6 --- kernel/trace/trace.h | 18 ++ kernel/trace/trace_kdb.c |6 --- net/bluetooth/hci_conn.c | 10 +- net/bluetooth/l2cap_core.c | 33 --- net/can/af_can.c |1 net/mac80211/ieee80211_i.h |3 + net/mac80211/mlme.c | 12 ++- net/mac80211/rx.c|2 + net/mac80211/tdls.c | 23 + net/mac80211/wpa.c |7 +++- net/wireless/core.c |2 - scripts/checkstack.pl|2 - security/apparmor/policy_unpack.c|2 - tools/objtool/check.c| 38 +++ tools/objtool/check.h|4 +- tools/objtool/elf.c |1 tools/objtool/elf.h |3 + 63 files changed, 336 insertions(+), 102 deletions(-) Alexander Mikhaylenko (1): Input: synaptics - enable SMBus on ThinkPad E480 and E580 Alexandra Winter (1): s390/qeth: fix VLAN attribute in bridge_hostnotify udev event Allan Xavier (1): objtool: Support per-function rodata sections Andrey Smirnov (1): Input: uinput - add compat ioctl number translation for UI_*_FF_UPLOAD Avri Altman (1): scsi: ufs: Check that space was properly alloced in copy_query_response Dan Carpenter (1): scsi: smartpqi: unlock on error in pqi_submit_raid_request_synchronous() Eduardo Valentin (1): hwmon: (core) add thermal sensors only if dev->of_node is
Re: Linux 4.14.130
diff --git a/Makefile b/Makefile
index 2a55dd5bee0a..9d0715c300b1 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 14
-SUBLEVEL = 129
+SUBLEVEL = 130
EXTRAVERSION =
NAME = Petit Gorille
@@ -650,6 +650,7 @@ KBUILD_CFLAGS += $(call
cc-disable-warning,frame-address,)
KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation)
KBUILD_CFLAGS += $(call cc-disable-warning, format-overflow)
KBUILD_CFLAGS += $(call cc-disable-warning, int-in-bool-context)
+KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
KBUILD_CFLAGS += $(call cc-disable-warning, attribute-alias)
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
@@ -716,7 +717,6 @@ ifeq ($(cc-name),clang)
KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier)
KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
-KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
# Quiet clang warning: comparison of unsigned expression < 0 is always false
KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare)
# CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as the
diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
index 8f627c200d60..57d81c6aa379 100644
--- a/arch/arc/boot/dts/hsdk.dts
+++ b/arch/arc/boot/dts/hsdk.dts
@@ -163,12 +163,16 @@
interrupt-names = "macirq";
phy-mode = "rgmii";
snps,pbl = <32>;
+ snps,multicast-filter-bins = <256>;
clocks = <>;
clock-names = "stmmaceth";
phy-handle = <>;
resets = <_rst HSDK_ETH_RESET>;
reset-names = "stmmaceth";
+ tx-fifo-depth = <4096>;
+ rx-fifo-depth = <4096>;
+
mdio {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arc/include/asm/cmpxchg.h b/arch/arc/include/asm/cmpxchg.h
index d819de1c5d10..3ea4112c8302 100644
--- a/arch/arc/include/asm/cmpxchg.h
+++ b/arch/arc/include/asm/cmpxchg.h
@@ -92,8 +92,11 @@ __cmpxchg(volatile void *ptr, unsigned long expected,
unsigned long new)
#endif /* CONFIG_ARC_HAS_LLSC */
-#define cmpxchg(ptr, o, n) ((typeof(*(ptr)))__cmpxchg((ptr), \
- (unsigned long)(o), (unsigned long)(n)))
+#define cmpxchg(ptr, o, n) ({ \
+ (typeof(*(ptr)))__cmpxchg((ptr),\
+ (unsigned long)(o), \
+ (unsigned long)(n)); \
+})
/*
* atomic_cmpxchg is same as cmpxchg
@@ -198,8 +201,11 @@ static inline unsigned long __xchg(unsigned long val,
volatile void *ptr,
return __xchg_bad_pointer();
}
-#define xchg(ptr, with) ((typeof(*(ptr)))__xchg((unsigned long)(with), (ptr), \
-sizeof(*(ptr
+#define xchg(ptr, with) ({ \
+ (typeof(*(ptr)))__xchg((unsigned long)(with), \
+ (ptr), \
+ sizeof(*(ptr))); \
+})
#endif /* CONFIG_ARC_PLAT_EZNPS */
diff --git a/arch/arc/mm/tlb.c b/arch/arc/mm/tlb.c
index 8ceefbf72fb0..e5817b9b2c3f 100644
--- a/arch/arc/mm/tlb.c
+++ b/arch/arc/mm/tlb.c
@@ -902,9 +902,11 @@ void do_tlb_overlap_fault(unsigned long cause, unsigned
long address,
struct pt_regs *regs)
{
struct cpuinfo_arc_mmu *mmu = _arc700[smp_processor_id()].mmu;
- unsigned int pd0[mmu->ways];
unsigned long flags;
- int set;
+ int set, n_ways = mmu->ways;
+
+ n_ways = min(n_ways, 4);
+ BUG_ON(mmu->ways > 4);
local_irq_save(flags);
@@ -912,9 +914,10 @@ void do_tlb_overlap_fault(unsigned long cause, unsigned
long address,
for (set = 0; set < mmu->sets; set++) {
int is_valid, way;
+ unsigned int pd0[4];
/* read out all the ways of current set */
- for (way = 0, is_valid = 0; way < mmu->ways; way++) {
+ for (way = 0, is_valid = 0; way < n_ways; way++) {
write_aux_reg(ARC_REG_TLBINDEX,
SET_WAY_TO_IDX(mmu, set, way));
write_aux_reg(ARC_REG_TLBCOMMAND, TLBRead);
@@ -928,14 +931,14 @@ void do_tlb_overlap_fault(unsigned long cause, unsigned
long address,
continue;
/* Scan the set for duplicate ways: needs a nested loop */
- for (way = 0; way < mmu->ways - 1; way++) {
+ for (way = 0; way < n_ways - 1; way++) {
int n;
if (!pd0[way])
Re: Linux 4.19 and GCC 9
On Mon, Jun 24, 2019 at 11:42:34AM +0100, Ignat Korchagin wrote: > Hi Greg, > > > > For us it seems applying the following 4 mainline patches makes 4.19.x > > > branch perf compile with GCC-9: > > > > > > 4d0f16d059ddb91424480d88473f7392f24aebdc: perf ui helpline: Use > > > strlcpy() as a shorter form of strncpy() + explicit set nul > > > b6313899f4ed2e76b8375cf8069556f5b94fbff0: perf help: Remove needless > > > use of strncpy() > > > 5192bde7d98c99f2cd80225649e3c2e7493722f7: perf header: Fix unchecked > > > usage of strncpy() > > > 97acec7df172cd1e450f81f5e293c0aa145a2797: perf data: Fix 'strncat may > > > truncate' build failure with recent gcc > > > > > > I also checked that 4.19.49 compiles fine with GCC 9, although with a > > > lot of warnings, mostly from objtool, like "warning: objtool: > > > sock_register()+0xd: sibling call from callable instruction with > > > modified stack frame". But it's a start. > > > > > > Can we apply the above-mentioned patches, please? > > > I'll look into these after the next round of kernels are released. I > > Did you by any chance forget to queue these patches? :) (the build is > still broken for GCC 9.1) I am on the road and getting to backports for this stuff is on the bottom of my list until next week at the earliest, sorry. > > guess I'll go find a distro that has gcc9 on it to actually test > > things... > > BTW, Arch already has GCC 9.1 package, so no need to compile your own > anymore for testing: > https://www.archlinux.org/packages/core/x86_64/gcc/ Yes, my laptop just updated, so I'm building here. Some gcc9 patches did just get backported, but not for perf. thanks, greg k-h
Re: Linux 4.19.56
diff --git a/Makefile b/Makefile
index 3addd4c286fa..a76c61f77bcd 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 19
-SUBLEVEL = 55
+SUBLEVEL = 56
EXTRAVERSION =
NAME = "People's Front"
@@ -652,6 +652,7 @@ KBUILD_CFLAGS += $(call
cc-disable-warning,frame-address,)
KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation)
KBUILD_CFLAGS += $(call cc-disable-warning, format-overflow)
KBUILD_CFLAGS += $(call cc-disable-warning, int-in-bool-context)
+KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += -Os $(call cc-disable-warning,maybe-uninitialized,)
@@ -696,7 +697,6 @@ ifeq ($(cc-name),clang)
KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier)
KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
-KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
# Quiet clang warning: comparison of unsigned expression < 0 is always false
KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare)
# CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as the
diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
index ef149f59929a..d131c54acd3e 100644
--- a/arch/arc/boot/dts/hsdk.dts
+++ b/arch/arc/boot/dts/hsdk.dts
@@ -175,6 +175,7 @@
interrupt-names = "macirq";
phy-mode = "rgmii";
snps,pbl = <32>;
+ snps,multicast-filter-bins = <256>;
clocks = <>;
clock-names = "stmmaceth";
phy-handle = <>;
@@ -183,6 +184,9 @@
mac-address = [00 00 00 00 00 00]; /* Filled in by
U-Boot */
dma-coherent;
+ tx-fifo-depth = <4096>;
+ rx-fifo-depth = <4096>;
+
mdio {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arc/include/asm/cmpxchg.h b/arch/arc/include/asm/cmpxchg.h
index d819de1c5d10..3ea4112c8302 100644
--- a/arch/arc/include/asm/cmpxchg.h
+++ b/arch/arc/include/asm/cmpxchg.h
@@ -92,8 +92,11 @@ __cmpxchg(volatile void *ptr, unsigned long expected,
unsigned long new)
#endif /* CONFIG_ARC_HAS_LLSC */
-#define cmpxchg(ptr, o, n) ((typeof(*(ptr)))__cmpxchg((ptr), \
- (unsigned long)(o), (unsigned long)(n)))
+#define cmpxchg(ptr, o, n) ({ \
+ (typeof(*(ptr)))__cmpxchg((ptr),\
+ (unsigned long)(o), \
+ (unsigned long)(n)); \
+})
/*
* atomic_cmpxchg is same as cmpxchg
@@ -198,8 +201,11 @@ static inline unsigned long __xchg(unsigned long val,
volatile void *ptr,
return __xchg_bad_pointer();
}
-#define xchg(ptr, with) ((typeof(*(ptr)))__xchg((unsigned long)(with), (ptr), \
-sizeof(*(ptr
+#define xchg(ptr, with) ({ \
+ (typeof(*(ptr)))__xchg((unsigned long)(with), \
+ (ptr), \
+ sizeof(*(ptr))); \
+})
#endif /* CONFIG_ARC_PLAT_EZNPS */
diff --git a/arch/arc/mm/tlb.c b/arch/arc/mm/tlb.c
index 4097764fea23..fa18c00b0cfd 100644
--- a/arch/arc/mm/tlb.c
+++ b/arch/arc/mm/tlb.c
@@ -911,9 +911,11 @@ void do_tlb_overlap_fault(unsigned long cause, unsigned
long address,
struct pt_regs *regs)
{
struct cpuinfo_arc_mmu *mmu = _arc700[smp_processor_id()].mmu;
- unsigned int pd0[mmu->ways];
unsigned long flags;
- int set;
+ int set, n_ways = mmu->ways;
+
+ n_ways = min(n_ways, 4);
+ BUG_ON(mmu->ways > 4);
local_irq_save(flags);
@@ -921,9 +923,10 @@ void do_tlb_overlap_fault(unsigned long cause, unsigned
long address,
for (set = 0; set < mmu->sets; set++) {
int is_valid, way;
+ unsigned int pd0[4];
/* read out all the ways of current set */
- for (way = 0, is_valid = 0; way < mmu->ways; way++) {
+ for (way = 0, is_valid = 0; way < n_ways; way++) {
write_aux_reg(ARC_REG_TLBINDEX,
SET_WAY_TO_IDX(mmu, set, way));
write_aux_reg(ARC_REG_TLBCOMMAND, TLBRead);
@@ -937,14 +940,14 @@ void do_tlb_overlap_fault(unsigned long cause, unsigned
long address,
continue;
/* Scan the set for duplicate ways: needs a nested loop */
- for (way = 0; way < mmu->ways - 1; way++) {
+ for (way = 0; way < n_ways - 1; way++) {
int n;
