[PATCH] binder: Set end of SG buffer area properly.
In case the target node requests a security context, the
extra_buffers_size is increased with the size of the security context.
But, that size is not available for use by regular scatter-gather
buffers; make sure the ending of that buffer is marked correctly.
Acked-by: Todd Kjos
Fixes: ec74136ded79 ("binder: create node flag to request sender's
security context")
Signed-off-by: Martijn Coenen
Cc: sta...@vger.kernel.org # 5.1+
---
drivers/android/binder.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 38a59a630cd4c..5bde08603fbc2 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -3239,7 +3239,8 @@ static void binder_transaction(struct binder_proc *proc,
buffer_offset = off_start_offset;
off_end_offset = off_start_offset + tr->offsets_size;
sg_buf_offset = ALIGN(off_end_offset, sizeof(void *));
- sg_buf_end_offset = sg_buf_offset + extra_buffers_size;
+ sg_buf_end_offset = sg_buf_offset + extra_buffers_size -
+ ALIGN(secctx_sz, sizeof(u64));
off_min = 0;
for (buffer_offset = off_start_offset; buffer_offset < off_end_offset;
buffer_offset += sizeof(binder_size_t)) {
--
2.22.0.410.gd8fdbe21b5-goog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Procedure questions - new filesystem driver..
On Tue, Jul 09, 2019 at 12:50:20AM -0400, Theodore Ts'o wrote: > How have you dealt with the patent claims which Microsoft has > asserted[1] on the exFAT file system design? > > [1] > https://www.microsoft.com/en-us/legal/intellectualproperty/mtl/exfat-licensing.aspx > > I am not making any claims about the validity of Microsoft's patent > assertions on exFAT, one way or another. But it might be a good idea > for some laywers from the Linux Foundation to render some legal advice > to their employees (namely Greg K-H and Linus Torvalds) regarding the > advisability of taking exFAT into the official Linux tree. > > Personally, if Microsoft is going to be unfriendly about not wanting > others to use their file system technology by making patent claims, > why should we reward them by making their file system better by > improvings its interoperability? (My personal opinion only.) How does https://www.zdnet.com/article/microsoft-open-sources-its-entire-patent-portfolio/ change your personal opinion? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
general protection fault in vmk80xx_write_packet
Hello, syzbot found the following crash on: HEAD commit:7829a896 usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer console output: https://syzkaller.appspot.com/x/log.txt?x=126dd493a0 kernel config: https://syzkaller.appspot.com/x/.config?x=f6d4561982f71f63 dashboard link: https://syzkaller.appspot.com/bug?extid=009f546aa1370056b1c2 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1684570ba0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=132c91f5a0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+009f546aa1370056b...@syzkaller.appspotmail.com usb 1-1: config 0 interface 160 has no altsetting 0 usb 1-1: New USB device found, idVendor=10cf, idProduct=5501, bcdDevice=eb.5b usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-1: config 0 descriptor?? kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 5.2.0-rc6+ #13 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:vmk80xx_write_packet+0x75/0x260 drivers/staging/comedi/drivers/vmk80xx.c:204 Code: 48 8d 7b 68 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 d3 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 68 4c 89 ea 48 c1 ea 03 <0f> b6 04 02 4c 89 ea 83 e2 07 38 d0 7f 08 84 c0 0f 85 84 01 00 00 RSP: 0018:8881d9eff1b0 EFLAGS: 00010202 RAX: dc00 RBX: 8881d4f596c0 RCX: RDX: 0002 RSI: 847cda93 RDI: 8881d4f59728 RBP: 8881cfc79900 R08: 8881d9e36000 R09: 0010 R10: R11: R12: 8881c5d84c80 R13: 0010 R14: R15: 8881d2690128 FS: () GS:8881db30() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f9c904c4000 CR3: 0001d2b52000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: vmk80xx_reset_device drivers/staging/comedi/drivers/vmk80xx.c:226 [inline] vmk80xx_auto_attach+0x13b1/0x17c0 drivers/staging/comedi/drivers/vmk80xx.c:814 comedi_auto_config+0x16e/0x250 drivers/staging/comedi/drivers.c:1067 usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 really_probe+0x281/0x660 drivers/base/dd.c:509 driver_probe_device+0x104/0x210 drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 __device_attach+0x217/0x360 drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 device_add+0xae6/0x16f0 drivers/base/core.c:2111 usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023 generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210 usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266 really_probe+0x281/0x660 drivers/base/dd.c:509 driver_probe_device+0x104/0x210 drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 __device_attach+0x217/0x360 drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 device_add+0xae6/0x16f0 drivers/base/core.c:2111 usb_new_device.cold+0x8c1/0x1016 drivers/usb/core/hub.c:2534 hub_port_connect drivers/usb/core/hub.c:5089 [inline] hub_port_connect_change drivers/usb/core/hub.c:5204 [inline] port_event drivers/usb/core/hub.c:5350 [inline] hub_event+0x1ada/0x3590 drivers/usb/core/hub.c:5432 process_one_work+0x905/0x1570 kernel/workqueue.c:2269 worker_thread+0x96/0xe20 kernel/workqueue.c:2415 kthread+0x30b/0x410 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Modules linked in: ---[ end trace 8425c817ce1da187 ]--- --- 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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Procedure questions - new filesystem driver..
On Tue, Jul 09, 2019 at 04:21:36AM -0700, Matthew Wilcox wrote: > How does > https://www.zdnet.com/article/microsoft-open-sources-its-entire-patent-portfolio/ > change your personal opinion? According to SFC's legal analysis, Microsoft joining the OIN doesn't mean that the eXFAT patents are covered, unless *Microsoft* contributes the code to the Linux usptream kernel. That's because the OIN is governed by the Linux System Definition, and until MS contributes code which covered by the exFAT patents, it doesn't count. For more details: https://sfconservancy.org/blog/2018/oct/10/microsoft-oin-exfat/ (This is not legal advice, and I am not a lawyer.) - Ted ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
exfat filesystem
On Tue, Jul 09, 2019 at 11:30:39AM -0400, Theodore Ts'o wrote: > On Tue, Jul 09, 2019 at 04:21:36AM -0700, Matthew Wilcox wrote: > > How does > > https://www.zdnet.com/article/microsoft-open-sources-its-entire-patent-portfolio/ > > change your personal opinion? > > According to SFC's legal analysis, Microsoft joining the OIN doesn't > mean that the eXFAT patents are covered, unless *Microsoft* > contributes the code to the Linux usptream kernel. That's because the > OIN is governed by the Linux System Definition, and until MS > contributes code which covered by the exFAT patents, it doesn't count. > > For more details: > > https://sfconservancy.org/blog/2018/oct/10/microsoft-oin-exfat/ > > (This is not legal advice, and I am not a lawyer.) Interesting analysis. It seems to me that the correct forms would be observed if someone suitably senior at Microsoft accepted the work from Valdis and submitted it with their sign-off. KY, how about it? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: exfat filesystem
On Tue, 2019-07-09 at 08:48 -0700, Matthew Wilcox wrote: > On Tue, Jul 09, 2019 at 11:30:39AM -0400, Theodore Ts'o wrote: > > On Tue, Jul 09, 2019 at 04:21:36AM -0700, Matthew Wilcox wrote: > > > How does > > > https://www.zdnet.com/article/microsoft-open-sources-its-entire-p > > > atent-portfolio/ > > > change your personal opinion? > > > > According to SFC's legal analysis, Microsoft joining the OIN > > doesn't mean that the eXFAT patents are covered, unless *Microsoft* > > contributes the code to the Linux usptream kernel. That's because > > the OIN is governed by the Linux System Definition, and until MS > > contributes code which covered by the exFAT patents, it doesn't > > count. > > > > For more details: > > > > https://sfconservancy.org/blog/2018/oct/10/microsoft-oin-exfat/ > > > > (This is not legal advice, and I am not a lawyer.) > > Interesting analysis. It seems to me that the correct forms would be > observed if someone suitably senior at Microsoft accepted the work > from Valdis and submitted it with their sign-off. KY, how about it? KY, if you need local help to convince anyone, I can do that ... I've been deeply involved in patent issues with open source from the community angle for a while and I'm used to talking to corporate counsels. Personally I think we could catch Microsoft in the implied licence to the FAT patent simply by putting exfat in the kernel and waiting for them to distribute it but I think it would benefit Microsoft much more from a community perspective to make an open donation of the FAT patents to Linux in much the same way they've already done for UEFI. If my analysis of the distribution situation is correct, it would be making a virtue of a necessity anyway which is always a useful business case argument. James ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: exfat filesystem
On Tue, 09 Jul 2019 08:48:34 -0700, Matthew Wilcox said: > Interesting analysis. It seems to me that the correct forms would be > observed if someone suitably senior at Microsoft accepted the work from > Valdis and submitted it with their sign-off. KY, how about it? I'd be totally OK with that pgpfry6tGeMKx.pgp Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: exfat filesystem
On Tue, Jul 09, 2019 at 08:48:34AM -0700, Matthew Wilcox wrote: On Tue, Jul 09, 2019 at 11:30:39AM -0400, Theodore Ts'o wrote: On Tue, Jul 09, 2019 at 04:21:36AM -0700, Matthew Wilcox wrote: > How does > https://www.zdnet.com/article/microsoft-open-sources-its-entire-patent-portfolio/ > change your personal opinion? According to SFC's legal analysis, Microsoft joining the OIN doesn't mean that the eXFAT patents are covered, unless *Microsoft* contributes the code to the Linux usptream kernel. That's because the OIN is governed by the Linux System Definition, and until MS contributes code which covered by the exFAT patents, it doesn't count. For more details: https://sfconservancy.org/blog/2018/oct/10/microsoft-oin-exfat/ (This is not legal advice, and I am not a lawyer.) Interesting analysis. It seems to me that the correct forms would be observed if someone suitably senior at Microsoft accepted the work from Valdis and submitted it with their sign-off. KY, how about it? Huh, that's really how this works? Let me talk with our lawyers to clear this up. Would this mean, hypothetically, that if MS has claims against the kernel's scheduler for example, it can still assert them if no one from MS touched the code? And then they lose that ability if a MS employee adds a tiny fix in? -- Thanks, Sasha ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: exfat filesystem
On Tue, Jul 09, 2019 at 08:48:34AM -0700, Matthew Wilcox wrote: > > Interesting analysis. It seems to me that the correct forms would be > observed if someone suitably senior at Microsoft accepted the work from > Valdis and submitted it with their sign-off. KY, how about it? It might be that the simplest way to do this is just to have someone from Microsoft send the pull request (with a signed tag) to Linus. There are any number ways to arrange this but the PGP-signed tag might be sufficient. Alternatively, some kind of declaration from a Microsoft lawyer to OIN might be sufficient. This is where asking the LF if they can bring together a meeting of the minds of LF, OIN, and Microsoft lawyers might make things much easier. - Ted ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: exfat filesystem
On Tue, 09 Jul 2019 16:39:31 -, KY Srinivasan said: > Let me dig up the details here. In case this helps clarify the chain of events, the code in question is the Samsung code mentioned here, updated to 5.2 kernel "We know that Microsoft has done patent troll shakedowns in the past on Linux products related to the exfat filesystem. While we at Conservancy were successful in getting the code that implements exfat for Linux released under GPL (by Samsung), that code has not been upstreamed into Linux. So, Microsoft has not included any patents they might hold on exfat into the patent non-aggression pact." https://sfconservancy.org/blog/2018/oct/10/microsoft-oin-exfat/ (Link in that para points here): https://sfconservancy.org/news/2013/aug/16/exfat-samsung/ pgpCPHQ3CST0f.pgp Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: exfat filesystem
On Tue, 2019-07-09 at 12:37 -0400, Sasha Levin wrote: > On Tue, Jul 09, 2019 at 08:48:34AM -0700, Matthew Wilcox wrote: > > On Tue, Jul 09, 2019 at 11:30:39AM -0400, Theodore Ts'o wrote: > > > On Tue, Jul 09, 2019 at 04:21:36AM -0700, Matthew Wilcox wrote: > > > > How does > > > > https://www.zdnet.com/article/microsoft-open-sources-its-entire > > > > -patent-portfolio/ > > > > change your personal opinion? > > > > > > According to SFC's legal analysis, Microsoft joining the OIN > > > doesn't mean that the eXFAT patents are covered, unless > > > *Microsoft* contributes the code to the Linux usptream > > > kernel. That's because the OIN is governed by the Linux System > > > Definition, and until MS contributes code which covered by the > > > exFAT patents, it doesn't count. > > > > > > For more details: > > > > > > https://sfconservancy.org/blog/2018/oct/10/microsoft-oin-exfat/ > > > > > > (This is not legal advice, and I am not a lawyer.) > > > > Interesting analysis. It seems to me that the correct forms would > > be observed if someone suitably senior at Microsoft accepted the > > work from Valdis and submitted it with their sign-off. KY, how > > about it? > > Huh, that's really how this works? Let me talk with our lawyers to > clear this up. Not exactly, no. A corporate signoff is useful evidence of intent to bind patents, but a formal statement would be better and wouldn't require a signoff. The SFC analysis is also a bit lacking: hypothetically if exfat became part of Linux, it would be covered by the OIN legal definition which would place MS in an untenable position with regard to the mutual defence pact if it still wanted to enforce FAT patents against Linux. > Would this mean, hypothetically, that if MS has claims against the > kernel's scheduler for example, it can still assert them if no one > from MS touched the code? And then they lose that ability if a MS > employee adds a tiny fix in? No. You're already shipping a linux kernel, that makes Microsoft a distributor meaning you're bound by the GPL express patent licences so any patent Microsoft has on technology in the Linux kernel would be unenforceable under that. Plus as a member of OIN, you've guaranteed not to sue for any patent that reads on the Linux System definition, which is also a promise you can be held to. James ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: exfat filesystem
-Original Message- From: Matthew Wilcox Sent: Tuesday, July 9, 2019 8:49 AM To: Theodore Ts'o ; Valdis Klētnieks ; Alexander Viro ; Greg Kroah-Hartman ; linux-fsde...@vger.kernel.org; linux-ker...@vger.kernel.org; de...@driverdev.osuosl.org; KY Srinivasan Cc: Sasha Levin Subject: exfat filesystem On Tue, Jul 09, 2019 at 11:30:39AM -0400, Theodore Ts'o wrote: > On Tue, Jul 09, 2019 at 04:21:36AM -0700, Matthew Wilcox wrote: > > How does > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > > w.zdnet.com%2Farticle%2Fmicrosoft-open-sources-its-entire-patent-por > > tfolio%2F&data=02%7C01%7Ckys%40microsoft.com%7Cd73183ff28c94bbbf > > 6dd08d70484f009%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369828 > > 41322780798&sdata=TCSgqe0h4FYaA5BBGVJl98WFBqbEHSo8B0FhlfTYVVA%3D > > &reserved=0 > > change your personal opinion? > > According to SFC's legal analysis, Microsoft joining the OIN doesn't > mean that the eXFAT patents are covered, unless *Microsoft* > contributes the code to the Linux usptream kernel. That's because the > OIN is governed by the Linux System Definition, and until MS > contributes code which covered by the exFAT patents, it doesn't count. > > For more details: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsfco > nservancy.org%2Fblog%2F2018%2Foct%2F10%2Fmicrosoft-oin-exfat%2F&da > ta=02%7C01%7Ckys%40microsoft.com%7Cd73183ff28c94bbbf6dd08d70484f009%7C > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636982841322780798&sdat > a=y%2BhZFhjIXUrFVn5%2FN%2BRVxRQWzYs2QI5V1jM8SDPN2dg%3D&reserved=0 > > (This is not legal advice, and I am not a lawyer.) >Interesting analysis. It seems to me that the correct forms would be observed >if someone suitably senior at Microsoft accepted the work from >Valdis and >submitted it with their sign-off. KY, how about it? Matthew, Let me dig up the details here. K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/5] MIPS: ralink: add dt binding header for mt7621-pll
This patch adds dt binding header for mediatek,mt7621-pll Signed-off-by: Weijie Gao Signed-off-by: Chuanhong Guo Reviewed-by: Rob Herring --- include/dt-bindings/clock/mt7621-clk.h | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 include/dt-bindings/clock/mt7621-clk.h diff --git a/include/dt-bindings/clock/mt7621-clk.h b/include/dt-bindings/clock/mt7621-clk.h new file mode 100644 index ..a29e14ee2efe --- /dev/null +++ b/include/dt-bindings/clock/mt7621-clk.h @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2018 Weijie Gao + */ + +#ifndef __DT_BINDINGS_MT7621_CLK_H +#define __DT_BINDINGS_MT7621_CLK_H + +#define MT7621_CLK_CPU 0 +#define MT7621_CLK_BUS 1 + +#define MT7621_CLK_MAX 2 + +#endif /* __DT_BINDINGS_MT7621_CLK_H */ -- 2.21.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/5] MIPS: ralink: add CPU clock detection for MT7621
This patchset ports CPU clock detection for MT7621 from OpenWrt. Last time I sent this, I forgot to add an binding include which caused a compile error and the patch doesn't stay in linux-next. This patchset resent the first two commits and also added binding documentation for mt7621-pll and used it in mt7621-dts at drivers/staging. BTW: What should I do with such a patchset that touches multiple parts in kernel? Is it correct to send the entire patchset to lists of all involved subsystems? Chuanhong Guo (5): MIPS: ralink: add dt binding header for mt7621-pll MIPS: ralink: fix cpu clock of mt7621 and add dt clk devices dt: bindings: add mt7621-pll dt binding documentation staging: mt7621-dts: add dt nodes for mt7621-pll staging: mt7621-dts: fix register range of memc node in mt7621.dtsi .../bindings/clock/mediatek,mt7621-pll.txt| 19 arch/mips/include/asm/mach-ralink/mt7621.h| 20 arch/mips/ralink/mt7621.c | 102 -- arch/mips/ralink/timer-gic.c | 4 +- drivers/staging/mt7621-dts/mt7621.dtsi| 17 ++- include/dt-bindings/clock/mt7621-clk.h| 14 +++ 6 files changed, 134 insertions(+), 42 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt create mode 100644 include/dt-bindings/clock/mt7621-clk.h -- 2.21.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/5] dt: bindings: add mt7621-pll dt binding documentation
This commit adds device tree binding documentation for MT7621
PLL controller.
Signed-off-by: Chuanhong Guo
---
.../bindings/clock/mediatek,mt7621-pll.txt| 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
b/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
new file mode 100644
index ..05c15062cd20
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
@@ -0,0 +1,19 @@
+Binding for Mediatek MT7621 PLL controller
+
+The PLL controller provides the 2 main clocks of the SoC: CPU and BUS.
+
+Required Properties:
+- compatible: has to be "mediatek,mt7621-pll"
+- #clock-cells: has to be one
+
+Optional properties:
+- clock-output-names: should be "cpu", "bus"
+
+Example:
+ pll {
+ compatible = "mediatek,mt7621-pll", "syscon";
+
+ #clock-cells = <1>;
+ clock-output-names = "cpu", "bus";
+ };
+
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/5] MIPS: ralink: fix cpu clock of mt7621 and add dt clk devices
For a long time the mt7621 uses a fixed cpu clock which causes a problem
if the cpu frequency is not 880MHz.
This patch fixes the cpu clock calculation and adds the cpu/bus clkdev
which will be used in dts.
Ported from OpenWrt:
c7ca224299 ramips: fix cpu clock of mt7621 and add dt clk devices
Signed-off-by: Weijie Gao
Signed-off-by: Chuanhong Guo
---
arch/mips/include/asm/mach-ralink/mt7621.h | 20
arch/mips/ralink/mt7621.c | 102 ++---
arch/mips/ralink/timer-gic.c | 4 +-
3 files changed, 93 insertions(+), 33 deletions(-)
diff --git a/arch/mips/include/asm/mach-ralink/mt7621.h
b/arch/mips/include/asm/mach-ralink/mt7621.h
index 65483a4681ab..51a6e51aef3f 100644
--- a/arch/mips/include/asm/mach-ralink/mt7621.h
+++ b/arch/mips/include/asm/mach-ralink/mt7621.h
@@ -17,6 +17,10 @@
#define SYSC_REG_CHIP_REV 0x0c
#define SYSC_REG_SYSTEM_CONFIG00x10
#define SYSC_REG_SYSTEM_CONFIG10x14
+#define SYSC_REG_CLKCFG0 0x2c
+#define SYSC_REG_CUR_CLK_STS 0x44
+
+#define MEMC_REG_CPU_PLL 0x648
#define CHIP_REV_PKG_MASK 0x1
#define CHIP_REV_PKG_SHIFT 16
@@ -24,6 +28,22 @@
#define CHIP_REV_VER_SHIFT 8
#define CHIP_REV_ECO_MASK 0xf
+#define XTAL_MODE_SEL_MASK 0x7
+#define XTAL_MODE_SEL_SHIFT6
+
+#define CPU_CLK_SEL_MASK 0x3
+#define CPU_CLK_SEL_SHIFT 30
+
+#define CUR_CPU_FDIV_MASK 0x1f
+#define CUR_CPU_FDIV_SHIFT 8
+#define CUR_CPU_FFRAC_MASK 0x1f
+#define CUR_CPU_FFRAC_SHIFT0
+
+#define CPU_PLL_PREDIV_MASK0x3
+#define CPU_PLL_PREDIV_SHIFT 12
+#define CPU_PLL_FBDIV_MASK 0x7f
+#define CPU_PLL_FBDIV_SHIFT4
+
#define MT7621_DRAM_BASE0x0
#define MT7621_DDR2_SIZE_MIN 32
#define MT7621_DDR2_SIZE_MAX 256
diff --git a/arch/mips/ralink/mt7621.c b/arch/mips/ralink/mt7621.c
index 9415be0d57b8..31158b88bcb6 100644
--- a/arch/mips/ralink/mt7621.c
+++ b/arch/mips/ralink/mt7621.c
@@ -7,22 +7,22 @@
#include
#include
+#include
+#include
+#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include "common.h"
-#define SYSC_REG_SYSCFG0x10
-#define SYSC_REG_CPLL_CLKCFG0 0x2c
-#define SYSC_REG_CUR_CLK_STS 0x44
-#define CPU_CLK_SEL(BIT(30) | BIT(31))
-
#define MT7621_GPIO_MODE_UART1 1
#define MT7621_GPIO_MODE_I2C 2
#define MT7621_GPIO_MODE_UART3_MASK0x3
@@ -108,49 +108,89 @@ static struct rt2880_pmx_group mt7621_pinmux_data[] = {
{ 0 }
};
+static struct clk *clks[MT7621_CLK_MAX];
+static struct clk_onecell_data clk_data = {
+ .clks = clks,
+ .clk_num = ARRAY_SIZE(clks),
+};
+
phys_addr_t mips_cpc_default_phys_base(void)
{
panic("Cannot detect cpc address");
}
+static struct clk *__init mt7621_add_sys_clkdev(
+ const char *id, unsigned long rate)
+{
+ struct clk *clk;
+ int err;
+
+ clk = clk_register_fixed_rate(NULL, id, NULL, 0, rate);
+ if (IS_ERR(clk))
+ panic("failed to allocate %s clock structure", id);
+
+ err = clk_register_clkdev(clk, id, NULL);
+ if (err)
+ panic("unable to register %s clock device", id);
+
+ return clk;
+}
+
void __init ralink_clk_init(void)
{
- int cpu_fdiv = 0;
- int cpu_ffrac = 0;
- int fbdiv = 0;
- u32 clk_sts, syscfg;
- u8 clk_sel = 0, xtal_mode;
- u32 cpu_clk;
+ const static u32 prediv_tbl[] = {0, 1, 2, 2};
+ u32 syscfg, xtal_sel, clkcfg, clk_sel, curclk, ffiv, ffrac;
+ u32 pll, prediv, fbdiv;
+ u32 xtal_clk, cpu_clk, bus_clk;
+
+ syscfg = rt_sysc_r32(SYSC_REG_SYSTEM_CONFIG0);
+ xtal_sel = (syscfg >> XTAL_MODE_SEL_SHIFT) & XTAL_MODE_SEL_MASK;
- if ((rt_sysc_r32(SYSC_REG_CPLL_CLKCFG0) & CPU_CLK_SEL) != 0)
- clk_sel = 1;
+ clkcfg = rt_sysc_r32(SYSC_REG_CLKCFG0);
+ clk_sel = (clkcfg >> CPU_CLK_SEL_SHIFT) & CPU_CLK_SEL_MASK;
+
+ curclk = rt_sysc_r32(SYSC_REG_CUR_CLK_STS);
+ ffiv = (curclk >> CUR_CPU_FDIV_SHIFT) & CUR_CPU_FDIV_MASK;
+ ffrac = (curclk >> CUR_CPU_FFRAC_SHIFT) & CUR_CPU_FFRAC_MASK;
+
+ if (xtal_sel <= 2)
+ xtal_clk = 20 * 1000 * 1000;
+ else if (xtal_sel <= 5)
+ xtal_clk = 40 * 1000 * 1000;
+ else
+ xtal_clk = 25 * 1000 * 1000;
switch (clk_sel) {
case 0:
- clk_sts = rt_sysc_r32(SYSC_REG_CUR_CLK_STS);
- cpu_fdiv = ((clk_sts >> 8) & 0x1F);
- cpu_ffrac = (clk_sts & 0x1F);
- cpu_clk = (500 * cpu_ffrac / cpu_fdiv) * 1000 * 1000;
+ cpu_clk = 500 * 1000 * 1000;
break;
-
case 1:
- fbdiv = ((rt_sysc
[PATCH 4/5] staging: mt7621-dts: add dt nodes for mt7621-pll
This commit adds device-tree node for mt7621-pll and use its clock
accordingly.
Signed-off-by: Chuanhong Guo
---
drivers/staging/mt7621-dts/mt7621.dtsi | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index a4c08110094b..12717f570ceb 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -1,4 +1,5 @@
#include
+#include
#include
/ {
@@ -27,12 +28,11 @@
serial0 = &uartlite;
};
- cpuclock: cpuclock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
+ pll: pll {
+ compatible = "mediatek,mt7621-pll", "syscon";
- /* FIXME: there should be way to detect this */
- clock-frequency = <88000>;
+ #clock-cells = <1>;
+ clock-output-names = "cpu", "bus";
};
sysclock: sysclock@0 {
@@ -155,7 +155,6 @@
compatible = "ns16550a";
reg = <0xc00 0x100>;
- clocks = <&sysclock>;
clock-frequency = <5000>;
interrupt-parent = <&gic>;
@@ -172,7 +171,7 @@
compatible = "ralink,mt7621-spi";
reg = <0xb00 0x100>;
- clocks = <&sysclock>;
+ clocks = <&pll MT7621_CLK_BUS>;
resets = <&rstctrl 18>;
reset-names = "spi";
@@ -372,7 +371,7 @@
timer {
compatible = "mti,gic-timer";
interrupts = ;
- clocks = <&cpuclock>;
+ clocks = <&pll MT7621_CLK_CPU>;
};
};
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/5] staging: mt7621-dts: fix register range of memc node in mt7621.dtsi
The memc node from mt7621.dtsi has incorrect register resource.
Fix it according to the programming guide.
Signed-off-by: Weijie Gao
Signed-off-by: Chuanhong Guo
---
drivers/staging/mt7621-dts/mt7621.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 12717f570ceb..ac9189276590 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -138,7 +138,7 @@
memc: memc@5000 {
compatible = "mtk,mt7621-memc";
- reg = <0x300 0x100>;
+ reg = <0x5000 0x1000>;
};
cpc: cpc@1fbf {
--
2.21.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Reminder: 1 open syzbot bug in "android/ashmem" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 1 of them as possibly being a bug in the "android/ashmem" subsystem. If you believe this bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed this bug to the "android/ashmem" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here is the bug: Title: WARNING in __vm_enough_memory Last occurred: 77 days ago Reported: 539 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=52304f8f4b4e28508d52875f95df5e30417eff1b Original thread: https://lkml.kernel.org/lkml/001a1144593661efb50562d96...@google.com/T/#u This bug has a C reproducer. The original thread for this bug received 1 reply, 539 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+cc298e15b6a571ba0...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/001a1144593661efb50562d96...@google.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: exfat filesystem
> -Original Message- > From: Valdis Kletnieks On Behalf Of Valdis Kletnieks > Sent: Tuesday, July 9, 2019 9:51 AM > To: KY Srinivasan > Cc: Matthew Wilcox ; Theodore Ts'o > ; Alexander Viro ; Greg Kroah- > Hartman ; linux-fsde...@vger.kernel.org; > linux-ker...@vger.kernel.org; de...@driverdev.osuosl.org; Sasha Levin > > Subject: Re: exfat filesystem > > On Tue, 09 Jul 2019 16:39:31 -, KY Srinivasan said: > > > Let me dig up the details here. > > In case this helps clarify the chain of events, the code in question is the > Samsung code mentioned here, updated to 5.2 kernel > > "We know that Microsoft has done patent troll shakedowns in the past on > Linux products related to the exfat filesystem. While we at Conservancy > were successful in getting the code that implements exfat for Linux released > under GPL (by Samsung), that code has not been upstreamed into Linux. So, > Microsoft has not included any patents they might hold on exfat into the > patent non-aggression pact." > > https://sfconservancy.org/blog/2018/oct/10/microsoft-oin-exfat/ > > (Link in that para points here): > https://sfconservancy.org/news/2013/aug/16/exfat-samsung/ > Thanks Valdis. I have started an internal thread on this; will get back ASAP. K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] media: dt: bindings: tegra-vde: Document new optional IOMMU property
On Sun, 23 Jun 2019 20:07:26 +0300, Dmitry Osipenko wrote: > All NVIDIA Tegra SoC generations provide IOMMU support for the video > decoder engine. Document new optional device-tree property that connects > VDE with the IOMMU provider. > > Signed-off-by: Dmitry Osipenko > --- > > No changes since v1. > > Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 00/12] treewide: Fix GENMASK misuses
These GENMASK uses are inverted argument order and the actual masks produced are incorrect. Fix them. Add checkpatch tests to help avoid more misuses too. Joe Perches (12): checkpatch: Add GENMASK tests clocksource/drivers/npcm: Fix misuse of GENMASK macro drm: aspeed_gfx: Fix misuse of GENMASK macro iio: adc: max9611: Fix misuse of GENMASK macro irqchip/gic-v3-its: Fix misuse of GENMASK macro mmc: meson-mx-sdio: Fix misuse of GENMASK macro net: ethernet: mediatek: Fix misuses of GENMASK macro net: stmmac: Fix misuses of GENMASK macro rtw88: Fix misuse of GENMASK macro phy: amlogic: G12A: Fix misuse of GENMASK macro staging: media: cedrus: Fix misuse of GENMASK macro ASoC: wcd9335: Fix misuse of GENMASK macro drivers/clocksource/timer-npcm7xx.c | 2 +- drivers/gpu/drm/aspeed/aspeed_gfx.h | 2 +- drivers/iio/adc/max9611.c | 2 +- drivers/irqchip/irq-gic-v3-its.c | 2 +- drivers/mmc/host/meson-mx-sdio.c | 2 +- drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +- drivers/net/ethernet/mediatek/mtk_sgmii.c | 2 +- drivers/net/ethernet/stmicro/stmmac/descs.h | 2 +- drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 4 ++-- drivers/net/wireless/realtek/rtw88/rtw8822b.c | 2 +- drivers/phy/amlogic/phy-meson-g12a-usb2.c | 2 +- drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 2 +- scripts/checkpatch.pl | 15 +++ sound/soc/codecs/wcd-clsh-v2.c| 2 +- 14 files changed, 29 insertions(+), 14 deletions(-) -- 2.15.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 11/12] staging: media: cedrus: Fix misuse of GENMASK macro
Arguments are supposed to be ordered high then low. Signed-off-by: Joe Perches --- drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h index 3e9931416e45..ddd29788d685 100644 --- a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h +++ b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h @@ -110,7 +110,7 @@ #define VE_DEC_MPEG_MBADDR (VE_ENGINE_DEC_MPEG + 0x10) #define VE_DEC_MPEG_MBADDR_X(w)(((w) << 8) & GENMASK(15, 8)) -#define VE_DEC_MPEG_MBADDR_Y(h)(((h) << 0) & GENMASK(0, 7)) +#define VE_DEC_MPEG_MBADDR_Y(h)(((h) << 0) & GENMASK(7, 0)) #define VE_DEC_MPEG_CTRL (VE_ENGINE_DEC_MPEG + 0x14) -- 2.15.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/5] staging: mt7621-dts: add dt nodes for mt7621-pll
On Wed, Jul 10, 2019 at 2:22 AM Chuanhong Guo wrote:
>
> This commit adds device-tree node for mt7621-pll and use its clock
> accordingly.
>
> Signed-off-by: Chuanhong Guo
Oops. Please ignore this single patch for now. I forgot to drop
cpuclock node in drivers/staging/mt7621-dts/gbpc1.dts
I'll resend this patch with changes for gbpc1.dts after the other four
patches are applied.
> ---
> drivers/staging/mt7621-dts/mt7621.dtsi | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
> b/drivers/staging/mt7621-dts/mt7621.dtsi
> index a4c08110094b..12717f570ceb 100644
> --- a/drivers/staging/mt7621-dts/mt7621.dtsi
> +++ b/drivers/staging/mt7621-dts/mt7621.dtsi
> @@ -1,4 +1,5 @@
> #include
> +#include
> #include
>
> / {
> @@ -27,12 +28,11 @@
> serial0 = &uartlite;
> };
>
> - cpuclock: cpuclock@0 {
> - #clock-cells = <0>;
> - compatible = "fixed-clock";
> + pll: pll {
> + compatible = "mediatek,mt7621-pll", "syscon";
>
> - /* FIXME: there should be way to detect this */
> - clock-frequency = <88000>;
> + #clock-cells = <1>;
> + clock-output-names = "cpu", "bus";
> };
>
> sysclock: sysclock@0 {
> @@ -155,7 +155,6 @@
> compatible = "ns16550a";
> reg = <0xc00 0x100>;
>
> - clocks = <&sysclock>;
> clock-frequency = <5000>;
>
> interrupt-parent = <&gic>;
> @@ -172,7 +171,7 @@
> compatible = "ralink,mt7621-spi";
> reg = <0xb00 0x100>;
>
> - clocks = <&sysclock>;
> + clocks = <&pll MT7621_CLK_BUS>;
>
> resets = <&rstctrl 18>;
> reset-names = "spi";
> @@ -372,7 +371,7 @@
> timer {
> compatible = "mti,gic-timer";
> interrupts = ;
> - clocks = <&cpuclock>;
> + clocks = <&pll MT7621_CLK_CPU>;
> };
> };
>
> --
> 2.21.0
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
