Re: [PATCH 1/1] iommu/arm-smmu: Add support to use Last level cache
Hi Robin, On Fri, Dec 7, 2018 at 2:54 PM Vivek Gautam wrote: > > Hi Robin, > > On Tue, Dec 4, 2018 at 8:51 PM Robin Murphy wrote: > > > > On 04/12/2018 11:01, Vivek Gautam wrote: > > > Qualcomm SoCs have an additional level of cache called as > > > System cache, aka. Last level cache (LLC). This cache sits right > > > before the DDR, and is tightly coupled with the memory controller. > > > The cache is available to all the clients present in the SoC system. > > > The clients request their slices from this system cache, make it > > > active, and can then start using it. > > > For these clients with smmu, to start using the system cache for > > > buffers and, related page tables [1], memory attributes need to be > > > set accordingly. > > > This change updates the MAIR and TCR configurations with correct > > > attributes to use this system cache. > > > > > > To explain a little about memory attribute requirements here: > > > > > > Non-coherent I/O devices can't look-up into inner caches. However, > > > coherent I/O devices can. But both can allocate in the system cache > > > based on system policy and configured memory attributes in page > > > tables. > > > CPUs can access both inner and outer caches (including system cache, > > > aka. Last level cache), and can allocate into system cache too > > > based on memory attributes, and system policy. > > > > > > Further looking at memory types, we have following - > > > a) Normal uncached :- MAIR 0x44, inner non-cacheable, > > >outer non-cacheable; > > > b) Normal cached :- MAIR 0xff, inner read write-back non-transient, > > >outer read write-back non-transient; > > >attribute setting for coherenet I/O devices. > > > > > > and, for non-coherent i/o devices that can allocate in system cache > > > another type gets added - > > > c) Normal sys-cached/non-inner-cached :- > > >MAIR 0xf4, inner non-cacheable, > > >outer read write-back non-transient > > > > > > So, CPU will automatically use the system cache for memory marked as > > > normal cached. The normal sys-cached is downgraded to normal non-cached > > > memory for CPUs. > > > Coherent I/O devices can use system cache by marking the memory as > > > normal cached. > > > Non-coherent I/O devices, to use system cache, should mark the memory as > > > normal sys-cached in page tables. > > > > > > This change is a realisation of following changes > > > from downstream msm-4.9: > > > iommu: io-pgtable-arm: Support DOMAIN_ATTRIBUTE_USE_UPSTREAM_HINT[2] > > > iommu: io-pgtable-arm: Implement IOMMU_USE_UPSTREAM_HINT[3] > > > > > > [1] https://patchwork.kernel.org/patch/10302791/ > > > [2] > > > https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/?h=msm-4.9=bf762276796e79ca90014992f4d9da5593fa7d51 > > > [3] > > > https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/?h=msm-4.9=d4c72c413ea27c43f60825193d4de9cb8ffd9602 > > > > > > Signed-off-by: Vivek Gautam > > > --- > > > > > > Changes since v1: > > > - Addressed Tomasz's comments for basing the change on > > > "NO_INNER_CACHE" concept for non-coherent I/O devices > > > rather than capturing "SYS_CACHE". This is to indicate > > > clearly the intent of non-coherent I/O devices that > > > can't access inner caches. > > > > That seems backwards to me - there is already a fundamental assumption > > that non-coherent devices can't access caches. What we're adding here is > > a weird exception where they *can* use some level of cache despite still > > being non-coherent overall. > > > > In other words, it's not a case of downgrading coherent devices' > > accesses to bypass inner caches, it's upgrading non-coherent devices' > > accesses to hit the outer cache. That's certainly the understanding I > > got from talking with Pratik at Plumbers, and it does appear to fit with > > your explanation above despite the final conclusion you draw being > > different. > > Thanks for the thorough review of the change. > Right, I guess it's rather an upgrade for non-coherent devices to use > an outer cache than a downgrade for coherent devices. > > > > > I do see what Tomasz meant in terms of the TCR attributes, but what we > > currently do there is a little unintuitive and not at all representative > > of actual mapping attributes - I'll come back to that inline. > > > > > drivers/iommu/arm-smmu.c | 15 +++ > > > drivers/iommu/dma-iommu.c | 3 +++ > > > drivers/iommu/io-pgtable-arm.c | 22 +- > > > drivers/iommu/io-pgtable.h | 5 + > > > include/linux/iommu.h | 3 +++ > > > 5 files changed, 43 insertions(+), 5 deletions(-) > > > > As a minor nit, I'd prefer this as at least two patches to separate the > > io-pgtable changes and arm-smmu changes - basically I'd expect it to > > look much the same as the non-strict mode support did. > > Sure, will split the patch. > >
[GIT PULL] s390 patches for the 4.21 merge window
Hi Linus, please pull s390 fixes and features for 4.21 The following changes since commit 94f371cb73944b410a269d570d6946c042f2ddd0: Merge tag 'acpi-4.20-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm (2018-11-29 15:54:12 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-4.21-1 for you to fetch changes up to ec10574d00da0d8b6ec9d0099410aae8aad4695a: Merge tag 'vfio-ccw-20181213' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into features (2018-12-13 10:44:18 +0100) s390 updates for the 4.21 merge window - A larger update for the zcrypt / AP bus code + Update two inline assemblies in the zcrypt driver to make gcc happy + Add a missing reply code for invalid special commands for zcrypt + Allow AP device reset to be triggered from user space + Split the AP scan function into smaller, more readable functions - Updates for vfio-ccw and vfio-ap + Add maintainers and reviewer for vfio-ccw + Include facility.h in vfio_ap_drv.c to avoid fragile include chain + Simplicy vfio-ccw state machine - Use the common code version of bust_spinlocks - Make use of the DEFINE_SHOW_ATTRIBUTE - Fix three incorrect file permissions in the DASD driver - Remove bit spin-lock from the PCI interrupt handler - Fix GFP_ATOMIC vs GFP_KERNEL in the PCI code Christian Borntraeger (1): MAINTAINERS/vfio-ccw: add Farhan and Eric, make Halil Reviewer Harald Freudenberger (4): s390/ap: rework assembler functions to use unions for in/out register variables s390/zcrypt: improve special ap message cmd handling s390/zcrypt: make sysfs reset attribute trigger queue reset s390/zcrypt: rework ap scan bus code Martin Schwidefsky (1): Merge tag 'vfio-ccw-20181213' of git://git.kernel.org/.../kvms390/vfio-ccw into features Petr Tesarik (1): s390: vfio-ap: include for test_facility() Pierre Morel (1): vfio: ccw: Merge BUSY and BOXED states Sebastian Ott (3): s390/drivers: fix proc/debugfs file permissions s390/pci: remove bit_lock usage in interrupt handler s390/pci: fix sleeping in atomic during hotplug Sergey Senozhatsky (1): s390: use common bust_spinlocks() Yangtao Li (1): s390: convert to DEFINE_SHOW_ATTRIBUTE MAINTAINERS | 4 +- arch/s390/include/asm/ap.h | 28 ++-- arch/s390/include/uapi/asm/zcrypt.h | 4 +- arch/s390/mm/fault.c| 24 arch/s390/pci/pci.c | 4 +- arch/s390/pci/pci_clp.c | 2 +- drivers/s390/block/dasd.c | 15 +- drivers/s390/block/dasd_proc.c | 3 +- drivers/s390/char/tape_proc.c | 7 +- drivers/s390/cio/qdio_debug.c | 18 +-- drivers/s390/cio/vfio_ccw_fsm.c | 7 +- drivers/s390/cio/vfio_ccw_private.h | 1 - drivers/s390/crypto/ap_bus.c| 277 +--- drivers/s390/crypto/ap_queue.c | 23 ++- drivers/s390/crypto/vfio_ap_drv.c | 1 + drivers/s390/crypto/zcrypt_error.h | 2 + lib/bust_spinlocks.c| 6 +- 17 files changed, 222 insertions(+), 204 deletions(-)
Re: [PATCH v3] regmap: regmap-irq/gpio-max77620: add level-irq support
On Mon, Dec 31, 2018 at 07:11:27PM +, Mark Brown wrote: > On Fri, Dec 28, 2018 at 10:05:33AM +0200, Matti Vaittinen wrote: > > > Last night - just when I was about to get some sleep - it stroke me. I > > think the correct thing to do would be leaving the irq_set_type to NULL > > for those IRQ chips which do not support type setting. If we do that, > > then the irq core will take care of situations where user requests type > > setting but the chip does not support it. Which means the regmap-irq > > would be no different from any other irq chip where type setting is not > > supported. > > Yes, this is the best fix - let the framework handle things properly. > We'll need a second set of operations and to select which to use based > on having type information but that's fine. > > > So at the cost of removing "const" from regmap_irq_chip we could do: > > ... > > > Mark, Geert, what do you think? (And maybe same for the .irq_set_wake - > > but I did omit this as I have never looked at the wake functionality > > before). > > We need a separate struct as otherwise if there's multiple devices with > regmap irq_chip implementations then they'll collide with each other Right. I must admit I didn't notice this! I was about to make a nasty error there... > otherwise I like this approach (or we could copy the irq_chip struct > when registering and then modify which is going to scale a bit better - I am really not a fan of dynamic allocation - I'd rather had static structs with different set of operations. But I admit I can't think of a sane system where we would have more than few regmap_irq controllers so memory consumption of allocating new structs is hardly an issue here. > you're probably right that we need to do the same thing for the wake > configuration. I'll still look at applying your patch as a temporary > fix though. Thanks Mark. I try to cook a patch with copying of struct irq_chip still at this week but I wont rush it (I have some other topics under work) as the regression should be fixed by the other patch. Br, Matti Vaittinen -- Matti Vaittinen ROHM Semiconductors ~~~ "I don't think so," said Rene Descartes. Just then, he vanished ~~~
Re: general protection fault in transparent_hugepage_enabled
On 12/24/18 4:48 PM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:6a1d293238c1 Add linux-next specific files for 20181224 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=149a2add40 > kernel config: https://syzkaller.appspot.com/x/.config?x=c190b602a5d2d731 > dashboard link: https://syzkaller.appspot.com/bug?extid=a5fea9200aefd1cf4818 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1798bfb740 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f4dc5740 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+a5fea9200aefd1cf4...@syzkaller.appspotmail.com > > sshd (6016) used greatest stack depth: 15720 bytes left > kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] PREEMPT SMP KASAN > CPU: 1 PID: 6032 Comm: syz-executor045 Not tainted 4.20.0-rc7-next-20181224 > #187 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:transparent_hugepage_enabled+0x8c/0x5e0 mm/huge_memory.c:69 FTR, it was most certainly the same thing as here: https://marc.info/?l=linux-mm=154563777207477=2 > Code: 80 3c 02 00 0f 85 ae 04 00 00 4c 8b a3 a0 00 00 00 48 b8 00 00 00 00 > 00 fc ff df 49 8d bc 24 b8 01 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f > 85 91 04 00 00 49 8b bc 24 b8 01 00 00 e8 2d 70 e6 > RSP: 0018:8881c2237138 EFLAGS: 00010202 > RAX: dc00 RBX: 8881c2bdbc60 RCX: > RDX: 0037 RSI: 81c8fa1a RDI: 01b8 > RBP: 8881c2237160 R08: ed10383b25ed R09: ed10383b25ec > R10: ed10383b25ec R11: 8881c1d92f63 R12: > R13: 8881c2bdbd00 R14: dc00 R15: 0f5e > FS: 01a48880() GS:8881dad0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 20b58000 CR3: 0001c221 CR4: 001406e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > show_smap+0x167/0x580 fs/proc/task_mmu.c:805 > traverse+0x344/0x7b0 fs/seq_file.c:113 > seq_read+0xc76/0x1150 fs/seq_file.c:188 > do_loop_readv_writev fs/read_write.c:700 [inline] > do_iter_read+0x4bc/0x670 fs/read_write.c:924 > vfs_readv+0x175/0x1c0 fs/read_write.c:986 > kernel_readv fs/splice.c:362 [inline] > default_file_splice_read+0x539/0xb20 fs/splice.c:417 > do_splice_to+0x12e/0x190 fs/splice.c:880 > splice_direct_to_actor+0x31c/0x9d0 fs/splice.c:957 > do_splice_direct+0x2d4/0x420 fs/splice.c:1066 > do_sendfile+0x62a/0xe50 fs/read_write.c:1439 > __do_sys_sendfile64 fs/read_write.c:1494 [inline] > __se_sys_sendfile64 fs/read_write.c:1486 [inline] > __x64_sys_sendfile64+0x15d/0x250 fs/read_write.c:1486 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x440089 > Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > ff 0f 83 5b 14 fc ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7fff3d710a18 EFLAGS: 0213 ORIG_RAX: 0028 > RAX: ffda RBX: 7fff3d710a20 RCX: 00440089 > RDX: 20b58000 RSI: 0003 RDI: 0003 > RBP: 006ca018 R08: 0010 R09: 65732f636f72702f > R10: R11: 0213 R12: 00401970 > R13: 00401a00 R14: R15: > Modules linked in: > ---[ end trace faf026efd8795e93 ]--- > RIP: 0010:transparent_hugepage_enabled+0x8c/0x5e0 mm/huge_memory.c:69 > Code: 80 3c 02 00 0f 85 ae 04 00 00 4c 8b a3 a0 00 00 00 48 b8 00 00 00 00 > 00 fc ff df 49 8d bc 24 b8 01 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f > 85 91 04 00 00 49 8b bc 24 b8 01 00 00 e8 2d 70 e6 > RSP: 0018:8881c2237138 EFLAGS: 00010202 > RAX: dc00 RBX: 8881c2bdbc60 RCX: > RDX: 0037 RSI: 81c8fa1a RDI: 01b8 > RBP: 8881c2237160 R08: ed10383b25ed R09: ed10383b25ec > R10: ed10383b25ec R11: 8881c1d92f63 R12: > R13: 8881c2bdbd00 R14: dc00 R15: 0f5e > FS: 01a48880() GS:8881dad0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 20b58000 CR3: 0001c221 CR4: 001406e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. >
Re: device_sysfs.c:undefined reference to `utf16s_to_utf8s'
On Tue, Jan 1, 2019 at 11:43 PM kbuild test robot wrote: > > Hi Sinan, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 28e8c4bc8eb483c22d977e147a0b98fc63efadf7 > commit: 5d32a66541c4683456507481a0944ed2985e75c7 PCI/ACPI: Allow ACPI to be > built without CONFIG_PCI set > date: 13 days ago > config: i386-alldefconfig (attached as .config) > compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 > reproduce: > git checkout 5d32a66541c4683456507481a0944ed2985e75c7 > # save the attached .config to linux build tree > make ARCH=i386 > > All errors (new ones prefixed by >>): > >drivers/acpi/device_sysfs.o: In function `description_show': > >> device_sysfs.c:(.text+0x44b): undefined reference to `utf16s_to_utf8s' > I posted a patch to fix the issue. Someone needs to pick it up. https://patchwork.kernel.org/patch/10745249/ > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH 6/8] scsi: pm80xx: reduce indentation
On Sun, Dec 30, 2018 at 5:29 PM Julia Lawall wrote:
>
> Delete tab aligning a statement with the right hand side of a
> preceding assignment rather than the left hand side.
>
> Found with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Thanks, Julia.
Acked-by: Jack Wang
>
> ---
> drivers/scsi/pm8001/pm8001_sas.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_sas.c
> b/drivers/scsi/pm8001/pm8001_sas.c
> index b3be49d41375..44b630aceb12 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.c
> +++ b/drivers/scsi/pm8001/pm8001_sas.c
> @@ -657,7 +657,7 @@ static int pm8001_dev_found_notify(struct domain_device
> *dev)
> if (dev->dev_type == SAS_SATA_DEV) {
> pm8001_device->attached_phy =
> dev->rphy->identify.phy_identifier;
> - flag = 1; /* directly sata*/
> + flag = 1; /* directly sata*/
> }
> } /*register this device to HBA*/
> PM8001_DISC_DBG(pm8001_ha, pm8001_printk("Found device\n"));
>
--
Jack Wang
Linux Kernel Developer
1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
Phone: +49 30 57700-8042 | Fax: +49 30 57700-8598
E-mail: jinpu.w...@cloud.ionos.com | Web: www.ionos.de
Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss
Member of United Internet
Re: [PATCH 1/1] iommu/arm-smmu: Add support to use Last level cache
On Thu, Dec 13, 2018 at 9:20 AM Tomasz Figa wrote: > > On Fri, Dec 7, 2018 at 6:25 PM Vivek Gautam > wrote: > > > > Hi Robin, > > > > On Tue, Dec 4, 2018 at 8:51 PM Robin Murphy wrote: > > > > > > On 04/12/2018 11:01, Vivek Gautam wrote: > > > > Qualcomm SoCs have an additional level of cache called as > > > > System cache, aka. Last level cache (LLC). This cache sits right > > > > before the DDR, and is tightly coupled with the memory controller. > > > > The cache is available to all the clients present in the SoC system. > > > > The clients request their slices from this system cache, make it > > > > active, and can then start using it. > > > > For these clients with smmu, to start using the system cache for > > > > buffers and, related page tables [1], memory attributes need to be > > > > set accordingly. > > > > This change updates the MAIR and TCR configurations with correct > > > > attributes to use this system cache. > > > > > > > > To explain a little about memory attribute requirements here: > > > > > > > > Non-coherent I/O devices can't look-up into inner caches. However, > > > > coherent I/O devices can. But both can allocate in the system cache > > > > based on system policy and configured memory attributes in page > > > > tables. > > > > CPUs can access both inner and outer caches (including system cache, > > > > aka. Last level cache), and can allocate into system cache too > > > > based on memory attributes, and system policy. > > > > > > > > Further looking at memory types, we have following - > > > > a) Normal uncached :- MAIR 0x44, inner non-cacheable, > > > >outer non-cacheable; > > > > b) Normal cached :- MAIR 0xff, inner read write-back non-transient, > > > >outer read write-back non-transient; > > > >attribute setting for coherenet I/O devices. > > > > > > > > and, for non-coherent i/o devices that can allocate in system cache > > > > another type gets added - > > > > c) Normal sys-cached/non-inner-cached :- > > > >MAIR 0xf4, inner non-cacheable, > > > >outer read write-back non-transient > > > > > > > > So, CPU will automatically use the system cache for memory marked as > > > > normal cached. The normal sys-cached is downgraded to normal non-cached > > > > memory for CPUs. > > > > Coherent I/O devices can use system cache by marking the memory as > > > > normal cached. > > > > Non-coherent I/O devices, to use system cache, should mark the memory as > > > > normal sys-cached in page tables. > > > > > > > > This change is a realisation of following changes > > > > from downstream msm-4.9: > > > > iommu: io-pgtable-arm: Support DOMAIN_ATTRIBUTE_USE_UPSTREAM_HINT[2] > > > > iommu: io-pgtable-arm: Implement IOMMU_USE_UPSTREAM_HINT[3] > > > > > > > > [1] https://patchwork.kernel.org/patch/10302791/ > > > > [2] > > > > https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/?h=msm-4.9=bf762276796e79ca90014992f4d9da5593fa7d51 > > > > [3] > > > > https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/?h=msm-4.9=d4c72c413ea27c43f60825193d4de9cb8ffd9602 > > > > > > > > Signed-off-by: Vivek Gautam > > > > --- > > > > > > > > Changes since v1: > > > > - Addressed Tomasz's comments for basing the change on > > > > "NO_INNER_CACHE" concept for non-coherent I/O devices > > > > rather than capturing "SYS_CACHE". This is to indicate > > > > clearly the intent of non-coherent I/O devices that > > > > can't access inner caches. > > > > > > That seems backwards to me - there is already a fundamental assumption > > > that non-coherent devices can't access caches. What we're adding here is > > > a weird exception where they *can* use some level of cache despite still > > > being non-coherent overall. > > > > > > In other words, it's not a case of downgrading coherent devices' > > > accesses to bypass inner caches, it's upgrading non-coherent devices' > > > accesses to hit the outer cache. That's certainly the understanding I > > > got from talking with Pratik at Plumbers, and it does appear to fit with > > > your explanation above despite the final conclusion you draw being > > > different. > > > > Thanks for the thorough review of the change. > > Right, I guess it's rather an upgrade for non-coherent devices to use > > an outer cache than a downgrade for coherent devices. > > > > Note that it was not my suggestion to use "NO_INNER_CACHE" for > enabling the system cache, sorry for not being clear. What I was > asking for in my comment was regarding the previous patch disabling > inner cache if system cache is requested, which may not make for > coherent devices, which could benefit from using both inner and system > cache. Sorry for not taking the cue correctly. The intention of the change was to let coherent devices use system cache as well. But I guess the change wasn't designed correctly. > > So note that there are several cases here: > -
[RFC v3 2/2] pstore/rom: add sample for pstore_rom
It is a sample for pstore_rom, using general ram rather than block device.
According to pstore_rom, the data will be saved to ram buffer if not
register device path and apis for panic. So, it can only used to dump
Oops and some things will not reboot.
Signed-off-by: liaoweixiong
---
fs/pstore/Kconfig | 9 +
fs/pstore/Makefile | 2 ++
fs/pstore/rombuf.c | 46 ++
3 files changed, 57 insertions(+)
create mode 100644 fs/pstore/rombuf.c
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index abf0453..426b5ea 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -159,3 +159,12 @@ config PSTORE_ROM
help
This enables panic and oops message to be logged to a block dev
where it can be read back at some later point.
+
+config PSTORE_ROMBUF
+ tristate "romoop buffer sample"
+ depends on PSTORE_ROM
+ help
+ This is a sample for pstore rom, but do NOT have a block dev.
+ According to pstore_rom, the data will be saved to ram buffer and
+ dropped when reboot. So, it can only used to dump Oops and some
+ things will not reboot.
diff --git a/fs/pstore/Makefile b/fs/pstore/Makefile
index ea38d6e..21c1226 100644
--- a/fs/pstore/Makefile
+++ b/fs/pstore/Makefile
@@ -15,3 +15,5 @@ obj-$(CONFIG_PSTORE_RAM) += ramoops.o
obj-$(CONFIG_PSTORE_ROM) += romoops.o
romoops-y += romzone.o
+
+obj-$(CONFIG_PSTORE_ROMBUF)+= rombuf.o
diff --git a/fs/pstore/rombuf.c b/fs/pstore/rombuf.c
new file mode 100644
index 000..bb21a85
--- /dev/null
+++ b/fs/pstore/rombuf.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * rombuf.c: ROM Oops/Panic logger
+ *
+ * Copyright (C) 2019 liaoweixiong
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#define pr_fmt(fmt) "rombuf: " fmt
+
+#include
+#include
+#include
+
+struct romz_info rombuf_info = {
+ .owner = THIS_MODULE,
+ .name = "rombuf",
+ .part_size = 512 * 1024,
+ .dmesg_size = 64 * 1024,
+ .dump_oops = true,
+};
+
+static int __init rombuf_init(void)
+{
+ return romz_register(_info);
+}
+module_init(rombuf_init);
+
+static void __exit rombuf_exit(void)
+{
+ romz_unregister(_info);
+}
+module_exit(rombuf_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("liaoweixiong ");
+MODULE_DESCRIPTION("Sample for Pstore ROM with Oops logger");
--
1.9.1
[RFC v3 1/2] pstore/rom: new support logger for block devices
pstore_rom is similar to pstore_ram, but dump log to block devices
rather than persistent ram.
Why should we need pstore_rom?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fast, there is already a sample for block device logger in driver
MTD (drivers/mtd/mtdoops.c).
2. Do not any equipment have battery, which means that it lost all data
on general ram if power failure. Pstore has little to do for these
equipments.
pstore_rom can only dump Oops/Panic log to block devices. It only
supports dmesg now. To make pstore_rom work, the block driver should
provide the path of a block partition device (/dev/) and the
read/write apis when on panic.
pstore_rom begins at 'romz_register', by witch block device can register
a block partition to pstore_rom. Then pstore_rom divide and manage the
partition as zones, which is similar to pstore_ram.
Recommend that, block driver register pstore_rom after block device is
ready.
pstore_rom works well on allwinner(sunxi) platform.
Signed-off-by: liaoweixiong
---
fs/pstore/Kconfig | 7 +
fs/pstore/Makefile | 3 +
fs/pstore/romzone.c| 957 +
include/linux/pstore_rom.h | 61 +++
4 files changed, 1028 insertions(+)
create mode 100644 fs/pstore/romzone.c
create mode 100644 include/linux/pstore_rom.h
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index 8b3ba27..abf0453 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -152,3 +152,10 @@ config PSTORE_RAM
"ramoops.ko".
For more information, see Documentation/admin-guide/ramoops.rst.
+
+config PSTORE_ROM
+ tristate "Log panic/oops to a block device"
+ depends on PSTORE
+ help
+ This enables panic and oops message to be logged to a block dev
+ where it can be read back at some later point.
diff --git a/fs/pstore/Makefile b/fs/pstore/Makefile
index 967b589..ea38d6e 100644
--- a/fs/pstore/Makefile
+++ b/fs/pstore/Makefile
@@ -12,3 +12,6 @@ pstore-$(CONFIG_PSTORE_PMSG) += pmsg.o
ramoops-objs += ram.o ram_core.o
obj-$(CONFIG_PSTORE_RAM) += ramoops.o
+
+obj-$(CONFIG_PSTORE_ROM) += romoops.o
+romoops-y += romzone.o
diff --git a/fs/pstore/romzone.c b/fs/pstore/romzone.c
new file mode 100644
index 000..afebfbc
--- /dev/null
+++ b/fs/pstore/romzone.c
@@ -0,0 +1,957 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * romzone.c: ROM Oops/Panic logger
+ *
+ * Copyright (C) 2019 liaoweixiong
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#define pr_fmt(fmt) "romzone: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct romz_head - head of zone to flush to storage
+ *
+ * @sig: signature to indicate header (ROM_SIG xor ROMZONE-type value)
+ * @datalen: length of data in @data
+ * @data: zone data.
+ */
+struct romz_buffer {
+#define ROM_SIG (0x43474244) /* DBGC */
+ uint32_t sig;
+ atomic_t datalen;
+ uint8_t data[0];
+};
+
+/**
+ * sruct romz_dmesg_header: dmesg information
+ *
+ * @magic: magic num for dmesg header
+ * @time: trigger time
+ * @compressed: whether conpressed
+ * @count: oops/panic counter
+ * @reason: identify oops or panic
+ */
+struct romz_dmesg_header {
+#define DMESG_HEADER_MAGIC 0x4dfc3ae5
+ uint32_t magic;
+ struct timespec64 time;
+ bool compressed;
+ uint32_t counter;
+ enum kmsg_dump_reason reason;
+ uint8_t data[0];
+};
+
+/**
+ * struct romz_zone - zone information
+ * @off:
+ * zone offset of partition
+ * @type:
+ * frontent type for this zone
+ * @name:
+ * frontent name for this zone
+ * @buffer:
+ * pointer to data buffer managed by this zone
+ * @buffer_size:
+ * bytes in @buffer->data
+ * @should_recover:
+ * should recover from storage
+ * @dirty:
+ * mark whether the data in @buffer are dirty (not flush to storage yet)
+ */
+struct romz_zone {
+ unsigned long off;
+ const char *name;
+ enum pstore_type_id type;
+
+ struct romz_buffer *buffer;
+ size_t buffer_size;
+ bool should_recover;
+ atomic_t dirty;
+};
+
+struct romoops_context {
+ struct romz_zone **drzs;/* Oops dump zones */
+ unsigned int dmesg_max_cnt;
+ unsigned int dmesg_read_cnt;
+ unsigned int dmesg_write_cnt;
+ /**
+* the counter should be recovered when do recovery
+* It records the oops/panic times after burning rather than booting.
+*/
+
[RFC v3 0/2] pstore/rom: new support logger for block devices
Why should we need pstore_rom? 1. Most embedded intelligent equipment have no persistent ram, which increases costs. We perfer to cheaper solutions, like block devices. In fast, there is already a sample for block device logger in driver MTD (drivers/mtd/mtdoops.c). 2. Do not any equipment have battery, which means that it lost all data on general ram if power failure. Pstore has little to do for these equipments. [PATCH v1] On patch 1: Core codes of pstore_rom, which works well on allwinner(sunxi) platform. On patch 2: A sample for pstore_rom, using general ram rather than block device. [PATCH v2] On patch 1: Fix build as module error for redefinition of 'romz_unregister' and 'romz_register' [PATCH v3] On patch 1: Fix build as module error for undefined 'vfs_read' and 'vfs_write' Both of 'vfs_read' and 'vfs_write' haven't be exproted yet, so we use 'kernel_read' and 'kernel_write' instead. liaoweixiong (2): pstore/rom: new support logger for block devices pstore/rom: add sample for pstore_rom fs/pstore/Kconfig | 16 + fs/pstore/Makefile | 5 + fs/pstore/rombuf.c | 46 +++ fs/pstore/romzone.c| 957 + include/linux/pstore_rom.h | 61 +++ 5 files changed, 1085 insertions(+) create mode 100644 fs/pstore/rombuf.c create mode 100644 fs/pstore/romzone.c create mode 100644 include/linux/pstore_rom.h -- 1.9.1
Re: [PATCH] genirq: Make sure the affinity to be set is not empty
On 12/20/2018 7:05 PM, Srinivas Ramana wrote:
If the default_affinity is managed/initialized by a system and
all the cpus present in irq_default_affinity are hotplugged out
we may end up passing a cpumask of 0 to irq_do_set_affinity().
Fix this by falling back to cpu_online_mask in case the
calculated affinity becomes zero.
Signed-off-by: Srinivas Ramana
---
kernel/irq/manage.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 9dbdccab3b6a..5c0ba5ca5930 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -393,6 +393,9 @@ int irq_setup_affinity(struct irq_desc *desc)
}
cpumask_and(, cpu_online_mask, set);
+ if (cpumask_empty())
+ cpumask_copy(, cpu_online_mask);
+
if (node != NUMA_NO_NODE) {
const struct cpumask *nodemask = cpumask_of_node(node);
Hi,
Can you provide your feedback on this?
Thanks,
-- Srinivas R
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
RE: [PATCH] driver: uio: fix possible memory leak in uio_open
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Xiubo Li
> Sent: Wednesday, January 02, 2019 2:37 PM
> To: liujian (CE)
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] driver: uio: fix possible memory leak in uio_open
>
> On 2019/1/3 0:26, liujian wrote:
> > Fixes: 57c5f4df0a5a ("uio: fix crash after the device is
> > unregistered")
> > Signed-off-by: liujian
> > ---
> > drivers/uio/uio.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c index
> > 5c10fc7..bde7d7a 100644
> > --- a/drivers/uio/uio.c
> > +++ b/drivers/uio/uio.c
> > @@ -496,7 +496,7 @@ static int uio_open(struct inode *inode, struct file
> *filep)
> > if (!idev->info) {
> > mutex_unlock(>info_lock);
> > ret = -EINVAL;
> > - goto err_alloc_listener;
> > + goto err_infoopen;
> > }
> >
> > if (idev->info && idev->info->open) @@ -508,6 +508,7 @@ static int
> > uio_open(struct inode *inode, struct file *filep)
> > return 0;
> >
> > err_infoopen:
>
> Maybe we should rename the "err_infoopen" to something like
> "err_idev_info"...
>
Yes, it's better to change this, I will send v2, thank you~
Best Regards,
liujian
> Thanks.
>
> BRs
>
> > + filep->private_data = NULL;
> > kfree(listener);
> >
> > err_alloc_listener:
>
Re: [PATCH v5 18/20] iommu/mediatek: Fix VLD_PA_RANGE register backup when suspend
On Tue, Jan 1, 2019 at 11:59 AM Yong Wu wrote:
>
> The register VLD_PA_RNG(0x118) was forgot to backup while adding 4GB
> mode support for mt2712. this patch add it.
>
> Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
> for 4GB mode")
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 2 ++
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 7fcef19..ddf1969 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -716,6 +716,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device
> *dev)
> reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
> reg->int_main_control = readl_relaxed(base +
> REG_MMU_INT_MAIN_CONTROL);
> reg->ivrp_paddr = readl_relaxed(base + REG_MMU_IVRP_PADDR);
> + reg->vld_pa_range = readl_relaxed(base + REG_MMU_VLD_PA_RNG);
Don't we want to add:
if (data->plat_data->vld_pa_rng)
before this save/restore operation? Or it doesn't matter?
> clk_disable_unprepare(data->bclk);
> return 0;
> }
> @@ -740,6 +741,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
> *dev)
> writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
> writel_relaxed(reg->int_main_control, base +
> REG_MMU_INT_MAIN_CONTROL);
> writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
> + writel_relaxed(reg->vld_pa_range, base + REG_MMU_VLD_PA_RNG);
> if (m4u_dom)
> writel(m4u_dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
>base + REG_MMU_PT_BASE_ADDR);
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 0a7c463..c500bfd 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -33,6 +33,7 @@ struct mtk_iommu_suspend_reg {
> u32 int_control0;
> u32 int_main_control;
> u32 ivrp_paddr;
> + u32 vld_pa_range;
Well, please be consistent ,-) Either vld_pa_rng, or valid_pa_range ,-)
> };
>
> enum mtk_iommu_plat {
> --
> 1.9.1
>
Re: [PATCH v1] phy: qcom-ufs: Use iopoll.h readl_poll_timeout macro
On Fri, Dec 21, 2018 at 9:43 PM Marc Gonzalez wrote:
>
> The private copy of readl_poll_timeout is no longer needed.
> Use the implementation in iopoll.h instead.
>
> Signed-off-by: Marc Gonzalez
> ---
> drivers/phy/qualcomm/phy-qcom-ufs-i.h | 19 +--
> 1 file changed, 1 insertion(+), 18 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-ufs-i.h
> b/drivers/phy/qualcomm/phy-qcom-ufs-i.h
> index 681644e43248..f798fb64de94 100644
> --- a/drivers/phy/qualcomm/phy-qcom-ufs-i.h
> +++ b/drivers/phy/qualcomm/phy-qcom-ufs-i.h
> @@ -23,24 +23,7 @@
> #include
> #include
> #include
> -
> -#define readl_poll_timeout(addr, val, cond, sleep_us, timeout_us) \
> -({ \
> - ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
> - might_sleep_if(timeout_us); \
> - for (;;) { \
> - (val) = readl(addr); \
> - if (cond) \
> - break; \
> - if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
> - (val) = readl(addr); \
> - break; \
> - } \
> - if (sleep_us) \
> - usleep_range(DIV_ROUND_UP(sleep_us, 4), sleep_us); \
> - } \
> - (cond) ? 0 : -ETIMEDOUT; \
> -})
> +#include
>
> #define UFS_QCOM_PHY_CAL_ENTRY(reg, val) \
> { \
> --
> 2.17.1
Thanks for the patch. LGTM.
Reviewed-by: Vivek Gautam
Best regards
Vivek
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] n_tty: update comment for WAKEUP_CHARS define
On 29. 12. 18, 13:48, Valentin Vidic wrote: > Give a better descriptions of what WAKEUP_CHARS represents. > > Signed-off-by: Valentin Vidic I am not a native speaker, but this is much better than the current text. Acked-by: Jiri Slaby BTW this text is copy from/to all the other WAKEUP_CHARS locations. Care to fix them all? > --- > drivers/tty/n_tty.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c > index 3ad460219fd6..1dfbd45746da 100644 > --- a/drivers/tty/n_tty.c > +++ b/drivers/tty/n_tty.c > @@ -50,8 +50,10 @@ > #include > #include > > - > -/* number of characters left in xmit buffer before select has we have room */ > +/* > + * Until this number of characters is queued in the xmit buffer, select will > + * return "we have room for writes". > + */ > #define WAKEUP_CHARS 256 > > /* > thanks, -- js suse labs
Re: [PATCHv3 2/2] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr
On Mon, Dec 31, 2018 at 4:46 PM Mike Rapoport wrote:
>
> On Fri, Dec 28, 2018 at 11:00:02AM +0800, Pingfan Liu wrote:
> > Customer reported a bug on a high end server with many pcie devices, where
> > kernel bootup with crashkernel=384M, and kaslr is enabled. Even
> > though we still see much memory under 896 MB, the finding still failed
> > intermittently. Because currently we can only find region under 896 MB,
> > if w/0 ',high' specified. Then KASLR breaks 896 MB into several parts
> > randomly, and crashkernel reservation need be aligned to 128 MB, that's
> > why failure is found. It raises confusion to the end user that sometimes
> > crashkernel=X works while sometimes fails.
> > If want to make it succeed, customer can change kernel option to
> > "crashkernel=384M, high". Just this give "crashkernel=xx@yy" a very
> > limited space to behave even though its grammer looks more generic.
> > And we can't answer questions raised from customer that confidently:
> > 1) why it doesn't succeed to reserve 896 MB;
> > 2) what's wrong with memory region under 4G;
> > 3) why I have to add ',high', I only require 384 MB, not 3840 MB.
> >
> > This patch simplifies the method suggested in the mail [1]. It just goes
> > bottom-up to find a candidate region for crashkernel. The bottom-up may be
> > better compatible with the old reservation style, i.e. still want to get
> > memory region from 896 MB firstly, then [896 MB, 4G], finally above 4G.
> >
> > There is one trivial thing about the compatibility with old kexec-tools:
> > if the reserved region is above 896M, then old tool will fail to load
> > bzImage. But without this patch, the old tool also fail since there is no
> > memory below 896M can be reserved for crashkernel.
> >
> > [1]: http://lists.infradead.org/pipermail/kexec/2017-October/019571.html
> > Signed-off-by: Pingfan Liu
> > Cc: Tang Chen
> > Cc: "Rafael J. Wysocki"
> > Cc: Len Brown
> > Cc: Andrew Morton
> > Cc: Mike Rapoport
> > Cc: Michal Hocko
> > Cc: Jonathan Corbet
> > Cc: Yaowei Bai
> > Cc: Pavel Tatashin
> > Cc: Nicholas Piggin
> > Cc: Naoya Horiguchi
> > Cc: Daniel Vacek
> > Cc: Mathieu Malaterre
> > Cc: Stefan Agner
> > Cc: Dave Young
> > Cc: Baoquan He
> > Cc: ying...@kernel.org,
> > Cc: vgo...@redhat.com
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > arch/x86/kernel/setup.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index d494b9b..165f9c3 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -541,15 +541,18 @@ static void __init reserve_crashkernel(void)
> >
> > /* 0 means: find the address automatically */
> > if (crash_base <= 0) {
> > + bool bottom_up = memblock_bottom_up();
> > +
> > + memblock_set_bottom_up(true);
> >
> > /*
> >* Set CRASH_ADDR_LOW_MAX upper bound for crash memory,
> >* as old kexec-tools loads bzImage below that, unless
> >* "crashkernel=size[KMG],high" is specified.
> >*/
> > crash_base = memblock_find_in_range(CRASH_ALIGN,
> > - high ? CRASH_ADDR_HIGH_MAX
> > - : CRASH_ADDR_LOW_MAX,
> > - crash_size, CRASH_ALIGN);
> > + (max_pfn * PAGE_SIZE), crash_size, CRASH_ALIGN);
> > + memblock_set_bottom_up(bottom_up);
>
> Using bottom-up does not guarantee that the allocation won't fall into a
> removable memory, it only makes it highly probable.
>
> I think that the 'max_pfn * PAGE_SIZE' limit should be replaced with the
> end of the non-removable memory node.
>
Since passing MEMBLOCK_NONE, memblock_find_in_range() ->...->
__next_mem_range(), there is a logic to guarantee hotmovable memory
will not be stamped over.
if (movable_node_is_enabled() && memblock_is_hotpluggable(m))
continue;
Thanks,
Pingfan
> > +
> > if (!crash_base) {
> > pr_info("crashkernel reservation failed - No suitable
> > area found.\n");
> > return;
> > --
> > 2.7.4
> >
>
> --
> Sincerely yours,
> Mike.
>
Re: [PATCHv3 1/2] mm/memblock: extend the limit inferior of bottom-up after parsing hotplug attr
On Mon, Dec 31, 2018 at 4:40 PM Mike Rapoport wrote:
>
> On Fri, Dec 28, 2018 at 11:00:01AM +0800, Pingfan Liu wrote:
> > The bottom-up allocation style is introduced to cope with movable_node,
> > where the limit inferior of allocation starts from kernel's end, due to
> > lack of knowledge of memory hotplug info at this early time. But if later,
> > hotplug info has been got, the limit inferior can be extend to 0.
> > 'kexec -c' prefers to reuse this style to alloc mem at lower address,
> > since if the reserved region is beyond 4G, then it requires extra mem
> > (default is 16M) for swiotlb.
>
> I fail to understand why the availability of memory hotplug information
> would allow to extend the lower limit of bottom-up memblock allocations
> below the kernel. The memory in the physical range [0, kernel_start) can be
> allocated as soon as the kernel memory is reserved.
>
Yes, the [0, kernel_start) can be allocated at this time by some func
e.g. memblock_reserve(). But there is trick. For the func like
memblock_find_in_range(), this is hotplug attr checking ,,it will
check the hotmovable attr in __next_mem_range()
{
if (movable_node_is_enabled() && memblock_is_hotpluggable(m))
continue
}. So the movable memory can be safely skipped.
Thanks for your kindly review.
Regards,
Pingfan
> The extents of the memory node hosting the kernel image can be used to
> limit memblok allocations from that particular node, even in top-down mode.
>
> > Signed-off-by: Pingfan Liu
> > Cc: Tang Chen
> > Cc: "Rafael J. Wysocki"
> > Cc: Len Brown
> > Cc: Andrew Morton
> > Cc: Mike Rapoport
> > Cc: Michal Hocko
> > Cc: Jonathan Corbet
> > Cc: Yaowei Bai
> > Cc: Pavel Tatashin
> > Cc: Nicholas Piggin
> > Cc: Naoya Horiguchi
> > Cc: Daniel Vacek
> > Cc: Mathieu Malaterre
> > Cc: Stefan Agner
> > Cc: Dave Young
> > Cc: Baoquan He
> > Cc: ying...@kernel.org,
> > Cc: vgo...@redhat.com
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > drivers/acpi/numa.c | 4
> > include/linux/memblock.h | 1 +
> > mm/memblock.c| 58
> > +---
> > 3 files changed, 40 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
> > index 2746994..3eea4e4 100644
> > --- a/drivers/acpi/numa.c
> > +++ b/drivers/acpi/numa.c
> > @@ -462,6 +462,10 @@ int __init acpi_numa_init(void)
> >
> > cnt = acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
> > acpi_parse_memory_affinity, 0);
> > +
> > +#if defined(CONFIG_X86) || defined(CONFIG_ARM64)
> > + mark_mem_hotplug_parsed();
> > +#endif
> > }
> >
> > /* SLIT: System Locality Information Table */
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > index aee299a..d89ed9e 100644
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -125,6 +125,7 @@ int memblock_reserve(phys_addr_t base, phys_addr_t
> > size);
> > void memblock_trim_memory(phys_addr_t align);
> > bool memblock_overlaps_region(struct memblock_type *type,
> > phys_addr_t base, phys_addr_t size);
> > +void mark_mem_hotplug_parsed(void);
> > int memblock_mark_hotplug(phys_addr_t base, phys_addr_t size);
> > int memblock_clear_hotplug(phys_addr_t base, phys_addr_t size);
> > int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 81ae63c..a3f5e46 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -231,6 +231,12 @@ __memblock_find_range_top_down(phys_addr_t start,
> > phys_addr_t end,
> > return 0;
> > }
> >
> > +static bool mem_hotmovable_parsed __initdata_memblock;
> > +void __init_memblock mark_mem_hotplug_parsed(void)
> > +{
> > + mem_hotmovable_parsed = true;
> > +}
> > +
> > /**
> > * memblock_find_in_range_node - find free area in given range and node
> > * @size: size of free area to find
> > @@ -259,7 +265,7 @@ phys_addr_t __init_memblock
> > memblock_find_in_range_node(phys_addr_t size,
> > phys_addr_t end, int nid,
> > enum memblock_flags flags)
> > {
> > - phys_addr_t kernel_end, ret;
> > + phys_addr_t kernel_end, ret = 0;
> >
> > /* pump up @end */
> > if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
> > @@ -270,34 +276,40 @@ phys_addr_t __init_memblock
> > memblock_find_in_range_node(phys_addr_t size,
> > end = max(start, end);
> > kernel_end = __pa_symbol(_end);
> >
> > - /*
> > - * try bottom-up allocation only when bottom-up mode
> > - * is set and @end is above the kernel image.
> > - */
> > - if (memblock_bottom_up() && end > kernel_end) {
> > - phys_addr_t bottom_up_start;
> > + if (memblock_bottom_up()) {
> > + phys_addr_t bottom_up_start = start;
> >
> > - /* make sure we will allocate above the kernel */
[PATCH] r8169: Add support for new Realtek Ethernet
There are two new Realtek Ethernet devices which are re-branded r8168h.
Add the IDs to to support them.
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/realtek/r8169.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 99bc3de906e2..66a3f3bf7835 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -205,6 +205,8 @@ enum cfg_version {
};
static const struct pci_device_id rtl8169_pci_tbl[] = {
+ { PCI_VDEVICE(REALTEK, 0x2502), RTL_CFG_1 },
+ { PCI_VDEVICE(REALTEK, 0x2600), RTL_CFG_1 },
{ PCI_VDEVICE(REALTEK, 0x8129), RTL_CFG_0 },
{ PCI_VDEVICE(REALTEK, 0x8136), RTL_CFG_2 },
{ PCI_VDEVICE(REALTEK, 0x8161), RTL_CFG_1 },
--
2.17.1
Re: [PATCH v5 11/20] iommu/mediatek: Move vld_pa_rng into plat_data
On Tue, Jan 1, 2019 at 11:58 AM Yong Wu wrote:
>
> Both mt8173 and mt8183 don't have this vld_pa_rng(valid physical address
> range) register while mt2712 have. Move it into the plat_data.
>
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 3 ++-
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 8d8ab21..2913ddb 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -548,7 +548,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
> *data)
> upper_32_bits(data->protect_base);
> writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
>
> - if (data->enable_4GB && data->plat_data->m4u_plat != M4U_MT8173) {
> + if (data->enable_4GB && data->plat_data->vld_pa_rng) {
> /*
> * If 4GB mode is enabled, the validate PA range is from
> * 0x1__ to 0x1__. here record bit[32:30].
> @@ -741,6 +741,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
> *dev)
> .m4u_plat = M4U_MT2712,
> .has_4gb_mode = true,
> .has_bclk = true,
> + .vld_pa_rng = true,
> .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index b46aeaa..a8c5d1e 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -48,6 +48,7 @@ struct mtk_iommu_plat_data {
> /* HW will use the EMI clock if there isn't the "bclk". */
> boolhas_bclk;
> boolreset_axi;
> + boolvld_pa_rng;
Since this is not a register name, maybe we can use something more
readable, like valid_pa_range?
(or at the very least describe it in a comment in the struct?)
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
> --
> 1.9.1
>
Re: [PATCH v5 10/20] iommu/mediatek: Move reset_axi into plat_data
On Tue, Jan 1, 2019 at 11:58 AM Yong Wu wrote:
>
> In mt8173 and mt8183, 0x48 is REG_MMU_STANDARD_AXI_MODE while
> it is extended to REG_MMU_CTRL which contains _STANDARD_AXI_MODE in
> the other SoCs. I move this property to plat_data since both mt8173
> and mt8183 use this property.
>
> It is a preparing patch for mt8183.
>
> Signed-off-by: Yong Wu
Reviewed-by: Nicolas Boichat
> ---
> drivers/iommu/mtk_iommu.c | 4 ++--
> drivers/iommu/mtk_iommu.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 35a1263..8d8ab21 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -558,8 +558,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
> *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> - /* It's MISC control register whose default value is ok except
> mt8173.*/
> - if (data->plat_data->m4u_plat == M4U_MT8173)
> + if (data->plat_data->reset_axi)
> writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
>
> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> @@ -749,6 +748,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
> *dev)
> .m4u_plat = M4U_MT8173,
> .has_4gb_mode = true,
> .has_bclk = true,
> + .reset_axi= true,
> .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> };
>
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index eec19a6..b46aeaa 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -47,7 +47,7 @@ struct mtk_iommu_plat_data {
>
> /* HW will use the EMI clock if there isn't the "bclk". */
> boolhas_bclk;
> -
> + boolreset_axi;
> unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
> --
> 1.9.1
>
Re: [PATCH] driver: uio: fix possible memory leak in uio_open
On 2019/1/3 0:26, liujian wrote:
Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered")
Signed-off-by: liujian
---
drivers/uio/uio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 5c10fc7..bde7d7a 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -496,7 +496,7 @@ static int uio_open(struct inode *inode, struct file *filep)
if (!idev->info) {
mutex_unlock(>info_lock);
ret = -EINVAL;
- goto err_alloc_listener;
+ goto err_infoopen;
}
if (idev->info && idev->info->open)
@@ -508,6 +508,7 @@ static int uio_open(struct inode *inode, struct file *filep)
return 0;
err_infoopen:
Maybe we should rename the "err_infoopen" to something like
"err_idev_info"...
Thanks.
BRs
+ filep->private_data = NULL;
kfree(listener);
err_alloc_listener:
Re: [PATCH] net: core: Fix to store new mtu setting in netdevice.
On 02.01.2019 00:36, Andrew Lunn wrote: >>> Is there a .ndo_change_mtu callback, which does not assign a new mtu itself? >>> >> So far all drivers have to do it themselves. But IMO this is more a >> workaround >> for the core not doing it. It's something the core should do. >> Now we can remove this from drivers. > > Hi Heiner > > I think somebody first needs to review all the ndo_change_mtu > implementations and check that none do something funny like round to > multiple of 2 or 4 to satisfy DMA restrictions, etc. If there is such > a thing, we cannot easily move this into the core. > > Andrew > . > Good point. I briefly grepped over all drivers and it's not that many drivers not using the standard assignment dev->mtu = new_mtu. Some are doing things like dev->mtu = max(new_mtu, xx) what could be achieved easier with an appropriate max_mtu setting. But that's a different story. And I was under the impression that such things had been checked because the patch had a "Reviewed-by" from Florian (although he wasn't on cc). Heiner
[PATCH] driver: uio: fix possible memory leak in uio_open
Fixes: 57c5f4df0a5a ("uio: fix crash after the device is unregistered")
Signed-off-by: liujian
---
drivers/uio/uio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 5c10fc7..bde7d7a 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -496,7 +496,7 @@ static int uio_open(struct inode *inode, struct file *filep)
if (!idev->info) {
mutex_unlock(>info_lock);
ret = -EINVAL;
- goto err_alloc_listener;
+ goto err_infoopen;
}
if (idev->info && idev->info->open)
@@ -508,6 +508,7 @@ static int uio_open(struct inode *inode, struct file *filep)
return 0;
err_infoopen:
+ filep->private_data = NULL;
kfree(listener);
err_alloc_listener:
--
2.7.4
Re: [PATCH v5 09/20] iommu/mediatek: Refine protect memory definition
On Tue, Jan 1, 2019 at 11:58 AM Yong Wu wrote: > > The protect memory setting is a little different in the different SoCs. > In the register REG_MMU_CTRL_REG(0x110), the TF_PROT(translation fault > protect) shift bit is normally 4 while it shift 5 bits only in the > mt8173. This patch delete the complex MACRO and use a common if-else > instead. > > Also, use "F_MMU_TF_PROT_TO_PROGRAM_ADDR" instead of the hard code(2) > which means the M4U will output the dirty data to the programmed > address that we allocated dynamically when translation fault occurs. > > Signed-off-by: Yong Wu > --- > @Nicalos, I don't put it in the plat_data since only the previous mt8173 > shift 5. As I know, the latest SoC always use the new setting like mt2712 > and mt8183. Thus, I think it is unnecessary to put it in plat_data and > let all the latest SoC set it. Hence, I still keep "== mt8173" for this > like the reg REG_MMU_CTRL_REG. Should be ok this way. But maybe one way to avoid hard-coding 4/5 below is to have 2 macros: #define F_MMU_TF_PROT_TO_PROGRAM_ADDR (2 << 4) #define F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173 (2 << 5) And still use the if below? > --- > drivers/iommu/mtk_iommu.c | 12 +--- > 1 file changed, 5 insertions(+), 7 deletions(-) > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > index eca1536..35a1263 100644 > --- a/drivers/iommu/mtk_iommu.c > +++ b/drivers/iommu/mtk_iommu.c > @@ -53,11 +53,7 @@ > > #define REG_MMU_CTRL_REG 0x110 > #define F_MMU_PREFETCH_RT_REPLACE_MOD BIT(4) > -#define F_MMU_TF_PROTECT_SEL_SHIFT(data) \ > - ((data)->plat_data->m4u_plat == M4U_MT2712 ? 4 : 5) > -/* It's named by F_MMU_TF_PROT_SEL in mt2712. */ > -#define F_MMU_TF_PROTECT_SEL(prot, data) \ > - (((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data)) > +#define F_MMU_TF_PROT_TO_PROGRAM_ADDR 2 > > #define REG_MMU_IVRP_PADDR 0x114 > > @@ -521,9 +517,11 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data > *data) > return ret; > } > > - regval = F_MMU_TF_PROTECT_SEL(2, data); > if (data->plat_data->m4u_plat == M4U_MT8173) > - regval |= F_MMU_PREFETCH_RT_REPLACE_MOD; > + regval = F_MMU_PREFETCH_RT_REPLACE_MOD | > + (F_MMU_TF_PROT_TO_PROGRAM_ADDR << 5); > + else > + regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR << 4; > writel_relaxed(regval, data->base + REG_MMU_CTRL_REG); > > regval = F_L2_MULIT_HIT_EN | > -- > 1.9.1 >
[PATCH v3 0/2] Add Stratix 10 PCIe Root Port support
Add PCIe Root Port support for Stratix 10 device and also update device tree binding documentation. v2 -> v3: - - Rename Stratix10 to Stratix 10. - Change bool s10_flag to enum version. v1 -> v2: - - Add define S10_TLP_FMTTYPE_* macros. - Remove initialize structure members to NULL/zero. - Rename *_funcs to *_data. - Update comment and fix coding style warning from checkpatch.pl. - Rename StratixXX to stratix10. History: [v1]: https://lkml.org/lkml/2018/12/26/68 [v2]: https://lkml.org/lkml/2018/12/31/46 Ley Foon Tan (2): PCI: altera: Add Stratix 10 PCIe support dt-bindings: PCI: altera: Add altr,pcie-root-port-2.0 .../devicetree/bindings/pci/altera-pcie.txt|4 +- drivers/pci/controller/Kconfig |2 +- drivers/pci/controller/pcie-altera.c | 246 ++-- 3 files changed, 226 insertions(+), 26 deletions(-)
[PATCH v3 1/2] PCI: altera: Add Stratix 10 PCIe support
Add PCIe Root Port support for Stratix 10 device.
Main differences:
- HIP interface to access Root Port configuration register.
- TLP programming flow:
- One REG0 register
- Don't need to check alignment
Signed-off-by: Ley Foon Tan
---
drivers/pci/controller/Kconfig |2 +-
drivers/pci/controller/pcie-altera.c | 246 ++
2 files changed, 223 insertions(+), 25 deletions(-)
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 6671946..6012f30 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -175,7 +175,7 @@ config PCIE_IPROC_MSI
config PCIE_ALTERA
bool "Altera PCIe controller"
- depends on ARM || NIOS2 || COMPILE_TEST
+ depends on ARM || NIOS2 || ARM64 || COMPILE_TEST
help
Say Y here if you want to enable PCIe controller support on Altera
FPGA.
diff --git a/drivers/pci/controller/pcie-altera.c
b/drivers/pci/controller/pcie-altera.c
index 7d05e51..4c3b61b 100644
--- a/drivers/pci/controller/pcie-altera.c
+++ b/drivers/pci/controller/pcie-altera.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -37,7 +38,12 @@
#define RP_LTSSM_MASK 0x1f
#define LTSSM_L0 0xf
-#define PCIE_CAP_OFFSET0x80
+#define S10_RP_TX_CNTRL0x2004
+#define S10_RP_RXCPL_REG 0x2008
+#define S10_RP_RXCPL_STATUS0x200C
+#define S10_RP_CFG_ADDR(pcie, reg) \
+ (((pcie)->hip_base) + (reg) + (1 << 20))
+
/* TLP configuration type 0 and 1 */
#define TLP_FMTTYPE_CFGRD0 0x04/* Configuration Read Type 0 */
#define TLP_FMTTYPE_CFGWR0 0x44/* Configuration Write Type 0 */
@@ -49,18 +55,19 @@
#define RP_DEVFN 0
#define TLP_REQ_ID(bus, devfn) (((bus) << 8) | (devfn))
#define TLP_CFGRD_DW0(pcie, bus) \
-bus == pcie->root_bus_nr) ? TLP_FMTTYPE_CFGRD0 \
- : TLP_FMTTYPE_CFGRD1) << 24) | \
- TLP_PAYLOAD_SIZE)
+ bus == pcie->root_bus_nr) ? pcie->pcie_data->cfgrd0 \
+ : pcie->pcie_data->cfgrd1) << 24) | \
+ TLP_PAYLOAD_SIZE)
#define TLP_CFGWR_DW0(pcie, bus) \
-bus == pcie->root_bus_nr) ? TLP_FMTTYPE_CFGWR0 \
- : TLP_FMTTYPE_CFGWR1) << 24) | \
- TLP_PAYLOAD_SIZE)
+ bus == pcie->root_bus_nr) ? pcie->pcie_data->cfgwr0 \
+ : pcie->pcie_data->cfgwr1) << 24) | \
+ TLP_PAYLOAD_SIZE)
#define TLP_CFG_DW1(pcie, tag, be) \
-(((TLP_REQ_ID(pcie->root_bus_nr, RP_DEVFN)) << 16) | (tag << 8) | (be))
+ (((TLP_REQ_ID(pcie->root_bus_nr, RP_DEVFN)) << 16) | (tag << 8) | (be))
#define TLP_CFG_DW2(bus, devfn, offset)\
(((bus) << 24) | ((devfn) << 16) | (offset))
#define TLP_COMP_STATUS(s) (((s) >> 13) & 7)
+#define TLP_BYTE_COUNT(s) (((s) >> 0) & 0xfff)
#define TLP_HDR_SIZE 3
#define TLP_LOOP 500
@@ -69,14 +76,43 @@
#define DWORD_MASK 3
+#define S10_TLP_FMTTYPE_CFGRD0 0x05
+#define S10_TLP_FMTTYPE_CFGRD1 0x04
+#define S10_TLP_FMTTYPE_CFGWR0 0x45
+#define S10_TLP_FMTTYPE_CFGWR1 0x44
+
+enum altera_pcie_version {
+ ALTERA_PCIE_V1 = 0,
+ ALTERA_PCIE_V2,
+};
+
struct altera_pcie {
struct platform_device *pdev;
- void __iomem*cra_base; /* DT Cra */
+ void __iomem*cra_base;
+ void __iomem*hip_base;
int irq;
u8 root_bus_nr;
struct irq_domain *irq_domain;
struct resource bus_range;
struct list_headresources;
+ const struct altera_pcie_data *pcie_data;
+};
+
+struct altera_pcie_data {
+ int (*tlp_read_pkt)(struct altera_pcie *pcie, u32 *value);
+ void (*tlp_write_pkt)(struct altera_pcie *pcie, u32 *headers,
+ u32 data, bool align);
+ bool (*get_link_status)(struct altera_pcie *pcie);
+ int (*rp_read_cfg)(struct altera_pcie *pcie, int where,
+ int size, u32 *value);
+ int (*rp_write_cfg)(struct altera_pcie *pcie, u8 bus, int where,
+ int size, u32 value);
+ enum altera_pcie_version version;
+ u32 cap_offset; /* PCIe capability structure register offset */
+ u32 cfgrd0;
+ u32 cfgrd1;
+ u32 cfgwr0;
+ u32 cfgwr1;
};
struct tlp_rp_regpair_t {
@@ -101,6 +137,15 @@ static bool altera_pcie_link_up(struct
[PATCH v3 2/2] dt-bindings: PCI: altera: Add altr,pcie-root-port-2.0
Add support for altr,pcie-root-port-2.0. Signed-off-by: Ley Foon Tan --- .../devicetree/bindings/pci/altera-pcie.txt|4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/pci/altera-pcie.txt b/Documentation/devicetree/bindings/pci/altera-pcie.txt index 6c396f1..816b244 100644 --- a/Documentation/devicetree/bindings/pci/altera-pcie.txt +++ b/Documentation/devicetree/bindings/pci/altera-pcie.txt @@ -1,11 +1,13 @@ * Altera PCIe controller Required properties: -- compatible : should contain "altr,pcie-root-port-1.0" +- compatible : should contain "altr,pcie-root-port-1.0" or "altr,pcie-root-port-2.0" - reg: a list of physical base address and length for TXS and CRA. + For "altr,pcie-root-port-2.0", additional HIP base address and length. - reg-names: must include the following entries: "Txs": TX slave port region "Cra": Control register access region + "Hip": Hard IP region (if "altr,pcie-root-port-2.0") - interrupts: specifies the interrupt source of the parent interrupt controller. The format of the interrupt specifier depends on the parent interrupt controller. -- 1.7.1
[PATCH v10 03/40] component: alloc component_match without any comp to match
If all the components associated to a component master is not added
to the component framework due to the HW capability or Kconfig
selection, component_match will be NULL at
component_master_add_with_match().
To avoid this, component_match_alloc() is added to the framework,
to allcoate the struct component_match with zero associated components.
Hence component master can be added with a component_match with zero
associated components.
This helps the component master bind call to get triggered,
even if no component is registered for that particular master.
This is meant for big PCI device drivers where small/optional
features are external components, and based on usecases different
combination of components are build as entire driver.
In such PCI device driver Load, if we use the component master for
waiting for few components(features) availability, only if they are
supported by the underlying HW, then we need to allocate memory for
component_match using the API introduced in this change before
the call to component_master_add_with_match.
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Kate Stewart
Cc: Thomas Gleixner
Cc: Philippe Ombredanne
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Daniel Vetter
Acked-by: Greg Kroah-Hartman
---
drivers/base/component.c | 30 ++
include/linux/component.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index e8d676fad0c9..0ab36b2255ea 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -312,6 +312,36 @@ static int component_match_realloc(struct device *dev,
}
/*
+ * Allocate the match without any component_match_array elements.
+ *
+ * This function is useful when the component master might end up
+ * registering itself without any matching components.
+ */
+void component_match_alloc(struct device *master,
+ struct component_match **matchptr)
+{
+ struct component_match *match = *matchptr;
+
+ if (IS_ERR(match))
+ return;
+
+ if (match)
+ return;
+
+ match = devres_alloc(devm_component_match_release,
+sizeof(*match), GFP_KERNEL);
+ if (!match) {
+ *matchptr = ERR_PTR(-ENOMEM);
+ return;
+ }
+
+ devres_add(master, match);
+
+ *matchptr = match;
+}
+EXPORT_SYMBOL(component_match_alloc);
+
+/*
* Add a component to be matched, with a release function.
*
* The match array is first created or extended if necessary.
diff --git a/include/linux/component.h b/include/linux/component.h
index e71fbbbc74e2..3f6b420a58f8 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -37,6 +37,8 @@ void component_match_add_release(struct device *master,
struct component_match **matchptr,
void (*release)(struct device *, void *),
int (*compare)(struct device *, void *), void *compare_data);
+void component_match_alloc(struct device *master,
+ struct component_match **matchptr);
static inline void component_match_add(struct device *master,
struct component_match **matchptr,
--
2.7.4
Re: [PATCH v5 08/20] iommu/mediatek: Add larb-id remapped support
On Tue, Jan 1, 2019 at 11:58 AM Yong Wu wrote:
>
> The larb-id may be remapped in the smi-common, this means the
> larb-id reported in the mtk_iommu_isr isn't the real larb-id,
>
> Take mt8183 as a example:
>M4U
> |
> -
> | SMI common |
> -0-7-5-6-1-2--3-4- <- Id remapped
> | | | | | | | |
> larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
> disp vdec img cam venc imgcam
> As above, larb0 connects with the id 0 in smi-common.
> larb1 connects with the id 7 in smi-common.
> ...
> If the larb-id reported in the isr is 7, actually it's larb1(vdec).
> In order to output the right larb-id in the isr, we add a larb-id
> remapping relationship in this patch.
>
> If there is no this larb-id remapping in some SoCs, use the linear
> mapping array instead.
>
> This also is a preparing patch for mt8183.
>
> Signed-off-by: Yong Wu
I think it's a little cleaner this way, thanks.
Reviewed-by: Nicolas Boichat
> ---
> drivers/iommu/mtk_iommu.c | 4
> drivers/iommu/mtk_iommu.h | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 847082c..eca1536 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -220,6 +220,8 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
> fault_port = F_MMU0_INT_ID_PORT_ID(regval);
>
> + fault_larb = data->plat_data->larbid_remap[fault_larb];
> +
> if (report_iommu_fault(>domain, data->dev, fault_iova,
>write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ))
> {
> dev_err_ratelimited(
> @@ -742,12 +744,14 @@ static int __maybe_unused mtk_iommu_resume(struct
> device *dev)
> .m4u_plat = M4U_MT2712,
> .has_4gb_mode = true,
> .has_bclk = true,
> + .larbid_remap = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
> };
>
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> .has_4gb_mode = true,
> .has_bclk = true,
> + .larbid_remap = {0, 1, 2, 3, 4, 5}, /* Linear mapping. */
> };
>
> static const struct of_device_id mtk_iommu_of_ids[] = {
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index b8749ac..eec19a6 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -47,6 +47,8 @@ struct mtk_iommu_plat_data {
>
> /* HW will use the EMI clock if there isn't the "bclk". */
> boolhas_bclk;
> +
> + unsigned char larbid_remap[MTK_LARB_NR_MAX];
> };
>
> struct mtk_iommu_domain;
> --
> 1.9.1
>
Re: [PATCH 07/20] dmaengine: at_hdmac: drop useless LIST_HEAD
On 23-12-18, 09:57, Julia Lawall wrote: > Drop LIST_HEAD where the variable it declares is never used. > > tmp_list has been declared since the introduction of the driver > and has never been used. The two declarations of list were > introduced with the containing functions but were also not used. > > The semantic patch that fixes this problem is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ > identifier x; > @@ > - LIST_HEAD(x); > ... when != x > // Applied with Ludovic's ack, thanks -- ~Vinod
Re: [PATCH 17/20] dmaengine: pl330: drop useless LIST_HEAD
On 23-12-18, 09:57, Julia Lawall wrote:
> Drop LIST_HEAD where the variable it declares is never used.
>
> The variable has not been used since the function was introduced
> in 740aa95703c5 ("dmaengine: pl330: Split device_control").
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> identifier x;
> @@
> - LIST_HEAD(x);
> ... when != x
> //
Applied, thanks
--
~Vinod
Re: [PATCH 18/20] dmaengine: sa11x0: drop useless LIST_HEAD
On 23-12-18, 09:57, Julia Lawall wrote: > Drop LIST_HEAD where the variable it declares has never been > used. > > The semantic patch that fixes this problem is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ > identifier x; > @@ > - LIST_HEAD(x); > ... when != x > // Applied, thanks -- ~Vinod
Re: [PATCH 12/20] dmaengine: dw: drop useless LIST_HEAD
On 23-12-18, 09:57, Julia Lawall wrote:
> Drop LIST_HEAD where the variable it declares is never used.
>
> Commit ab703f818ac3 ("dmaengine: dw: lazy allocation of dma
> descriptors") removed the uses, but not the declaration.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> identifier x;
> @@
> - LIST_HEAD(x);
> ... when != x
> //
Applied, thanks
--
~Vinod
Re: [PATCH 14/20] dmaengine: st_fdma: drop useless LIST_HEAD
On 23-12-18, 09:57, Julia Lawall wrote:
> Drop LIST_HEAD where the variable it declares is never used.
>
> The declarations were introduced with the file, but the declared
> variables were not used.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
> identifier x;
> @@
> - LIST_HEAD(x);
> ... when != x
> //
>
> Fixes: 6b4cd727eaf1 ("dmaengine: st_fdma: Add STMicroelectronics FDMA engine
> driver support")
> Signed-off-by: Julia Lawall
Applied, thanks
--
~Vinod
[PATCH] PCI: Mediatek: Use resource_size function on resource object
From: Honghui Zhang drivers/pci/pcie-mediatek.c:720:13-16: WARNING: Suspicious code. resource_size is maybe missing with mem Generated by: scripts/coccinelle/api/resource_size.cocci Signed-off-by: Honghui Zhang --- drivers/pci/controller/pcie-mediatek.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c index e307166..0168376 100644 --- a/drivers/pci/controller/pcie-mediatek.c +++ b/drivers/pci/controller/pcie-mediatek.c @@ -654,7 +654,6 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port) struct resource *mem = >mem; const struct mtk_pcie_soc *soc = port->pcie->soc; u32 val; - size_t size; int err; /* MT7622 platforms need to enable LTSSM and ASPM from PCIe subsys */ @@ -706,8 +705,7 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port) mtk_pcie_enable_msi(port); /* Set AHB to PCIe translation windows */ - size = mem->end - mem->start; - val = lower_32_bits(mem->start) | AHB2PCIE_SIZE(fls(size)); + val = lower_32_bits(mem->start) | AHB2PCIE_SIZE(fls(resource_size(mem))); writel(val, port->base + PCIE_AHB_TRANS_BASE0_L); val = upper_32_bits(mem->start); -- 2.6.4
Re: [PATCH v6 0/3] iommu/io-pgtable-arm-v7s: Use DMA32 zone for page tables
Hi all,
On Mon, Dec 10, 2018 at 9:15 AM Nicolas Boichat wrote:
>
> This is a follow-up to the discussion in [1], [2].
>
> IOMMUs using ARMv7 short-descriptor format require page tables
> (level 1 and 2) to be allocated within the first 4GB of RAM, even
> on 64-bit systems.
>
> For L1 tables that are bigger than a page, we can just use __get_free_pages
> with GFP_DMA32 (on arm64 systems only, arm would still use GFP_DMA).
>
> For L2 tables that only take 1KB, it would be a waste to allocate a full
> page, so we considered 3 approaches:
> 1. This series, adding support for GFP_DMA32 slab caches.
> 2. genalloc, which requires pre-allocating the maximum number of L2 page
> tables (4096, so 4MB of memory).
> 3. page_frag, which is not very memory-efficient as it is unable to reuse
> freed fragments until the whole page is freed. [3]
>
> This series is the most memory-efficient approach.
Does anyone have any further comment on this series? If not, which
maintainer is going to pick this up? I assume Andrew Morton?
Thanks,
> stable@ note:
> We confirmed that this is a regression, and IOMMU errors happen on 4.19
> and linux-next/master on MT8173 (elm, Acer Chromebook R13). The issue
> most likely starts from commit ad67f5a6545f ("arm64: replace ZONE_DMA
> with ZONE_DMA32"), i.e. 4.15, and presumably breaks a number of Mediatek
> platforms (and maybe others?).
>
> [1]
> https://lists.linuxfoundation.org/pipermail/iommu/2018-November/030876.html
> [2]
> https://lists.linuxfoundation.org/pipermail/iommu/2018-December/031696.html
> [3] https://patchwork.codeaurora.org/patch/671639/
>
> Changes since v1:
> - Add support for SLAB_CACHE_DMA32 in slab and slub (patches 1/2)
> - iommu/io-pgtable-arm-v7s (patch 3):
>- Changed approach to use SLAB_CACHE_DMA32 added by the previous
> commit.
>- Use DMA or DMA32 depending on the architecture (DMA for arm,
> DMA32 for arm64).
>
> Changes since v2:
> - Reworded and expanded commit messages
> - Added cache_dma32 documentation in PATCH 2/3.
>
> v3 used the page_frag approach, see [3].
>
> Changes since v4:
> - Dropped change that removed GFP_DMA32 from GFP_SLAB_BUG_MASK:
>instead we can just call kmem_cache_*alloc without GFP_DMA32
>parameter. This also means that we can drop PATCH v4 1/3, as we
>do not make any changes in GFP flag verification.
> - Dropped hunks that added cache_dma32 sysfs file, and moved
>the hunks to PATCH v5 3/3, so that maintainer can decide whether
>to pick the change independently.
>
> Changes since v5:
> - Rename ARM_V7S_TABLE_SLAB_CACHE to ARM_V7S_TABLE_SLAB_FLAGS.
> - Add stable@ to cc.
>
> Nicolas Boichat (3):
> mm: Add support for kmem caches in DMA32 zone
> iommu/io-pgtable-arm-v7s: Request DMA32 memory, and improve debugging
> mm: Add /sys/kernel/slab/cache/cache_dma32
>
> Documentation/ABI/testing/sysfs-kernel-slab | 9 +
> drivers/iommu/io-pgtable-arm-v7s.c | 19 +++
> include/linux/slab.h| 2 ++
> mm/slab.c | 2 ++
> mm/slab.h | 3 ++-
> mm/slab_common.c| 2 +-
> mm/slub.c | 16
> tools/vm/slabinfo.c | 7 ++-
> 8 files changed, 53 insertions(+), 7 deletions(-)
>
> --
> 2.20.0.rc2.403.gdbc3b29805-goog
>
linux-next: Tree for Jan 2
Hi all, Please do not add any material destined for the next merge window to your linux-next included trees until after -rc1 has been released. Changes since 20181224: The vfs tree gained conflicts against Linus' and the ext3 trees. It also gained a build failure for which I added a work around patch. Non-merge commits (relative to Linus' tree): 1256 1353 files changed, 46422 insertions(+), 20486 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 293 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (28e8c4bc8eb4 Merge tag 'rtc-4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux) Merging fixes/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging kbuild-current/fixes (e1ef035d272e Merge tag 'armsoc-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging arc-current/for-curr (5fac3149be6f ARC: adjust memblock_reserve of kernel memory) Merging arm-current/fixes (c2a3831df6dc ARM: 8816/1: dma-mapping: fix potential uninitialized return) Merging arm64-fixes/for-next/fixes (3238c359acee arm64: dma-mapping: Fix FORCE_CONTIGUOUS buffer clearing) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (a225f1567405 powerpc/ptrace: replace ptrace_report_syscall() with a tracehook call) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (e888402789b9 net: hns3: call hns3_nic_net_open() while doing HNAE3_UP_CLIENT) Merging bpf/master (8b6b25cf93b7 selftests/bpf: fix error printing in test_devmap()) Merging ipsec/master (3061169a47ee Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging netfilter/master (a007232066f6 netfilter: nf_conncount: fix argument order to find_next_bit) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (53884577fbce ath10k: skip sending quiet mode cmd for WCN3990) Merging mac80211/master (1d51b4b1d3f2 Merge tag 'm68k-for-v4.20-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k) Merging rdma-fixes/for-rc (37fbd834b4e4 IB/core: Fix oops in netdev_next_upper_dev_rcu()) Merging sound-current/for-linus (63d2a9ec310d ALSA: hda/tegra: clear pending irq handlers) Merging sound-asoc-fixes/for-linus (6cb3c5b355ab Merge branch 'asoc-4.20' into asoc-linus) Merging regmap-fixes/for-linus (8fe28cb58bcb Linux 4.20) Merging regulator-fixes/for-linus (c8c6b9fda37f Merge branch 'regulator-4.20' into regulator-linus) Merging spi-fixes/for-linus (21929ad56551 Merge branch 'spi-4.20' into spi-linus) Merging pci-current/for-linus (1063a5148ac9 PCI/AER: Queue one GHES event, not several uninitialized ones) Merging driver-core.current/driver-core-linus (195303136f19 Merge tag 'kconfig-v4.21-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging tty.current/tty-linus (195303136f19 Merge tag 'kconfig-v4.21-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging
[PATCH] driver: uio: fix possible memory leak and use-after-free in __uio_register_device
Before device_register, if something goes wrong, we need to manually
free idev.
In the error handling path, after device_unregister, idev maybe have been
released, we should not use it anymore.
Signed-off-by: liujian
---
drivers/uio/uio.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 1313422..5c10fc7 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -413,13 +413,18 @@ static int uio_get_minor(struct uio_device *idev)
return retval;
}
-static void uio_free_minor(struct uio_device *idev)
+static void __uio_free_minor(int id)
{
mutex_lock(_lock);
- idr_remove(_idr, idev->minor);
+ idr_remove(_idr, id);
mutex_unlock(_lock);
}
+static void uio_free_minor(struct uio_device *idev)
+{
+ __uio_free_minor(idev->minor);
+}
+
/**
* uio_event_notify - trigger an interrupt event
* @info: UIO device capabilities
@@ -919,6 +924,7 @@ int __uio_register_device(struct module *owner,
{
struct uio_device *idev;
int ret = 0;
+ int uio_minor;
if (!uio_class_registered)
return -EPROBE_DEFER;
@@ -940,8 +946,12 @@ int __uio_register_device(struct module *owner,
atomic_set(>event, 0);
ret = uio_get_minor(idev);
- if (ret)
+ if (ret) {
+ kfree(idev);
return ret;
+ }
+
+ uio_minor = idev->minor;
idev->dev.devt = MKDEV(uio_major, idev->minor);
idev->dev.class = _class;
@@ -950,8 +960,11 @@ int __uio_register_device(struct module *owner,
dev_set_drvdata(>dev, idev);
ret = dev_set_name(>dev, "uio%d", idev->minor);
- if (ret)
- goto err_device_create;
+ if (ret) {
+ __uio_free_minor(uio_minor);
+ kfree(idev);
+ return ret;
+ }
ret = device_register(>dev);
if (ret)
@@ -987,7 +1000,7 @@ int __uio_register_device(struct module *owner,
err_uio_dev_add_attributes:
device_unregister(>dev);
err_device_create:
- uio_free_minor(idev);
+ __uio_free_minor(uio_minor);
return ret;
}
EXPORT_SYMBOL_GPL(__uio_register_device);
--
2.7.4
[GIT PULL] Mailbox changes for v4.21
Hi Linus, The following changes since commit f5d582777bcb1c7ff19a5a2343f66ea01de401c6: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid (2018-12-10 11:04:41 -0800) are available in the Git repository at: git://git.linaro.org/landing-teams/working/fujitsu/integration.git tags/mailbox-v4.21 for you to fetch changes up to d69e11648e486ee0f21cb246f687b083f0d4e124: mailbox: tegra-hsp: Use device-managed registration API (2018-12-21 22:31:26 -0600) - Introduce device-managed registration devm_mbox_controller_un/register and convert drivers to use it - Introduce flush api to support clients that must busy-wait in atomic context - Support multiple controllers per device - Hi3660: a bugfix and constify ops structure - TI-MsgMgr: off by one bugfix. - BCM: switch to spdx license - Tegra-HSP: support for shared mailboxes and suspend/resume. Bartosz Golaszewski (1): mailbox: tegra-hsp: use devm_kstrdup_const() Dan Carpenter (1): mailbox: ti-msgmgr: Off by one in ti_msgmgr_of_xlate() Julia Lawall (1): mailbox: hi3660: constify mbox_chan_ops structure Kevin Wangtao (1): mailbox: Hi3660: Fixup mailbox state machine malfunction issue Mikko Perttunen (2): mailbox: Allow multiple controllers per device dt-bindings: tegra186-hsp: Add shared mailboxes Stefan Wahren (1): mailbox: bcm2835: Switch to SPDX identifier Thierry Reding (23): mailbox: Add device-managed registration functions mailbox: arm-mhu: Use device-managed registration API mailbox: bcm2835: Use device-managed registration API mailbox: bcm-flexrm: Use device-managed registration API mailbox: bcm-pdc: Use device-managed registration API mailbox: hi3660: Use device-managed registration API mailbox: hi6220: Use device-managed registration API mailbox: imx: Use device-managed registration API mailbox: altera: Use device-managed registration API mailbox: sti: Use device-managed registration API mailbox: xgene-slimpro: Use device-managed registration API mailbox: mtk-cmdq: Use device-managed registration API mailbox: mtk-cmdq: Remove needless devm_kfree() calls mailbox: omap: Use device-managed registration API mailbox: platform-mhu: Use device-managed registration API mailbox: qcom-apcs: Use device-managed registration API mailbox: rockchip: Use device-managed registration API mailbox: stm32-ipcc: Use device-managed registration API mailbox: ti-msgmgr: Use device-managed registration API mailbox: Support blocking transfers in atomic context mailbox: tegra-hsp: Add support for shared mailboxes mailbox: tegra-hsp: Add suspend/resume support mailbox: tegra-hsp: Use device-managed registration API .../bindings/mailbox/nvidia,tegra186-hsp.txt | 30 +- drivers/mailbox/arm_mhu.c | 12 +- drivers/mailbox/bcm-flexrm-mailbox.c | 4 +- drivers/mailbox/bcm-pdc-mailbox.c | 4 +- drivers/mailbox/bcm2835-mailbox.c | 18 +- drivers/mailbox/hi3660-mailbox.c | 35 +- drivers/mailbox/hi6220-mailbox.c | 11 +- drivers/mailbox/imx-mailbox.c | 3 +- drivers/mailbox/mailbox-altera.c | 15 +- drivers/mailbox/mailbox-sti.c | 13 +- drivers/mailbox/mailbox-xgene-slimpro.c| 11 +- drivers/mailbox/mailbox.c | 101 +++- drivers/mailbox/mtk-cmdq-mailbox.c | 11 +- drivers/mailbox/omap-mailbox.c | 4 +- drivers/mailbox/platform_mhu.c | 12 +- drivers/mailbox/qcom-apcs-ipc-mailbox.c| 3 +- drivers/mailbox/rockchip-mailbox.c | 15 +- drivers/mailbox/stm32-ipcc.c | 4 +- drivers/mailbox/tegra-hsp.c| 517 + drivers/mailbox/ti-msgmgr.c| 15 +- include/dt-bindings/mailbox/tegra186-hsp.h | 11 + include/linux/mailbox_client.h | 1 + include/linux/mailbox_controller.h | 9 + 23 files changed, 612 insertions(+), 247 deletions(-)
Re: [RFC PATCH 0/2] allow optee to be exposed on ACPI systems
On Fri, 28 Dec 2018 at 00:31, Ard Biesheuvel wrote: > > Similar to how OP-TEE is exposed as a pseudo device under /firmware/optee > on DT systems, permit OP-TEE presence to be exposed via a device object > in the ACPI namespace. This makes it possible to model the OP-TEE interface > as a platform device gets instantiated automatically both on DT and ACPI > systems, and implement the driver as a platform driver that is able to > use the generic device properties API to access the 'method' attribute > as well as potential future extensions to the binding that introduce > new attributes. > > What remains to be discussed is how to expose OP-TEE pseudo devices, > e.g., Sumit's RNG implementation on SynQuacer which we would like to > bind a Linux driver to. > > Cc: Jens Wiklander > Cc: Sumit Garg > Cc: Graeme Gregory > Cc: Jerome Forissier > > Ard Biesheuvel (2): > optee: model OP-TEE as a platform device/driver > optee: add ACPI support > > drivers/tee/optee/core.c | 94 +--- > 1 file changed, 41 insertions(+), 53 deletions(-) > Looks good to me. Acked-by: Sumit Garg > -- > 2.19.2 >
Re: linux-next: manual merge of the f2fs tree with the fscrypt tree
On Wednesday, January 2, 2019 5:56:10 AM IST Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 11 Dec 2018 10:13:22 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the f2fs tree got a conflict in:
> >
> > fs/f2fs/dir.c
> >
> > between commit:
> >
> > 848a010287e6 ("f2fs: use IS_ENCRYPTED() to check encryption status")
> >
> > from the fscrypt tree and commit:
> >
> > 4e240d1bab1e ("f2fs: check memory boundary by insane namelen")
> >
> > from the f2fs tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
>
> This is now a conflict between the fscrypt tree and Linus' tree.
>
>
fscrypt's master branch has fsverity patches applied. These are not available
on Linus' tree. Hence the conflict.
Just FYI, The discussion on merging fsverity into mainline kernel is still
going on.
--
chandan
Re: [PATCH v5 0/3] Stingray thermal driver support
Hi Rui, Eduardo, Wish you very happy new year and Thank you very much for your response. Regards, Srinath. On Tue, Jan 1, 2019 at 9:37 PM Eduardo Valentin wrote: > > On Tue, Jan 01, 2019 at 10:04:39PM +0800, Zhang Rui wrote: > > On 一, 2018-12-31 at 14:15 -0800, Florian Fainelli wrote: > > > > > > On 04/12/2018 19:17, Srinath Mannam wrote: > > > > > > > > Hi, > > > > > > > > Could you please provide your feedback to this patch series? > > > Rui or Eduardo can we get either one of you to review the thermal > > > driver > > > parts of this patch series? Why do we constantly have to chase people > > > to > > > respond in this specific subsystem? > > > > > Eduardo, can you please take a look at this patch series? > > Yup, I will take a look. > > > > > thanks, > > rui > > > > > > > > > > > > Regards, > > > > Srinath. > > > > On Thu, Nov 8, 2018 at 3:45 AM Florian Fainelli > > > om> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On 10/16/2018 8:11 AM, Srinath Mannam wrote: > > > > > > > > > > > > These patches adds the stingray thermal driver and its > > > > > > corresponding DT nodes with documentation. > > > > > Can we get feedback from the thermal maintains whether this is > > > > > acceptable or not? > > > > > > > > > > > > > > > > > > > > > > > Changes from v4 > > > > > > - Addressed Rob Herring comments on DT parameters and > > > > > > thermal driver architecture. > > > > > > - Removed brcm,max-crit-temp DT parameter > > > > > > - Changed driver to thermal sensor registration model. > > > > > > - Added trip DT properties. > > > > > > > > > > > > Changes from v3 > > > > > > - Addressed Daniel lezcano comments. > > > > > > - Elaborated commit description of thermal driver patch. > > > > > > - Added brcm,max-crit-temp DT parameter. > > > > > > > > > > > > Changes from v2: > > > > > > - All stingray TMON DT nodes are combine together into > > > > > > single. > > > > > > Temperature registers are combined into one mem resource. > > > > > > brcm,tmon-mask parameter has available TMONs mask value. > > > > > > - All available TMONs are initialized together in single > > > > > > instance of driver probe call. > > > > > > > > > > > > Changes from v1: > > > > > > - Fixed auto build sparce warning. > > > > > > > > > > > > Pramod Kumar (3): > > > > > > dt-bindings: thermal: Add binding document for SR thermal > > > > > > thermal: broadcom: Add Stingray thermal driver > > > > > > arm64: dts: stingray: Add Stingray Thermal DT support. > > > > > > > > > > > > .../bindings/thermal/brcm,sr-thermal.txt | 105 > > > > > > > > > > > > .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 89 > > > > > > + > > > > > > drivers/thermal/Kconfig| 3 +- > > > > > > drivers/thermal/broadcom/Kconfig | 9 ++ > > > > > > drivers/thermal/broadcom/Makefile | 1 + > > > > > > drivers/thermal/broadcom/sr-thermal.c | 138 > > > > > > + > > > > > > 6 files changed, 344 insertions(+), 1 deletion(-) > > > > > > create mode 100644 > > > > > > Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt > > > > > > create mode 100644 drivers/thermal/broadcom/sr-thermal.c > > > > > > > > > > > -- > > > > > Florian
Re: [PATCH v3 2/2] mm: rid swapoff of quadratic complexity
On Tue, 1 Jan 2019, Vineeth Pillai wrote:
> Thanks a lot for the fixes and detailed explanation Hugh! I shall fold all
> the changes from you and Huang in the next iteration.
>
> Thanks for all the suggestions and comments as well. I am looking into all
> those and will include all the changes in the next version. Will discuss
> over mail in case of any clarifications.
One more fix on top of what I sent yesterday: once I delved into
the retries, I found that the major cause of exceeding MAX_RETRIES
was the way the retry code neatly avoided retrying the last part of
its work. With this fix in, I have not yet seen retries go above 1:
no doubt it could, but at present I have no actual evidence that
the MAX_RETRIES-or-livelock issue needs to be dealt with urgently.
Fix sent for completeness, but it reinforces the point that the
structure of try_to_unuse() should be reworked, and oldi gone.
Hugh
---
mm/swapfile.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- mmotm/mm/swapfile.c 2018-12-31 12:30:55.822407154 -0800
+++ linux/mm/swapfile.c 2019-01-01 19:50:34.377277830 -0800
@@ -2107,8 +2107,8 @@ int try_to_unuse(unsigned int type, bool
struct swap_info_struct *si = swap_info[type];
struct page *page;
swp_entry_t entry;
- unsigned int i = 0;
- unsigned int oldi = 0;
+ unsigned int i;
+ unsigned int oldi;
int retries = 0;
if (!frontswap)
@@ -2154,6 +2154,7 @@ retry:
goto out;
}
+ i = oldi = 0;
while ((i = find_next_to_unuse(si, i, frontswap)) != 0) {
/*
* Under global memory pressure, swap entries
Re: WARNING: ODEBUG bug in netdev_freemem
syzbot has found a reproducer for the following crash on:
HEAD commit:28e8c4bc8eb4 Merge tag 'rtc-4.21' of git://git.kernel.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1745f5bf40
kernel config: https://syzkaller.appspot.com/x/.config?x=c2ab9708c613a224
dashboard link: https://syzkaller.appspot.com/bug?extid=979ffc89b87309b1b94b
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17a93c4b40
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+979ffc89b87309b1b...@syzkaller.appspotmail.com
bond0 (unregistering): Released all slaves
IPVS: ftp: loaded support on port[0] = 21
[ cut here ]
ODEBUG: free active (active state 0) object type: timer_list hint:
delayed_work_timer_fn+0x0/0x90 kernel/workqueue.c:4916
kobject: 'lo' (c9c1b9e0): kobject_add_internal: parent: 'net',
set: 'devices'
WARNING: CPU: 1 PID: 9386 at lib/debugobjects.c:325
debug_print_object+0x16a/0x250 lib/debugobjects.c:325
kobject: 'loop1' (0c184f51): kobject_uevent_env
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 9386 Comm: kworker/u4:6 Not tainted 4.20.0+ #4
kobject: 'lo' (c9c1b9e0): kobject_uevent_env
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
kobject: 'loop1' (0c184f51): fill_kobj_path: path
= '/devices/virtual/block/loop1'
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
panic+0x2cb/0x589 kernel/panic.c:189
kobject: 'lo' (c9c1b9e0): fill_kobj_path: path
= '/devices/virtual/net/lo'
kobject: 'queues' (cd7bde5f): kobject_add_internal: parent: 'lo',
set: ''
__warn.cold+0x20/0x4b kernel/panic.c:544
report_bug+0x263/0x2b0 lib/bug.c:186
kobject: 'loop1' (0c184f51): kobject_uevent_env
fixup_bug arch/x86/kernel/traps.c:178 [inline]
fixup_bug arch/x86/kernel/traps.c:173 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
kobject: 'loop1' (0c184f51): fill_kobj_path: path
= '/devices/virtual/block/loop1'
do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290
kobject: 'queues' (cd7bde5f): kobject_uevent_env
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
RIP: 0010:debug_print_object+0x16a/0x250 lib/debugobjects.c:325
Code: dd c0 46 81 88 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 b5 00 00 00 48
8b 14 dd c0 46 81 88 48 c7 c7 60 3c 81 88 e8 06 22 bb fd <0f> 0b 83 05 01
85 cb 06 01 48 83 c4 20 5b 41 5c 41 5d 41 5e 5d c3
RSP: 0018:8880a3ac7270 EFLAGS: 00010086
RAX: RBX: 0003 RCX:
RDX: RSI: 8167d666 RDI: 0005
RBP: 8880a3ac72b0 R08: 88807a33a040 R09: ed1015ce3ef9
R10: ed1015ce3ef8 R11: 8880ae71f7c7 R12: 0001
R13: 899a8e20 R14: 816e2a80 R15: dc00
kobject: 'queues' (cd7bde5f): kobject_uevent_env: filter function
caused the event to drop!
kobject: 'rx-0' (1770de44): kobject_add_internal: parent: 'queues',
set: 'queues'
__debug_check_no_obj_freed lib/debugobjects.c:785 [inline]
debug_check_no_obj_freed+0x39d/0x588 lib/debugobjects.c:817
kobject: 'rx-0' (1770de44): kobject_uevent_env
kfree+0xbd/0x230 mm/slab.c:3803
kvfree+0x61/0x70 mm/util.c:445
netdev_freemem+0x4c/0x60 net/core/dev.c:8991
netdev_release+0x119/0x180 net/core/net-sysfs.c:1640
kobject: 'rx-0' (1770de44): fill_kobj_path: path
= '/devices/virtual/net/lo/queues/rx-0'
device_release+0x7d/0x210 drivers/base/core.c:919
kobject_cleanup lib/kobject.c:662 [inline]
kobject_release lib/kobject.c:691 [inline]
kref_put include/linux/kref.h:67 [inline]
kobject_put.cold+0x28f/0x2ec lib/kobject.c:708
netdev_run_todo+0x704/0xae0 net/core/dev.c:8896
kobject: 'loop3' (21871ddf): kobject_uevent_env
rtnl_unlock+0xe/0x10 net/core/rtnetlink.c:117
default_device_exit_batch+0x4d3/0x5f0 net/core/dev.c:9677
ops_exit_list.isra.0+0x105/0x160 net/core/net_namespace.c:156
cleanup_net+0x51d/0xb10 net/core/net_namespace.c:551
process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153
worker_thread+0x143/0x14a0 kernel/workqueue.c:2296
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
==
WARNING: possible circular locking dependency detected
4.20.0+ #4 Not tainted
--
kworker/u4:6/9386 is trying to acquire lock:
1121b7cd ((console_sem).lock){-.-.}, at: down_trylock+0x13/0x70
kernel/locking/semaphore.c:136
but task is already holding lock:
5012344f (_hash[i].lock){-.-.}, at: __debug_check_no_obj_freed
lib/debugobjects.c:776 [inline]
5012344f (_hash[i].lock){-.-.}, at:
debug_check_no_obj_freed+0x170/0x588
linux-next: build failure after merge of the vfs tree
Hi Al,
After merging the vfs tree, today's linux-next build (x86_64 allnoconfig)
failed like this:
fs/fs_context.c: In function 'logfc':
fs/fs_context.c:400:3: error: implicit declaration of function 'vprintk_emit';
did you mean 'dev_printk_emit'? [-Werror=implicit-function-declaration]
vprintk_emit(0, LOGLEVEL_WARNING, NULL, 0, fmt, va);
^~~~
dev_printk_emit
Caused by commit
e6d72ffc503f ("vfs: Implement logging through fs_context")
# CONFIG_PRINTK is not set
I added the following hack for today:
From: Stephen Rothwell
Date: Wed, 2 Jan 2019 14:57:36 +1100
Subject: [PATCH] vfs: work around CONFIG_PRINTK=n in fs_context logging code
Signed-off-by: Stephen Rothwell
---
fs/fs_context.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/fs_context.c b/fs/fs_context.c
index 8728d49c7871..b0324598f573 100644
--- a/fs/fs_context.c
+++ b/fs/fs_context.c
@@ -391,6 +391,7 @@ EXPORT_SYMBOL(vfs_dup_fs_context);
*/
void logfc(struct fs_context *fc, const char *fmt, ...)
{
+#ifdef CONFIG_PRINTK
va_list va;
va_start(va, fmt);
@@ -409,6 +410,7 @@ void logfc(struct fs_context *fc, const char *fmt, ...)
pr_cont("\n");
va_end(va);
+#endif
}
EXPORT_SYMBOL(logfc);
--
2.19.1
--
Cheers,
Stephen Rothwell
pgpYqcfq2D0qI.pgp
Description: OpenPGP digital signature
[GIT PULL] 9p updates for 4.21
Small pull request this time around with only two commits; some missing prototype warning fix and a syzkaller fix when a 9p server advertises a too small msize. The commit date is close-ish because I reworded a commit message to add a Cc to stable for the msize fix recently, but the patchs themselves have been in linux-next since Nov 20~ish Thanks, The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad: Linux 4.20-rc2 (2018-11-11 17:12:31 -0600) are available in the Git repository at: git://github.com/martinetd/linux tags/9p-for-4.21 for you to fetch changes up to 574d356b7a02c7e1b01a1d9cba8a26b3c2888f45: 9p/net: put a lower bound on msize (2018-12-25 17:07:49 +0900) Pull request for inclusion in 4.21 Missing prototype warning fix and a syzkaller fix when a 9p server advertises a too small msize Adeodato Simó (1): net/9p: include trans_common.h to fix missing prototype warning. Dominique Martinet (1): 9p/net: put a lower bound on msize net/9p/client.c | 21 + net/9p/trans_common.c | 1 + -- Dominique Martinet
Re: [PATCH 2/2] torture.txt: update the list of supported torture types
On Wed, Jan 2, 2019 at 1:54 AM Paul E. McKenney wrote: > > On Tue, Jan 01, 2019 at 10:03:20PM +0800, Junchang Wang wrote: > > Torture types "rcu_bh" and "sched" were removed in commit "c770c82a23". > > The name of torture type "rcu_busted" was changed to "busted" in commit > > "b3c983142d". Two other types, "srcud" and "busted_srcud" were added in > > commits "ca1d51ed98" and "2397d072f7", respectively. This patch updates > > torture.txt accordingly. > > > > Signed-off-by: Junchang Wang > > Given that this section of this file duplicates the rcutorture kernel boot > parameters called out in Documentation/admin-guide/kernel-parameters.txt, > perhaps the best way forward is to instead remove this information from > Documentation/RCU/torture.txt in favor of a reference to the information > (with search string) in Documentation/admin-guide/kernel-parameters.txt. > > Thoughts? Hi Paul, Thanks for the comment; indeed the section "MODULE PARAMETERS" in torture.txt duplicates the corresponding sections in kernel-parameters.txt. I can resubmit a patch that (1) removes the section "MODULE PARAMETERS" in torture.txt, and (2) add a single sentence saying "Module parameters are detailed in Documentation/admin-guide/kernel-parameters.txt". Does that sound good? Thanks, --Junchang > > Thanx, Paul > > > --- > > Documentation/RCU/torture.txt | 15 +++ > > 1 file changed, 7 insertions(+), 8 deletions(-) > > > > diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt > > index 55918b5..6395f0b 100644 > > --- a/Documentation/RCU/torture.txt > > +++ b/Documentation/RCU/torture.txt > > @@ -155,20 +155,19 @@ torture_typeThe type of RCU to test, with string > > values as follows: > > along with expedited, synchronous, and polling > > variants. > > > > - "rcu_bh": rcu_read_lock_bh(), rcu_read_unlock_bh(), and > > - call_rcu_bh(), along with expedited and synchronous > > - variants. > > - > > - "rcu_busted": This tests an intentionally incorrect version > > + "busted": This tests an intentionally incorrect version > > of RCU in order to help test rcutorture itself. > > > > "srcu": srcu_read_lock(), srcu_read_unlock() and > > call_srcu(), along with expedited and > > synchronous variants. > > > > - "sched": preempt_disable(), preempt_enable(), and > > - call_rcu_sched(), along with expedited, > > - synchronous, and polling variants. > > + "srcud": A second form of srcu that dynamically allocates > > + and frees srcu_struct to test srcu cleanup code path. > > + > > + "busted_srcud": This torture type verifies rcutorture's > > ability > > + to detect extensions of RCU read-side critical > > sections > > + that are not handled. > > > > "tasks": voluntary context switch and call_rcu_tasks(), > > along with expedited and synchronous variants. > > -- > > 2.7.4 > > >
Re: [PATCH v2] thermal: tsens: qcom: do not create duplicate regmap debugfs entries
On Thu 06 Dec 01:39 PST 2018, Srinivas Kandagatla wrote:
> Regmap would use device name to create debugfs entries. If the device
> has multiple regmaps it is recommended to use name field in regmap_config.
> Fix this by providing name to the regmap configs correctly.
>
> Without this patch we would see below error on DB820c.
>
> qcom-tsens 4a9000.thermal-sensor: Failed to create 4a9000.thermal-sensor
> debugfs directory
>
> Signed-off-by: Srinivas Kandagatla
> Acked-by: Amit Kucheria
> Tested-by: Amit Kucheria
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> Changes since v1:
> -rename tsens_config to tsens_tm_config as suggested by Amit.
>
> drivers/thermal/qcom/tsens-common.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens-common.c
> b/drivers/thermal/qcom/tsens-common.c
> index 3be4be2e0465..ddfdf88ffb4e 100644
> --- a/drivers/thermal/qcom/tsens-common.c
> +++ b/drivers/thermal/qcom/tsens-common.c
> @@ -113,7 +113,15 @@ int get_temp_common(struct tsens_device *tmdev, int id,
> int *temp)
> return 0;
> }
>
> -static const struct regmap_config tsens_config = {
> +static const struct regmap_config tsens_tm_config = {
> + .name = "tm",
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static const struct regmap_config tsens_srot_config = {
> + .name = "srot",
> .reg_bits = 32,
> .val_bits = 32,
> .reg_stride = 4,
> @@ -139,8 +147,8 @@ int __init init_common(struct tsens_device *tmdev)
> if (IS_ERR(srot_base))
> return PTR_ERR(srot_base);
>
> - tmdev->srot_map = devm_regmap_init_mmio(tmdev->dev,
> - srot_base,
> _config);
> + tmdev->srot_map = devm_regmap_init_mmio(tmdev->dev, srot_base,
> + _srot_config);
> if (IS_ERR(tmdev->srot_map))
> return PTR_ERR(tmdev->srot_map);
>
> @@ -154,7 +162,8 @@ int __init init_common(struct tsens_device *tmdev)
> if (IS_ERR(tm_base))
> return PTR_ERR(tm_base);
>
> - tmdev->tm_map = devm_regmap_init_mmio(tmdev->dev, tm_base,
> _config);
> + tmdev->tm_map = devm_regmap_init_mmio(tmdev->dev, tm_base,
> + _tm_config);
> if (IS_ERR(tmdev->tm_map))
> return PTR_ERR(tmdev->tm_map);
>
> --
> 2.19.2
>
[PATCH 1/1] net-next/hinic:add shutdown callback
If there is no shutdown callback, our board will report pcie UNF errors
after restarting. This patch add shutdown callback for hinic.
Signed-off-by: Xue Chaojing
---
drivers/net/ethernet/huawei/hinic/hinic_main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_main.c
b/drivers/net/ethernet/huawei/hinic/hinic_main.c
index 6d48dc62a44b..da323b9e1f62 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_main.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
@@ -1106,6 +1106,11 @@ static void hinic_remove(struct pci_dev *pdev)
dev_info(>dev, "HiNIC driver - removed\n");
}
+static void hinic_shutdown(struct pci_dev *pdev)
+{
+ pci_disable_device(pdev);
+}
+
static const struct pci_device_id hinic_pci_table[] = {
{ PCI_VDEVICE(HUAWEI, HINIC_DEV_ID_QUAD_PORT_25GE), 0},
{ PCI_VDEVICE(HUAWEI, HINIC_DEV_ID_DUAL_PORT_25GE), 0},
@@ -1119,6 +1124,7 @@ static struct pci_driver hinic_driver = {
.id_table = hinic_pci_table,
.probe = hinic_probe,
.remove = hinic_remove,
+ .shutdown = hinic_shutdown,
};
module_pci_driver(hinic_driver);
--
2.17.1
Re: KASAN: slab-out-of-bounds Read in tun_net_xmit (2)
On 2018/12/31 下午5:51, Jesper Dangaard Brouer wrote: Hi MST and Jason, Could you please take a look at this? This bug is caused by a thread resizing the tun-queue (via tun_queue_resize -> ptr_ring_resize_multiple). And error happens in tun_net_xmit -> ptr_ring_produce. My guess is bug happens when reading r->queue in ptr_ring_produce. I've look at the code (see diff comments below), but I cannot spot the issue as the (implicit) memory barrier of a spinlock should cover the cases I can imagine. Hi: Cong sent a patch for this and looks like it was fixed in https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=aff6db454599d62191aabc208930e891748e4322. Thanks
Re: [PATCH RFC 1/2] virtio-net: bql support
On 2018/12/31 上午2:48, Michael S. Tsirkin wrote:
On Thu, Dec 27, 2018 at 06:04:53PM +0800, Jason Wang wrote:
On 2018/12/26 下午11:22, Michael S. Tsirkin wrote:
On Thu, Dec 06, 2018 at 04:17:36PM +0800, Jason Wang wrote:
On 2018/12/6 上午6:54, Michael S. Tsirkin wrote:
When use_napi is set, let's enable BQLs. Note: some of the issues are
similar to wifi. It's worth considering whether something similar to
commit 36148c2bbfbe ("mac80211: Adjust TSQ pacing shift") might be
benefitial.
I've played a similar patch several days before. The tricky part is the mode
switching between napi and no napi. We should make sure when the packet is
sent and trakced by BQL, it should be consumed by BQL as well.
I just went over the patch again and I don't understand this comment.
This patch only enabled BQL with tx napi.
Thus there's no mode switching.
What did I miss?
Consider the case:
TX NAPI is disabled:
send N packets
turn TX NAPI on:
get tx interrupt
BQL try to consume those packets when lead WARN for dql.
Thanks
Can one really switch tx napi on and off? How?
While root can change the napi_tx module parameter, I don't think
that has any effect outside device probe time. What did I miss?
We support switch the mode through ethtool recently. See
commit 0c465be183c7c57a26446df6ea96d8676b865f92
Author: Jason Wang
Date: Tue Oct 9 10:06:26 2018 +0800
virtio_net: ethtool tx napi configuration
Implement ethtool .set_coalesce (-C) and .get_coalesce (-c) handlers.
Interrupt moderation is currently not supported, so these accept and
display the default settings of 0 usec and 1 frame.
Toggle tx napi through setting tx-frames. So as to not interfere
with possible future interrupt moderation, value 1 means tx napi while
value 0 means not.
Only allow the switching when device is down for simplicity.
Link: https://patchwork.ozlabs.org/patch/948149/
Suggested-by: Jason Wang
Signed-off-by: Willem de Bruijn
Signed-off-by: Jason Wang
Signed-off-by: David S. Miller
Thanks
Re: [PATCH RFC 1/2] virtio-net: bql support
On 2018/12/31 上午2:45, Michael S. Tsirkin wrote:
On Thu, Dec 27, 2018 at 06:00:36PM +0800, Jason Wang wrote:
On 2018/12/26 下午11:19, Michael S. Tsirkin wrote:
On Thu, Dec 06, 2018 at 04:17:36PM +0800, Jason Wang wrote:
On 2018/12/6 上午6:54, Michael S. Tsirkin wrote:
When use_napi is set, let's enable BQLs. Note: some of the issues are
similar to wifi. It's worth considering whether something similar to
commit 36148c2bbfbe ("mac80211: Adjust TSQ pacing shift") might be
benefitial.
I've played a similar patch several days before. The tricky part is the mode
switching between napi and no napi. We should make sure when the packet is
sent and trakced by BQL, it should be consumed by BQL as well. I did it by
tracking it through skb->cb. And deal with the freeze by reset the BQL
status. Patch attached.
But when testing with vhost-net, I don't very a stable performance,
So how about increasing TSQ pacing shift then?
I can test this. But changing default TCP value is much more than a
virtio-net specific thing.
Well same logic as wifi applies. Unpredictable latencies related
to radio in one case, to host scheduler in the other.
it was
probably because we batch the used ring updating so tx interrupt may come
randomly. We probably need to implement time bounded coalescing mechanism
which could be configured from userspace.
I don't think it's reasonable to expect userspace to be that smart ...
Why do we need time bounded? used ring is always updated when ring
becomes empty.
We don't add used when means BQL may not see the consumed packet in time.
And the delay varies based on the workload since we count packets not bytes
or time before doing the batched updating.
Thanks
Sorry I still don't get it.
When nothing is outstanding then we do update the used.
So if BQL stops userspace from sending packets then
we get an interrupt and packets start flowing again.
Yes, but how about the cases of multiple flows. That's where I see
unstable results.
It might be suboptimal, we might need to tune it but I doubt running
timers is a solution, timer interrupts cause VM exits.
Probably not a timer but a time counter (or event byte counter) in vhost
to add used and signal guest if it exceeds a value instead of waiting
the number of packets.
Thanks
Btw, maybe it's time just enable napi TX by default. I get ~10% TCP_RR
regression on machine without APICv, (haven't found time to test APICv
machine). But consider it was for correctness, I think it's acceptable? Then
we can do optimization on top?
Thanks
Signed-off-by: Michael S. Tsirkin
---
drivers/net/virtio_net.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index cecfd77c9f3c..b657bde6b94b 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1325,7 +1325,8 @@ static int virtnet_receive(struct receive_queue *rq, int
budget,
return stats.packets;
}
-static void free_old_xmit_skbs(struct send_queue *sq)
+static void free_old_xmit_skbs(struct send_queue *sq, struct netdev_queue *txq,
+ bool use_napi)
{
struct sk_buff *skb;
unsigned int len;
@@ -1347,6 +1348,9 @@ static void free_old_xmit_skbs(struct send_queue *sq)
if (!packets)
return;
+ if (use_napi)
+ netdev_tx_completed_queue(txq, packets, bytes);
+
u64_stats_update_begin(>stats.syncp);
sq->stats.bytes += bytes;
sq->stats.packets += packets;
@@ -1364,7 +1368,7 @@ static void virtnet_poll_cleantx(struct receive_queue *rq)
return;
if (__netif_tx_trylock(txq)) {
- free_old_xmit_skbs(sq);
+ free_old_xmit_skbs(sq, txq, true);
__netif_tx_unlock(txq);
}
@@ -1440,7 +1444,7 @@ static int virtnet_poll_tx(struct napi_struct *napi, int
budget)
struct netdev_queue *txq = netdev_get_tx_queue(vi->dev, vq2txq(sq->vq));
__netif_tx_lock(txq, raw_smp_processor_id());
- free_old_xmit_skbs(sq);
+ free_old_xmit_skbs(sq, txq, true);
__netif_tx_unlock(txq);
virtqueue_napi_complete(napi, sq->vq, 0);
@@ -1505,13 +1509,15 @@ static netdev_tx_t start_xmit(struct sk_buff *skb,
struct net_device *dev)
struct send_queue *sq = >sq[qnum];
int err;
struct netdev_queue *txq = netdev_get_tx_queue(dev, qnum);
- bool kick = !skb->xmit_more;
+ bool more = skb->xmit_more;
bool use_napi = sq->napi.weight;
+ unsigned int bytes = skb->len;
+ bool kick;
/* Free up any pending old buffers before queueing new ones. */
- free_old_xmit_skbs(sq);
+ free_old_xmit_skbs(sq, txq, use_napi);
- if (use_napi && kick)
+ if (use_napi && !more)
virtqueue_enable_cb_delayed(sq->vq);
/* timestamp packet in software */
@@ -1552,7 +1558,7 @@ static netdev_tx_t
drivers/pci/controller/pcie-mediatek.c:720:13-16: WARNING: Suspicious code. resource_size is maybe missing with mem
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 8e143b90e4d45cca3dc53760d3cfab988bc74571
commit: 031337ace2d1c22a447da6390716fe92592cdd6e PCI: mediatek: Add loadable
kernel module support
date: 3 months ago
coccinelle warnings: (new ones prefixed by >>)
>> drivers/pci/controller/pcie-mediatek.c:720:13-16: WARNING: Suspicious code.
>> resource_size is maybe missing with mem
vim +720 drivers/pci/controller/pcie-mediatek.c
b099631d drivers/pci/host/pcie-mediatek.c Ryder Lee 2017-08-10 661
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 662
static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 663 {
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 664
struct mtk_pcie *pcie = port->pcie;
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 665
struct resource *mem = >mem;
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 666
const struct mtk_pcie_soc *soc = port->pcie->soc;
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 667
u32 val;
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 668
size_t size;
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 669
int err;
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 670
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 671
/* MT7622 platforms need to enable LTSSM and ASPM from PCIe subsys */
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 672
if (pcie->base) {
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 673
val = readl(pcie->base + PCIE_SYS_CFG_V2);
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 674
val |= PCIE_CSR_LTSSM_EN(port->slot) |
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 675
PCIE_CSR_ASPM_L1_EN(port->slot);
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 676
writel(val, pcie->base + PCIE_SYS_CFG_V2);
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 677
}
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 678
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 679
/* Assert all reset signals */
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 680
writel(0, port->base + PCIE_RST_CTRL);
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 681
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 682
/*
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 683
* Enable PCIe link down reset, if link status changed from link up to
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 684
* link down, this will reset MAC control registers and configuration
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 685
* space.
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 686
*/
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 687
writel(PCIE_LINKDOWN_RST_EN, port->base + PCIE_RST_CTRL);
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 688
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 689
/* De-assert PHY, PE, PIPE, MAC and configuration reset */
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 690
val = readl(port->base + PCIE_RST_CTRL);
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 691
val |= PCIE_PHY_RSTB | PCIE_PERSTB | PCIE_PIPE_SRSTB |
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 692
PCIE_MAC_SRSTB | PCIE_CRSTB;
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 693
writel(val, port->base + PCIE_RST_CTRL);
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 694
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 695
/* Set up vendor ID and class code */
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 696
if (soc->need_fix_class_id) {
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 697
val = PCI_VENDOR_ID_MEDIATEK;
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 698
writew(val, port->base + PCIE_CONF_VEND_ID);
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 699
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 700
val = PCI_CLASS_BRIDGE_PCI;
3828d60f drivers/pci/controller/pcie-mediatek.c Honghui Zhang 2018-10-15 701
Re: [PATCH 6/6] MAINTAINERS: Add linux-actions mailing list for Actions Semi
Hi Joe, On Tue, Jan 01, 2019 at 08:56:49AM -0800, Joe Perches wrote: > On Tue, 2019-01-01 at 08:56 +0530, Manivannan Sadhasivam wrote: > > Hi Joe, > > Hi Manivannan. > > > On Mon, Dec 31, 2018 at 11:12:18AM -0800, Joe Perches wrote: > > > On Tue, 2019-01-01 at 00:25 +0530, Manivannan Sadhasivam wrote: > > > > Add the linux-actions mailing list for Actions Semi SoC architecture. > > > > > > Unrelated to adding this L: entry > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > [] > > > > @@ -1240,6 +1240,7 @@ ARM/ACTIONS SEMI ARCHITECTURE > > > > M: Andreas Färber > > > > R: Manivannan Sadhasivam > > > > L: linux-arm-ker...@lists.infradead.org (moderated for > > > > non-subscribers) > > > > +L: linux-acti...@lists.infradead.org (moderated for > > > > non-subscribers) > > > > S: Maintained > > > > N: owl > > > > > > The N: entry matches too many non-owl entries like: > > > > > > Documentation/parport-lowlevel.txt > > > drivers/misc/ibmasm/lowlevel.c > > > drivers/misc/ibmasm/lowlevel.h > > > fs/udf/lowlevel.c > > > net/ipv6/ip6_flowlabel.c > > > sound/soc/samsung/lowland.c > > > > > > Maybe there should be two entries > > > > > > N:/owl > > > N:-owl > > > > > > > Thanks for letting us know. Yes, we need to change it. How about below? > > > > N: owl- > > N: -owl > > > > Will do it as a follow-up patch if agreed! > > from MAINTAINERS: > > scripts/get_maintainer.pl has different behavior for files that > match F: pattern and matches of N: patterns. By default, > get_maintainer will not look at git log history when an F: pattern > match occurs. When an N: match occurs, git log history is used > to also notify the people that have git commit signatures. > > F: entries are preferred to N: entries because the > get_maintainer.pl script does not assume that the > N: entries are exclusively maintained. Maybe use a > more comprehensive F: list like: > > F:Documentation/devicetree/bindings/*/*owl-* > F:arch/arm/boot/dts/owl-* > F:drivers/*/owl-* > F:drivers/*/*-owl* > F:drivers/*/*/owl-* > F:drivers/*/*/*-owl* > F:include/dt-bindings/power/owl-* > F:include/linux/soc/actions/owl-sps.h > Makes sense! Andreas: What is your opinion on above entries? Thanks, Mani >
[PATCH v9 2/2] arm: dts: mt2712: add uart APDMA to device tree
1. add uart APDMA controller device node
2. add uart 0/1/2/3/4/5 DMA function
Signed-off-by: Long Cheng
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 50 +
1 file changed, 50 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 976d92a..be1a22a 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -300,6 +300,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+ dmas = < 10
+11>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -369,6 +372,38 @@
(GIC_CPU_MASK_RAW(0x13) | IRQ_TYPE_LEVEL_HIGH)>;
};
+ apdma: dma-controller@11000400 {
+ compatible = "mediatek,mt2712-uart-dma",
+"mediatek,mt6577-uart-dma";
+ reg = <0 0x11000400 0 0x80>,
+ <0 0x11000480 0 0x80>,
+ <0 0x11000500 0 0x80>,
+ <0 0x11000580 0 0x80>,
+ <0 0x11000600 0 0x80>,
+ <0 0x11000680 0 0x80>,
+ <0 0x11000700 0 0x80>,
+ <0 0x11000780 0 0x80>,
+ <0 0x11000800 0 0x80>,
+ <0 0x11000880 0 0x80>,
+ <0 0x11000900 0 0x80>,
+ <0 0x11000980 0 0x80>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ clocks = < CLK_PERI_AP_DMA>;
+ clock-names = "apdma";
+ #dma-cells = <1>;
+ };
+
auxadc: adc@11001000 {
compatible = "mediatek,mt2712-auxadc";
reg = <0 0x11001000 0 0x1000>;
@@ -385,6 +420,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+ dmas = < 0
+1>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -395,6 +433,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+ dmas = < 2
+3>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -405,6 +446,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+ dmas = < 4
+5>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -415,6 +459,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+ dmas = < 6
+7>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -629,6 +676,9 @@
interrupts = ;
clocks = <_clk>, <_clk>;
clock-names = "baud", "bus";
+ dmas = < 8
+9>;
+ dma-names = "tx", "rx";
status = "disabled";
};
--
1.7.9.5
[PATCH v9 1/2] dmaengine: 8250_mtk_dma: add MediaTek uart DMA support
In DMA engine framework, add 8250 uart dma to support MediaTek uart.
If MediaTek uart enabled(SERIAL_8250_MT6577), and want to improve
the performance, can enable the function.
Signed-off-by: Long Cheng
---
drivers/dma/mediatek/8250_mtk_dma.c | 652 +++
drivers/dma/mediatek/Kconfig| 11 +
drivers/dma/mediatek/Makefile |1 +
3 files changed, 664 insertions(+)
create mode 100644 drivers/dma/mediatek/8250_mtk_dma.c
diff --git a/drivers/dma/mediatek/8250_mtk_dma.c
b/drivers/dma/mediatek/8250_mtk_dma.c
new file mode 100644
index 000..dbf811e
--- /dev/null
+++ b/drivers/dma/mediatek/8250_mtk_dma.c
@@ -0,0 +1,652 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek 8250 DMA driver.
+ *
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Long Cheng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../virt-dma.h"
+
+#define MTK_UART_APDMA_CHANNELS(CONFIG_SERIAL_8250_NR_UARTS *
2)
+
+#define VFF_EN_B BIT(0)
+#define VFF_STOP_B BIT(0)
+#define VFF_FLUSH_BBIT(0)
+#define VFF_4G_SUPPORT_B BIT(0)
+#define VFF_RX_INT_EN0_B BIT(0) /*rx valid size >= vff thre*/
+#define VFF_RX_INT_EN1_B BIT(1)
+#define VFF_TX_INT_EN_BBIT(0) /*tx left size >= vff thre*/
+#define VFF_WARM_RST_B BIT(0)
+#define VFF_RX_INT_FLAG_CLR_B (BIT(0) | BIT(1))
+#define VFF_TX_INT_FLAG_CLR_B 0
+#define VFF_STOP_CLR_B 0
+#define VFF_INT_EN_CLR_B 0
+#define VFF_4G_SUPPORT_CLR_B 0
+
+/* interrupt trigger level for tx */
+#define VFF_TX_THRE(n) ((n) * 7 / 8)
+/* interrupt trigger level for rx */
+#define VFF_RX_THRE(n) ((n) * 3 / 4)
+
+#define VFF_RING_SIZE 0xU
+/* invert this bit when wrap ring head again*/
+#define VFF_RING_WRAP 0x1U
+
+#define VFF_INT_FLAG 0x00
+#define VFF_INT_EN 0x04
+#define VFF_EN 0x08
+#define VFF_RST0x0c
+#define VFF_STOP 0x10
+#define VFF_FLUSH 0x14
+#define VFF_ADDR 0x1c
+#define VFF_LEN0x24
+#define VFF_THRE 0x28
+#define VFF_WPT0x2c
+#define VFF_RPT0x30
+/*TX: the buffer size HW can read. RX: the buffer size SW can read.*/
+#define VFF_VALID_SIZE 0x3c
+/*TX: the buffer size SW can write. RX: the buffer size HW can write.*/
+#define VFF_LEFT_SIZE 0x40
+#define VFF_DEBUG_STATUS 0x50
+#define VFF_4G_SUPPORT 0x54
+
+struct mtk_uart_apdmadev {
+ struct dma_device ddev;
+ struct clk *clk;
+ bool support_33bits;
+ unsigned int dma_irq[MTK_UART_APDMA_CHANNELS];
+};
+
+struct mtk_uart_apdma_desc {
+ struct virt_dma_desc vd;
+
+ unsigned int avail_len;
+};
+
+struct mtk_chan {
+ struct virt_dma_chan vc;
+ struct dma_slave_config cfg;
+ void __iomem *base;
+ struct mtk_uart_apdma_desc *desc;
+
+ bool requested;
+
+ unsigned int rx_status;
+};
+
+static inline struct mtk_uart_apdmadev *
+to_mtk_uart_apdma_dev(struct dma_device *d)
+{
+ return container_of(d, struct mtk_uart_apdmadev, ddev);
+}
+
+static inline struct mtk_chan *to_mtk_uart_apdma_chan(struct dma_chan *c)
+{
+ return container_of(c, struct mtk_chan, vc.chan);
+}
+
+static inline struct mtk_uart_apdma_desc *to_mtk_uart_apdma_desc
+ (struct dma_async_tx_descriptor *t)
+{
+ return container_of(t, struct mtk_uart_apdma_desc, vd.tx);
+}
+
+static void mtk_uart_apdma_write(struct mtk_chan *c,
+ unsigned int reg, unsigned int val)
+{
+ writel(val, c->base + reg);
+}
+
+static unsigned int mtk_uart_apdma_read(struct mtk_chan *c, unsigned int reg)
+{
+ return readl(c->base + reg);
+}
+
+static void mtk_uart_apdma_desc_free(struct virt_dma_desc *vd)
+{
+ struct dma_chan *chan = vd->tx.chan;
+ struct mtk_chan *c = to_mtk_uart_apdma_chan(chan);
+
+ kfree(c->desc);
+}
+
+static void mtk_uart_apdma_start_tx(struct mtk_chan *c)
+{
+ unsigned int len, send, left, wpt, d_wpt, tmp;
+ int ret;
+
+ left = mtk_uart_apdma_read(c, VFF_LEFT_SIZE);
+ if (!left) {
+ mtk_uart_apdma_write(c, VFF_INT_EN, VFF_TX_INT_EN_B);
+ return;
+ }
+
+ /* Wait 1sec for flush, can't sleep*/
+ ret = readx_poll_timeout(readl, c->base + VFF_FLUSH, tmp,
+ tmp != VFF_FLUSH_B, 0, 100);
+ if (ret)
+ dev_warn(c->vc.chan.device->dev, "tx: fail, debug=0x%x\n",
+ mtk_uart_apdma_read(c, VFF_DEBUG_STATUS));
+
+ send = min_t(unsigned int, left, c->desc->avail_len);
+ wpt = mtk_uart_apdma_read(c, VFF_WPT);
+ len = mtk_uart_apdma_read(c, VFF_LEN);
+
+ d_wpt
[PATCH v9 0/2] add uart DMA function
In Mediatek SOCs, the uart can support DMA function. Base on DMA engine formwork, we add the DMA code to support uart. And put the code under drivers/dma. This series contains document bindings, Kconfig to control the function enable or not, device tree including interrupt and dma device node, the code of UART DMA Changes compared to v8 -revise missing items Changes compared to v7: -modify apdma uart tx Changes compared to v6: -Correct spelling Changes compared to v5: -move 'requst irqs' to alloc channel -remove tasklet. Changes compared to v4: -modify Kconfig depends on. Changes compared to v3: -fix CONFIG_PM, will cause build fail Changes compared to v2: -remove unimportant parameters -instead of cookie, use APIs of virtual channel. -use of_dma_xlate_by_chan_id. Changes compared to v1: -mian revised file, 8250_mtk_dma.c --parameters renamed for standard --remove atomic operation
Re: linux-next: manual merge of the tip tree with the vfs tree
Hi all,
On Mon, 26 Nov 2018 15:39:25 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/kernel/cpu/resctrl/rdtgroup.c
>
> between commit:
>
> 16ec1a5d58ea ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
> (where the file is arch/x86/kernel/cpu/intel_rdt_rdtgroup.c)
>
> from the vfs tree and commit:
>
> 580ebb66cbb3 ("x86/resctrl: Add vendor check for the MBA software
> controller")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 37c0ccb50823,61b102dd51a5..
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@@ -2032,88 -2065,8 +2032,91 @@@ out
> rdt_last_cmd_clear();
> mutex_unlock(_mutex);
> cpus_read_unlock();
> +return ret;
> +}
> +
> +enum rdt_param {
> +Opt_cdp,
> +Opt_cdpl2,
> +Opt_mba_mpbs,
> +nr__rdt_params
> +};
>
> -return dentry;
> +static const struct fs_parameter_spec rdt_param_specs[nr__rdt_params] = {
> +[Opt_cdp] = { fs_param_is_flag },
> +[Opt_cdpl2] = { fs_param_is_flag },
> +[Opt_mba_mpbs] = { fs_param_is_flag },
> +};
> +
> +static const char *const rdt_param_keys[nr__rdt_params] = {
> +[Opt_cdp] = "cdp",
> +[Opt_cdpl2] = "cdpl2",
> +[Opt_mba_mpbs] = "mba_mbps",
> +};
> +
> +static const struct fs_parameter_description rdt_fs_parameters = {
> +.name = "rdt",
> +.nr_params = nr__rdt_params,
> +.keys = rdt_param_keys,
> +.specs = rdt_param_specs,
> +.no_source = true,
> +};
> +
> +static int rdt_parse_param(struct fs_context *fc, struct fs_parameter
> *param)
> +{
> +struct rdt_fs_context *ctx = rdt_fc2context(fc);
> +struct fs_parse_result result;
> +int opt;
> +
> +opt = fs_parse(fc, _fs_parameters, param, );
> +if (opt < 0)
> +return opt;
> +
> +switch (opt) {
> +case Opt_cdp:
> +ctx->enable_cdpl3 = true;
> +return 0;
> +case Opt_cdpl2:
> +ctx->enable_cdpl2 = true;
> +return 0;
> +case Opt_mba_mpbs:
> - ctx->enable_mba_mbps = true;
> - return 0;
> ++if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
> ++ctx->enable_mba_mbps = true;
> ++return 0;
> ++}
> ++break;
> +}
> +
> +return -EINVAL;
> +}
> +
> +static void rdt_fs_context_free(struct fs_context *fc)
> +{
> +struct rdt_fs_context *ctx = rdt_fc2context(fc);
> +
> +kernfs_free_fs_context(fc);
> +kfree(ctx);
> +}
> +
> +static const struct fs_context_operations rdt_fs_context_ops = {
> +.free = rdt_fs_context_free,
> +.parse_param= rdt_parse_param,
> +.get_tree = rdt_get_tree,
> +};
> +
> +static int rdt_init_fs_context(struct fs_context *fc, struct dentry
> *reference)
> +{
> +struct rdt_fs_context *ctx;
> +
> +ctx = kzalloc(sizeof(struct rdt_fs_context), GFP_KERNEL);
> +if (!ctx)
> +return -ENOMEM;
> +
> +ctx->kfc.root = rdt_root;
> +ctx->kfc.magic = RDTGROUP_SUPER_MAGIC;
> +fc->fs_private = >kfc;
> +fc->ops = _fs_context_ops;
> +return 0;
> }
>
> static int reset_all_ctrls(struct rdt_resource *r)
This is now a conflict between Linus' tree and the vfs tree.
--
Cheers,
Stephen Rothwell
pgprZIlQs20FY.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 1/2] pci: altera: Add Stratix10 PCIe support
On Mon, 2018-12-31 at 09:17 -0600, Bjorn Helgaas wrote:
> Run "git log --oneline --follow drivers/pci/controller/pcie-altera.c"
> and
> make your subject line match in style, phrasing, and capitalization.
>
> Hint:
>
> pci: altera: Add Stratix10 PCIe support
> ef75369a5b9a PCI: altera: Fix platform_get_irq() error handling
> bfdbbf0e3c2a PCI: altera: Use size=4 IRQ domain for legacy INTx
> 6ab380957838 PCI: altera: Drop pci_fixup_irqs()
> 9815791319a0 PCI: altera: Convert PCI scan API to
> pci_scan_root_bus_bridge()
> 2a7275a3d867 PCI: altera: Fix TLP_CFG_DW0 for TLP write
>
> One of these is not like the others.
Okay, will change it.
>
> On Mon, Dec 31, 2018 at 04:24:52PM +0800, Ley Foon Tan wrote:
> ...
> >
> > +struct altera_pcie_data {
> > + int (*tlp_read_pkt)(struct altera_pcie *pcie, u32 *value);
> > + void (*tlp_write_pkt)(struct altera_pcie *pcie, u32
> > *headers,
> > + u32 data, bool align);
> > + bool (*get_link_status)(struct altera_pcie *pcie);
> > + int (*rp_read_cfg)(struct altera_pcie *pcie, int where,
> > + int size, u32 *value);
> > + int (*rp_write_cfg)(struct altera_pcie *pcie, u8 bus, int
> > where,
> > + int size, u32 value);
> > + bool s10_flag; /* Stratix 10 */
> This is OK if you only ever have two programming models (the original
> and Stratix 10). But if there's a possibility of more, an int model
> type that can be tested with a switch is more extensible.
>
> Personally I prefer bitfields over bool in structures, but ultimately
> Lorenzo will take this and I don't know whether he has a preference.
>
> https://lkml.kernel.org/r/CA+55aFxnePDimkVKVtv3gNmRGcwc8KQ5mHYvUxY8sA
> qg6yv...@mail.gmail.com
> https://lkml.kernel.org/r/CA+55aFzKQ6Pj18TB8p4Yr0M4t+S+BsiHH=BJNmn=76
> -ncjt...@mail.gmail.com
Yes, you are right. Will change it to something like "version type".
Regards
Ley Foon
Re: [PATCH v2 1/2] pci: altera: Add Stratix10 PCIe support
On Mon, 2018-12-31 at 09:17 -0600, Bjorn Helgaas wrote:
> Run "git log --oneline --follow drivers/pci/controller/pcie-altera.c"
> and
> make your subject line match in style, phrasing, and capitalization.
>
> Hint:
>
> pci: altera: Add Stratix10 PCIe support
> ef75369a5b9a PCI: altera: Fix platform_get_irq() error handling
> bfdbbf0e3c2a PCI: altera: Use size=4 IRQ domain for legacy INTx
> 6ab380957838 PCI: altera: Drop pci_fixup_irqs()
> 9815791319a0 PCI: altera: Convert PCI scan API to
> pci_scan_root_bus_bridge()
> 2a7275a3d867 PCI: altera: Fix TLP_CFG_DW0 for TLP write
>
> One of these is not like the others.
Okay, will change it.
>
> On Mon, Dec 31, 2018 at 04:24:52PM +0800, Ley Foon Tan wrote:
> ...
> >
> > +struct altera_pcie_data {
> > + int (*tlp_read_pkt)(struct altera_pcie *pcie, u32 *value);
> > + void (*tlp_write_pkt)(struct altera_pcie *pcie, u32
> > *headers,
> > + u32 data, bool align);
> > + bool (*get_link_status)(struct altera_pcie *pcie);
> > + int (*rp_read_cfg)(struct altera_pcie *pcie, int where,
> > + int size, u32 *value);
> > + int (*rp_write_cfg)(struct altera_pcie *pcie, u8 bus, int
> > where,
> > + int size, u32 value);
> > + bool s10_flag; /* Stratix 10 */
> This is OK if you only ever have two programming models (the original
> and Stratix 10). But if there's a possibility of more, an int model
> type that can be tested with a switch is more extensible.
>
> Personally I prefer bitfields over bool in structures, but ultimately
> Lorenzo will take this and I don't know whether he has a preference.
>
> https://lkml.kernel.org/r/CA+55aFxnePDimkVKVtv3gNmRGcwc8KQ5mHYvUxY8sA
> qg6yv...@mail.gmail.com
> https://lkml.kernel.org/r/CA+55aFzKQ6Pj18TB8p4Yr0M4t+S+BsiHH=BJNmn=76
> -ncjt...@mail.gmail.com
Yes, you are right. Will change it to something like "version type".
Regards
Ley Foon
Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating
On 12/31/18 12:27 AM, Tariq Toukan wrote:
>
>
> On 1/27/2018 2:41 PM, jianchao.wang wrote:
>> Hi Tariq
>>
>> Thanks for your kindly response.
>> That's really appreciated.
>>
>> On 01/25/2018 05:54 PM, Tariq Toukan wrote:
>>>
>>>
>>> On 25/01/2018 8:25 AM, jianchao.wang wrote:
Hi Eric
Thanks for you kindly response and suggestion.
That's really appreciated.
Jianchao
On 01/25/2018 11:55 AM, Eric Dumazet wrote:
> On Thu, 2018-01-25 at 11:27 +0800, jianchao.wang wrote:
>> Hi Tariq
>>
>> On 01/22/2018 10:12 AM, jianchao.wang wrote:
> On 19/01/2018 5:49 PM, Eric Dumazet wrote:
>> On Fri, 2018-01-19 at 23:16 +0800, jianchao.wang wrote:
>>> Hi Tariq
>>>
>>> Very sad that the crash was reproduced again after applied the
>>> patch.
Memory barriers vary for different Archs, can you please share more
details regarding arch and repro steps?
>>> The hardware is HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89
>>> 12/27/2015
>>> The xen is installed. The crash occurred in DOM0.
>>> Regarding to the repro steps, it is a customer's test which does heavy
>>> disk I/O over NFS storage without any guest.
>>>
>>
>> What is the finial suggestion on this ?
>> If use wmb there, is the performance pulled down ?
>>>
>>> I want to evaluate this effect.
>>> I agree with Eric, expected impact is restricted, especially after batching
>>> the allocations.>
>
> Since
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_pub_scm_linux_kernel_git_davem_net-2Dnext.git_commit_-3Fid-3Ddad42c3038a59d27fced28ee4ec1d4a891b28155=DwICaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=7WdAxUBeiTUTCy8v-7zXyr4qk7sx26ATvfo6QSTvZyQ=c0oI8duFkyFBILMQYDsqRApHQrOlLY_2uGiz_utcd7s=E4_XKmSI0B63qB0DLQ1EX_fj1bOP78ZdeYADBf33B-k=
>
> we batch allocations, so mlx4_en_refill_rx_buffers() is not called that
> often.
>
> I doubt the additional wmb() will have serious impact there.
>
>>>
>>> I will test the effect (it'll be beginning of next week).
>>> I'll update so we can make a more confident decision.
>>>
>> I have also sent patches with wmb and batching allocations to customer and
>> let them check whether the performance is impacted.
>> And update here asap when get feedback.
>>
>>> Thanks,
>>> Tariq
>>>
>
> Hi Jianchao,
>
> I am interested to push this bug fix.
> Do you want me to submit, or do it yourself?
> Can you elaborate regarding the arch with the repro?
>
> This is the patch I suggest:
>
> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> @@ -161,6 +161,8 @@ static bool mlx4_en_is_ring_empty(const struct
> mlx4_en_rx_ring *ring)
>
> static inline void mlx4_en_update_rx_prod_db(struct mlx4_en_rx_ring *ring)
> {
> + /* ensure rx_desc updating reaches HW before prod db updating */
> + wmb();
> *ring->wqres.db.db = cpu_to_be32(ring->prod & 0x);
> }
>
Hi Tariq
Happy new year !
The customer provided confused test result for us.
The fix cannot fix their issue.
And we finally find a upstream fix
5d70bd5c98d0e655bde2aae2b5251bdd44df5e71
(net/mlx4_en: fix potential use-after-free with dma_unmap_page)
and killed the issue during Oct 2018. That's really a long way.
Please go ahead with this patch.
Thanks
Jianchao
knifeshack (Linux Property rights)
Let's say you had an old knife shack. Called Knife Shack InC. (you ain't incorporated, you just call it that, looks nice on the sign). On an old dusty road, telephone pole bout ready to fall down next typhoon hit. Behind yo knoif shack there is quite a body of water, now it's murky, but it is infact quite deep. An old sink hole, now filled beyond filling with the dandruff of the ages. No outlets, so the water just pools and infiltrates the surrounding properties. You own this little piece of the world, owned it for a few generations, bought it off of the old landlords when they were selling mineral rights and then decided to get rid of the rest too. They went up north. A reverse carpet-bagging situation. You don't have much. You have a house on another piece of property, quite aways up the road, and this shack, and this sinkhole. You actually are quite the property owner, but it ain't worth shit. That's what erryone tell you anyhow. The old big house been turned into an old folks home a decaded ago, shame, it's a piece of shit like your property now - least that's what everyone say. Pope's on TV, old fan from the 50s still working, You could get a flat screen but the power supplies can't handle the brown outs here, old TV still works fine, you use it like a radio anyway. Guy comes into your fish shack. You ain't never seen him in your life, you tell yourself. You know him however, he lives somewhat close, comes in from time to time, looks around, he in a suit, he never buys from you anything, he has a reputation, suits getting dusty, the pinstripes are wider than that which the people on TV wear. He comes up to you. You're playing with a knife of yours, spinning it on it's tip. It's a fish skinning knife with a gutting hook on the back. It is quite a large one. The blade is a full 15 inches, thick, you could work on the sand sharks with this, if you ever took the hour and ahalf drive down to the beach. You have a sign on your counter: "We's generous". Sometimes people ask you what that means. The man in the suit approaches you: first time for everthing. S: "Ay, I'd like that knife" You tell him it isn't for sale. S: "I ain neva said I thoughts it was, whass 'Wes generous' mean anyhow" You tell him that you will lend him the knife if he wishes. S: "Aight" He takes possession of the knife. He's a fisher he says. The man in the striped suit leaves. Months go by. You see the man sometimes, he tells you how the knife you licensed to him is getting great use, he fishes alot you see. He then inquires about that murky seemingly bottomless sinkhole out back. He wishes to be-able to dump some fishing refuse in it. S: "We's generous, right?" You grant him license to travel over your land to the sinkhole and dump the fishing refuse into the sinkhole. Time passes. You notice your knife has become more resplendent. Each time the stripped suited man, this fisher, catches a fish, it seems, he is in the habit of tacking a red five pointed star from Russia onto the handle. Each time the man comes into your shack you notice that there are more and more red stars, additionally, between the stars is now a dark red lacquer. It looks quite stunning, a battle worn cleaver; shouting it's victory against countless ensnared aquatic beings. Time, again, passes. Two police officers show up. Not the state troopers who sometimes come by the shop, no these are from one of the towns. P1: "You sell guttin knives here" You respond in the affirmative. P1: "You ever sold a rather large red gutting knife, tack handled" He seems to be getting agitated. You say no, but you have licensed a fisher to use a knife you own, and while it was not originally tack-handled, nor red, now it would indeed match such a description. P1: "You fking piece of shit, you get us back that knife or you are going down as an accomplice, you understand that you coal bla.." The second police man interrupts him. They start to head out. The second police man informs you that they will be by the store three days from now, as well as one week from now. To please reassert possession of the knife in that time. A month goes by and they do not come. Three months later you are arrested and interrogated in the harshest possible terms. You wonder if you can father children anymore. You are informed that the prosecutor has agreed to prosecute you as an accomplice, however if you come into possession of the knife, they may reconsider. Soon thereafter the suited man appears in your store. You tell him that you are ending the license you had extended to him, regarding both the knife and the permission to dump in the sinkhole. He contends that the knife is irrevocable: He relys upon the knife to execute his job of fishing. Furthermore he has put tacks in the knife, and if he were to return the knife to you his tack work would go to waste from his point of view. Additionally he tells you that he also relys on your extended license to dump the
[PATCH v2] usb: devio: update max count of DPs per interval for ISOC
The failure happened when I tried to send up to 96DPs per an interval
for SSP ISOC transations by libusb, this is used to verify SSP ISOC
function of USB3 GEN2 controller, so update it as 96DPs.
(refer usb3.1r1.0 section 8.12.6 Isochronous Transactions)
Signed-off-by: Chunfeng Yun
---
v2: update changelog text suggested by Greg
---
drivers/usb/core/devio.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index a75bc0b8a50f..82c16210e34c 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1564,12 +1564,10 @@ static int proc_do_submiturb(struct usb_dev_state *ps,
struct usbdevfs_urb *uurb
}
for (totlen = u = 0; u < number_of_packets; u++) {
/*
-* arbitrary limit need for USB 3.0
-* bMaxBurst (0~15 allowed, 1~16 packets)
-* bmAttributes (bit 1:0, mult 0~2, 1~3 packets)
-* sizemax: 1024 * 16 * 3 = 49152
+* arbitrary limit need for USB 3.1 Gen2
+* sizemax: 96 DPs at SSP, 96 * 1024 = 98304
*/
- if (isopkt[u].length > 49152) {
+ if (isopkt[u].length > 98304) {
ret = -EINVAL;
goto error;
}
--
2.19.1
linux-next: manual merge of the vfs tree with Linus' tree
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
kernel/cgroup/cgroup-v1.c
between commit:
3fc9c12d27b4 ("cgroup: Add named hierarchy disabling to cgroup_no_v1 boot
param")
from Linus' tree and commit:
b3678086951a ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
from the vfs tree.
Its a pity that the former commit did not appear until after the merge
window opened. :-(
I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/cgroup/cgroup-v1.c
index 583b969b0c0e,4b189e821cad..
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@@ -1003,17 -968,91 +971,94 @@@ int cgroup1_parse_param(struct fs_conte
continue;
/* Mutually exclusive option 'all' + subsystem name */
- if (all_ss)
- return -EINVAL;
- opts->subsys_mask |= (1 << i);
- one_ss = true;
+ if (ctx->all_ss)
+ return cg_invalf(fc, "cgroup1: subsys name
conflicts with all");
+ ctx->subsys_mask |= (1 << i);
+ ctx->one_ss = true;
+ return 0;
+ }
- break;
+ return cg_invalf(fc, "cgroup1: Unknown subsys name '%s'",
param->key);
+ }
+ if (opt < 0)
+ return opt;
+
+ switch (opt) {
+ case Opt_none:
+ /* Explicitly have no subsystems */
+ ctx->none = true;
+ return 0;
+ case Opt_all:
+ /* Mutually exclusive option 'all' + subsystem name */
+ if (ctx->one_ss)
+ return cg_invalf(fc, "cgroup1: all conflicts with
subsys name");
+ ctx->all_ss = true;
+ return 0;
+ case Opt_noprefix:
+ ctx->flags |= CGRP_ROOT_NOPREFIX;
+ return 0;
+ case Opt_clone_children:
+ ctx->cpuset_clone_children = true;
+ return 0;
+ case Opt_cpuset_v2_mode:
+ ctx->flags |= CGRP_ROOT_CPUSET_V2_MODE;
+ return 0;
+ case Opt_xattr:
+ ctx->flags |= CGRP_ROOT_XATTR;
+ return 0;
+ case Opt_release_agent:
+ /* Specifying two release agents is forbidden */
+ if (ctx->release_agent)
+ return cg_invalf(fc, "cgroup1: release_agent
respecified");
+ ctx->release_agent = param->string;
+ param->string = NULL;
+ if (!ctx->release_agent)
+ return -ENOMEM;
+ return 0;
+
+ case Opt_name:
++ /* blocked by boot param? */
++ if (cgroup_no_v1_named)
++ return cg_invalf(fc, "cgroup1: Blocked by boot
paramter");
+ /* Can't specify an empty name */
+ if (!param->size)
+ return cg_invalf(fc, "cgroup1: Empty name");
+ if (param->size > MAX_CGROUP_ROOT_NAMELEN - 1)
+ return cg_invalf(fc, "cgroup1: Name too long");
+ /* Must match [\w.-]+ */
+ for (i = 0; i < param->size; i++) {
+ char c = param->string[i];
+ if (isalnum(c))
+ continue;
+ if ((c == '.') || (c == '-') || (c == '_'))
+ continue;
+ return cg_invalf(fc, "cgroup1: Invalid name");
}
- if (i == CGROUP_SUBSYS_COUNT)
- return -ENOENT;
+ /* Specifying two names is forbidden */
+ if (ctx->name)
+ return cg_invalf(fc, "cgroup1: name respecified");
+ ctx->name = param->string;
+ param->string = NULL;
+ return 0;
}
+ return 0;
+ }
+
+ /*
+ * Validate the options that have been parsed.
+ */
+ static int cgroup1_validate(struct fs_context *fc)
+ {
+ struct cgroup_fs_context *ctx = cgroup_fc2context(fc);
+ struct cgroup_subsys *ss;
+ u16 mask = U16_MAX;
+ int i;
+
+ #ifdef CONFIG_CPUSETS
+ mask = ~((u16)1 << cpuset_cgrp_id);
+ #endif
+
/*
* If the 'all' option was specified select all the subsystems,
* otherwise if 'none', 'name=' and a subsystem name options were
pgplYLUup5Xjv.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 0/2] Add Stratix10 PCIe Root Port support
On Mon, 2018-12-31 at 10:15 -0600, Bjorn Helgaas wrote: > On Mon, Dec 31, 2018 at 04:24:51PM +0800, Ley Foon Tan wrote: > > > > Add PCIe Root Port support for Stratix10 device and also update > "Stratix10" is a big step better than "StratixXX" because a web > search > for the latter finds nothing, while the former does find useful > things. > > Intel materials on the web seem to use "Stratix 10". You might as > well include the space in English text. Okay, will change to Stratix 10. Regards Ley Foon
Re: [v6] PCI: imx: make msi work without CONFIG_PCIEPORTBUS=y
On Fri, Dec 21, 2018 at 04:33:38AM +, Richard Zhu wrote:
> The MSI Enable bit in the MSI Capability (PCIe r4.0, sec 7.7.1.2)
> controls whether a Function can request service using MSI.
>
> i.MX6 Root Ports implement the MSI Capability and may use MSI to
> request service for events like PME, hotplug, AER, etc. In
> addition, on i.MX6, the MSI Enable bit controls delivery of MSI
> interrupts from components below the Root Port.
>
> Prior to commit f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection
> of CONFIG_PCIEPORTBUS"), enabling CONFIG_PCI_IMX6 automatically also
> enabled CONFIG_PCIEPORTBUS, and when portdrv claimed the Root Ports,
> it set the MSI Enable bit so it could use PME, hotplug, AER, etc.
> As a side effect, that also enabled delivery of MSI interrupts from
> downstream components.
>
> After f3fdfc4ac3a2, the imx6q-pcie driver can operate without
> portdrv, but that means imx6q-pcie must set the MSI Enable bit
> itself if downstream components use MSI.
>
> Fixes: f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
> CONFIG_PCIEPORTBUS")
>
> Signed-off-by: Richard Zhu
> Reviewed-by: Lucas Stach
> Tested-by: Sven Van Asbroeck
> Acked-by: Lorenzo Pieralisi
Applied with Trent's tested-by to pci/imx6 for v4.21.
> ---
> Changes v1 -> v2:
> * Assert the MSI_EN unconditionally when MSI is supported.
> Changes v2 -> v3:
> * Remove the IS_ENABLED(CONFIG_PCI_MSI) since the driver depends on
> PCI_MSI_IRQ_DOMAIN
> * Extended with a check for pci_msi_enabled() to see if the user
> explicitly want legacy IRQs
> Changes v3 -> v4:
> * Refer to Bjorn's comments, refine the subject and commit log and change
> the PCI_MSI_CAP to PCIE_RC_IMX6_MSI_CAP.
> Changes v4 -> v5:
> * Correct one spell mistake from PCIE_RC_MSI_IMX6_CAP to
> PCIE_RC_IMX6_MSI_CAP.
> Changes v5 -> v6:
> * Update with Bjorn's commit.
> * One "commit" added in "Prior to f3fdfc4ac3a2" refer to the complain of
> checkpatch.pl.
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> b/drivers/pci/controller/dwc/pci-imx6.c
> index e563ca9..73542dd 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -82,6 +82,7 @@ struct imx6_pcie {
> #define PHY_PLL_LOCK_WAIT_USLEEP_MAX 200
>
> /* PCIe Root Complex registers (memory-mapped) */
> +#define PCIE_RC_IMX6_MSI_CAP 0x50
> #define PCIE_RC_LCR 0x7c
> #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN1 0x1
> #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN2 0x2
> @@ -999,6 +1000,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> struct resource *dbi_base;
> struct device_node *node = dev->of_node;
> int ret;
> + u16 val;
>
> imx6_pcie = devm_kzalloc(dev, sizeof(*imx6_pcie), GFP_KERNEL);
> if (!imx6_pcie)
> @@ -1149,6 +1151,14 @@ static int imx6_pcie_probe(struct platform_device
> *pdev)
> if (ret < 0)
> return ret;
>
> + if (pci_msi_enabled()) {
> + val = dw_pcie_readw_dbi(pci, PCIE_RC_IMX6_MSI_CAP +
> + PCI_MSI_FLAGS);
> + val |= PCI_MSI_FLAGS_ENABLE;
> + dw_pcie_writew_dbi(pci, PCIE_RC_IMX6_MSI_CAP +
> + PCI_MSI_FLAGS, val);
> + }
> +
> return 0;
> }
>
> --
> 2.7.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
linux-next: manual merge of the vfs tree with Linus' tree
Hi Al,
Today's linux-next merge of the vfs tree got conflicts in:
kernel/cgroup/cgroup.c
between commit:
e250d91d6575 ("cgroup: fix parsing empty mount option string")
from Linus' tree and commit:
b3678086951a ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
from the vfs tree.
I fixed it up (I just used the vfs version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpB4dRZNLTOz.pgp
Description: OpenPGP digital signature
Re: [PATCH] x86/retpoline: change RETPOLINE into CONFIG_RETPOLINE
On 2019/1/1 7:42, Nadav Amit wrote:
A recent enhancement intentionally fails the kernel build if the
compiler does not support retpolines and CONFIG_RETPOLINE is set.
However, the patch that introduced it did not change RETPOLINE macro
references into CONFIG_RETPOLINE ones. As a result, indirect branches
that are used by init functions are not kept (i.e., they use
retpolines), and modules that do not use retpolines are marked as
retpoline-safe.
Fix it be changing RETPOLINE into CONFIG_RETPOLINE.
Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler
support")
Cc: Peter Zijlstra
Cc: Zhenzhong Duan
Cc: Thomas Gleixner
Cc: David Woodhouse
Cc: Andy Lutomirski
Cc: Masahiro Yamada
Cc: sta...@vger.kernel.org
Signed-off-by: Nadav Amit
---
arch/x86/kernel/cpu/bugs.c | 2 +-
include/linux/compiler-gcc.h | 2 +-
include/linux/module.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 8654b8b0c848..1de0f4170178 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -215,7 +215,7 @@ static enum spectre_v2_mitigation spectre_v2_enabled
__ro_after_init =
static enum spectre_v2_user_mitigation spectre_v2_user __ro_after_init =
SPECTRE_V2_USER_NONE;
-#ifdef RETPOLINE
+#ifdef CONFIG_RETPOLINE
static bool spectre_v2_bad_module;
bool retpoline_module_ok(bool has_retpoline)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 2010493e1040..977ddf2774f9 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -68,7 +68,7 @@
*/
#define uninitialized_var(x) x = x
-#ifdef RETPOLINE
+#ifdef CONFIG_RETPOLINE
#define __noretpoline __attribute__((__indirect_branch__("keep")))
#endif
diff --git a/include/linux/module.h b/include/linux/module.h
index fce6b4335e36..0c575f51fe57 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -817,7 +817,7 @@ static inline void module_bug_finalize(const Elf_Ehdr *hdr,
static inline void module_bug_cleanup(struct module *mod) {}
#endif/* CONFIG_GENERIC_BUG */
-#ifdef RETPOLINE
+#ifdef CONFIG_RETPOLINE
extern bool retpoline_module_ok(bool has_retpoline);
#else
static inline bool retpoline_module_ok(bool has_retpoline)
Someone sent a similar patch last month, see below link, you missed the
change in scripts/mod/modpost.c
https://lkml.org/lkml/2018/12/10/540
But you patch description is more clear.
--
Thanks
Zhenzhong
[LKP] bea5b158ff BUG: kernel reboot-without-warning in boot-around-mounting-root stage
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit bea5b158ff0da9c7246ff391f754f5f38e34577a Author: Rob Herring AuthorDate: Thu Aug 11 10:20:58 2016 -0500 Commit: Greg Kroah-Hartman CommitDate: Wed Aug 31 15:13:55 2016 +0200 driver core: add test of driver remove calls during probe In recent discussions on ksummit-discuss[1], it was suggested to do a sequence of probe, remove, probe for testing driver remove paths. This adds a kconfig option for said test. [1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html Suggested-by: Arnd Bergmann Cc: Greg Kroah-Hartman Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman cebf8fd169 driver core: fix race between creating/querying glue dir and its cleanup bea5b158ff driver core: add test of driver remove calls during probe e1ef035d27 Merge tag 'armsoc-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc 6a1d293238 Add linux-next specific files for 20181224 +--++++---+ | | cebf8fd169 | bea5b158ff | e1ef035d27 | next-20181224 | +--++++---+ | boot_successes | 31 | 0 | 0 | 0 | | boot_failures| 0 | 11 | 11 | 7 | | BUG:kernel_reboot-without-warning_in_boot-around-mounting-root_stage | 0 | 11 | 11 | 7 | +--++++---+ [ 14.073515] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 14.095297] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 14.177113] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A [ 14.256672] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A [ 14.278578] console [ttyS0] disabled BUG: kernel reboot-without-warning in boot-around-mounting-root stage # HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD git bisect start v4.9 v4.8 -- git bisect bad 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942 # 15:38 B 0 11 26 0 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 git bisect bad 5fa0eb0b4d4780fbd6d8a09850cc4fd539e9fe65 # 16:43 B 0 1 16 0 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad d8ea757b25ec82687c497fc90aa83f9bcea24b5b # 17:22 B 0 2 17 0 Merge tag 'xtensa-20161005' of git://github.com/jcmvbkbc/linux-xtensa git bisect bad e6445f52d9c8b0e6557a45fa7d0e8e088d430a8c # 18:03 B 0 1 16 0 Merge tag 'usb-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb git bisect good 1a4a2bc460721bc8f91e4c1294d39b38e5af132f # 18:29 G 11 00 0 Merge branch 'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good 49deffe0b0e4c2030696c7a6fd680bacf4761069 # 18:48 G 10 00 0 Merge tag 'arc-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc git bisect good 597f03f9d133e9837d00965016170271d4f87dcf # 19:03 G 10 00 0 Merge branch 'smp-hotplug-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad 9929780e86854833e649b39b290b5fe921eb1701 # 19:22 B 0 10 25 0 Merge tag 'driver-core-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core git bisect good 7a53eea1f7b527fd3b6d7ca992914840981afe99 # 20:11 G 10 00 0 Merge tag 'char-misc-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc git bisect bad 775115c06091fcfa1189a50aca488fa596839617 # 20:36 B 0 4 19 0 drivers/base dmam_declare_coherent_memory leaks git bisect bad 426bc8e789f8ac84270b196191904d347586032f # 20:59 B 0 3 18 0 base: soc: make it explicitly non-modular git bisect bad bea5b158ff0da9c7246ff391f754f5f38e34577a # 21:32 B 0 6 21 0 driver core: add test of driver remove calls during probe git bisect good cebf8fd16900fdfd58c0028617944f808f97fe50 # 21:56 G 11 00 0 driver core: fix race between creating/querying glue dir and its cleanup # first bad commit: [bea5b158ff0da9c7246ff391f754f5f38e34577a] driver core: add test of driver remove calls during
arch/sh/kernel/dwarf.c:1209:0: error: unterminated argument list invoking macro "WARN_ON"
Hi Steven, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 8e143b90e4d45cca3dc53760d3cfab988bc74571 commit: cec8d0e7f06e08b981e9d61bef267c8c36d536f5 sh: ftrace: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack date: 11 days ago config: sh-allmodconfig (attached as .config) compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout cec8d0e7f06e08b981e9d61bef267c8c36d536f5 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=sh All errors (new ones prefixed by >>): arch/sh/kernel/dwarf.c: In function 'dwarf_unwind_stack': >> arch/sh/kernel/dwarf.c:1209:0: error: unterminated argument list invoking >> macro "WARN_ON" early_initcall(dwarf_unwinder_init); >> arch/sh/kernel/dwarf.c:622:3: error: 'WARN_ON' undeclared (first use in this >> function); did you mean 'WMARK_LOW'? WARN_ON(ftrace_graph_get_ret_stack(current, 1); ^~~ WMARK_LOW arch/sh/kernel/dwarf.c:622:3: note: each undeclared identifier is reported only once for each function it appears in >> arch/sh/kernel/dwarf.c:622:3: error: expected ';' at end of input >> arch/sh/kernel/dwarf.c:622:3: error: expected declaration or statement at >> end of input >> arch/sh/kernel/dwarf.c:622:3: error: expected declaration or statement at >> end of input >> arch/sh/kernel/dwarf.c:584:16: error: unused variable 'addr' >> [-Werror=unused-variable] unsigned long addr; ^~~~ >> arch/sh/kernel/dwarf.c:583:20: error: unused variable 'reg' >> [-Werror=unused-variable] struct dwarf_reg *reg; ^~~ >> arch/sh/kernel/dwarf.c:582:20: error: unused variable 'fde' >> [-Werror=unused-variable] struct dwarf_fde *fde; ^~~ >> arch/sh/kernel/dwarf.c:581:20: error: unused variable 'cie' >> [-Werror=unused-variable] struct dwarf_cie *cie; ^~~ >> arch/sh/kernel/dwarf.c:580:22: error: unused variable 'frame' >> [-Werror=unused-variable] struct dwarf_frame *frame; ^ arch/sh/kernel/dwarf.c:622:3: error: control reaches end of non-void function [-Werror=return-type] WARN_ON(ftrace_graph_get_ret_stack(current, 1); ^~~ At top level: >> arch/sh/kernel/dwarf.c:399:12: error: 'dwarf_cfa_execute_insns' defined but >> not used [-Werror=unused-function] static int dwarf_cfa_execute_insns(unsigned char *insn_start, ^~~ >> arch/sh/kernel/dwarf.c:306:26: error: 'dwarf_lookup_cie' defined but not >> used [-Werror=unused-function] static struct dwarf_cie *dwarf_lookup_cie(unsigned long cie_ptr) ^~~~ >> arch/sh/kernel/dwarf.c:226:12: error: 'dwarf_read_encoded_value' defined but >> not used [-Werror=unused-function] static int dwarf_read_encoded_value(char *addr, unsigned long *val, ^~~~ >> arch/sh/kernel/dwarf.c:107:26: error: 'dwarf_frame_reg' defined but not used >> [-Werror=unused-function] static struct dwarf_reg *dwarf_frame_reg(struct dwarf_frame *frame, ^~~ >> arch/sh/kernel/dwarf.c:41:27: error: 'dwarf_reg_cachep' defined but not used >> [-Werror=unused-variable] static struct kmem_cache *dwarf_reg_cachep; ^~~~ >> arch/sh/kernel/dwarf.c:38:27: error: 'dwarf_frame_cachep' defined but not >> used [-Werror=unused-variable] static struct kmem_cache *dwarf_frame_cachep; ^~ cc1: all warnings being treated as errors vim +/WARN_ON +1209 arch/sh/kernel/dwarf.c a6a2f2ad Matt Fleming 2009-10-09 1160 a6a2f2ad Matt Fleming 2009-10-09 1161 /** a6a2f2ad Matt Fleming 2009-10-09 1162 * dwarf_unwinder_init - initialise the dwarf unwinder a6a2f2ad Matt Fleming 2009-10-09 1163 * a6a2f2ad Matt Fleming 2009-10-09 1164 *Build the data structures describing the .dwarf_frame section to a6a2f2ad Matt Fleming 2009-10-09 1165 *make it easier to lookup CIE and FDE entries. Because the a6a2f2ad Matt Fleming 2009-10-09 1166 *.eh_frame section is packed as tightly as possible it is not a6a2f2ad Matt Fleming 2009-10-09 1167 *easy to lookup the FDE for a given PC, so we build a list of FDE a6a2f2ad Matt Fleming 2009-10-09 1168 *and CIE entries that make it easier. a6a2f2ad Matt Fleming 2009-10-09 1169 */ a6a2f2ad Matt Fleming 2009-10-09 1170 static int __init dwarf_unwinder_init(void) a6a2f2ad
linux-next: manual merge of the vfs tree with the ext3 tree
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/Makefile
between commit:
d44170a7ba48 ("fs: common implementation of file type")
from the ext3 tree and commits:
fe43eec04841 ("vfs: Introduce fs_context, switch vfs_kern_mount() to it.")
82685adaccb3 ("vfs: Add configuration parser helpers")
from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/Makefile
index da0d43eb2bc5,9a0b8003f069..
--- a/fs/Makefile
+++ b/fs/Makefile
@@@ -13,7 -13,7 +13,7 @@@ obj-y := open.o read_write.o file_table
seq_file.o xattr.o libfs.o fs-writeback.o \
pnode.o splice.o sync.o utimes.o d_path.o \
stack.o fs_struct.o statfs.o fs_pin.o nsfs.o \
- fs_types.o
- fs_context.o fs_parser.o
++ fs_types.o fs_context.o fs_parser.o
ifeq ($(CONFIG_BLOCK),y)
obj-y += buffer.o block_dev.o direct-io.o mpage.o
pgpzTRaMUYj_k.pgp
Description: OpenPGP digital signature
Re: How to force RC to forward p2p TLPs
Hi Yu As I understand it you are asking about the case where the two PCIe End Points (EPs) are connected below the same PCIe switch that is connected via it's Upstream Port (UPS) to a Root Port (RP) that is part of a Root Complex (RC). Do I understand this correctly? The ECR Eric mentioned aims to implement a platform neutral method for determining if P2P *between* RPs is viable in a system. However I think that is a bit different to your case (since your EPs are connected to the same RP via a PCIe switch). What I *think* should be happening in your case when ACS is enabled is the the TLPs should be routed to the RP and from there to some translation agent (often an IOMMU). If the IOMMU has an entry for the addresses in the TLPs then it should attempt to do a translation and forward on the TLP. If the IOMMU does not have a translation (or does not exist) then the behaviour is probably ill-defined and very specific to the platform you are working on. If the IOMMU does exist and does have a translation entry it still may not support routing the TLP back to the PCI hierarchy. This again would be platform specific. I guess what I am saying is the same as Logan and Eric. Once TLPs leave the PCIe Root Port and enter the system (CPU or SOC) you leave the world of the PCI/PCIe specification and the behaviour of those TLPs will be dependant on the specifics of your platform. Do note that if your platform and your EPs supports ATS then I think the behaviour can be different again because then the P2P TLPs should be able to use a translated address and you can setup ACS to allow for translated addresses. However we have not had access to any ATS enabled systems to work on this aspect of p2pdma yet. It's on the roadmap. Cheers Stephen From: Eric Wehage Sent: December 31, 2018 11:20 PM To: Bjorn Helgaas; yu Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Logan Gunthorpe; Stephen Bates; Jonathan Cameron; Alexander Duyck Subject: RE: How to force RC to forward p2p TLPs There is no method to force an RC to forward requests p2p. RC's are also not required to support p2p and whether they do or not is implementation specific. There is also currently no PCIe based standard to determine whether an RC supports p2p or in what capacity. Also, even if p2p is supported, it might not be supported in a system that enables Virtualization (the Virtualization would have to setup p2p tables to allow it). There is currently a PCIe ECR that has been submitted, but is undergoing review, that defines a PCIe capability for bridge devices (Root Ports and Switch Downstream Ports) that would allow them to advertise what level of p2p is supported by the device. Eric Wehage Huawei Principal Engineer, PCIe -Original Message- From: Bjorn Helgaas [mailto:helg...@kernel.org] Sent: Friday, December 28, 2018 6:29 PM To: yu Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Logan Gunthorpe ; Stephen Bates ; Jonathan Cameron ; Eric Wehage ; Alexander Duyck Subject: Re: How to force RC to forward p2p TLPs [+cc Logan, Stephen, Jonathan, Eric, Alex] On Sat, Dec 22, 2018 at 12:50:19PM +0800, yu wrote: > Hi all, > > We have a PCIE card which has a PEX8732 switch on-board, and there > are two endpoint SOCs like graphic decoder behind the switch, and by > default the ACS is enabled in 8732. > > We use the p2p DMA to transfer data between these two endpoint SOCs, > and if the host server is not enable ACS in BIOS, the p2p works well, > but when ACS is enabled in BIOS, the p2p is always failed. With the > help of a protocol analyzer, we can see that the TLP is redirected to > RC, and RC just discard it. > > I tried to find how to make RC forward redirected TLP to its original > target, but nothing found, it seems this is highly related to the RC > vendors. > > In the PCIE 4.0 spec, the section of the RC behavior of the p2p > request redirect said that ''implementation-specific logic within the > RC that determines whether the request is directed towards its > original target, or blocked as an ACS Violation error. the algorithms > and specific controls for making this determination are not > architected by this spec''. > > > So is there some spec or document to describe how to set the RC? Any > suggestion is appreciated. Not that I'm aware of, but the folks I cc'd would know a lot more about this area. Bjorn
Re: [PATCH] Revert "staging:r8188eu: use lib80211 CCMP decrypt"
On 1/1/19 1:31 PM, Michael Straube wrote: I've tested your patch and it solved the issue. No freezes and dmesg looks good. I noticed that try_then_request_module() is also used in rtw_wep_encrypt() and rtw_wep_decrypt(). I guess that also could cause problems? Yes, I believe it would if anyone is still using WEP. My plan is to get rid of the try_then_request_module() there as well, and for completeness, I plan to restore usage of the lib80211 routines for TKIP as well. Once I get a chance to test the TKIP and WEP changes, I plan to have a set of 4 patches to switch the driver to using lib80211 routines for all decryption/encryption. Larry
[RFC v2 2/2] pstore/rom: add sample for pstore_rom
It is a sample for pstore_rom, using general ram rather than block device.
According to pstore_rom, the data will be saved to ram buffer if not
register device path and apis for panic. So, it can only used to dump
Oops and some things will not reboot.
Signed-off-by: liaoweixiong
---
fs/pstore/Kconfig | 9 +
fs/pstore/Makefile | 2 ++
fs/pstore/rombuf.c | 46 ++
3 files changed, 57 insertions(+)
create mode 100644 fs/pstore/rombuf.c
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index abf0453..426b5ea 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -159,3 +159,12 @@ config PSTORE_ROM
help
This enables panic and oops message to be logged to a block dev
where it can be read back at some later point.
+
+config PSTORE_ROMBUF
+ tristate "romoop buffer sample"
+ depends on PSTORE_ROM
+ help
+ This is a sample for pstore rom, but do NOT have a block dev.
+ According to pstore_rom, the data will be saved to ram buffer and
+ dropped when reboot. So, it can only used to dump Oops and some
+ things will not reboot.
diff --git a/fs/pstore/Makefile b/fs/pstore/Makefile
index ea38d6e..21c1226 100644
--- a/fs/pstore/Makefile
+++ b/fs/pstore/Makefile
@@ -15,3 +15,5 @@ obj-$(CONFIG_PSTORE_RAM) += ramoops.o
obj-$(CONFIG_PSTORE_ROM) += romoops.o
romoops-y += romzone.o
+
+obj-$(CONFIG_PSTORE_ROMBUF)+= rombuf.o
diff --git a/fs/pstore/rombuf.c b/fs/pstore/rombuf.c
new file mode 100644
index 000..bb21a85
--- /dev/null
+++ b/fs/pstore/rombuf.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * rombuf.c: ROM Oops/Panic logger
+ *
+ * Copyright (C) 2019 liaoweixiong
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#define pr_fmt(fmt) "rombuf: " fmt
+
+#include
+#include
+#include
+
+struct romz_info rombuf_info = {
+ .owner = THIS_MODULE,
+ .name = "rombuf",
+ .part_size = 512 * 1024,
+ .dmesg_size = 64 * 1024,
+ .dump_oops = true,
+};
+
+static int __init rombuf_init(void)
+{
+ return romz_register(_info);
+}
+module_init(rombuf_init);
+
+static void __exit rombuf_exit(void)
+{
+ romz_unregister(_info);
+}
+module_exit(rombuf_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("liaoweixiong ");
+MODULE_DESCRIPTION("Sample for Pstore ROM with Oops logger");
--
1.9.1
Re: kmemleak: Cannot allocate a kmemleak_object structure - Kernel 4.19.13
It was unrelated to my USB issue. It happened again after I rebooted within 4 hours of uptime. This time there were 2 traces, one right after the other and included another line number. * Jan 01 17:47:54 computername plasmashell[1048]: qt.qpa.xcb: QXcbConnection: XCB error: 2 (BadValue), sequence: 45625, resource id: 69206018, major code: 142 (Unknown), minor code: 3 Jan 01 17:50:14 computername kernel: WARNING: CPU: 3 PID: 2154 at mm/page_alloc.c:4262 __alloc_pages_nodemask+0xf74/0xfb0 Jan 01 17:50:15 computername kernel: Modules linked in: rfcomm ccm bnep nct6775 hwmon_vid nls_iso8859_1 nls_cp437 vfat fat tda18271 au8522_dig au8522_common au0828 tveeprom dvb_core arc4 v4l2_common intel_rapl snd_soc_rt5640 iTCO_wdt rtl8821ae x86_pkg_temp_thermal btcoexist i> Jan 01 17:50:16 computername kernel: soundcore mei_me lpc_ich mei crypto_user ip_tables x_tables serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 serpent_generic xts algif_skcipher af_alg uas usb_storage dm_crypt dm_mod sr_mod cdrom sd_mod hid_logitech_hidpp hid_logitech_> Jan 01 17:50:16 computername kernel: CPU: 3 PID: 2154 Comm: PeripBusCEC Not tainted 4.19.13-dirty #2 Jan 01 17:50:16 computername kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H97M-ITX/ac, BIOS P1.80 07/27/2015 Jan 01 17:50:16 computername kernel: RIP: 0010:__alloc_pages_nodemask+0xf74/0xfb0 Jan 01 17:50:16 computername kernel: Code: ff 0f 0b e9 dc fc ff ff 0f 0b 48 8b b4 24 80 00 00 00 8b 7c 24 18 44 89 f1 48 c7 c2 40 9e 4a b6 e8 91 ef ff ff e9 d3 f1 ff ff <0f> 0b e9 a9 fc ff ff e8 c0 7f ea ff 85 d2 0f 85 15 fd ff ff 48 c7 Jan 01 17:50:16 computername kernel: RSP: 0018:999e032731e0 EFLAGS: 00010202 Jan 01 17:50:16 computername kernel: RAX: 8bbcbabc0040 RBX: 0040 RCX: 0020 Jan 01 17:50:16 computername kernel: RDX: RSI: 0002 RDI: 8bbd9fdfc000 Jan 01 17:50:16 computername kernel: RBP: 0020 R08: 0040 R09: 0f82 Jan 01 17:50:16 computername kernel: R10: 0020 R11: R12: Jan 01 17:50:16 computername kernel: R13: R14: R15: Jan 01 17:50:16 computername kernel: FS: 7f9515642700() GS:8bbd9818() knlGS: Jan 01 17:50:16 computername kernel: CS: 0010 DS: ES: CR0: 80050033 Jan 01 17:50:16 computername kernel: CR2: 7fdbd95b1000 CR3: 00011087c003 CR4: 001626e0 Jan 01 17:50:16 computername kernel: Call Trace: Jan 01 17:50:16 computername kernel: ? ___slab_alloc+0x43f/0x630 Jan 01 17:50:16 computername kernel: ? orc_find+0x108/0x190 Jan 01 17:50:16 computername kernel: ? kmem_cache_alloc+0x1c5/0x210 Jan 01 17:50:16 computername kernel: ? unwind_next_frame+0x2f8/0x460 Jan 01 17:50:16 computername kernel: new_slab+0x2fb/0x6f0 Jan 01 17:50:16 computername kernel: ? _raw_spin_unlock+0x16/0x30 Jan 01 17:50:16 computername kernel: ? deactivate_slab.isra.27+0x5b4/0x690 Jan 01 17:50:16 computername kernel: ___slab_alloc+0x43f/0x630 Jan 01 17:50:16 computername kernel: ? alloc_extent_state+0x1f/0xd0 [btrfs] Jan 01 17:50:16 computername kernel: ? create_object+0x43/0x2a0 Jan 01 17:50:16 computername kernel: ? ___slab_alloc+0x58d/0x630 Jan 01 17:50:16 computername kernel: ? create_object+0x43/0x2a0 Jan 01 17:50:16 computername kernel: __slab_alloc.isra.28+0x52/0x70 Jan 01 17:50:16 computername kernel: ? create_object+0x43/0x2a0 Jan 01 17:50:16 computername kernel: kmem_cache_alloc+0x1c5/0x210 Jan 01 17:50:16 computername kernel: ? alloc_extent_state+0x1f/0xd0 [btrfs] Jan 01 17:50:16 computername kernel: create_object+0x43/0x2a0 Jan 01 17:50:16 computername kernel: ? alloc_extent_state+0x1f/0xd0 [btrfs] Jan 01 17:50:16 computername kernel: kmem_cache_alloc+0x1a6/0x210 Jan 01 17:50:16 computername kernel: alloc_extent_state+0x1f/0xd0 [btrfs] Jan 01 17:50:16 computername kernel: __clear_extent_bit+0x297/0x390 [btrfs] Jan 01 17:50:16 computername kernel: ? _raw_spin_unlock+0x16/0x30 Jan 01 17:50:16 computername kernel: try_release_extent_mapping+0x1b4/0x220 [btrfs] Jan 01 17:50:16 computername kernel: btrfs_releasepage+0x45/0x60 [btrfs] Jan 01 17:50:16 computername kernel: shrink_page_list+0xb20/0xc80 Jan 01 17:50:16 computername kernel: shrink_inactive_list+0x29f/0x6b0 Jan 01 17:50:16 computername kernel: shrink_node_memcg+0x20f/0x780 Jan 01 17:50:16 computername kernel: shrink_node+0xcf/0x4a0 Jan 01 17:50:16 computername kernel: do_try_to_free_pages+0xc6/0x370 Jan 01 17:50:16 computername kernel: try_to_free_pages+0xca/0x1e0 Jan 01 17:50:16 computername kernel: __alloc_pages_nodemask+0x616/0xfb0 Jan 01 17:50:16 computername kernel: ? __kernel_text_address+0xe/0x30 Jan 01 17:50:16 computername kernel: ? unwind_get_return_address+0x1b/0x30 Jan 01 17:50:16 computername kernel: ? __save_stack_trace+0x92/0x100 Jan 01 17:50:16 computername kernel: new_slab+0x2fb/0x6f0 Jan 01 17:50:16
[RFC v2 0/2] pstore/rom: new support logger for block devices
Why should we need pstore_rom? 1. Most embedded intelligent equipment have no persistent ram, which increases costs. We perfer to cheaper solutions, like block devices. In fast, there is already a sample for block device logger in driver MTD (drivers/mtd/mtdoops.c). 2. Do not any equipment have battery, which means that it lost all data on general ram if power failure. Pstore has little to do for these equipments. [PATCH v1] On patch 1: Core codes of pstore_rom, which works well on allwinner(sunxi) platform. On patch 2: A sample for pstore_rom, using general ram rather than block device. [PATCH v2] On patch 1: Fix build as module error for redefinition of 'romz_unregister' and 'romz_register' liaoweixiong (2): pstore/rom: new support logger for block devices pstore/rom: add sample for pstore_rom fs/pstore/Kconfig | 16 + fs/pstore/Makefile | 5 + fs/pstore/rombuf.c | 46 +++ fs/pstore/romzone.c| 965 + include/linux/pstore_rom.h | 61 +++ 5 files changed, 1093 insertions(+) create mode 100644 fs/pstore/rombuf.c create mode 100644 fs/pstore/romzone.c create mode 100644 include/linux/pstore_rom.h -- 1.9.1
[RFC v2 1/2] pstore/rom: new support logger for block devices
pstore_rom is similar to pstore_ram, but dump log to block devices
rather than persistent ram.
Why should we need pstore_rom?
1. Most embedded intelligent equipment have no persistent ram, which
increases costs. We perfer to cheaper solutions, like block devices.
In fast, there is already a sample for block device logger in driver
MTD (drivers/mtd/mtdoops.c).
2. Do not any equipment have battery, which means that it lost all data
on general ram if power failure. Pstore has little to do for these
equipments.
pstore_rom can only dump Oops/Panic log to block devices. It only
supports dmesg now. To make pstore_rom work, the block driver should
provide the path of a block partition device (/dev/) and the
read/write apis when on panic.
pstore_rom begins at 'romz_register', by witch block device can register
a block partition to pstore_rom. Then pstore_rom divide and manage the
partition as zones, which is similar to pstore_ram.
Recommend that, block driver register pstore_rom after block device is
ready.
pstore_rom works well on allwinner(sunxi) platform.
Signed-off-by: liaoweixiong
---
fs/pstore/Kconfig | 7 +
fs/pstore/Makefile | 3 +
fs/pstore/romzone.c| 965 +
include/linux/pstore_rom.h | 61 +++
4 files changed, 1036 insertions(+)
create mode 100644 fs/pstore/romzone.c
create mode 100644 include/linux/pstore_rom.h
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index 8b3ba27..abf0453 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -152,3 +152,10 @@ config PSTORE_RAM
"ramoops.ko".
For more information, see Documentation/admin-guide/ramoops.rst.
+
+config PSTORE_ROM
+ tristate "Log panic/oops to a block device"
+ depends on PSTORE
+ help
+ This enables panic and oops message to be logged to a block dev
+ where it can be read back at some later point.
diff --git a/fs/pstore/Makefile b/fs/pstore/Makefile
index 967b589..ea38d6e 100644
--- a/fs/pstore/Makefile
+++ b/fs/pstore/Makefile
@@ -12,3 +12,6 @@ pstore-$(CONFIG_PSTORE_PMSG) += pmsg.o
ramoops-objs += ram.o ram_core.o
obj-$(CONFIG_PSTORE_RAM) += ramoops.o
+
+obj-$(CONFIG_PSTORE_ROM) += romoops.o
+romoops-y += romzone.o
diff --git a/fs/pstore/romzone.c b/fs/pstore/romzone.c
new file mode 100644
index 000..405fbb1
--- /dev/null
+++ b/fs/pstore/romzone.c
@@ -0,0 +1,965 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * romzone.c: ROM Oops/Panic logger
+ *
+ * Copyright (C) 2019 liaoweixiong
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#define pr_fmt(fmt) "romzone: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct romz_head - head of zone to flush to storage
+ *
+ * @sig: signature to indicate header (ROM_SIG xor ROMZONE-type value)
+ * @datalen: length of data in @data
+ * @data: zone data.
+ */
+struct romz_buffer {
+#define ROM_SIG (0x43474244) /* DBGC */
+ uint32_t sig;
+ atomic_t datalen;
+ uint8_t data[0];
+};
+
+/**
+ * sruct romz_dmesg_header: dmesg information
+ *
+ * @magic: magic num for dmesg header
+ * @time: trigger time
+ * @compressed: whether conpressed
+ * @count: oops/panic counter
+ * @reason: identify oops or panic
+ */
+struct romz_dmesg_header {
+#define DMESG_HEADER_MAGIC 0x4dfc3ae5
+ uint32_t magic;
+ struct timespec64 time;
+ bool compressed;
+ uint32_t counter;
+ enum kmsg_dump_reason reason;
+ uint8_t data[0];
+};
+
+/**
+ * struct romz_zone - zone information
+ * @off:
+ * zone offset of partition
+ * @type:
+ * frontent type for this zone
+ * @name:
+ * frontent name for this zone
+ * @buffer:
+ * pointer to data buffer managed by this zone
+ * @buffer_size:
+ * bytes in @buffer->data
+ * @should_recover:
+ * should recover from storage
+ * @dirty:
+ * mark whether the data in @buffer are dirty (not flush to storage yet)
+ */
+struct romz_zone {
+ unsigned long off;
+ const char *name;
+ enum pstore_type_id type;
+
+ struct romz_buffer *buffer;
+ size_t buffer_size;
+ bool should_recover;
+ atomic_t dirty;
+};
+
+struct romoops_context {
+ struct romz_zone **drzs;/* Oops dump zones */
+ unsigned int dmesg_max_cnt;
+ unsigned int dmesg_read_cnt;
+ unsigned int dmesg_write_cnt;
+ /**
+* the counter should be recovered when do recovery
+* It records the oops/panic times after burning rather than booting.
+*/
+
Re: [RFC][PATCH v2 11/21] kvm: allocate page table pages from DRAM
On Tue, Jan 01, 2019 at 02:53:07PM +0530, Aneesh Kumar K.V wrote:
> Fengguang Wu writes:
>
> > From: Yao Yuan
> >
> > Signed-off-by: Yao Yuan
> > Signed-off-by: Fengguang Wu
> > ---
> > arch/x86/kvm/mmu.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > --- linux.orig/arch/x86/kvm/mmu.c 2018-12-26 20:54:48.846720344 +0800
> > +++ linux/arch/x86/kvm/mmu.c2018-12-26 20:54:48.842719614 +0800
> > @@ -950,6 +950,16 @@ static void mmu_free_memory_cache(struct
> > kmem_cache_free(cache, mc->objects[--mc->nobjs]);
> > }
> >
> > +static unsigned long __get_dram_free_pages(gfp_t gfp_mask)
> > +{
> > + struct page *page;
> > +
> > + page = __alloc_pages(GFP_KERNEL_ACCOUNT, 0, numa_node_id());
> > + if (!page)
> > + return 0;
> > + return (unsigned long) page_address(page);
> > +}
> > +
>
> May be it is explained in other patches. What is preventing the
> allocation from pmem here? Is it that we are not using the memory
> policy prefered node id and hence the zone list we built won't have the
> PMEM node?
That because the PMEM nodes are memory-only node in the patchset,
so numa_node_id() will always return the node id from DRAM nodes.
About the zone list, yes in patch 10/21 we build the PMEM nodes to
seperate zonelist, so DRAM nodes will not fall back to PMEM nodes.
>
> > static int mmu_topup_memory_cache_page(struct kvm_mmu_memory_cache *cache,
> >int min)
> > {
> > @@ -958,7 +968,7 @@ static int mmu_topup_memory_cache_page(s
> > if (cache->nobjs >= min)
> > return 0;
> > while (cache->nobjs < ARRAY_SIZE(cache->objects)) {
> > - page = (void *)__get_free_page(GFP_KERNEL_ACCOUNT);
> > + page = (void *)__get_dram_free_pages(GFP_KERNEL_ACCOUNT);
> > if (!page)
> > return cache->nobjs >= min ? 0 : -ENOMEM;
> > cache->objects[cache->nobjs++] = page;
>
> -aneesh
>
Re: [GIT PULL] Thermal-SoC management updates for v4.21-rc1
On Tue, Jan 01, 2019 at 03:32:50PM -0800, Linus Torvalds wrote: > On Tue, Jan 1, 2019 at 3:16 PM Eduardo Valentin wrote: > > > > > It doesn't even build cleanly. > > > > > > > Do you still have have a copy of the build error? > > A plain "make allmodconfig" shows a warning. I see. I am afraid I really did not catch this. I supposed you are referring to the warning like this: thermal_hwmon.h:29:1: warning: ‘thermal_remove_hwmon_sysfs’ defined but not used [-Wunused-function] I am sending out a patch for this on thermal_hwmon.h and will be resending the pull request once the CIs report back. > > And I refuse to add new warnings. Fair enough. I would not expect anything different. Thanks for reporting. > > Linus
Re: [PATCH] Docs/kernel-api.rst: Remove removed blk-tag.c reference
Patch sent by mistake. The commit message should be: "Docs/kernel-api.rst: Remove blk-tag.c reference" Thanks, On Tue, Jan 01, 2019 at 10:40:14PM -0200, Marcos Paulo de Souza wrote: > After 7ca01926463a, legacy rq tagging was removed, so block/blk-tag.c > does not exists anymore. When generating pdfdocs, sphinx complains about > this missing file: > > Error: Cannot open file ./block/blk-tag.c > Error: Cannot open file ./block/blk-tag.c > Error: Cannot open file ./block/blk-tag.c > Error: Cannot open file ./block/blk-tag.c > > So remove blk-tag.c traces from kernel-api.rst file to silence these > warnings. > > Signed-off-by: Marcos Paulo de Souza > --- > Documentation/core-api/kernel-api.rst | 6 -- > 1 file changed, 6 deletions(-) > > diff --git a/Documentation/core-api/kernel-api.rst > b/Documentation/core-api/kernel-api.rst > index 3431337ee4e6..cdd24943fbcc 100644 > --- a/Documentation/core-api/kernel-api.rst > +++ b/Documentation/core-api/kernel-api.rst > @@ -291,12 +291,6 @@ Block Devices > .. kernel-doc:: block/blk-lib.c > :export: > > -.. kernel-doc:: block/blk-tag.c > - :export: > - > -.. kernel-doc:: block/blk-tag.c > - :internal: > - > .. kernel-doc:: block/blk-integrity.c > :export: > > -- > 2.16.4 > -- Thanks, Marcos
Re: [PATCH v3 lora-next 5/5] net: lora: sx125x sx1301: allow radio to register as a clk provider
Am 31.12.18 um 23:56 schrieb Andreas Färber: > Am 31.12.18 um 18:50 schrieb Mark Brown: >> On Sun, Dec 30, 2018 at 11:55:46AM +0100, Andreas Färber wrote: >>> Given that observed symptoms were CPU stalls, workqueue hangs and RCU >>> problems, requiring a power-cycle to recover, I wonder whether we are >>> running into some atomic/locking issue with clk_enable()? Is it valid at >>> all to use SPI/regmap for clk_enable()? If it is, is there a known issue >>> specific to spi-sun6i (A64) in 4.20.0? >>> I already tried setting .disable_locking = true in both regmap_configs. >>> Any suggestions how to further debug? >> >> You can't use SPI for clk_enable(), clk_enable() needs to be doable in >> atomic context since we need to wait for the bus operations to complete >> (you can start SPI transfers in atomic context but you still need to >> wait for them to complete). Any clocks that are only accessible via a >> slow bus like I2C or SPI need to do the enable/disable in the >> prepare/unprepare operations which aren't done in atomic context. >> >> regmap can be used in atomic contexts, though you need to configure it >> to use spinlocks instead of mutexes and ensure that no register cache >> allocations happen during I/O (eg, by providing defaults for all >> registers or by not using a cache). > > We have .cache_type = REGCACHE_NONE on both bus and spi regmap_configs. > > I moved the regmap_field_write() from .enable to .prepare and set > .fast_io = true on both regmap_configs to force using spinlocks, but > same hang as in .enable before... > > And same if I set .disable_locking = true on both. > > Given that it works with one SPI driver and not with the other, > independent of the locking options applied, I assume my symptoms are not > a regmap-layer issue. > > Is it allowed during a .prepare operation to call the mentioned > clk_get_rate(), which ends up calling clk_prepare_lock()? > > According to my debug output in spi-sun6i.c our hanging > regmap_field_write() ends up calling sun6i_transfer_one() three times, > the first two look okay, but the third one doesn't make it past the > clk_get_rate() [...]. SysRq still works in that state! Attached is SysRq-w output. (still with .disable_locking = true in both regmap_configs) In the very bottom you see the "ip" task, at wait_for_completion() from __spi_sync(). I trigger this issue with `ip link set lora2 up`, so that looks okay. Then there's a "spi1" task at clk_prepare_lock()' mutex_lock() coming from spi_pump_messages(). The reason for that will be that clk_prepare_lock()'s mutex_trylock() failed (because we're holding the prepare_lock from clk_prepare_enable() in the "ip" task) and that the prepare_owner == current check fails for this separate task_struct, too. So, the third invocation of sun6i_transfer_one() calling clk_get_rate() hangs at the prepare_lock instead of reference-counting, because it runs from a separate kthread, unlike the two previous calls? Besides, there's also an mmc_rescan workqueue task at clk_prepare_lock() coming from sunxi_mmc_enable() due to pm_generic_runtime_resume(). My rootfs is on microSD card. I did not find any *regmap_init_spi() based example in drivers/clk/, and all other "spi" mentions in drivers/clk/ appeared to be clock names. The closest was devm_regmap_init_i2c() based clk-cdce706.c, which uses the prepare/unprepare ops, as suggested by Mark, and does regmap_update_bits() from there. A quick grep in drivers/i2c/ does not find any mention of "kthread", so probably that's the breaking difference? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) [39292.911444] sysrq: SysRq : Show Blocked State [39292.915819] taskPC stack pid father [39292.921784] kworker/0:2 D0 170 2 0x0028 [39292.927282] Workqueue: ipv6_addrconf addrconf_verify_work [39292.932676] Call trace: [39292.935127] __switch_to+0x9c/0xd8 [39292.938530] __schedule+0x2a0/0x888 [39292.942016] schedule+0x30/0x88 [39292.945157] schedule_preempt_disabled+0x14/0x20 [39292.949770] __mutex_lock.isra.1+0x2c0/0x4b8 [39292.954036] __mutex_lock_slowpath+0x24/0x30 [39292.958302] mutex_lock+0x48/0x50 [39292.961615] rtnl_lock+0x1c/0x28 [39292.964841] addrconf_verify_work+0x14/0x28 [39292.969022] process_one_work+0x1f4/0x428 [39292.973028] worker_thread+0x44/0x4a8 [39292.976686] kthread+0x130/0x138 [39292.979912] ret_from_fork+0x10/0x18 [39292.983518] btrfs-transacti D0 383 2 0x0028 [39292.988998] Call trace: [39292.991444] __switch_to+0x9c/0xd8 [39292.994845] __schedule+0x2a0/0x888 [39292.998330] schedule+0x30/0x88 [39293.001472] io_schedule+0x20/0x40 [39293.004874] wbt_wait+0x1bc/0x2f8 [39293.008188] rq_qos_throttle+0x4c/0x68 [39293.011936] blk_mq_make_request+0xc4/0x4f0 [39293.016118] generic_make_request+0xf4/0x308 [39293.020384] submit_bio+0x40/0x198 [39293.023977]
[PATCH] Docs/kernel-api.rst: Remove removed blk-tag.c reference
After 7ca01926463a, legacy rq tagging was removed, so block/blk-tag.c does not exists anymore. When generating pdfdocs, sphinx complains about this missing file: Error: Cannot open file ./block/blk-tag.c Error: Cannot open file ./block/blk-tag.c Error: Cannot open file ./block/blk-tag.c Error: Cannot open file ./block/blk-tag.c So remove blk-tag.c traces from kernel-api.rst file to silence these warnings. Signed-off-by: Marcos Paulo de Souza --- Documentation/core-api/kernel-api.rst | 6 -- 1 file changed, 6 deletions(-) diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 3431337ee4e6..cdd24943fbcc 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -291,12 +291,6 @@ Block Devices .. kernel-doc:: block/blk-lib.c :export: -.. kernel-doc:: block/blk-tag.c - :export: - -.. kernel-doc:: block/blk-tag.c - :internal: - .. kernel-doc:: block/blk-integrity.c :export: -- 2.16.4
Re: linux-next: manual merge of the jc_docs tree with the fscrypt tree
Hi all,
On Fri, 7 Dec 2018 11:53:40 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> Today's linux-next merge of the jc_docs tree got a conflict in:
>
> Documentation/filesystems/index.rst
>
> between commit:
>
> 1b71a6809f96 ("fs-verity: add a documentation file")
>
> from the fscrypt tree and commit:
>
> 7bbfd9ad8eb2 ("Documentation: convert path-lookup from markdown to
> resturctured text")
>
> from the jc_docs tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc Documentation/filesystems/index.rst
> index 818390c32be6,ba921bdd5b06..
> --- a/Documentation/filesystems/index.rst
> +++ b/Documentation/filesystems/index.rst
> @@@ -360,13 -360,13 +360,24 @@@ encryption of files and directories
>
> fscrypt
>
> +Verity API
> +==
> +
> +A library which filesystems can hook into to support transparent
> +authentication of read-only files.
> +
> +.. toctree::
> +:maxdepth: 2
> +
> +fsverity
> ++
> + Pathname lookup
> + ===
> +
> + Pathname lookup in Linux is a complex beast; the document linked below
> + provides a comprehensive summary for those looking for the details.
> +
> + .. toctree::
> +:maxdepth: 2
> +
> +path-lookup.rst
This is now a conflict between the fscrypt tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpjZkLZ9dudl.pgp
Description: OpenPGP digital signature
Re: [GIT PULL] v4.21 Updates for OpenRISC
The pull request you sent on Tue, 1 Jan 2019 07:20:41 +0900: > git://github.com/openrisc/linux.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fbea8c7c793397cdf4ba53a32f99b656467b7c7f Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] kgdb changes v4.21-rc1
The pull request you sent on Sun, 30 Dec 2018 10:51:31 +: > git://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux.git/ > tags/kgdb-4.21-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fcf010449ebe1db0cb68b2c6410972a782f2bd14 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [git pull] IOMMU Updates for Linux v4.21
The pull request you sent on Mon, 31 Dec 2018 17:36:58 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git > tags/iommu-updates-v4.21 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8e143b90e4d45cca3dc53760d3cfab988bc74571 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] dmaengine updates for v4.21-rc1
The pull request you sent on Mon, 31 Dec 2018 20:21:36 +0530: > git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-4.21-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/78e8696c234ab637c4dd516cabeac344d84ec10b Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: linux-next: manual merge of the f2fs tree with the fscrypt tree
Hi all,
On Tue, 11 Dec 2018 10:13:22 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the f2fs tree got a conflict in:
>
> fs/f2fs/dir.c
>
> between commit:
>
> 848a010287e6 ("f2fs: use IS_ENCRYPTED() to check encryption status")
>
> from the fscrypt tree and commit:
>
> 4e240d1bab1e ("f2fs: check memory boundary by insane namelen")
>
> from the f2fs tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc fs/f2fs/dir.c
> index cf9e2564388d,c0c845da12fa..
> --- a/fs/f2fs/dir.c
> +++ b/fs/f2fs/dir.c
> @@@ -808,7 -808,18 +808,18 @@@ int f2fs_fill_dentries(struct dir_conte
> de_name.name = d->filename[bit_pos];
> de_name.len = le16_to_cpu(de->name_len);
>
> + /* check memory boundary before moving forward */
> + bit_pos += GET_DENTRY_SLOTS(le16_to_cpu(de->name_len));
> + if (unlikely(bit_pos > d->max)) {
> + f2fs_msg(sbi->sb, KERN_WARNING,
> + "%s: corrupted namelen=%d, run fsck to fix.",
> + __func__, le16_to_cpu(de->name_len));
> + set_sbi_flag(sbi, SBI_NEED_FSCK);
> + err = -EINVAL;
> + goto out;
> + }
> +
> -if (f2fs_encrypted_inode(d->inode)) {
> +if (IS_ENCRYPTED(d->inode)) {
> int save_len = fstr->len;
>
> err = fscrypt_fname_disk_to_usr(d->inode,
This is now a conflict between the fscrypt tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpOQgaupNWsM.pgp
Description: OpenPGP digital signature
Re: Nouveau module X server not starting on a NP900X5N Kaby Lake machine
On Tue, Jan 1, 2019 at 5:30 PM Jan Vlietland wrote: > > Hi Ilia, many thanks for answering my mail. > > Tonight I tried to see what happens if I generate a xorg.conf file and place > it in /etc/X11/xorg.conf, as described here: > https://askubuntu.com/questions/4662/where-is-the-x-org-config-file-how-do-i-configure-x-there > > When I do that X starts without the framebuffer error. X starts with a > backtrace list in the shell and then stops with the error: > > 'Segmentation fault at address 0x0. > > Fatal sever error etc etc etc. Unless you're an advanced user, you'll get the best results by not supplying a manual xorg.conf. Generically, this indicates that you messed something up. Without knowing precisely what the contents of that file are, it would be difficult to say what exactly went wrong. However I wouldn't advise this path without a good reason. > > Hope this helps! > > In fact the above is part of a much bigger issue I have with the > machine. When I enable the i915 module (Kaby lake native video) my > screen goed black after a while. The machine is totally stuck in that > state. Even ssh connection is not possible. It shows no errors in the > (saved) logs after restarting the machine. > > So I disabled the i915 module and try to get the nvidia card running. > Without any luck. > > Thank you for inviting me for irc.freenode.net. What it the procss to > get access? It's an IRC network like any other. More info about the network available at https://freenode.net/ It's open to anyone... #nouveau for nouveau, #intel-gfx for intel. > > I have included the full dmesg in zip format. > > For me it is a showstopper using the machine with Linux. I really do not > understand that I am the only person on this planet that cannot run > Linux on a plain vanilla Kaby lake machine. I don't know the specifics of your laptop, but on many other GM108M laptops, the displays are only attached to the Intel GPU. So running without i915 is just not an option, if you want anything displayed. You would be able to use the GM108M chip for 3D acceleration if you chose, but nothing to do with actual display. If your screen goes black with i915 loaded, I suspect that you'd be better served reporting this issue to Intel. >From your logs, you also appear to have a variety of combinations of nomodeset/.modeset=0 combinations -- these will just impede the proper mode of operation. The i915 and nouveau drivers effectively do nothing under those conditions. Cheers, -ilia
An attached interest is essential to argue that rescission is improper: you must have paid the owner for such an attached interest.
1015331 You cannot revoke the GPL license, having no attached interest is meaningless. It is not meaningless, it is essential. For you to have an attached interest, you must secure it. And you must secure it from the property owner. The GPL is a commercial distribution license. It is not. Nothing was payed to many 1000s of property owners for them to forgo their default rights, nor did they disclaim them in the license, nor were they paid for said non-existent disclaimers. People are allowed to distribute GPL software and they are allowed to make a big profit by doing this. Until the license is revoked. All your "rights" stem from the choice of the property owner to alienate his property as he sees fit. Here he has chosen to alienate his property very little: he has simply granted a license (not a transfer). He may revoke this grant at his leasure since it is not secured by an interest. You paid nothing to Owner. Owner gave nothing to you. He is simply allowing you to temporarily use his property. He can end this permission when he wishes. You then must prove that you paid him to not use this property right of his, and that he gave to you (in return for this payment in money, performance, goods) a promise to forgo this right of his. You cannot show that. You have no right to prevent him from recovering his property. In this case the code. He can say: nope, you cannot use it any-longer in new editions of this software. Then the burden is on you to show the court where he sold you some right that runs counter to his default rights in his own property. He never did so, so you have nothing to show. >>1015264 >Without an attached interest you can very well revoke the license and prevent all further distribution of your code, and further use of it in future versions. You cannot revoke the GPL license, having no attached interest is meaningless. The GPL is a commercial distribution license. People are allowed to distribute GPL software and they are allowed to make a big profit by doing this.
Yes: your code IS property. It is YOUR property.
he compares lending a physical object to licensing intellectual property Why are you still LARPing as a laywer? 1015334 The foundation of this law IS in property law. Copyright is alienable in all ways that property is (see: US Copyright statute). That is where you get the ability to LICENSE software, books, music, etc to begin with. The Copyright act announces that these ethereal concepts, these things that are not in reality something one can truly physically extend dominion and control (ownership) over... are never the less... to be treated as such. Yes, a License, first and foremost, is a PROPERTY law concept. Property which you can defend, which you can build walls around, which you can enclose, from which you can eject trespassers. An Idea? A song? Can one eject a tresspasser from that? Can one ever rape a mind of an allready-recieved idea? Can one cut from the grasp of an interlocutor, this supposed Object ... a song? No. Not in reality. But the Copyright Act declares differently. It declares that these incorporeal concepts be imagined to be that piece of land on which your stronghold sits, onwhich your implements of defence are trained from the high towers you have erected. It declares that a Song, A piece of litererature, every copy there-of, all-in-the-same, is not a wisp upon the wind... but a piece of land, or some personal implement such as an ax. And that you can, indeed, cut from the grasp of some theif this ax, you can cut his fingers one by one until that Ax of yours falls from his countenance back into your possession. And the way this is done is by the destruction of all offending articles: which a court may order, and or the punishment of those who would violate the property rights of the owner, which again the court may order. So yes, intellectual property is... like a physical thing. Because the law says it is. Even though you cannot even prevent yourself from knowing that which is thrust upon you... Here the property owners, who came to be property owners at the fixation of the article (that is: when the code was written down), chose not to transfer their ownership in the article. Instead they, after reading the Copyright Act, elected to a different from of Property alienation. A rather limited form known as a license. Permission. A temporary grant which, at their time of choosing, they may end. Since this grant makes no mention of them selling off their right to rescind the permission, and since, indeed, forbearance of said right was not sold, there is no attached interest with which to bind their hand. They may rescind. If you don't like that: pay them for a forbearance.
device_sysfs.c:undefined reference to `utf16s_to_utf8s'
Hi Sinan, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 28e8c4bc8eb483c22d977e147a0b98fc63efadf7 commit: 5d32a66541c4683456507481a0944ed2985e75c7 PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set date: 13 days ago config: i386-alldefconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: git checkout 5d32a66541c4683456507481a0944ed2985e75c7 # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/acpi/device_sysfs.o: In function `description_show': >> device_sysfs.c:(.text+0x44b): undefined reference to `utf16s_to_utf8s' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] net: core: Fix to store new mtu setting in netdevice.
> > Is there a .ndo_change_mtu callback, which does not assign a new mtu itself? > > > So far all drivers have to do it themselves. But IMO this is more a workaround > for the core not doing it. It's something the core should do. > Now we can remove this from drivers. Hi Heiner I think somebody first needs to review all the ndo_change_mtu implementations and check that none do something funny like round to multiple of 2 or 4 to satisfy DMA restrictions, etc. If there is such a thing, we cannot easily move this into the core. Andrew
Re: [GIT PULL] Thermal-SoC management updates for v4.21-rc1
On Tue, Jan 1, 2019 at 3:16 PM Eduardo Valentin wrote: > > > It doesn't even build cleanly. > > > > Do you still have have a copy of the build error? A plain "make allmodconfig" shows a warning. And I refuse to add new warnings. Linus
Re: Thank you for your messages, and Happy New Year ;)
Thanks for your response :). Please Spread the word regarding the copyright-holders rights (remeber: the Linux kernel programmers did not sign over their copyrights, one of the reasons Linux grew so quickly amongst developers where GNU very slowly (The FSF will only include code where the copyright has been transferred to it)), thus the various 1000s of linux programmers who didn't work for a company all retain their property rights. A license is just that: license (permission). It is not a transfer of rights. These licenses that were given are non-exclusive (not to just one entity) and are thus cannot be construed as transfers either. It's simply permission to use property, same as if you allowed a neighbor to use an ax you owned (gave them license to use the ax). If that neighbor went and then chopped an enemy to pieces with that ax, limb by limb, joint by joint, applying burning cauterizing oil after each dismemberment, he cannot say "I will not give you back the ax, because I relied on your lease, and thus used the ax in such a way as it would be inconvenient for me to return it to you". The ax is still yours and you may tell your friend: give me my ax back now (this is you rescinding the license).
Re: [PATCH] net: core: Fix to store new mtu setting in netdevice.
On Tue, Jan 01, 2019 at 03:18:51PM +0530, Murali Krishna Policharla wrote: > Hi Andrew, >Currently net/dsa/slave.c does not have > ndo_change_mtu function. But shortly I will be submitting a separate > patch outside this fix that has ndo_change_mtu function support added to > DSA switch. As part of testing the newly added ndo_change_mtu function > for DSA switch it uncovered that new mtu size is not being updated to > netdevice structure. This patch fixes this issue and updates new mtu size > to netdevice structure. > > Hope this clarifies, let me know if you need any further information. Hi Murali Thanks for the explanation. However, i looked at the patch you listed as 'fixes'. I don't see what came before that setting the mtu when an ndo_change_mtu function is provided. It seems to me, if you provide an ndo_change_mtu, it has to do the assignment. I don't think you are fixing anything here. If you do want to move the assignment into the core, please review all the MAC drivers which implement ndo_change_mtu and remove the assignment from them. Thanks Andrew
Re: [GIT PULL] Thermal-SoC management updates for v4.21-rc1
On Tue, Jan 01, 2019 at 01:35:36PM -0800, Linus Torvalds wrote: > On Tue, Jan 1, 2019 at 8:05 AM Eduardo Valentin wrote: > > > > Please consider pulling from > > > > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal > > linus > > No. > > I pulled and immediately unpulled again. > hmm... ok I am double checking. > It doesn't even build cleanly. > Do you still have have a copy of the build error? The local tests I did were not enough to see this error, neither were the kernel CI builds. Only failed build was on something completely unrelated (ARC) to these changes: Full Build Summary: https://kernelci.org/build/evalenti/branch/for-kernelci/kernel/v4.20-rc5-42-g055ddb633a35/ > Linus
Re: [gentoo-user] Re: CoC loving Linux programmers... is completely on topic.
Funny, the pro-CoC developers claim any discussion is off-topic on the linux developer lists. The licensing of linux-kernel is completely on topic, since there may be linux-copyright-holders reading this list. They have been told they have no rights, that they transferred them away. This is a complete lie. They have only magnanimously granted a license to use their code. They have received nothing for it. It is a gratuitous license given by them. They can rescind this license from whomever they want at any time. Including the linux kernel project. This is being resolved off-list shortly. Some veiled threat? Because you do not like my way of speaking, or the topic? You want the property-owners to be dispossessed? On 2019-01-01 20:49, Rich Freeman wrote: On Tue, Jan 1, 2019 at 3:44 PM Dale wrote: Question. Why are these license discussions being done on a USER list instead of a DEVELOPER list? Gentoo has mailing lists that are to be used for this sort of topic. How about taking them there? Here is a link with them listed. This is indeed off-topic for this list (and other Gentoo lists). This is being resolved off-list shortly. I appreciate everybody's ongoing patience with not replying.
Yes you can rescind. Re: CoC loving Linux programmers swear the GPLv2 is irrevocable. They are wrong. (As are the women they wish to empower).
If you lend (license) your lawnmower to BrucePerens, and receive nothing in return, and BrucePerens hires someone else to draw a star on your lawnmower, BrucePerens believes he can keep your lawnmower forever because he "relied" on your lease and , even though he paid you nothing and you never said you would not rescind the license (a default right of yours, you being the property owner). On 2019-01-01 12:42, william drescher wrote: "Consideration" can be in form of " detrimental reliance." That means that you relied on the license and that reliance cost you something. So if you spend money to pay programmers or if you spend time writing programs based on the license you have paid for the license.
Happy New Year
I have a very profitable business proposal for you
