Re: [PATCH v3 0/8] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits
Hi Tony, > Am 17.09.2019 um 16:35 schrieb H. Nikolaus Schaller : > > Hi Tony, > >> Am 16.09.2019 um 18:28 schrieb Tony Lindgren : >> >> * H. Nikolaus Schaller [190911 17:48]: >>> CHANGES V3: >>> * make omap36xx control the abb-ldo and properly switch mode >>> (suggested by Adam Ford ) >>> * add a note about enabling the turbo-mode OPPs >> >> Looks good to me, when applying, please provide a >> minimal immutable branch maybe against v5.3 or v5.4-rc1, >> that I can also merge in if needed for the dts changes. > > Should I resend a v4 with your Acked-By added? > > BR and thanks, > Nikolaus > what is the procedure to get this and Adam's thermal setup into linux-next? BR and thanks, Nikolaus
Re: [PATCH] input: touchscreen: imx6ul_tsc: Use 'dev' instead of dereferencing it repeatedly
On 01. 10. 19 1:08, Dmitry Torokhov wrote: On Tue, Sep 24, 2019 at 05:02:11PM +0800, Anson Huang wrote: Add helper variable dev = >dev to simply the code. Do we get any code savings from this? I noticed Anson submitted similar patches into various other subsystems. Here [1] is a very detailed response from David Laight shedding some light on this topic. [1] https://lkml.org/lkml/2019/9/24/151 Signed-off-by: Anson Huang --- drivers/input/touchscreen/imx6ul_tsc.c | 37 +- 1 file changed, 19 insertions(+), 18 deletions(-)
Re: [PATCH] x86/PCI: Remove D0 PME capability on AMD FCH xHCI
> On Oct 2, 2019, at 08:07, Bjorn Helgaas wrote:
>
> [+cc Alan, Mathias, Rafael, Lukas]
>
> On Mon, Sep 02, 2019 at 10:52:52PM +0800, Kai-Heng Feng wrote:
>> There's an xHCI device that doesn't wake when a USB 2.0 device gets
>> plugged to its USB 3.0 port. The driver's own runtime suspend callback
>> was called, PME# signaling was enabled, but it stays at PCI D0:
>>
>> 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB
>> XHCI Controller [1022:7914] (rev 20) (prog-if 30 [XHCI])
>>Subsystem: Dell FCH USB XHCI Controller [1028:087e]
>>Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B- DisINTx+
>>Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> SERR- >Interrupt: pin A routed to IRQ 18
>>Region 0: Memory at f0b68000 (64-bit, non-prefetchable) [size=8K]
>>Capabilities: [50] Power Management version 3
>>Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>> PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>Status: D0 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
>>
>> A PCI device can be runtime suspended while still stays at D0 when it
>> supports D0 PME# and its ACPI _S0W method reports D0. Though plugging
>> USB 3.0 devices can wakeup the xHCI, it doesn't respond to USB 2.0
>> devices.
>
> I don't think _S0W and runtime suspend are relevant here. What *is*
> relevant is that the device advertises that it can generate PME from
> D0, and it apparently does not do so.
Yes that's the case. It doesn't generate PME when USB2.0 or USB1.1 device gets
plugged.
>
> Table 10 in the xHCI spec r1.0, sec 4.15.2.3, says the xHC should
> assert PME# if enabled and the port's WCE bit is set. Did you ever
> confirm that WCE is set?
How do I check WCE when xHCI is suspended?
If I want to read WCE then I have the resume the device, but after resuming all
USB devices get enumerated, and checking WCE doesn't matter anymore.
>
> I assume WCE *is* set because plugging in a USB3 device *does*
> generate a PME#, and I don't see anything in Table 10 that says it
> would work for USB3 but not USB2.
It should work on all USB speeds, but it didn't.
That's why the OEM/ODM use the _S0W workaround on Windows.
Kai-Heng
>
>> So let's disable D0 PME capability on this device to avoid the issue.
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203673
>> Signed-off-by: Kai-Heng Feng
>> ---
>> arch/x86/pci/fixup.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
>> index 527e69b12002..0851a05d092f 100644
>> --- a/arch/x86/pci/fixup.c
>> +++ b/arch/x86/pci/fixup.c
>> @@ -588,6 +588,17 @@ static void pci_fixup_amd_ehci_pme(struct pci_dev *dev)
>> }
>> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x7808, pci_fixup_amd_ehci_pme);
>>
>> +/*
>> + * Device [1022:7914]
>> + * D0 PME# doesn't get asserted when plugging USB 2.0 device.
>> + */
>> +static void pci_fixup_amd_fch_xhci_pme(struct pci_dev *dev)
>> +{
>> +dev_info(>dev, "PME# does not work under D0, disabling it\n");
>
> Use pci_info() as in the rest of the file.
>
>> +dev->pme_support &= ~(PCI_PM_CAP_PME_D0 >> PCI_PM_CAP_PME_SHIFT);
>> +}
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x7914,
>> pci_fixup_amd_fch_xhci_pme);
>> +
>> /*
>> * Apple MacBook Pro: Avoid [mem 0x7fa0-0x7fbf]
>> *
>> --
>> 2.17.1
Re: [v2] fs: affs: fix a memory leak in affs_remount
> Hi Markus, thanks for your suggestions for improving the quality of > the patch. At the moment I prefer first get a confirmation from > contributors about the leak and then work on any possible improvements > for the patch. Please fix this patch as soon as possible if you care for the correctness of the provided information. Regards, Markus
Re: [v2] fs: affs: fix a memory leak in affs_remount
> Hi Markus, thanks for your suggestions for improving the quality of > the patch. At the moment I prefer first get a confirmation from > contributors about the leak and then work on any possible improvements > for the patch. Please fix this patch as soon as possible if you care for the correctness of the provided information. Regards, Markus
Re: [v2] spi: gpio: prevent memory leak in spi_gpio_probe
> Hi Markus, thanks for your suggestions for improving the quality of > the patch. At the moment I prefer first get a confirmation from > contributors about the leak and then work on any possible improvements > for the patch. Please fix this patch as soon as possible if you care for the correctness of the provided information. Regards, Markus
Re: [PATCH v2] perf script python: integrate page reclaim analyze script
On Tue, Oct 1, 2019 at 10:45 PM Mel Gorman wrote: > > On Mon, Sep 30, 2019 at 11:19:44PM -0400, Yafang Shao wrote: > > A new perf script page-reclaim is introduced in this patch. This new script > > is used to report the page reclaim details. The possible usage of this > > script is as bellow, > > - identify latency spike caused by direct reclaim > > - whehter the latency spike is relevant with pageout > > - why is page reclaim requested, i.e. whether it is because of memory > > fragmentation > > - page reclaim efficiency > > etc > > In the future we may also enhance it to analyze the memcg reclaim. > > > > Hi, > > I ended up not reviewing this patch in detail simply because I would > approach the same class of problem in an entirely different way today. > There is value in accumulating the stats in a report like this; > > > $ perf script report page-reclaim > > Direct reclaims: 4924 > > Direct latency (ms)total max avg min > > 177823.2116378.977 36.114 0.051 > > Direct file reclaimed 22920 > > Direct file scanned 28306 > > Direct file sync write I/O 0 > > Direct file async write I/O 0 > > Direct anon reclaimed 212567 > > Direct anon scanned 1446854 > > Direct anon sync write I/O 0 > > Direct anon async write I/O 278325 > > Direct order 0 1 3 > > 48702331 > > Wake kswapd requests 716 > > Wake order 0 1 > > 715 1 > > > > Kswapd reclaims: 9 > > However, the basic option I would prefer is having the raw latency > information for Direct latency that can be externally parsed by R or any > other statistical method. The reason why is because knowing the max latency > is not enough, I'd want to know the spread of latencies and whether they > were clustered at a point of time or spread out over long periods of > time. I would then build the higher-level reports on top if necessary. > > Today, I would also have considered getting the latency figures using eBPF > or systemtap instead although having perf do it may be useful too. That's > not universally popular though so at minimum I would have; > eBPF requires newer kernel, while there're still lots of servers running with old kernels. The systemtap is not convenient as it requires many debug packages, and it is still not stable enough to run on the product environment, for example, the systemtap deamon may exit without uninstalling the systemtap kernel module. > perf script record page-reclaim -- capture all page-reclaim tracepoints > perf script report page-reclaim -- For reclaim entry/exit, merge the two > tracepoints into one that reports latency. Dump the rest out > verbatim > > For latencies, I would externally post-process them until such time as I > found a common class of bug that needed a high-level report and then > build the perf script support for it. > This seem like a good suggestion. I will try to think about it. > Please note that I did not spot anything wrong with your script, it's > just that I would not use it myself in its current format for debugging > a reclaim-related problem. > > -- > Mel Gorman > SUSE Labs
RE: [PATCH] iommu/ipmmu-vmsa: Only call platform_get_irq() when interrupt is mandatory
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, October 2, 2019 3:06 AM
>
> As platform_get_irq() now prints an error when the interrupt does not
> exist, calling it gratuitously causes scary messages like:
>
> ipmmu-vmsa e674.mmu: IRQ index 0 not found
>
> Fix this by moving the call to platform_get_irq() down, where the
> existence of the interrupt is mandatory.
>
> Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to
> platform_get_irq*()")
> Signed-off-by: Geert Uytterhoeven
> ---
> This is a fix for v5.4-rc1.
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
And, I tested this patch on R-Car H3. So,
Tested-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
RE: [PATCH] serial: sh-sci: Use platform_get_irq_optional() for optional interrupts
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, October 2, 2019 3:08 AM
>
> As platform_get_irq() now prints an error when the interrupt does not
> exist, scary warnings may be printed for optional interrupts:
>
> sh-sci e655.serial: IRQ index 1 not found
> sh-sci e655.serial: IRQ index 2 not found
> sh-sci e655.serial: IRQ index 3 not found
> sh-sci e655.serial: IRQ index 4 not found
> sh-sci e655.serial: IRQ index 5 not found
>
> Fix this by calling platform_get_irq_optional() instead for all but the
> first interrupts, which are optional.
>
> Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to
> platform_get_irq*()")
> Signed-off-by: Geert Uytterhoeven
> ---
> This is a fix for v5.4-rc1.
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
And, I tested this patch on R-Car H3. So,
Tested-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
RE: [PATCH] phy: renesas: rcar-gen3-usb2: Use platform_get_irq_optional() for optional irq
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, October 2, 2019 3:11 AM
>
> As platform_get_irq() now prints an error when the interrupt does not
> exist, a scary warning may be printed for an optional interrupt:
>
> phy_rcar_gen3_usb2 ee0a0200.usb-phy: IRQ index 0 not found
>
> Fix this by calling platform_get_irq_optional() instead.
>
> Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to
> platform_get_irq*()")
> Signed-off-by: Geert Uytterhoeven
> ---
> This is a fix for v5.4-rc1.
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
And, I tested this patch on R-Car H3. So,
Tested-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
RE: [PATCH] mmc: renesas_sdhi: Do not use platform_get_irq() to count interrupts
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, October 2, 2019 3:07 AM
>
> As platform_get_irq() now prints an error when the interrupt does not
> exist, counting interrupts by looping until failure causes the printing
> of scary messages like:
>
> renesas_sdhi_internal_dmac ee14.sd: IRQ index 1 not found
>
> Fix this by using the platform_irq_count() helper to avoid touching
> non-existent interrupts.
>
> Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to
> platform_get_irq*()")
> Signed-off-by: Geert Uytterhoeven
> ---
> This is a fix for v5.4-rc1.
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
And, I tested this patch on R-Car H3. So,
Tested-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
RE: [PATCH] mmc: sh_mmcif: Use platform_get_irq_optional() for optional interrupt
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, October 2, 2019 3:09 AM
>
> As platform_get_irq() now prints an error when the interrupt does not
> exist, a scary warning may be printed for an optional interrupt:
>
> sh_mmcif ee20.mmc: IRQ index 1 not found
>
> Fix this by calling platform_get_irq_optional() instead for the second
> interrupt, which is optional.
>
> Remove the now superfluous error printing for the first interrupt, which
> is mandatory.
>
> Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to
> platform_get_irq*()")
> Signed-off-by: Geert Uytterhoeven
> ---
> This is a fix for v5.4-rc1.
> ---
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
And, I tested this patch on R-Car H2. So,
Tested-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
RE: [PATCH] pinctrl: sh-pfc: Do not use platform_get_irq() to count interrupts
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, October 2, 2019 3:06 AM
>
> As platform_get_irq() now prints an error when the interrupt does not
> exist, counting interrupts by looping until failure causes the printing
> of scary messages like:
>
> sh-pfc e606.pin-controller: IRQ index 0 not found
>
> Fix this by using the platform_irq_count() helper instead.
>
> Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to
> platform_get_irq*()")
> Signed-off-by: Geert Uytterhoeven
> ---
> This is a fix for v5.4-rc1.
Thank you for the patch!
Reviewed-by: Yoshihiro Shimoda
And, I tested this patch on R-Car H3. So,
Tested-by: Yoshihiro Shimoda
Best regards,
Yoshihiro Shimoda
linux-next: Tree for Oct 2
Hi all,
Changes since 20191001:
My fixes tree contains:
04e6dac68d9b ("powerpc/64s/radix: fix for "tidy up TLB flushing code" and
!CONFIG_PPC_RADIX_MMU")
The akpm-current tree gained a conflict against the jc_docs tree.
Non-merge commits (relative to Linus' tree): 974
1170 files changed, 30063 insertions(+), 13139 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 313 trees (counting Linus' and 78 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 (54ecb8f7028c Linux 5.4-rc1)
Merging fixes/master (04e6dac68d9b powerpc/64s/radix: fix for "tidy up TLB
flushing code" and !CONFIG_PPC_RADIX_MMU)
Merging kbuild-current/fixes (d159d87700e9 namespace: fix namespace.pl script
to support relative paths)
Merging arc-current/for-curr (41277ba7eb4e ARC: mm: tlb flush optim: elide
redundant uTLB invalidates for MMUv3)
Merging arm-current/fixes (5b3efa4f1479 ARM: 8901/1: add a criteria for
pfn_valid of arm)
Merging arm-soc-fixes/arm/fixes (cdee3b60af59 ARM: dts: ux500: Fix up the CPU
thermal zone)
Merging arm64-fixes/for-next/fixes (a2b99dcac36c docs: arm64: Fix indentation
and doc formatting)
Merging m68k-current/for-linus (0f1979b402df m68k: Remove ioremap_fullcache())
Merging powerpc-fixes/fixes (253c892193ab powerpc/eeh: Fix eeh
eeh_debugfs_break_device() with SRIOV devices)
Merging s390-fixes/fixes (9f494438d4bc s390/qdio: clarify size of the QIB parm
area)
Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (569aad4fcd82 net: ag71xx: fix mdio subnode support)
Merging bpf/master (1bd63524593b libbpf: handle symbol versioning properly for
libbpf.a)
Merging ipsec/master (68ce6688a5ba net: sched: taprio: Fix potential integer
overflow in taprio_set_picos_per_byte)
Merging netfilter/master (34a4c95abd25 netfilter: nft_connlimit: disable bh on
garbage collection)
Merging ipvs/master (02dc96ef6c25 Merge
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging wireless-drivers/master (54ecb8f7028c Linux 5.4-rc1)
Merging mac80211/master (569aad4fcd82 net: ag71xx: fix mdio subnode support)
Merging rdma-fixes/for-rc (54ecb8f7028c Linux 5.4-rc1)
Merging sound-current/for-linus (f41f900568d9 ALSA: usb-audio: Add DSD support
for EVGA NU Audio)
Merging sound-asoc-fixes/for-linus (bbb90c4ed03b Merge branch 'asoc-5.4' into
asoc-linus)
Merging regmap-fixes/for-linus (54ecb8f7028c Linux 5.4-rc1)
Merging regulator-fixes/for-linus (c3f1e312854c Merge branch 'regulator-5.4'
into regulator-linus)
Merging spi-fixes/for-linus (6efab62559b1 Merge branch 'spi-5.4' into spi-linus)
Merging pci-current/for-linus (5184d449600f Merge tag 'microblaze-v5.4-rc1' of
git://git.monstr.eu/linux-2.6-microblaze)
Merging driver-core.current/driver-core-linus (54ecb8f7028c Linux 5.4-rc1)
Merging tty.current/tty-linus (54ecb8f7028c Linux 5.4-rc1)
Merging usb.current/usb-linus (54ecb8f7028c Linux 5.4-rc1)
Merging usb-gadget-fixes/fixes (4a56a478a525 usb: gadget: mass_storage: Fix
races between fsg_disable and fsg_set_alt)
Merging usb-serial-fixes/usb-linus (54ecb8f7028c Linux 5.4-rc1)
Merging usb-chipidea-fixes/ci-for-usb-stable (16009db47c51 usb: chipidea: udc:
workaro
Re: [RFC PATCH] xen/gntdev: Stop abusing DT of_dma_configure API
On 10/1/19 9:23 PM, Stefano Stabellini wrote: > On Thu, 26 Sep 2019, Rob Herring wrote: >> On Thu, Sep 26, 2019 at 6:16 AM Oleksandr Andrushchenko >> wrote: >>> On 9/26/19 1:46 PM, Robin Murphy wrote: On 2019-09-26 11:17 am, Oleksandr Andrushchenko wrote: > On 9/26/19 12:49 PM, Julien Grall wrote: >> Hi Rob, >> >> >> On 9/25/19 10:50 PM, Rob Herring wrote: >>> As the comment says, this isn't a DT based device. of_dma_configure() >>> is going to stop allowing a NULL DT node, so this needs to be fixed. >> And this can't work on arch not selecting CONFIG_OF and can select >> CONFIG_XEN_GRANT_DMA_ALLOC. >> >> We are lucky enough on x86 because, AFAICT, arch_setup_dma_ops is just >> a nop. >> > No luck is needed as [1] does nothing for those platforms not using > CONFIG_OF >>> Not sure exactly what setup besides arch_setup_dma_ops is needed... >> We probably want to update dma_mask, coherent_dma_mask and >> dma_pfn_offset. >> >> Also, while look at of_configure_dma, I noticed that we consider the >> DMA will not be coherent for the grant-table. Oleksandr, do you know >> why they can't be coherent? > The main and the only reason to use of_configure_dma is that if we don't > then we > are about to stay with dma_dummy_ops [2]. It effectively means that > operations on dma-bufs > will end up returning errors, like [3], [4], thus not making it possible > for Xen PV DRM and DMA > part of gntdev driver to do what we need (dma-bufs in our use-cases > allow zero-copying > while using graphics buffers and many more). > > I didn't find any better way of achieving that, but of_configure_dma... > If there is any better solution which will not break the existing > functionality then > I will definitely change the drivers so we do not abuse DT ) > Before that, please keep in mind that merging this RFC will break Xen PV > DRM + > DMA buf support in gntdev... > Hope we can work out some acceptable solution, so everyone is happy As I mentioned elsewhere, the recent dma-direct rework means that dma_dummy_ops are now only explicitly installed for the ACPI error case, so - much as I may dislike it - you should get regular (direct/SWIOTLB) ops by default again. >>> Ah, my bad, I missed that change. So, if no dummy dma ops are to be used >>> then >>> I believe we can apply both changes, e.g. remove of_dma_configure from >>> both of the drivers. >> What about the dma masks? I think there's a default setup, but it is >> considered a driver bug to not set its mask. xen_drm_front sets the >> coherent_dma_mask (why only 32-bits though?), but not the dma_mask. >> gntdev is doing neither. I could copy out what of_dma_configure does >> but better for the Xen folks to decide what is needed or not and test >> the change. I'm not setup to test any of this. > FYI I have seen the issue Oleksandr is talking about too. I confirm that > the only reason for the of_configure_dma call is to get away from the > dummy_dma_ops and use the default dma_ops instead. I think this should > be mentioned in the commit message so that if one day the behavior > regarding dummy_dma_ops changes one more time, hopefully we'll be able > to figure out the issue more easily with bisection. > > In regards to the coherent_dma_mask and dma_mask, I can't see why gntdev > would have any dma addressing limitations, so we should be able to set > both to 64 bits. I also can't see why xen_drm_front would limit it to > 32 bits, after all this is just the frontend, if anything it would be > the backend that has a limitation. So, we should be able to set both > dma_mask and coherent_dma_mask in xen_drm_front to 64 bits. Oleksandr, > can you confirm? I am totally fine with 64-bits in both cases and agree with what Stefano says.
Re: [PATCH] x86/xen: Return from panic notifier
On 01.10.19 17:16, Boris Ostrovsky wrote: Currently execution of panic() continues until Xen's panic notifier (xen_panic_event()) is called at which point we make a hypercall that never returns. This means that any notifier that is supposed to be called later as well as significant part of panic() code (such as pstore writes from kmsg_dump()) is never executed. There is no reason for xen_panic_event() to be this last point in execution since panic()'s emergency_restart() will call into xen_emergency_restart() from where we can perform our hypercall. Reported-by: James Dingwall Signed-off-by: Boris Ostrovsky Reviewed-by: Juergen Gross Juergen
Re: [PATCH] rtl8xxxu: prevent leaking urb
Navid Emamdoost wrote: > In rtl8xxxu_submit_int_urb if usb_submit_urb fails the allocated urb > should be released. > > Signed-off-by: Navid Emamdoost > Reviewed-by: Chris Chiu Patch applied to wireless-drivers-next.git, thanks. a2cdd07488e6 rtl8xxxu: prevent leaking urb -- https://patchwork.kernel.org/patch/11153733/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 0/3] PCI: pciehp: Do not turn off slot if presence comes up after link
On Tue, Oct 1, 2019 at 11:13 PM Lukas Wunner wrote: > > On Tue, Oct 01, 2019 at 05:14:16PM -0400, Stuart Hayes wrote: > > This patch set is based on a patch set [1] submitted many months ago by > > Alexandru Gagniuc, who is no longer working on it. > > > > [1] https://patchwork.kernel.org/cover/10909167/ > > [v3,0/4] PCI: pciehp: Do not turn off slot if presence comes up after > > link > > If I'm not mistaken, these two are identical to Alex' patches, right? > > PCI: pciehp: Add support for disabling in-band presence > PCI: pciehp: Wait for PDS when in-band presence is disabled > > I'm not sure if it's appropriate to change the author and > omit Alex' Signed-off-by. > > Otherwise I have no objections against this series. > > Thanks, > > Lukas Thanks! The first patch is identical to the one Alex submitted, and the second is nearly so... they both basically his work. I wasn't sure what proper etiquette was--I was thinking the signed-off-by was taking responsibility that the patch was ok (functional, not copyrighted by someone else, etc) rather than giving credit, but he definitely deserves credit for them. I'm happy to add a signed-off-by for Alex on the first two and resubmit if he doesn't object.
Re: [PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
Chris Chiu wrote: > We have 3 laptops which connect the wifi by the same RTL8723BU. > The PCI VID/PID of the wifi chip is 10EC:B720 which is supported. > They have the same problem with the in-kernel rtl8xxxu driver, the > iperf (as a client to an ethernet-connected server) gets ~1Mbps. > Nevertheless, the signal strength is reported as around -40dBm, > which is quite good. From the wireshark capture, the tx rate for each > data and qos data packet is only 1Mbps. Compare to the Realtek driver > at https://github.com/lwfinger/rtl8723bu, the same iperf test gets > ~12Mbps or better. The signal strength is reported similarly around > -40dBm. That's why we want to improve. > > After reading the source code of the rtl8xxxu driver and Realtek's, the > major difference is that Realtek's driver has a watchdog which will keep > monitoring the signal quality and updating the rate mask just like the > rtl8xxxu_gen2_update_rate_mask() does if signal quality changes. > And this kind of watchdog also exists in rtlwifi driver of some specific > chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have > the same member function named dm_watchdog and will invoke the > corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate > mask. > > With this commit, the tx rate of each data and qos data packet will > be 39Mbps (MCS4) with the 0xF0 as the tx rate mask. The 20th bit > to 23th bit means MCS4 to MCS7. It means that the firmware still picks > the lowest rate from the rate mask and explains why the tx rate of > data and qos data is always lowest 1Mbps because the default rate mask > passed is always 0xFFF ranges from the basic CCK rate, OFDM rate, > and MCS rate. However, with Realtek's driver, the tx rate observed from > wireshark under the same condition is almost 65Mbps or 72Mbps, which > indicating that rtl8xxxu could still be further improved. > > Signed-off-by: Chris Chiu > Reviewed-by: Daniel Drake > Acked-by: Jes Sorensen New warning: drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c: In function 'rtl8xxxu_refresh_rate_mask': drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:5907:7: warning: this statement may fall through [-Wimplicit-fallthrough=] if (priv->tx_paths == 2 && priv->rx_paths == 2) ^ drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:5911:3: note: here case (WIRELESS_MODE_B | WIRELESS_MODE_G | WIRELESS_MODE_N_24G): ^~~~ Patch set to Changes Requested. -- https://patchwork.kernel.org/patch/11148163/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2] rtl8xxxu: add bluetooth co-existence support for single antenna
Chris Chiu wrote: > The RTL8723BU suffers the wifi disconnection problem while bluetooth > device connected. While wifi is doing tx/rx, the bluetooth will scan > without results. This is due to the wifi and bluetooth share the same > single antenna for RF communication and they need to have a mechanism > to collaborate. > > BT information is provided via the packet sent from co-processor to > host (C2H). It contains the status of BT but the rtl8723bu_handle_c2h > dose not really handle it. And there's no bluetooth coexistence > mechanism to deal with it. > > This commit adds a workqueue to set the tdma configurations and > coefficient table per the parsed bluetooth link status and given > wifi connection state. The tdma/coef table comes from the vendor > driver code of the RTL8192EU and RTL8723BU. However, this commit is > only for single antenna scenario which RTL8192EU is default dual > antenna. The rtl8xxxu_parse_rxdesc24 which invokes the handle_c2h > is only for 8723b and 8192e so the mechanism is expected to work > on both chips with single antenna. Note RTL8192EU dual antenna is > not supported. > > Signed-off-by: Chris Chiu Failed to apply, please rebase on top of wireless-drivers-next. fatal: sha1 information is lacking or useless (drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h). error: could not build fake ancestor Applying: rtl8xxxu: add bluetooth co-existence support for single antenna Patch failed at 0001 rtl8xxxu: add bluetooth co-existence support for single antenna The copy of the patch that failed is found in: .git/rebase-apply/patch Patch set to Changes Requested. -- https://patchwork.kernel.org/patch/11140223/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2] rtl8xxxu: add bluetooth co-existence support for single antenna
Chris Chiu wrote: > The RTL8723BU suffers the wifi disconnection problem while bluetooth > device connected. While wifi is doing tx/rx, the bluetooth will scan > without results. This is due to the wifi and bluetooth share the same > single antenna for RF communication and they need to have a mechanism > to collaborate. > > BT information is provided via the packet sent from co-processor to > host (C2H). It contains the status of BT but the rtl8723bu_handle_c2h > dose not really handle it. And there's no bluetooth coexistence > mechanism to deal with it. > > This commit adds a workqueue to set the tdma configurations and > coefficient table per the parsed bluetooth link status and given > wifi connection state. The tdma/coef table comes from the vendor > driver code of the RTL8192EU and RTL8723BU. However, this commit is > only for single antenna scenario which RTL8192EU is default dual > antenna. The rtl8xxxu_parse_rxdesc24 which invokes the handle_c2h > is only for 8723b and 8192e so the mechanism is expected to work > on both chips with single antenna. Note RTL8192EU dual antenna is > not supported. > > Signed-off-by: Chris Chiu As Jes was positive about this in v1 and had only cosmetic comments, I'm planning to apply this. If there are any changes needed, those can be fixed in a followup patch. -- https://patchwork.kernel.org/patch/11140223/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: ptrace/strace and freezer oddities and v5.2+ kernels
On Tue, Oct 1, 2019 at 10:01 PM Roman Gushchin wrote: > > On Tue, Oct 01, 2019 at 12:14:18PM -0400, Bruce Ashfield wrote: > > Hi all, > > > > Hi Bruce! > > > The Yocto project has an upcoming release this fall, and I've been trying to > > sort through some issues that are happening with kernel 5.2+ .. although > > there is a specific yocto kernel, I'm testing and seeing this with > > normal / vanilla > > mainline kernels as well. > > > > I'm running into an issue that is *very* similar to the one discussed in the > > [REGRESSION] ptrace broken from "cgroup: cgroup v2 freezer" (76f969e) > > thread from this past may: https://lkml.org/lkml/2019/5/12/272 > > > > I can confirm that I have the proposed fix for the initial regression > > report in > > my build (05b2892637 [signal: unconditionally leave the frozen state > > in ptrace_stop()]), > > but yet I'm still seeing 3 or 4 minute runtimes on a test that used to take > > 3 or > > 4 seconds. > > So, the problem is that you're experiencing a severe performance regression > in some test, right? Hi Roman, Correct. In particular, running some of the tests that ship with strace itself. The performance change is so drastic, that it definitely makes you wonder "What have I done wrong? Since everyone must be seeing this" .. and I always blame myself first. > > > > > This isn't my normal area of kernel hacking, so I've so far come up empty > > at either fixing it myself, or figuring out a viable workaround. (well, I > > can > > "fix" it by remove the cgroup_enter_frozen() call in ptrace_stop ... > > but obviously, > > that is just me trying to figure out what could be causing the issue). > > > > As part of the release, we run tests that come with various applications. > > The > > ptrace test that is causing us issues can be boiled down to this: > > > > $ cd /usr/lib/strace/ptest/tests > > $ time ../strace -o log -qq -esignal=none -e/clock ./printpath-umovestr>ttt > > > > (I can provide as many details as needed, but I wanted to keep this initial > > email relatively short). > > > > I'll continue to debug and attempt to fix this myself, but I grabbed the > > email list from the regression report in May to see if anyone has any ideas > > or angles that I haven't covered in my search for a fix. > > I'm definitely happy to help, but it's a bit hard to say anything from what > you've provided. I'm not aware of any open issues with the freezer except > some spurious cgroup frozen<->not frozen transitions which can happen in some > cases. If you'll describe how can I reproduce the issue, and I'll try to take > a look asap. That would be great. I'll attempt to remove all of the build system specifics out of this (and Richard Purdie on the cc' of this can probably help provide more details / setup info as well). We are running the built-in tests of strace. So here's a cut and paste of what I did to get the tests available (ignore/skip what is common sense or isn't needed in your test rig). % git clone https://github.com/strace/strace.git % cd strace % ./bootstrap # the --enable flag isn't strictly required, but may break on some build machines % ./configure --enable-mpers=no % make % make check-TESTS That last step will not only build the tests, but run them all .. so ^c the run once it starts, since it is a lot of noise (we carry a patch to strace that allows us to build the tests without running them). % cd tests % time strace -o log -qq -esignal=none -e/clock ./printpath-umovestr > fff real0m2.566s user0m0.284s sys 0m2.519 On pre-cgroup2 freezer kernels, you see a run time similar to what I have above. On the newer kernels we are testing, it is taking 3 or 4 minutes to run the test. I hope that is simple enough to setup and try. Since I've been seeing this on both mainline kernels and the yocto reference kernels, I don't think it is something that I'm carrying in the distro/reference kernel that is causing this (but again, I always blame myself first). If you don't see that same run time, then that does point the finger back at what we are doing and I'll have to apologize for chewing up some of your time. Cheers, Bruce > > Roman -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
[PATCH] arm64: dts: qcom: db845c: Enable LVS 1 and 2
vreg_lvs1a_1p8 and vreg_lvs2a_1p8 are both feeding pins in the low speed
connectors and should as such alway be on, so enable them.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
index c314b5d55796..6e97ae7f7a08 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
@@ -312,6 +312,18 @@
regulator-max-microvolt = <120>;
regulator-initial-mode = ;
};
+
+ vreg_lvs1a_1p8: lvs1 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ vreg_lvs2a_1p8: lvs2 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
};
pmi8998-rpmh-regulators {
--
2.18.0
Re: [PATCH v2 17/35] net/wireless: Use kmemdup rather than duplicating its implementation
Fuqian Huang wrote: > kmemdup is introduced to duplicate a region of memory in a neat way. > Rather than kmalloc/kzalloc + memcpy, which the programmer needs to > write the size twice (sometimes lead to mistakes), kmemdup improves > readability, leads to smaller code and also reduce the chances of mistakes. > Suggestion to use kmemdup rather than using kmalloc/kzalloc + memcpy. > > Signed-off-by: Fuqian Huang Patch applied to wireless-drivers-next.git, thanks. ab8c31dd8c8a net/wireless: Use kmemdup rather than duplicating its implementation -- https://patchwork.kernel.org/patch/11029833/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 0/3] PCI: pciehp: Do not turn off slot if presence comes up after link
On Tue, Oct 01, 2019 at 05:14:16PM -0400, Stuart Hayes wrote: > This patch set is based on a patch set [1] submitted many months ago by > Alexandru Gagniuc, who is no longer working on it. > > [1] https://patchwork.kernel.org/cover/10909167/ > [v3,0/4] PCI: pciehp: Do not turn off slot if presence comes up after link If I'm not mistaken, these two are identical to Alex' patches, right? PCI: pciehp: Add support for disabling in-band presence PCI: pciehp: Wait for PDS when in-band presence is disabled I'm not sure if it's appropriate to change the author and omit Alex' Signed-off-by. Otherwise I have no objections against this series. Thanks, Lukas
Re: [PATCH bpf 2/2] selftests/bpf: test_progs: don't leak server_fd in test_sockopt_inherit
Thanks for reviewing the patches Andrii!
Although Daniel fixed them and applied them correctly.
On Tue, Oct 1, 2019 at 8:20 PM Andrii Nakryiko
wrote:
>
> On Tue, Oct 1, 2019 at 10:40 AM Brian Vazquez wrote:
> >
>
> I don't think there is a need to add "test_progs:" to subject, "
> test_sockopt_inherit" is specific enough ;)
>
> > server_fd needs to be close if pthread can't be created.
>
> typo: closed
>
> >
> > Fixes: e3e02e1d9c24 ("selftests/bpf: test_progs: convert
> > test_sockopt_inherit")
> > Cc: Stanislav Fomichev
> > Signed-off-by: Brian Vazquez
> > ---
>
> Acked-by: Andrii Nakryiko
>
> > tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c
> > b/tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c
> > index 6cbeea7b4bf16..8547ecbdc61ff 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c
> > @@ -195,7 +195,7 @@ static void run_test(int cgroup_fd)
> >
> > if (CHECK_FAIL(pthread_create(, NULL, server_thread,
> > (void *)_fd)))
> > - goto close_bpf_object;
> > + goto close_server_fd;
> >
> > pthread_mutex_lock(_started_mtx);
> > pthread_cond_wait(_started, _started_mtx);
> > --
> > 2.23.0.444.g18eeb5a265-goog
> >
[PATCH v2] IB/hfi1: prevent memory leak in sdma_init
In sdma_init if rhashtable_init fails the allocated memory for
tmp_sdma_rht should be released.
Fixes: 5a52a7acf7e2 ("IB/hfi1: NULL pointer dereference when freeing
rhashtable")
Signed-off-by: Navid Emamdoost
---
Changes in v2:
-- added Fixes tag.
---
drivers/infiniband/hw/hfi1/sdma.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/hfi1/sdma.c
b/drivers/infiniband/hw/hfi1/sdma.c
index 2395fd4233a7..2ed7bfd5feea 100644
--- a/drivers/infiniband/hw/hfi1/sdma.c
+++ b/drivers/infiniband/hw/hfi1/sdma.c
@@ -1526,8 +1526,11 @@ int sdma_init(struct hfi1_devdata *dd, u8 port)
}
ret = rhashtable_init(tmp_sdma_rht, _rht_params);
- if (ret < 0)
+ if (ret < 0) {
+ kfree(tmp_sdma_rht);
goto bail;
+ }
+
dd->sdma_rht = tmp_sdma_rht;
dd_dev_info(dd, "SDMA num_sdma: %u\n", dd->num_sdma);
--
2.17.1
Re: [PATCH bpf 2/2] selftests/bpf: test_progs: don't leak server_fd in test_sockopt_inherit
On Tue, Oct 1, 2019 at 10:40 AM Brian Vazquez wrote:
>
I don't think there is a need to add "test_progs:" to subject, "
test_sockopt_inherit" is specific enough ;)
> server_fd needs to be close if pthread can't be created.
typo: closed
>
> Fixes: e3e02e1d9c24 ("selftests/bpf: test_progs: convert
> test_sockopt_inherit")
> Cc: Stanislav Fomichev
> Signed-off-by: Brian Vazquez
> ---
Acked-by: Andrii Nakryiko
> tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c
> b/tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c
> index 6cbeea7b4bf16..8547ecbdc61ff 100644
> --- a/tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c
> +++ b/tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c
> @@ -195,7 +195,7 @@ static void run_test(int cgroup_fd)
>
> if (CHECK_FAIL(pthread_create(, NULL, server_thread,
> (void *)_fd)))
> - goto close_bpf_object;
> + goto close_server_fd;
>
> pthread_mutex_lock(_started_mtx);
> pthread_cond_wait(_started, _started_mtx);
> --
> 2.23.0.444.g18eeb5a265-goog
>
linux-next: manual merge of the akpm-current tree with the jc_docs tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
Documentation/admin-guide/cgroup-v2.rst
between commit:
6ee0fac199e1 ("docs: fix memory.low description in cgroup-v2.rst")
from the jc_docs tree and commit:
3968bb6dec48 ("mm, memcg: proportional memory.{low,min} reclaim")
from the akpm-current 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/admin-guide/cgroup-v2.rst
index 26d1cde6b34a,5361ebec3361..
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@@ -1117,8 -1120,11 +1120,11 @@@ PAGE_SIZE multiple when read back
Best-effort memory protection. If the memory usage of a
cgroup is within its effective low boundary, the cgroup's
- memory won't be reclaimed unless memory can be reclaimed
- from unprotected cgroups. Above the effective low boundary (or
- effective min boundary if it is higher), pages are reclaimed
- proportionally to the overage, reducing reclaim pressure for
- smaller overages.
+ memory won't be reclaimed unless there is no reclaimable
- memory available in unprotected cgroups.
++ memory available in unprotected cgroups. Above the effective
++ low boundary (or effective min boundary if it is higher), pages
++ are reclaimed proportionally to the overage, reducing reclaim
++ pressure for smaller overages.
Effective low boundary is limited by memory.low values of
all ancestor cgroups. If there is memory.low overcommitment
pgpcl4rBMJ8TZ.pgp
Description: OpenPGP digital signature
Re: [PATCH bpf 1/2] selftests/bpf: test_progs: don't leak server_fd in tcp_rtt
On Tue, Oct 1, 2019 at 10:39 AM Brian Vazquez wrote:
>
> server_fd needs to be closed if pthread can't be created.
>
> Fixes: 8a03222f508b ("selftests/bpf: test_progs: fix client/server race
> in tcp_rtt")
Fixes tag hast to be on single line, no wrapping. Besides that:
Acked-by: Andrii Nakryiko
> Cc: Stanislav Fomichev
>
> Signed-off-by: Brian Vazquez
> ---
> tools/testing/selftests/bpf/prog_tests/tcp_rtt.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c
> b/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c
> index a82da555b1b02..f4cd60d6fba2e 100644
> --- a/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c
> +++ b/tools/testing/selftests/bpf/prog_tests/tcp_rtt.c
> @@ -260,13 +260,14 @@ void test_tcp_rtt(void)
>
> if (CHECK_FAIL(pthread_create(, NULL, server_thread,
> (void *)_fd)))
> - goto close_cgroup_fd;
> + goto close_server_fd;
>
> pthread_mutex_lock(_started_mtx);
> pthread_cond_wait(_started, _started_mtx);
> pthread_mutex_unlock(_started_mtx);
>
> CHECK_FAIL(run_test(cgroup_fd, server_fd));
> +close_server_fd:
> close(server_fd);
> close_cgroup_fd:
> close(cgroup_fd);
> --
> 2.23.0.444.g18eeb5a265-goog
>
Re: [PATCH RFC 00/14] The new slab memory controller
On Tue, Oct 01, 2019 at 05:12:02PM +0200, Michal Koutný wrote: > On Thu, Sep 05, 2019 at 02:45:44PM -0700, Roman Gushchin wrote: > > Roman Gushchin (14): > > [...] > > mm: memcg/slab: use one set of kmem_caches for all memory cgroups > From that commit's message: > > > 6) obsoletes kmem.slabinfo cgroup v1 interface file, as there are > > no per-memcg kmem_caches anymore (empty output is printed) > > The empty file means no allocations took place in the particular cgroup. > I find this quite a surprising change for consumers of these stats. > > I understand obtaining the same data efficiently from the proposed > structures is difficult, however, such a change should be avoided. (In > my understanding, obsoleted file ~ not available in v2, however, it > should not disappear from v1.) Well, my assumption is that nobody is using this file for anything except debugging purposes (I might be wrong, if somebody has an automation based on it, please, let me know). A number of allocations of each type per memory cgroup is definitely a useful debug information, but currently it barely works (displayed numbers show mostly the number of allocated pages, not the number of active objects). We can support it, but it comes with the price, and most users don't really need it. So I don't think it worth it to make all allocations slower just to keep some debug interface working for some cgroup v1 users. Do you have examples when it's really useful and worth extra cpu cost? Unfortunately, we can't enable it conditionally, as a user can switch between cgroup v1 and cgroup v2 memory controllers dynamically. Thanks!
Re: ptrace/strace and freezer oddities and v5.2+ kernels
On Tue, Oct 01, 2019 at 12:14:18PM -0400, Bruce Ashfield wrote: > Hi all, > Hi Bruce! > The Yocto project has an upcoming release this fall, and I've been trying to > sort through some issues that are happening with kernel 5.2+ .. although > there is a specific yocto kernel, I'm testing and seeing this with > normal / vanilla > mainline kernels as well. > > I'm running into an issue that is *very* similar to the one discussed in the > [REGRESSION] ptrace broken from "cgroup: cgroup v2 freezer" (76f969e) > thread from this past may: https://lkml.org/lkml/2019/5/12/272 > > I can confirm that I have the proposed fix for the initial regression report > in > my build (05b2892637 [signal: unconditionally leave the frozen state > in ptrace_stop()]), > but yet I'm still seeing 3 or 4 minute runtimes on a test that used to take 3 > or > 4 seconds. So, the problem is that you're experiencing a severe performance regression in some test, right? > > This isn't my normal area of kernel hacking, so I've so far come up empty > at either fixing it myself, or figuring out a viable workaround. (well, I can > "fix" it by remove the cgroup_enter_frozen() call in ptrace_stop ... > but obviously, > that is just me trying to figure out what could be causing the issue). > > As part of the release, we run tests that come with various applications. The > ptrace test that is causing us issues can be boiled down to this: > > $ cd /usr/lib/strace/ptest/tests > $ time ../strace -o log -qq -esignal=none -e/clock ./printpath-umovestr>ttt > > (I can provide as many details as needed, but I wanted to keep this initial > email relatively short). > > I'll continue to debug and attempt to fix this myself, but I grabbed the > email list from the regression report in May to see if anyone has any ideas > or angles that I haven't covered in my search for a fix. I'm definitely happy to help, but it's a bit hard to say anything from what you've provided. I'm not aware of any open issues with the freezer except some spurious cgroup frozen<->not frozen transitions which can happen in some cases. If you'll describe how can I reproduce the issue, and I'll try to take a look asap. Roman
Re: [v6 PATCH] RISC-V: Remove unsupported isa string info print
On Tue, Oct 01, 2019 at 03:10:16AM -0700, h...@infradead.org wrote: > On Tue, Oct 01, 2019 at 08:22:37AM +, Atish Patra wrote: > > riscv_of_processor_hartid() or seems to be a better candidate. We > > already check if "rv" is present in isa string or not. I will extend > > that to check for rv64i or rv32i. Is that okay ? > > I'd rather lift the checks out of that into a function that is called > exactly once per hart on boot (and future cpu hotplug). Sorry that I am a bit out of date on this. Is there any related discussion about such checks? Just want to make sure if the check stops here and will not go any further for extensions, Xs and Zs. > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH v2 1/1] xen-netfront: do not use ~0U as error return value for xennet_fill_frags()
From: Dongli Zhang
Date: Tue, 1 Oct 2019 21:56:41 +0800
> xennet_fill_frags() uses ~0U as return value when the sk_buff is not able
> to cache extra fragments. This is incorrect because the return type of
> xennet_fill_frags() is RING_IDX and 0x is an expected value for
> ring buffer index.
>
> In the situation when the rsp_cons is approaching 0x, the return
> value of xennet_fill_frags() may become 0x which xennet_poll() (the
> caller) would regard as error. As a result, queue->rx.rsp_cons is set
> incorrectly because it is updated only when there is error. If there is no
> error, xennet_poll() would be responsible to update queue->rx.rsp_cons.
> Finally, queue->rx.rsp_cons would point to the rx ring buffer entries whose
> queue->rx_skbs[i] and queue->grant_rx_ref[i] are already cleared to NULL.
> This leads to NULL pointer access in the next iteration to process rx ring
> buffer entries.
>
> The symptom is similar to the one fixed in
> commit 00b368502d18 ("xen-netfront: do not assume sk_buff_head list is
> empty in error handling").
>
> This patch changes the return type of xennet_fill_frags() to indicate
> whether it is successful or failed. The queue->rx.rsp_cons will be
> always updated inside this function.
>
> Fixes: ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags")
> Signed-off-by: Dongli Zhang
Applied and queued up for -stable.
Re: Many unexpected warnings with current sparse
On Tue, Oct 01, 2019 at 08:24:45PM -0500, Steve French wrote:
> On Tue, Oct 1, 2019 at 7:19 PM Luc Van Oostenryck
> wrote:
> >
> > On Tue, Oct 01, 2019 at 06:14:23PM -0500, Steve French wrote:
> > > It may be related to the following sparse make warning:
> > >
> > > No rule to make target
> > > '/usr/include/x86_64-linux-gnu/bits/huge_val.h', needed by
> > > 'sparse-llvm.o'
> > >
> > > I don't see huge_val.h in the Ubuntu 19 version of libc6-dev
> >
> > Yes, I've been bitten myself by this. It's fixed since a little while.
> > So, just doing a clean build or removing all the deps (.*.d)
> > should allow you to build sparse.
> >
> > I've verified the problem with asm and __inline in quota.h:
> > it's autodetected by kconfig (CC_HAS_ASM_INLINE) so the exact config
> > doesn't matter (only gcc's version does) but in all cases recent
> > versions of sparse don't have a problem with it
>
> Removed the dependencies and rebuilt as you suggested and it worked ...
> and even better ... with the noise removed I now see two real bugs
Ahh, good!
> (endian conversion missing on two lines) and only one possible problem
> with sparse/gcc itself
>
> Sparse now flags this line from one of Paulo's DFS features merged last year:
>
> struct smb_vol fake_vol = {0};
>
> with
>
> "warning: Using plain integer as NULL pointer"
>
> What is the recommended way to initialize a struct to avoid the sparse
> warning?
Well, personally, I simply use '{}'. GCC and sparse are happy with it but, IIRC,
it's not allowed by the standard...
> And what about the "namespace" warnings from the fscache (cache.o)
> code that now show up? I hadn't seen those before.
> Any easy way to remove them?
>
> "WARNING: module cifs uses symbol sigprocmask from namespace
> fs/cifs/cache.o: $(deps_/home/sfrench/cifs-2.6/fs/cifs/cache.o), but
> does not import it."
This one is not from sparse, it's from modpost (see EXPORT_SYMBOL_NS).
Cheers,
-- Luc
Re: [PATCH v3 0/3] selftests: netfilter: introduce test cases for ipvs
On Tue, Oct 01, 2019 at 09:34:13PM +0300, Julian Anastasov wrote: > > Hello, > > On Tue, 1 Oct 2019, Haishuang Yan wrote: > > > This series patch include test cases for ipvs. > > > > The test topology is who as below: > > +--+ > > | | | > > | ns0 | ns1 | > > | --- | ------| > > | | veth01 | - | veth10 || veth12 || > > | ---peer ------| > > | | || | > > | --- || | > > | | br0| |- peer |--| > > | --- || | > > | | || | > > | -- peer -- --- | > > | | veth02 | - | veth20 | | veth12 | | > > | -- | -- --- | > > | | ns2 | > > | | | > > +--+ > > > > Test results: > > # selftests: netfilter: ipvs.sh > > # Testing DR mode... > > # Testing NAT mode... > > # Testing Tunnel mode... > > # ipvs.sh: PASS > > ok 6 selftests: netfilter: ipvs.sh > > > > Haishuang Yan (3): > > selftests: netfilter: add ipvs test script > > selftests: netfilter: add ipvs nat test case > > selftests: netfilter: add ipvs tunnel test case > > Acked-by: Julian Anastasov > > > tools/testing/selftests/netfilter/Makefile | 2 +- > > tools/testing/selftests/netfilter/ipvs.sh | 234 > > + > > 2 files changed, 235 insertions(+), 1 deletion(-) > > create mode 100755 tools/testing/selftests/netfilter/ipvs.sh > > Regards > > -- > Julian Anastasov I still prefer #!/bin/sh in 1/3. You never know what's in someone's environment Cheers ... Duncan.
Re: [PATCH net-next v2] vsock/virtio: add support for MSG_PEEK
From: Matias Ezequiel Vara Larsen Date: Mon, 30 Sep 2019 18:25:23 + > This patch adds support for MSG_PEEK. In such a case, packets are not > removed from the rx_queue and credit updates are not sent. > > Signed-off-by: Matias Ezequiel Vara Larsen > Reviewed-by: Stefano Garzarella > Tested-by: Stefano Garzarella Applied.
Re: Many unexpected warnings with current sparse
On Tue, Oct 1, 2019 at 7:19 PM Luc Van Oostenryck
wrote:
>
> On Tue, Oct 01, 2019 at 06:14:23PM -0500, Steve French wrote:
> > It may be related to the following sparse make warning:
> >
> > No rule to make target
> > '/usr/include/x86_64-linux-gnu/bits/huge_val.h', needed by
> > 'sparse-llvm.o'
> >
> > I don't see huge_val.h in the Ubuntu 19 version of libc6-dev
>
> Yes, I've been bitten myself by this. It's fixed since a little while.
> So, just doing a clean build or removing all the deps (.*.d)
> should allow you to build sparse.
>
> I've verified the problem with asm and __inline in quota.h:
> it's autodetected by kconfig (CC_HAS_ASM_INLINE) so the exact config
> doesn't matter (only gcc's version does) but in all cases recent
> versions of sparse don't have a problem with it
Removed the dependencies and rebuilt as you suggested and it worked ...
and even better ... with the noise removed I now see two real bugs
(endian conversion missing on two lines) and only one possible problem
with sparse/gcc itself
Sparse now flags this line from one of Paulo's DFS features merged last year:
struct smb_vol fake_vol = {0};
with
"warning: Using plain integer as NULL pointer"
What is the recommended way to initialize a struct to avoid the sparse warning?
And what about the "namespace" warnings from the fscache (cache.o)
code that now show up? I hadn't seen those before.
Any easy way to remove them?
"WARNING: module cifs uses symbol sigprocmask from namespace
fs/cifs/cache.o: $(deps_/home/sfrench/cifs-2.6/fs/cifs/cache.o), but
does not import it."
--
Thanks,
Steve
Re: [PATCH v10 12/16] leds: lp55xx: Add multicolor framework support to lp55xx
Hi Dan, I love your patch! Yet something to improve: [auto build test ERROR on j.anaszewski-leds/for-next] [cannot apply to v5.4-rc1 next-20191001] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework/20191002-062337 base: https://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git for-next config: x86_64-rhel (attached as .config) compiler: gcc-7 (Debian 7.4.0-13) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> ERROR: "led_classdev_multicolor_register_ext" >> [drivers/leds/leds-lp55xx-common.ko] undefined! >> ERROR: "led_mc_calc_brightness" [drivers/leds/leds-lp55xx-common.ko] >> undefined! --- 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 v3] vsock: Fix a lockdep warning in __vsock_release()
From: Dexuan Cui Date: Mon, 30 Sep 2019 18:43:50 + > Lockdep is unhappy if two locks from the same class are held. > > Fix the below warning for hyperv and virtio sockets (vmci socket code > doesn't have the issue) by using lock_sock_nested() when __vsock_release() > is called recursively: ... > Tested-by: Stefano Garzarella > Signed-off-by: Dexuan Cui Applied, thanks.
Re: [PATCH v8 1/5] kasan: support backing vmalloc space with real shadow memory
Hi,
>> /*
>> * Find a place in the tree where VA potentially will be
>> * inserted, unless it is merged with its sibling/siblings.
>> @@ -741,6 +752,10 @@ merge_or_add_vmap_area(struct vmap_area *va,
>> if (sibling->va_end == va->va_start) {
>> sibling->va_end = va->va_end;
>>
>> +kasan_release_vmalloc(orig_start, orig_end,
>> + sibling->va_start,
>> + sibling->va_end);
>> +
> The same.
The call to kasan_release_vmalloc() is a static inline no-op if
CONFIG_KASAN_VMALLOC is not defined, which I thought was the preferred
way to do things rather than sprinkling the code with ifdefs?
The complier should be smart enough to eliminate all the
orig_state/orig_end stuff at compile time because it can see that it's
not used, so there's no cost in the binary.
Regards,
Daniel
Re: [PATCH 1/1] sched/rt: avoid contend with CFS task
On Thu, 2019-09-19 at 16:11 +0100, Qais Yousef wrote: > On 09/19/19 16:37, Vincent Guittot wrote: > > On Thu, 19 Sep 2019 at 16:32, Vincent Guittot > > wrote: > > > > > > On Thu, 19 Sep 2019 at 16:23, Qais Yousef wrote: > > > > > > > > On 09/19/19 14:27, Vincent Guittot wrote: > > > > > > > > But for requirement of performance, I think it is better to > > > > > > > > differentiate between idle CPU and CPU has CFS task. > > > > > > > > > > > > > > > > For example, we use rt-app to evaluate runnable time on > > > > > > > > non-patched environment. > > > > > > > > There are (NR_CPUS-1) heavy CFS tasks and 1 RT Task. When a CFS > > > > > > > > task is running, the RT task wakes up and choose the same CPU. > > > > > > > > The CFS task will be preempted and keep runnable until it is > > > > > > > > migrated to another cpu by load balance. > > > > > > > > But load balance is not triggered immediately, it will be > > > > > > > > triggered until timer tick hits with some condition > > > > > > > > satisfied(ex. rq->next_balance). > > > > > > > > > > > > > > Yes you will have to wait for the next tick that will trigger an > > > > > > > idle > > > > > > > load balance because you have an idle cpu and 2 runnable tack (1 > > > > > > > RT + > > > > > > > 1CFS) on the same CPU. But you should not wait for more than 1 > > > > > > > tick > > > > > > > > > > > > > > The current load_balance doesn't handle correctly the situation > > > > > > > of 1 > > > > > > > CFS and 1 RT task on same CPU while 1 CPU is idle. There is a > > > > > > > rework > > > > > > > of the load_balance that is under review on the mailing list that > > > > > > > fixes this problem and your CFS task should migrate to the idle > > > > > > > CPU > > > > > > > faster than now > > > > > > > > > > > > > > > > > > > Period load balance should be triggered when current jiffies is > > > > > > behind > > > > > > rq->next_balance, but rq->next_balance is not often exactly the same > > > > > > with next tick. > > > > > > If cpu_busy, interval = sd->balance_interval * sd->busy_factor, and > > > > > > > > > > But if there is an idle CPU on the system, the next idle load balance > > > > > should apply shortly because the busy_factor is not used for this CPU > > > > > which is not busy. > > > > > In this case, the next_balance interval is sd_weight which is probably > > > > > 4ms at cluster level and 8ms at system level in your case. This means > > > > > between 1 and 2 ticks > > > > > > > > But if the CFS task we're preempting was latency sensitive - this 1 or > > > > 2 tick > > > > is too late of a recovery. > > > > > > > > So while it's good we recover, but a preventative approach would be > > > > useful too. > > > > Just saying :-) I'm still not sure if this is the best longer term > > > > approach. > > > > > > like using a rt task ? > > > > I mean, RT task should select a sub optimal CPU because of CFS > > If you want to favor CFS compared to RT it's probably because your > > task should be RT too > > Yes possibly. But I don't think this is always doable. Especially when you're > running on generic system not a special purposed one. > > And we don't need to favor CFS over RT. But I think they can play nicely > together. > > For example on Android there are few RT tasks and rarely more than 1 runnable > RT task at a time. But if it happened to wakeup on the same CPU that is > running the UI thread you could lose a frame. And from what I've seen as well > we have 1-3 CFS tasks runnable, weighted more towards 1 task. So we do have > plenty of idle CPUs on average. > > But as I mentioned earlier I couldn't prove yet this being a serious problem. > I was hoping the use case presented here is based on a real workload, but it's > synthetic. So I agree we need stronger reasons, but I think conceptually we do > have a conflict of interest where RT task could unnecessarily hurt the > performance of CFS task. > > Another way to look at the problem is that the system is not partitioned > correctly and the admin could do a better job to prevent this. > > -- > Qais Yousef I use some third-party application, such as weibo and others, to test the application launch time. I apply this RT patch, and compare it with original design. Both RT patch test case and original design test case are already apply the patch:https://lore.kernel.org/patchwork/patch/1129117/ After apply the RT patch, launch time of weibo from 1325.72ms to 1214.88 ms, its launch time decreases 110.84ms(about 8.36%). Other applications also decrease 7~13%. At original design test case, RT tasks(surfaceflinger) could preempt some CFS tasks, if we add all these CFS tasks runnable time, it may have some impact on app launch time. So even if we already use the load balance patch and reduce a lot of CFS runnable time, I think choose idle CPU at RT scheduler could also reduce the some CFS runnable time. Best regards, Jing-Ting Wu
[PATCH v4 2/2] arm64: dts: qcom: msm8998: Add gpucc node
Add MSM8998 GPU Clock Controller DT node.
Signed-off-by: Jeffrey Hugo
---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 5a9efd749fa6..896f37c936ee 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -3,6 +3,7 @@
#include
#include
+#include
#include
#include
#include
@@ -951,6 +952,19 @@
#interrupt-cells = <0x2>;
};
+ gpucc: clock-controller@5065000 {
+ compatible = "qcom,gpucc-msm8998";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ reg = <0x05065000 0x9000>;
+
+ clocks = < RPM_SMD_XO_CLK_SRC>,
+< GPLL0_OUT_MAIN>;
+ clock-names = "xo",
+ "gpll0";
+ };
+
spmi_bus: spmi@800f000 {
compatible = "qcom,spmi-pmic-arb";
reg = <0x0800f000 0x1000>,
--
2.17.1
[PATCH v4 1/2] clk: qcom: Add MSM8998 GPU Clock Controller (GPUCC) driver
The GPUCC manages the clocks for the Adreno GPU found on MSM8998.
Signed-off-by: Jeffrey Hugo
---
drivers/clk/qcom/Kconfig | 9 +
drivers/clk/qcom/Makefile| 1 +
drivers/clk/qcom/gpucc-msm8998.c | 346 +++
3 files changed, 356 insertions(+)
create mode 100644 drivers/clk/qcom/gpucc-msm8998.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 96efee18fa6c..31a70168327c 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -230,6 +230,15 @@ config MSM_MMCC_8998
Say Y if you want to support multimedia devices such as display,
graphics, video encode/decode, camera, etc.
+config MSM_GPUCC_8998
+ tristate "MSM8998 Graphics Clock Controller"
+ select MSM_GCC_8998
+ select QCOM_GDSC
+ help
+ Support for the graphics clock controller on MSM8998 devices.
+ Say Y if you want to support graphics controller devices and
+ functionality such as 3D graphics.
+
config QCS_GCC_404
tristate "QCS404 Global Clock Controller"
help
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 0ac3c1459313..616b68f91db6 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_MSM_GCC_8994) += gcc-msm8994.o
obj-$(CONFIG_MSM_GCC_8996) += gcc-msm8996.o
obj-$(CONFIG_MSM_LCC_8960) += lcc-msm8960.o
obj-$(CONFIG_MSM_GCC_8998) += gcc-msm8998.o
+obj-$(CONFIG_MSM_GPUCC_8998) += gpucc-msm8998.o
obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
diff --git a/drivers/clk/qcom/gpucc-msm8998.c b/drivers/clk/qcom/gpucc-msm8998.c
new file mode 100644
index ..f0ccb4963885
--- /dev/null
+++ b/drivers/clk/qcom/gpucc-msm8998.c
@@ -0,0 +1,346 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, Jeffrey Hugo
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-regmap-divider.h"
+#include "clk-alpha-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+#include "reset.h"
+#include "gdsc.h"
+
+enum {
+ P_XO,
+ P_GPLL0,
+ P_GPUPLL0_OUT_EVEN,
+};
+
+/* Instead of going directly to the block, XO is routed through this branch */
+static struct clk_branch gpucc_cxo_clk = {
+ .halt_reg = 0x1020,
+ .clkr = {
+ .enable_reg = 0x1020,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gpucc_cxo_clk",
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "xo",
+ .name = "xo"
+ },
+ .num_parents = 1,
+ .ops = _branch2_ops,
+ .flags = CLK_IS_CRITICAL,
+ },
+ },
+};
+
+static const struct clk_div_table post_div_table_fabia_even[] = {
+ { 0x0, 1 },
+ { 0x1, 2 },
+ { 0x3, 4 },
+ { 0x7, 8 },
+ { }
+};
+
+static struct clk_alpha_pll gpupll0 = {
+ .offset = 0x0,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "gpupll0",
+ .parent_hws = (const struct clk_hw *[]){ _cxo_clk.clkr.hw
},
+ .num_parents = 1,
+ .ops = _alpha_pll_fixed_fabia_ops,
+ },
+};
+
+static struct clk_alpha_pll_postdiv gpupll0_out_even = {
+ .offset = 0x0,
+ .post_div_shift = 8,
+ .post_div_table = post_div_table_fabia_even,
+ .num_post_div = ARRAY_SIZE(post_div_table_fabia_even),
+ .width = 4,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "gpupll0_out_even",
+ .parent_hws = (const struct clk_hw *[]){ },
+ .num_parents = 1,
+ .ops = _alpha_pll_postdiv_fabia_ops,
+ },
+};
+
+static const struct parent_map gpu_xo_gpll0_map[] = {
+ { P_XO, 0 },
+ { P_GPLL0, 5 },
+};
+
+static const struct clk_parent_data gpu_xo_gpll0[] = {
+ { .hw = _cxo_clk.clkr.hw },
+ { .fw_name = "gpll0", .name = "gpll0" },
+};
+
+static const struct parent_map gpu_xo_gpupll0_map[] = {
+ { P_XO, 0 },
+ { P_GPUPLL0_OUT_EVEN, 1 },
+};
+
+static const struct clk_parent_data gpu_xo_gpupll0[] = {
+ { .hw = _cxo_clk.clkr.hw },
+ { .hw = _out_even.clkr.hw },
+};
+
+static const struct freq_tbl ftbl_rbcpr_clk_src[] = {
+ F(1920, P_XO, 1, 0, 0),
+ F(5000, P_GPLL0, 12, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 rbcpr_clk_src = {
+ .cmd_rcgr = 0x1030,
+ .hid_width = 5,
+ .parent_map = gpu_xo_gpll0_map,
+ .freq_tbl
Re: [PATCH v2 1/3] selftests: netfilter: add ipvs test script
On Tue, Oct 01, 2019 at 11:50:33AM +0200, Simon Horman wrote:
> On Fri, Sep 27, 2019 at 02:21:04PM +0800, Haishuang Yan wrote:
> > Test virutal server via directing routing for IPv4.
> >
> > Tested:
> >
> > # selftests: netfilter: ipvs.sh
> > # Testing DR mode...
> > # ipvs.sh: PASS
> > ok 6 selftests: netfilter: ipvs.sh
> >
> > Signed-off-by: Haishuang Yan
> > ---
> > v2: optimize test script
> > ---
> > tools/testing/selftests/netfilter/Makefile | 2 +-
> > tools/testing/selftests/netfilter/ipvs.sh | 184
> > +
> > 2 files changed, 185 insertions(+), 1 deletion(-)
> > create mode 100755 tools/testing/selftests/netfilter/ipvs.sh
> >
> > diff --git a/tools/testing/selftests/netfilter/Makefile
> > b/tools/testing/selftests/netfilter/Makefile
> > index 4144984..de1032b 100644
> > --- a/tools/testing/selftests/netfilter/Makefile
> > +++ b/tools/testing/selftests/netfilter/Makefile
> > @@ -2,6 +2,6 @@
> > # Makefile for netfilter selftests
> >
> > TEST_PROGS := nft_trans_stress.sh nft_nat.sh bridge_brouter.sh \
> > - conntrack_icmp_related.sh nft_flowtable.sh
> > + conntrack_icmp_related.sh nft_flowtable.sh ipvs.sh
> >
> > include ../lib.mk
> > diff --git a/tools/testing/selftests/netfilter/ipvs.sh
> > b/tools/testing/selftests/netfilter/ipvs.sh
> > new file mode 100755
> > index 000..658c06b
> > --- /dev/null
> > +++ b/tools/testing/selftests/netfilter/ipvs.sh
> > @@ -0,0 +1,184 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier: GPL-2.0
> > +#
> > +# End-to-end ipvs test suite
> > +# Topology:
> > +#--+
> > +# | |
> > +# ns0 | ns1 |
> > +# --- | ------|
> > +# | veth01 | - | veth10 || veth12 ||
> > +# ---peer ------|
> > +# | || |
> > +# --- || |
> > +# | br0| |- peer |--|
> > +# --- || |
> > +# | || |
> > +# -- peer -- --- |
> > +# | veth02 | - | veth20 | | veth21 | |
> > +# -- | -- --- |
> > +# | ns2 |
> > +# | |
> > +#--+
> > +#
> > +# We assume that all network driver are loaded
> > +#
> > +
> > +# Kselftest framework requirement - SKIP code is 4.
> > +ksft_skip=4
> > +ret=0
> > +GREEN='\033[0;92m'
> > +RED='\033[0;31m'
> > +NC='\033[0m' # No Color
> > +
> > +readonly port=8080
> > +
> > +readonly vip_v4=207.175.44.110
> > +readonly cip_v4=10.0.0.2
> > +readonly gip_v4=10.0.0.1
> > +readonly dip_v4=172.16.0.1
> > +readonly rip_v4=172.16.0.2
> > +readonly sip_v4=10.0.0.3
> > +
> > +readonly infile="$(mktemp)"
> > +readonly outfile="$(mktemp)"
> > +
> > +sysipvsnet=/proc/sys/net/ipv4/vs/
> > +if [ ! -d /proc/sys/net/ipv4/vs/ ]; then
> > +modprobe -q ip_vs
> > +if [ $? -ne 0 ]; then
> > +echo "SKIP: Could not run test without ipvs module"
> > + exit $ksft_skip
> > +fi
> > +fi
> > +
> > +ip -Version > /dev/null 2>&1
> > +if [ $? -ne 0 ]; then
> > + echo "SKIP: Could not run test without ip tool"
> > + exit $ksft_skip
> > +fi
> > +
> > +ipvsadm -v > /dev/null 2>&1
> > +if [ $? -ne 0 ]; then
> > + echo "SKIP: Could not run test without ipvsadm"
> > + exit $ksft_skip
> > +fi
> > +
> > +nc --version > /dev/null 2>&1
> > +if [ $? -ne 0 ]; then
> > + echo "SKIP: Could not run test without ncat"
> > + exit $ksft_skip
> > +fi
> > +
> > +setup() {
> > +ip netns add ns0
> > +ip netns add ns1
> > +ip netns add ns2
> > +
> > +ip link add veth01 netns ns0 type veth peer name veth10 netns ns1
> > +ip link add veth02 netns ns0 type veth peer name veth20 netns ns2
> > +ip link add veth12 netns ns1 type veth peer name veth21 netns ns2
> > +
> > +ip netns exec ns0 ip link set veth01 up
> > +ip netns exec ns0 ip link set veth02 up
> > +ip netns exec ns0 ip link add br0 type bridge
> > +ip netns exec ns0 ip link set veth01 master br0
> > +ip netns exec ns0 ip link set veth02 master br0
> > +ip netns exec ns0 ip link set br0 up
> > +ip netns exec ns0 ip addr add ${cip_v4}/24 dev br0
> > +
> > +ip netns exec ns1 ip link set lo up
> > +ip netns exec ns1 ip link set veth10 up
> > +ip netns exec ns1 ip addr add ${gip_v4}/24 dev veth10
> > +ip netns exec ns1 ip link set veth12 up
> > +ip netns exec ns1 ip addr add ${dip_v4}/24 dev veth12
>
[PATCH v4 0/2] MSM8998 GPUCC Support
The Adreno GPU on MSM8998 has its own clock controller, which is a dependency for bringing up the GPU. This series gets the gpucc all in place as another step on the road to getting the GPU enabled. v4: -rebase onto mmcc series -remove clk_get from the clock provider v3: -drop accepted DT patch -correct "avoid" typo -expand comment on why XO is required v2: -drop dead code Jeffrey Hugo (2): clk: qcom: Add MSM8998 GPU Clock Controller (GPUCC) driver arm64: dts: qcom: msm8998: Add gpucc node arch/arm64/boot/dts/qcom/msm8998.dtsi | 14 ++ drivers/clk/qcom/Kconfig | 9 + drivers/clk/qcom/Makefile | 1 + drivers/clk/qcom/gpucc-msm8998.c | 346 ++ 4 files changed, 370 insertions(+) create mode 100644 drivers/clk/qcom/gpucc-msm8998.c -- 2.17.1
Re: [PATCH net] hso: fix NULL-deref on tty open
From: Johan Hovold
Date: Mon, 30 Sep 2019 17:12:41 +0200
> Fix NULL-pointer dereference on tty open due to a failure to handle a
> missing interrupt-in endpoint when probing modem ports:
>
> BUG: kernel NULL pointer dereference, address: 0006
> ...
> RIP: 0010:tiocmget_submit_urb+0x1c/0xe0 [hso]
> ...
> Call Trace:
> hso_start_serial_device+0xdc/0x140 [hso]
> hso_serial_open+0x118/0x1b0 [hso]
> tty_open+0xf1/0x490
>
> Fixes: 542f54823614 ("tty: Modem functions for the HSO driver")
> Signed-off-by: Johan Hovold
Applied, thanks.
Re: [EXT] Re: [PATCH v5] arm64: dts: ls1028a: Add esdhc node in dts
On Tue, Sep 24, 2019 at 03:02:04AM +, Yinbo Zhu wrote: > Hi Shawn Guo, > > I see that you had merged my patch, but I don't see that in > url = git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git master > branch. > Please help check. My master branch will only get updated to each -rc1 tag when merge window closes. I just updated it to v5.4-rc1, and it should has your patch now. Shawn
Re: [PATCH v3 0/3] Fix typo in RWH_WRITE_LIFE_NOT_SET constant name
On 10/1/19 5:12 PM, Song Liu wrote: > On Fri, Sep 20, 2019 at 8:58 AM Eugene Syromiatnikov wrote: >> >> Hello. >> >> This is a small fix of a typo (or, more specifically, some remnant of >> the old patch version spelling) in RWH_WRITE_LIFE_NOT_SET constant, >> which is named as RWF_WRITE_LIFE_NOT_SET currently. Since the name >> with "H" is used in man page and everywhere else, it's probably worth >> to make the name used in the fcntl.h UAPI header in line with it. >> The two follow-up patches update usage sites of this constant in kernel >> to use the new spelling. >> >> The old name is retained as it is part of UAPI now. >> >> Changes since v2[1]: >> * Updated RWF_WRITE_LIFE_NOT_SET constant usage >> in drivers/md/raid5-ppl.c:ppl_init_log(). >> >> Changes since v1[2]: >> * Changed format of the commit ID in the commit message of the first patch. >> * Removed bogus Signed-off-by that snuck into the resend of the series. > > Applied to md-next. I think the core fs change should core in through a core tree, then the md bits can go in at will after that. -- Jens Axboe
Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting
On Tue, Oct 1, 2019 at 12:16 PM Nitesh Narayan Lal wrote: > > > On 10/1/19 12:21 PM, Alexander Duyck wrote: > > On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote: > >> On 01.10.19 17:29, Alexander Duyck wrote: > >>> This series provides an asynchronous means of reporting to a hypervisor > >>> that a guest page is no longer in use and can have the data associated > >>> with it dropped. To do this I have implemented functionality that allows > >>> for what I am referring to as unused page reporting. The advantage of > >>> unused page reporting is that we can support a significant amount of > >>> memory over-commit with improved performance as we can avoid having to > >>> write/read memory from swap as the VM will instead actively participate > >>> in freeing unused memory so it doesn't have to be written. > >>> > >>> The functionality for this is fairly simple. When enabled it will allocate > >>> statistics to track the number of reported pages in a given free area. > >>> When the number of free pages exceeds this value plus a high water value, > >>> currently 32, it will begin performing page reporting which consists of > >>> pulling non-reported pages off of the free lists of a given zone and > >>> placing them into a scatterlist. The scatterlist is then given to the page > >>> reporting device and it will perform the required action to make the pages > >>> "reported", in the case of virtio-balloon this results in the pages being > >>> madvised as MADV_DONTNEED. After this they are placed back on their > >>> original free list. If they are not merged in freeing an additional bit is > >>> set indicating that they are a "reported" buddy page instead of a standard > >>> buddy page. The cycle then repeats with additional non-reported pages > >>> being pulled until the free areas all consist of reported pages. > >>> > >>> In order to try and keep the time needed to find a non-reported page to > >>> a minimum we maintain a "reported_boundary" pointer. This pointer is used > >>> by the get_unreported_pages iterator to determine at what point it should > >>> resume searching for non-reported pages. In order to guarantee pages do > >>> not get past the scan I have modified add_to_free_list_tail so that it > >>> will not insert pages behind the reported_boundary. Doing this allows us > >>> to keep the overhead to a minimum as re-walking the list without the > >>> boundary will result in as much as 18% additional overhead on a 32G VM. > >>> > >>> > > > > > >>> As far as possible regressions I have focused on cases where performing > >>> the hinting would be non-optimal, such as cases where the code isn't > >>> needed as memory is not over-committed, or the functionality is not in > >>> use. I have been using the will-it-scale/page_fault1 test running with 16 > >>> vcpus and have modified it to use Transparent Huge Pages. With this I see > >>> almost no difference with the patches applied and the feature disabled. > >>> Likewise I see almost no difference with the feature enabled, but the > >>> madvise disabled in the hypervisor due to a device being assigned. With > >>> the feature fully enabled in both guest and hypervisor I see a regression > >>> between -1.86% and -8.84% versus the baseline. I found that most of the > >>> overhead was due to the page faulting/zeroing that comes as a result of > >>> the pages having been evicted from the guest. > >> I think Michal asked for a performance comparison against Nitesh's > >> approach, to evaluate if keeping the reported state + tracking inside > >> the buddy is really worth it. Do you have any such numbers already? (or > >> did my tired eyes miss them in this cover letter? :/) > >> > > I thought what Michal was asking for was what was the benefit of using the > > boundary pointer. I added a bit up above and to the description for patch > > 3 as on a 32G VM it adds up to about a 18% difference without factoring in > > the page faulting and zeroing logic that occurs when we actually do the > > madvise. > > > > Do we have a working patch set for Nitesh's code? The last time I tried > > running his patch set I ran into issues with kernel panics. If we have a > > known working/stable patch set I can give it a try. > > Did you try the v12 patch-set [1]? > I remember that you reported the CPU stall issue, which I fixed in the v12. > > [1] https://lkml.org/lkml/2019/8/12/593 So I tried testing with the spin_lock calls replaced with spin_lock _irq to resolve the IRQ issue. I also had shuffle enabled in order to increase the number of pages being dirtied. With that setup the bitmap approach is running significantly worse then my approach, even with the boundary removed. Since I had to modify the code to even getting working I am not comfortable posting numbers. My suggestion would be to look at reworking the patch set and post numbers for my patch set versus the bitmap approach and we can look at them then. I would prefer not to spend my time fixing and tuning a
Re: [PATCH] PCI: Add Loongson vendor ID and device IDs
On 10/01/2019 08:50 PM, Bjorn Helgaas wrote: On Tue, Oct 01, 2019 at 10:53:44AM +0800, Tiezhu Yang wrote: On 09/30/2019 10:02 PM, Andrew Murray wrote: On Mon, Sep 30, 2019 at 12:55:20PM +0800, Tiezhu Yang wrote: Add the Loongson vendor ID and device IDs to pci_ids.h to be used in the future. The Loongson IDs can be found at the following link: https://git.kernel.org/pub/scm/utils/pciutils/pciutils.git/tree/pci.ids Co-developed-by: Lu Zeng Signed-off-by: Lu Zeng Signed-off-by: Tiezhu Yang --- include/linux/pci_ids.h | 19 +++ 1 file changed, 19 insertions(+) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 21a5724..119639d 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -3111,4 +3111,23 @@ #define PCI_VENDOR_ID_NCUBE0x10ff +#define PCI_VENDOR_ID_LOONGSON 0x0014 +#define PCI_DEVICE_ID_LOONGSON_HT 0x7a00 +#define PCI_DEVICE_ID_LOONGSON_APB 0x7a02 +#define PCI_DEVICE_ID_LOONGSON_GMAC0x7a03 +#define PCI_DEVICE_ID_LOONGSON_OTG 0x7a04 +#define PCI_DEVICE_ID_LOONGSON_GPU_2K1000 0x7a05 +#define PCI_DEVICE_ID_LOONGSON_DC 0x7a06 +#define PCI_DEVICE_ID_LOONGSON_HDA 0x7a07 +#define PCI_DEVICE_ID_LOONGSON_SATA0x7a08 +#define PCI_DEVICE_ID_LOONGSON_PCIE_X1 0x7a09 +#define PCI_DEVICE_ID_LOONGSON_SPI 0x7a0b +#define PCI_DEVICE_ID_LOONGSON_LPC 0x7a0c +#define PCI_DEVICE_ID_LOONGSON_DMA 0x7a0f +#define PCI_DEVICE_ID_LOONGSON_EHCI0x7a14 +#define PCI_DEVICE_ID_LOONGSON_GPU_7A1000 0x7a15 +#define PCI_DEVICE_ID_LOONGSON_PCIE_X4 0x7a19 +#define PCI_DEVICE_ID_LOONGSON_OHCI0x7a24 +#define PCI_DEVICE_ID_LOONGSON_PCIE_X8 0x7a29 Hi Tiezhu, Thanks for the patch - however it is preferred to provide new PCI definitions along with the drivers that use them. They don't provide any useful value without drivers that use them. Thanks for your reply. This is the first step of the Loongson kernel team, we will submit other related individual driver patches step by step in the near future, these small patches make an easily understood change that can be verified by reviewers. There are two opposing goals here: 1) The "publish early, publish often" idea that posting small things early helps get useful feedback. 2) The idea of waiting until things can be published in logical units so readers can see context and how things fit together. I think Andrew's point (which I agree with) is that an individual trivial patch like this is not enough to give meaningful feedback. I think you'll get better feedback if you wait and collect things until you can post a series that actually fixes a bug or adds a small feature. It also makes it easier for me to track patches if I can deal with a whole series at once instead of trying to figure out which individual patches are related. So I'd encourage you to think in terms of a series of 3-10 patches that are all related and together produce something useful. That's easier for readers to digest than the same patches posted incrementally over several days or weeks. Hi Bjorn, Thanks for your valuable suggestion, it is very useful. In the next work, I will submit a series of patches as soon as possible. Thanks, Tiezhu Yang Bjorn
Re: [PATCH] nios2: force the string buffer NULL-terminated
On Mon, 2019-08-05 at 18:17 +0800, Wang Xiayang wrote: > strncpy() does not ensure NULL-termination when the input string > size equals to the destination buffer size COMMAND_LINE_SIZE. > Besides, grep under arch/ with 'boot_command_line' shows > no other arch-specific code uses strncpy() when copying > boot_command_line. > > Use strlcpy() instead. > > This issue is identified by a Coccinelle script. > > Signed-off-by: Wang Xiayang Merged to v5.4-rc1. Thanks. Acked-by: Ley Foon Tan > --- > arch/nios2/kernel/setup.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/nios2/kernel/setup.c b/arch/nios2/kernel/setup.c > index 6bbd4ae2beb0..4cf35b09c0ec 100644 > --- a/arch/nios2/kernel/setup.c > +++ b/arch/nios2/kernel/setup.c > @@ -123,7 +123,7 @@ asmlinkage void __init nios2_boot_init(unsigned > r4, unsigned r5, unsigned r6, > dtb_passed = r6; > > if (r7) > - strncpy(cmdline_passed, (char *)r7, > COMMAND_LINE_SIZE); > + strlcpy(cmdline_passed, (char *)r7, > COMMAND_LINE_SIZE); > } > #endif > > @@ -131,10 +131,10 @@ asmlinkage void __init nios2_boot_init(unsigned > r4, unsigned r5, unsigned r6, > > #ifndef CONFIG_CMDLINE_FORCE > if (cmdline_passed[0]) > - strncpy(boot_command_line, cmdline_passed, > COMMAND_LINE_SIZE); > + strlcpy(boot_command_line, cmdline_passed, > COMMAND_LINE_SIZE); > #ifdef CONFIG_NIOS2_CMDLINE_IGNORE_DTB > else > - strncpy(boot_command_line, CONFIG_CMDLINE, > COMMAND_LINE_SIZE); > + strlcpy(boot_command_line, CONFIG_CMDLINE, > COMMAND_LINE_SIZE); > #endif > #endif > > -- > 2.11.0 > > > > > Confidentiality Notice. > This message may contain information that is confidential or > otherwise protected from disclosure. If you are not the intended > recipient, you are hereby notified that any use, disclosure, > dissemination, distribution, or copying of this message, or any > attachments, is strictly prohibited. If you have received this > message in error, please advise the sender by reply e-mail, and > delete the message and any attachments. Thank you.
Re: [PATCH v7 4/4] ftrace: Add an option for tracing console latencies
On Fri, Sep 20, 2019 at 05:22:19PM +0200, Viktor Rosendahl (BMW) wrote:
> This new trace option "console-latency" will enable the latency
> tracers to trace the console latencies. Previously this has always been
> implicitely disabled. I guess this is because they are considered
> to be well known and unavoidable.
>
> However, for some organizations it may nevertheless be desirable to
> trace them. Basically, we want to be able to tell that there are
> latencies in the system under test because someone has incorrectly
> enabled the serial console.
>
> Signed-off-by: Viktor Rosendahl (BMW)
> ---
> include/linux/irqflags.h | 22 ++
> kernel/printk/printk.c | 6 --
> kernel/trace/trace.h | 1 +
> kernel/trace/trace_irqsoff.c | 12
> 4 files changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h
> index 21619c92c377..3de891723331 100644
> --- a/include/linux/irqflags.h
> +++ b/include/linux/irqflags.h
> @@ -13,6 +13,7 @@
> #define _LINUX_TRACE_IRQFLAGS_H
>
> #include
> +#include
> #include
>
> /* Currently trace_softirqs_on/off is used only by lockdep */
> @@ -68,9 +69,30 @@ do { \
> defined(CONFIG_PREEMPT_TRACER)
> extern void stop_critical_timings(void);
> extern void start_critical_timings(void);
> + extern bool console_tracing_disabled(void);
> +
> +# define console_stop_critical_timings(flag) \
> + do {\
> + typecheck(bool, flag); \
> + flag = console_tracing_disabled(); \
> + if (flag) \
> + stop_critical_timings();\
> + } while (0)
> +
> +# define console_start_critical_timings(flag) \
> + do { \
> + typecheck(bool, flag); \
> + if (flag)\
> + start_critical_timings();\
> + } while (0)
> +
> #else
> # define stop_critical_timings() do { } while (0)
> # define start_critical_timings() do { } while (0)
> +# define console_stop_critical_timings(flag) \
> + do { typecheck(bool, flag); } while (0)
> +# define console_start_critical_timings(flag)\
> + do { typecheck(bool, flag); } while (0)
> #endif
>
> /*
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 1888f6a3b694..036460a7e4cd 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2359,6 +2359,7 @@ void console_unlock(void)
> static char ext_text[CONSOLE_EXT_LOG_MAX];
> static char text[LOG_LINE_MAX + PREFIX_MAX];
> unsigned long flags;
> + bool cflag;
> bool do_cond_resched, retry;
>
> if (console_suspended) {
> @@ -2459,9 +2460,10 @@ void console_unlock(void)
>*/
> console_lock_spinning_enable();
>
> - stop_critical_timings();/* don't trace print latency */
> + /* don't trace print latency if it's disabled */
> + console_stop_critical_timings(cflag);
> call_console_drivers(ext_text, ext_len, text, len);
> - start_critical_timings();
> + console_start_critical_timings(cflag);
>
> if (console_lock_spinning_disable_and_check()) {
> printk_safe_exit_irqrestore(flags);
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 4913ed1138aa..93a8b82c27e4 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -1262,6 +1262,7 @@ extern int trace_get_user(struct trace_parser *parser,
> const char __user *ubuf,
> C(PRINTK_MSGONLY, "printk-msg-only"), \
> C(CONTEXT_INFO, "context-info"), /* Print
> pid/cpu/time */ \
> C(LATENCY_FMT, "latency-format"), \
> + C(CONSOLE_LATENCY, "console-latency"), \
> C(RECORD_CMD, "record-cmd"), \
> C(RECORD_TGID, "record-tgid"), \
> C(OVERWRITE,"overwrite"), \
> diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
> index a745b0cee5d3..bc02be207a7a 100644
> --- a/kernel/trace/trace_irqsoff.c
> +++ b/kernel/trace/trace_irqsoff.c
> @@ -456,6 +456,18 @@ void stop_critical_timings(void)
> EXPORT_SYMBOL_GPL(stop_critical_timings);
> NOKPROBE_SYMBOL(stop_critical_timings);
>
> +bool console_tracing_disabled(void)
> +{
> + struct trace_array *tr = irqsoff_trace;
> + int pc = preempt_count();
> +
> + if (!preempt_trace(pc) && !irq_trace())
> + return false;
Why this condition here? Why not just make the call to
stop_critical_timings() dependent on the new flag you are adding? Please
explain it more and
[PATCH v4] media: vimc: Implement debayer control for mean window size
Add mean window size parameter for debayer filter as a control in
vimc-debayer.
vimc-debayer was patched to allow changing mean window parameter
of the filter without needing to reload the driver. The parameter
can now be set using a v4l2-ctl control(mean_window_size).
Co-developed-by: Laís Pessine do Carmo
Signed-off-by: Laís Pessine do Carmo
Signed-off-by: Arthur Moraes do Lago
---
Changes in V2:
- Updated documentation
- Added v4l2_subev_core_ops to solve errors in v4l2-ctl compliance test
- Changed control naming to follow English capitalization rules
- Rebased to Shuah Khan's newest patch series 171283
("Collapse vimc single monolithic driver")
- Change maximum value for mean window size
Changes in V3:
- Renamed debayer control
- Fixed typo in documentation
- Freed control handler in vimc_deb_release
Changes in V4:
- Removed unecessary function and checking for setting the control
We had originally intended to leave that bit of code checking if the
value is being set to make it similar to what's done in vimc-sensor,
and in case some extra caution is needed when chaging control in the
future. But I guess they really were not necessary.
Thanks!
---
Documentation/media/v4l-drivers/vimc.rst | 10 +--
drivers/media/platform/vimc/vimc-common.h | 1 +
drivers/media/platform/vimc/vimc-debayer.c | 81 ++
3 files changed, 71 insertions(+), 21 deletions(-)
diff --git a/Documentation/media/v4l-drivers/vimc.rst
b/Documentation/media/v4l-drivers/vimc.rst
index a582af0509ee..28646c76dad5 100644
--- a/Documentation/media/v4l-drivers/vimc.rst
+++ b/Documentation/media/v4l-drivers/vimc.rst
@@ -80,9 +80,7 @@ vimc-capture:
Module options
---
-Vimc has a few module parameters to configure the driver.
-
-param=value
+Vimc has a module parameter to configure the driver.
* ``sca_mult=``
@@ -91,12 +89,6 @@ Vimc has a few module parameters to configure the driver.
original one. Currently, only supports scaling up (the default value
is 3).
-* ``deb_mean_win_size=``
-
-Window size to calculate the mean. Note: the window size needs to be an
-odd number, as the main pixel stays in the center of the window,
-otherwise the next odd number is considered (the default value is 3).
-
Source code documentation
-
diff --git a/drivers/media/platform/vimc/vimc-common.h
b/drivers/media/platform/vimc/vimc-common.h
index 236412ad7548..3a5102ddf794 100644
--- a/drivers/media/platform/vimc/vimc-common.h
+++ b/drivers/media/platform/vimc/vimc-common.h
@@ -19,6 +19,7 @@
#define VIMC_CID_VIMC_BASE (0x00f0 | 0xf000)
#define VIMC_CID_VIMC_CLASS(0x00f0 | 1)
#define VIMC_CID_TEST_PATTERN (VIMC_CID_VIMC_BASE + 0)
+#define VIMC_CID_MEAN_WIN_SIZE (VIMC_CID_VIMC_BASE + 1)
#define VIMC_FRAME_MAX_WIDTH 4096
#define VIMC_FRAME_MAX_HEIGHT 2160
diff --git a/drivers/media/platform/vimc/vimc-debayer.c
b/drivers/media/platform/vimc/vimc-debayer.c
index 37f3767db469..ba0af4b2fb9b 100644
--- a/drivers/media/platform/vimc/vimc-debayer.c
+++ b/drivers/media/platform/vimc/vimc-debayer.c
@@ -11,17 +11,12 @@
#include
#include
#include
+#include
+#include
#include
#include "vimc-common.h"
-static unsigned int deb_mean_win_size = 3;
-module_param(deb_mean_win_size, uint, );
-MODULE_PARM_DESC(deb_mean_win_size, " the window size to calculate the mean.\n"
- "NOTE: the window size needs to be an odd number, as the main pixel "
- "stays in the center of the window, otherwise the next odd number "
- "is considered");
-
enum vimc_deb_rgb_colors {
VIMC_DEB_RED = 0,
VIMC_DEB_GREEN = 1,
@@ -46,6 +41,8 @@ struct vimc_deb_device {
u8 *src_frame;
const struct vimc_deb_pix_map *sink_pix_map;
unsigned int sink_bpp;
+ unsigned int mean_win_size;
+ struct v4l2_ctrl_handler hdl;
};
static const struct v4l2_mbus_framefmt sink_fmt_default = {
@@ -346,11 +343,18 @@ static int vimc_deb_s_stream(struct v4l2_subdev *sd, int
enable)
return 0;
}
+static const struct v4l2_subdev_core_ops vimc_deb_core_ops = {
+ .log_status = v4l2_ctrl_subdev_log_status,
+ .subscribe_event = v4l2_ctrl_subdev_subscribe_event,
+ .unsubscribe_event = v4l2_event_subdev_unsubscribe,
+};
+
static const struct v4l2_subdev_video_ops vimc_deb_video_ops = {
.s_stream = vimc_deb_s_stream,
};
static const struct v4l2_subdev_ops vimc_deb_ops = {
+ .core = _deb_core_ops,
.pad = _deb_pad_ops,
.video = _deb_video_ops,
};
@@ -384,7 +388,7 @@ static void vimc_deb_calc_rgb_sink(struct vimc_deb_device
*vdeb,
* the top left corner of the mean window (considering the current
* pixel as the center)
*/
- seek = deb_mean_win_size / 2;
+ seek = vdeb->mean_win_size / 2;
/* Sum the values of the colors in the mean window */
Re: [PATCH v7 2/4] preemptirq_delay_test: Add the burst feature and a sysfs trigger
On Fri, Sep 20, 2019 at 05:22:17PM +0200, Viktor Rosendahl (BMW) wrote:
> This burst feature enables the user to generate a burst of
> preempt/irqsoff latencies. This makes it possible to test whether we
> are able to detect latencies that systematically occur very close to
> each other.
>
> The maximum burst size is 10. We also create 10 identical test
> functions, so that we get 10 different backtraces; this is useful
> when we want to test whether we can detect all the latencies in a
> burst. Otherwise, there would be no easy way of differentiating
> between which latency in a burst was captured by the tracer.
>
> In addition, there is a sysfs trigger, so that it's not necessary to
> reload the module to repeat the test. The trigger will appear as
> /sys/kernel/preemptirq_delay_test/trigger in sysfs.
>
> Signed-off-by: Viktor Rosendahl (BMW)
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> ---
> kernel/trace/Kconfig | 6 +-
> kernel/trace/preemptirq_delay_test.c | 144 +++
> 2 files changed, 128 insertions(+), 22 deletions(-)
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index e08527f50d2a..2a58380ea310 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -752,9 +752,9 @@ config PREEMPTIRQ_DELAY_TEST
> configurable delay. The module busy waits for the duration of the
> critical section.
>
> - For example, the following invocation forces a one-time irq-disabled
> - critical section for 500us:
> - modprobe preemptirq_delay_test test_mode=irq delay=50
> + For example, the following invocation generates a burst of three
> + irq-disabled critical sections for 500us:
> + modprobe preemptirq_delay_test test_mode=irq delay=500 burst_size=3
>
> If unsure, say N
>
> diff --git a/kernel/trace/preemptirq_delay_test.c
> b/kernel/trace/preemptirq_delay_test.c
> index d8765c952fab..31c0fad4cb9e 100644
> --- a/kernel/trace/preemptirq_delay_test.c
> +++ b/kernel/trace/preemptirq_delay_test.c
> @@ -10,18 +10,25 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
>
> static ulong delay = 100;
> -static char test_mode[10] = "irq";
> +static char test_mode[12] = "irq";
> +static uint burst_size = 1;
>
> -module_param_named(delay, delay, ulong, S_IRUGO);
> -module_param_string(test_mode, test_mode, 10, S_IRUGO);
> -MODULE_PARM_DESC(delay, "Period in microseconds (100 uS default)");
> -MODULE_PARM_DESC(test_mode, "Mode of the test such as preempt or irq
> (default irq)");
> +module_param_named(delay, delay, ulong, 0444);
> +module_param_string(test_mode, test_mode, 12, 0444);
> +module_param_named(burst_size, burst_size, uint, 0444);
> +MODULE_PARM_DESC(delay, "Period in microseconds (100 us default)");
> +MODULE_PARM_DESC(test_mode, "Mode of the test such as preempt, irq, or
> alternate (default irq)");
> +MODULE_PARM_DESC(burst_size, "The size of a burst (default 1)");
> +
> +#define MIN(x, y) ((x) < (y) ? (x) : (y))
>
> static void busy_wait(ulong time)
> {
> @@ -34,37 +41,136 @@ static void busy_wait(ulong time)
> } while ((end - start) < (time * 1000));
> }
>
> -static int preemptirq_delay_run(void *data)
> +static __always_inline void irqoff_test(void)
> {
> unsigned long flags;
> + local_irq_save(flags);
> + busy_wait(delay);
> + local_irq_restore(flags);
> +}
>
> - if (!strcmp(test_mode, "irq")) {
> - local_irq_save(flags);
> - busy_wait(delay);
> - local_irq_restore(flags);
> - } else if (!strcmp(test_mode, "preempt")) {
> - preempt_disable();
> - busy_wait(delay);
> - preempt_enable();
> +static __always_inline void preemptoff_test(void)
> +{
> + preempt_disable();
> + busy_wait(delay);
> + preempt_enable();
> +}
> +
> +static void execute_preemptirqtest(int idx)
> +{
> + if (!strcmp(test_mode, "irq"))
> + irqoff_test();
> + else if (!strcmp(test_mode, "preempt"))
> + preemptoff_test();
> + else if (!strcmp(test_mode, "alternate")) {
> + if (idx % 2 == 0)
> + irqoff_test();
> + else
> + preemptoff_test();
> }
> +}
> +
> +#define DECLARE_TESTFN(POSTFIX) \
> + static void preemptirqtest_##POSTFIX(int idx) \
> + { \
> + execute_preemptirqtest(idx);\
> + } \
>
> +/*
> + * We create 10 different functions, so that we can get 10 different
> + * backtraces.
> + */
> +DECLARE_TESTFN(0)
> +DECLARE_TESTFN(1)
> +DECLARE_TESTFN(2)
> +DECLARE_TESTFN(3)
> +DECLARE_TESTFN(4)
> +DECLARE_TESTFN(5)
> +DECLARE_TESTFN(6)
> +DECLARE_TESTFN(7)
> +DECLARE_TESTFN(8)
> +DECLARE_TESTFN(9)
> +
> +static void
Re: [RFC][PATCH] sysctl: Remove the sysctl system call
+Kostya (code owner for LLVM sanitizer_common) as FYI On Wed, Oct 2, 2019 at 12:54 AM Eric W. Biederman wrote: > Kees Cook writes: > > On Tue, Oct 01, 2019 at 01:36:32PM -0500, Eric W. Biederman wrote: [...] > > I think you can actually take this further and remove (or at least > > empty) the uapi/linux/sysctl.h file too. [...] > I would make it a followup that removes uapi/linux/sysctl.h. I don't > see anything in it that isn't about the sysctl system call. I will keep > it a separate patch as I can imagine something silly that needs the > header file to compile. A separate patch would make a revert easier > if we find something like that. Unfortunately, I think that header (or at least parts of it) has to stay around for now: Looking through the search results for linux/sysctl.h (ignoring glibc's sys/sysctl.h, which pulls in linux/sysctl.h, because almost all of those hits are conditional includes for BSD systems) on codesearch.debian.net, I noticed that e.g. the ASAN code that GCC and LLVM use pulls in linux/sysctl.h and uses things from it: https://github.com/llvm-mirror/compiler-rt/blob/124fd5d9aff57cf47bf077df81ad939b289acc6e/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp#L1063 And indeed, after replacing /usr/include/linux/sysctl.h with an empty file, a build of LLVM's runtime library component (compiler-rt) (git HEAD version) falls over with error spew about __sysctl_args: $ cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS='clang;compiler-rt' -DCMAKE_C_COMPILER=clang-7 -DCMAKE_CXX_COMPILER=clang++-7 -DLLVM_TARGETS_TO_BUILD="X86" -DLLVM_USE_LINKER=lld-7 -DBUILD_SHARED_LIBS=Off ../llvm [...] $ ninja -j64 FAILED: projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.i386.dir/sanitizer_platform_limits_posix.cpp.o [...] [...]/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp:1063:17: error: use of undeclared identifier '__sysctl_args' CHECK_TYPE_SIZE(__sysctl_args); ^ [...]/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp:1064:23: error: use of undeclared identifier '__sysctl_args' CHECK_SIZE_AND_OFFSET(__sysctl_args, name); ^ [...]/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp:1064:1: error: expected expression CHECK_SIZE_AND_OFFSET(__sysctl_args, name); ^ [...]/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.h:1438:34: note: expanded from macro 'CHECK_SIZE_AND_OFFSET' sizeof(((CLASS *)NULL)->MEMBER));\ ^ [...]/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp:1064:23: error: unknown type name '__sysctl_args' CHECK_SIZE_AND_OFFSET(__sysctl_args, name); ^
[PATCH] ARM: dts: imx6q-logicpd: Fix 3.3V regulator on SDHC1
NVCC_SD1 is driven by a selector which chooses between 3.3V and
1.8. Currently, this is pulled down by a 10k resistor, but
occasionally, voltage spikes on this rail cause the regulator to
jump between 1.8 and 3.3V.
This patch explicitly sets GPIO_19 to choose the 3.3V rail by
forcing this IO pin low to stabilize NVCC_SD1.
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/imx6-logicpd-som.dtsi
b/arch/arm/boot/dts/imx6-logicpd-som.dtsi
index 547fb141ec0c..233762acbaaf 100644
--- a/arch/arm/boot/dts/imx6-logicpd-som.dtsi
+++ b/arch/arm/boot/dts/imx6-logicpd-som.dtsi
@@ -15,6 +15,18 @@
reg = <0x1000 0x8000>;
};
+ reg_sdhc1: regulator-sdhc1 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <_reg_sdhc1>;
+ regulator-name = "reg_sdhc1";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = < 5 GPIO_ACTIVE_LOW>;
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
+
reg_wl18xx_vmmc: regulator-wl18xx {
compatible = "regulator-fixed";
regulator-name = "vwl1837";
@@ -267,6 +279,12 @@
>;
};
+ pinctrl_reg_sdhc1: regsdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_19__GPIO4_IO05 0x1b0b0
+ >;
+ };
+
pinctrl_tempsense: tempsensegrp {
fsl,pins = <
MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x1b0b0
@@ -343,7 +361,9 @@
non-removable;
keep-power-in-suspend;
wakeup-source;
+ no-1-8-v;
vmmc-supply = <_reg>;
+ vqmmc-supply = <_sdhc1>;
status = "okay";
};
--
2.17.1
[PATCH] ARM: dts: imx6q-logicpd: Fix 3.3V regulator on SDHC1
NVCC_SD1 is driven by a selector which chooses between 3.3V and
1.8. Currently, this is pulled down by a 10k resistor, but
occasionally, voltage spikes on this rail cause the regulator to
jump between 1.8 and 3.3V.
This patch explicitly sets GPIO_19 to choose the 3.3V rail by
forcing this IO pin low to stabilize NVCC_SD1.
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/imx6-logicpd-som.dtsi
b/arch/arm/boot/dts/imx6-logicpd-som.dtsi
index 547fb141ec0c..233762acbaaf 100644
--- a/arch/arm/boot/dts/imx6-logicpd-som.dtsi
+++ b/arch/arm/boot/dts/imx6-logicpd-som.dtsi
@@ -15,6 +15,18 @@
reg = <0x1000 0x8000>;
};
+ reg_sdhc1: regulator-sdhc1 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <_reg_sdhc1>;
+ regulator-name = "reg_sdhc1";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = < 5 GPIO_ACTIVE_LOW>;
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
+
reg_wl18xx_vmmc: regulator-wl18xx {
compatible = "regulator-fixed";
regulator-name = "vwl1837";
@@ -267,6 +279,12 @@
>;
};
+ pinctrl_reg_sdhc1: regsdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_19__GPIO4_IO05 0x1b0b0
+ >;
+ };
+
pinctrl_tempsense: tempsensegrp {
fsl,pins = <
MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x1b0b0
@@ -343,7 +361,9 @@
non-removable;
keep-power-in-suspend;
wakeup-source;
+ no-1-8-v;
vmmc-supply = <_reg>;
+ vqmmc-supply = <_sdhc1>;
status = "okay";
};
--
2.17.1
Re: [PATCH v7 1/4] ftrace: Implement fs notification for tracing_max_latency
Some nits, but others looks good:
On Fri, Sep 20, 2019 at 05:22:16PM +0200, Viktor Rosendahl (BMW) wrote:
> This patch implements the feature that the tracing_max_latency file,
> e.g. /sys/kernel/debug/tracing/tracing_max_latency will receive
> notifications through the fsnotify framework when a new latency is
> available.
>
> One particularly interesting use of this facility is when enabling
> threshold tracing, through /sys/kernel/debug/tracing/tracing_thresh,
> together with the preempt/irqsoff tracers. This makes it possible to
> implement a user space program that can, with equal probability,
> obtain traces of latencies that occur immediately after each other in
> spite of the fact that the preempt/irqsoff tracers operate in overwrite
> mode.
>
> This facility works with the hwlat, preempt/irqsoff, and wakeup
> tracers.
>
> The tracers may call the latency_fsnotify() from places such as
> __schedule() or do_idle(); this makes it impossible to call
> queue_work() directly without risking a deadlock. The same would
> happen with a softirq, kernel thread or tasklet. For this reason we
> use the irq_work mechanism to call queue_work().
>
> This patch creates a new workqueue. The reason for doing this is that
> I wanted to use the WQ_UNBOUND and WQ_HIGHPRI flags. My thinking was
> that WQ_UNBOUND might help with the latency in some important cases.
>
> If we use:
>
> queue_work(system_highpri_wq, >fsnotify_work);
>
> then the work will (almost) always execute on the same CPU but if we are
> unlucky that CPU could be too busy while there could be another CPU in
> the system that would be able to process the work soon enough.
>
> queue_work_on() could be used to queue the work on another CPU but it
> seems difficult to select the right CPU.
>
> Signed-off-by: Viktor Rosendahl (BMW)
> ---
> kernel/trace/trace.c | 75 +-
> kernel/trace/trace.h | 18 +
> kernel/trace/trace_hwlat.c | 4 +-
> 3 files changed, 94 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 947ba433865f..2d2150bf0d42 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -44,6 +44,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> #include "trace.h"
> #include "trace_output.h"
> @@ -1480,6 +1483,74 @@ static ssize_t trace_seq_to_buffer(struct trace_seq
> *s, void *buf, size_t cnt)
>
> unsigned long __read_mostly tracing_thresh;
>
> +#if (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)) && \
> + defined(CONFIG_FSNOTIFY)
> +
> +static const struct file_operations tracing_max_lat_fops;
> +static struct workqueue_struct *fsnotify_wq;
> +
> +static void latency_fsnotify_workfn(struct work_struct *work)
> +{
> + struct trace_array *tr = container_of(work, struct trace_array,
> + fsnotify_work);
> + fsnotify(tr->d_max_latency->d_inode, FS_MODIFY,
> + tr->d_max_latency->d_inode, FSNOTIFY_EVENT_INODE, NULL, 0);
> +}
> +
> +static void latency_fsnotify_workfn_irq(struct irq_work *iwork)
> +{
> + struct trace_array *tr = container_of(iwork, struct trace_array,
> + fsnotify_irqwork);
> + queue_work(fsnotify_wq, >fsnotify_work);
> +}
> +
> +static void trace_create_maxlat_file(struct trace_array *tr,
> + struct dentry *d_tracer)
> +{
> + INIT_WORK(>fsnotify_work, latency_fsnotify_workfn);
> + init_irq_work(>fsnotify_irqwork, latency_fsnotify_workfn_irq);
> + tr->d_max_latency = trace_create_file("tracing_max_latency", 0644,
> + d_tracer, >max_latency,
> + _max_lat_fops);
> +}
> +
> +__init static int latency_fsnotify_init(void)
> +{
> + fsnotify_wq = alloc_workqueue("tr_max_lat_wq",
> + WQ_UNBOUND | WQ_HIGHPRI, 0);
> + if (!fsnotify_wq) {
> + pr_err("Unable to allocate tr_max_lat_wq\n");
> + return -ENOMEM;
> + }
> + return 0;
> +}
> +
> +late_initcall_sync(latency_fsnotify_init);
> +
> +void latency_fsnotify(struct trace_array *tr)
> +{
> + if (!fsnotify_wq)
> + return;
> + /*
> + * We cannot call queue_work(>fsnotify_work) from here because it's
> + * possible that we are called from __schedule() or do_idle(), which
> + * could cause a deadlock.
> + */
> + irq_work_queue(>fsnotify_irqwork);
> +}
> +
> +/*
> + * (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)) && \
> + * defined(CONFIG_FSNOTIFY)
> + */
> +#else
> +
> +#define trace_create_maxlat_file(tr, d_tracer)
> \
> + trace_create_file("tracing_max_latency", 0644, d_tracer,\
> + >max_latency, _max_lat_fops)
I would forward declare tracing_max_lat_fops here as
Re: [PATCH v10 12/16] leds: lp55xx: Add multicolor framework support to lp55xx
Hi Dan,
I love your patch! Yet something to improve:
[auto build test ERROR on j.anaszewski-leds/for-next]
[cannot apply to v5.4-rc1 next-20191001]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework/20191002-062337
base:
https://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git
for-next
config: x86_64-randconfig-f004-201939 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
ld: drivers/leds/leds-lp55xx-common.o: in function `lp55xx_set_brightness':
>> drivers/leds/leds-lp55xx-common.c:158: undefined reference to
>> `led_mc_calc_brightness'
ld: drivers/leds/leds-lp55xx-common.o: in function
`led_classdev_multicolor_register':
>> include/linux/led-class-multicolor.h:64: undefined reference to
>> `led_classdev_multicolor_register_ext'
vim +158 drivers/leds/leds-lp55xx-common.c
147
148 static int lp55xx_set_brightness(struct led_classdev *cdev,
149 enum led_brightness brightness)
150 {
151 struct lp55xx_led *led = cdev_to_lp55xx_led(cdev);
152 struct lp55xx_device_config *cfg = led->chip->cfg;
153 int channel_num;
154 int ret;
155 int i;
156
157 if (led->mc_cdev.num_leds > 1) {
> 158 led_mc_calc_brightness(>mc_cdev, brightness,
159 _component[0]);
160
161 for (i = 0; i < led->mc_cdev.num_leds; i++) {
162 channel_num = lp55xx_get_channel(led,
163
color_component[i].color_id);
164 if (channel_num < 0)
165 return channel_num;
166
167 ret = cfg->color_intensity_fn(led, channel_num,
168
color_component[i].brightness);
169 if (ret)
170 return ret;
171 }
172 } else {
173 led->brightness = (u8)brightness;
174 ret = cfg->brightness_fn(led);
175 }
176
177 return ret;
178 }
179
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] acpi/hmat: ACPI_HMAT_MEMORY_PD_VALID is deprecated in ACPI-6.3
On Tue, 3 Sep 2019 11:03:45 +1000 Daniel Black wrote: > On Mon, 2 Sep 2019 23:28:50 +0200 > "Rafael J. Wysocki" wrote: > > > On Tue, Aug 6, 2019 at 6:24 AM Daniel Black wrote: > > > > > > ACPI-6.3 corresponds to when hmat revision was bumped from > > > 1 to 2. In this version ACPI_HMAT_MEMORY_PD_VALID was > > > deprecated and made reserved. > > > > > > As such in revision 2+ we shouldn't be testing this flag. > > > > > > This is as per ACPI-6.3, 5.2.27.3, Table 5-145 > > > "Memory Proximity Domain Attributes Structure" > > > for Flags. > > > > > > Signed-off-by: Daniel Black > > > > Keith, any comments? > > FYI this was found when I was testing Tao Xu's qemu implementation of HMAT > ACPI-6.3 which has no implementation of ACPI_HMAT_MEMORY_PD_VALID. > > Current patch implementing Memory Proximity Domain Attributes Structure: > https://patchwork.kernel.org/patch/11125301/ On Mon, 12 Aug 2019 16:03:15 +0800 Tao Xu wrote: > > Looks good to me. > > Reviewed-by: Tao Xu Ping. Any comments?
[PATCH] ARM: dts: imx6q-logicpd: Re-Enable SNVS power key
A previous patch disabled the SNVS power key by default which
breaks the ability for the imx6q-logicpd board to wake from sleep.
This patch re-enables this feature for this board.
Fixes: 770856f0da5d ("ARM: dts: imx6qdl: Enable SNVS power key according to
board design")
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/imx6-logicpd-som.dtsi
b/arch/arm/boot/dts/imx6-logicpd-som.dtsi
index 7ceae3573248..547fb141ec0c 100644
--- a/arch/arm/boot/dts/imx6-logicpd-som.dtsi
+++ b/arch/arm/boot/dts/imx6-logicpd-som.dtsi
@@ -207,6 +207,10 @@
vin-supply = <_reg>;
};
+_poweroff {
+ status = "okay";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_hog>;
--
2.17.1
Re: [PATCH v6 00/19] More improvements for Tegra30 devfreq driver
Hello Dmitry and Thierry, On 19. 10. 2. 오전 6:15, Dmitry Osipenko wrote: > 12.08.2019 00:22, Dmitry Osipenko пишет: >> Hello, >> >> This series addresses some additional review comments that were made by >> Thierry Reding to [1], makes several important changes to the driver, >> fixing excessive interrupts activity, and adds new features. In the end >> I'm proposing myself as a maintainer for the Tegra devfreq drivers. >> >> [1] >> https://lore.kernel.org/lkml/0fb50eb1-a173-1756-6889-2526a10ac...@gmail.com/T/ >> >> Changelog: >> >> v6: Addressed review comment that was made by Chanwoo Choi to v5 by >> squashing "Define ACTMON_DEV_CTRL_STOP" patch into the "Use CPUFreq >> notifier" patch. >> >> v5: Addressed review comments that were made by Chanwoo Choi to v4 by >> squashing few patches, dropping some questionable patches, rewording >> comments to the code, restructuring the code and etc. >> >> These patches are now dropped from the series: >> >>PM / devfreq: tegra30: Use tracepoints for debugging >>PM / devfreq: tegra30: Inline all one-line functions >> >> The interrupt-optimization patches are squashed into a single patch: >> >>PM / devfreq: tegra30: Reduce unnecessary interrupts activity >> >> because it's better to keep the optimizations as a separate change and >> this also helps to reduce code churning, since the code changes depend >> on a previous patch in order to stay cleaner. >> >> Fixed a lockup bug that I spotted recently, which is caused by a >> clk-notifier->cpufreq_get()->clk_set_rate() sequence. Now a non-blocking >> variant of CPU's frequency retrieving is used, i.e. cpufreq_quick_get(). >> >> Further optimized the CPUFreq notifier by postponing the delayed >> updating in accordance to the polling interval, this actually uncovered >> the above lockup bug. >> >> Implemented new minor driver feature in the new patch: >> >>PM / devfreq: tegra30: Support variable polling interval >> >> v4: Added two new patches to the series: >> >>PM / devfreq: tegra30: Synchronize average count on target's update >>PM / devfreq: tegra30: Increase sampling period to 16ms >> >> The first patch addresses problem where governor could get stuck due >> to outdated "average count" value which is snapshoted by ISR and there >> are cases where manual update of the value is required. >> >> The second patch is just a minor optimization. >> >> v3: Added support for tracepoints, replacing the debug messages. >> Fixed few more bugs with the help of tracepoints. >> >> New patches in this version: >> >>PM / devfreq: tegra30: Use tracepoints for debugging >>PM / devfreq: tegra30: Optimize CPUFreq notifier >>PM / devfreq: tegra30: Optimize upper consecutive watermark selection >>PM / devfreq: tegra30: Optimize upper average watermark selection >>PM / devfreq: tegra30: Include appropriate header >> >> Some of older patches of this series also got some extra minor polish. >> >> v2: Added more patches that are cleaning driver's code further and >> squashing another kHz conversion bug. >> >> The patch "Rework frequency management logic" of the v1 series is now >> converted to "Set up watermarks properly" because I found some problems >> in the original patch and then realized that there is no need to change >> the logic much. So the logic mostly preserved and only got improvements. >> >> The series is based on the today's linux-next (25 Jun) and takes into >> account minor changes that MyungJoo Ham made to the already queued >> patches from the first batch [1]. >> >> Dmitry Osipenko (19): >> PM / devfreq: tegra30: Change irq type to unsigned int >> PM / devfreq: tegra30: Keep interrupt disabled while governor is >> stopped >> PM / devfreq: tegra30: Handle possible round-rate error >> PM / devfreq: tegra30: Drop write-barrier >> PM / devfreq: tegra30: Set up watermarks properly >> PM / devfreq: tegra30: Tune up boosting thresholds >> PM / devfreq: tegra30: Fix integer overflow on CPU's freq max out >> PM / devfreq: tegra30: Ensure that target freq won't overflow >> PM / devfreq: tegra30: Use kHz units uniformly in the code >> PM / devfreq: tegra30: Reduce unnecessary interrupts activity >> PM / devfreq: tegra30: Use CPUFreq notifier >> PM / devfreq: tegra30: Move clk-notifier's registration to governor's >> start >> PM / devfreq: tegra30: Reset boosting on startup >> PM / devfreq: tegra30: Don't enable consecutive-down interrupt on >> startup >> PM / devfreq: tegra30: Constify structs >> PM / devfreq: tegra30: Include appropriate header >> PM / devfreq: tegra30: Increase sampling period to 16ms >> PM / devfreq: tegra30: Support variable polling interval >> PM / devfreq: tegra20/30: Add Dmitry as a maintainer >> >> MAINTAINERS
[PATCH] ARM: dts: imx6q-logicpd: Re-Enable SNVS power key
A previous patch disabled the SNVS power key by default which
breaks the ability for the imx6q-logicpd board to wake from sleep.
This patch re-enables this feature for this board.
Fixes: 770856f0da5d ("ARM: dts: imx6qdl: Enable SNVS power key according to
board design")
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/imx6-logicpd-som.dtsi
b/arch/arm/boot/dts/imx6-logicpd-som.dtsi
index 7ceae3573248..547fb141ec0c 100644
--- a/arch/arm/boot/dts/imx6-logicpd-som.dtsi
+++ b/arch/arm/boot/dts/imx6-logicpd-som.dtsi
@@ -207,6 +207,10 @@
vin-supply = <_reg>;
};
+_poweroff {
+ status = "okay";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_hog>;
--
2.17.1
Re: Many unexpected warnings with current sparse
On Tue, Oct 01, 2019 at 06:14:23PM -0500, Steve French wrote: > It may be related to the following sparse make warning: > > No rule to make target > '/usr/include/x86_64-linux-gnu/bits/huge_val.h', needed by > 'sparse-llvm.o' > > I don't see huge_val.h in the Ubuntu 19 version of libc6-dev Yes, I've been bitten myself by this. It's fixed since a little while. So, just doing a clean build or removing all the deps (.*.d) should allow you to build sparse. I've verified the problem with asm and __inline in quota.h: it's autodetected by kconfig (CC_HAS_ASM_INLINE) so the exact config doesn't matter (only gcc's version does) but in all cases recent versions of sparse don't have a problem with it (an upstream version of `sparse --version` should return "v0.6.1-rc1-37-gd466a0281"). Best regards, -- Luc
Re: [PATCH v10 06/16] leds: lp50xx: Add the LP50XX family of the RGB LED driver
Hi Dan,
I love your patch! Yet something to improve:
[auto build test ERROR on j.anaszewski-leds/for-next]
[cannot apply to v5.4-rc1 next-20191001]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework/20191002-062337
base:
https://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git
for-next
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/leds/leds-lp50xx.c:358:27: error: initializer element is not constant
.lp50xx_regmap_config = lp5012_regmap_config,
^~~~
drivers/leds/leds-lp50xx.c:358:27: note: (near initialization for
'lp50xx_chip_info_tbl[0].lp50xx_regmap_config')
drivers/leds/leds-lp50xx.c:368:27: error: initializer element is not constant
.lp50xx_regmap_config = lp5012_regmap_config,
^~~~
drivers/leds/leds-lp50xx.c:368:27: note: (near initialization for
'lp50xx_chip_info_tbl[1].lp50xx_regmap_config')
drivers/leds/leds-lp50xx.c:378:27: error: initializer element is not constant
.lp50xx_regmap_config = lp5024_regmap_config,
^~~~
drivers/leds/leds-lp50xx.c:378:27: note: (near initialization for
'lp50xx_chip_info_tbl[2].lp50xx_regmap_config')
drivers/leds/leds-lp50xx.c:388:27: error: initializer element is not constant
.lp50xx_regmap_config = lp5024_regmap_config,
^~~~
drivers/leds/leds-lp50xx.c:388:27: note: (near initialization for
'lp50xx_chip_info_tbl[3].lp50xx_regmap_config')
drivers/leds/leds-lp50xx.c:398:27: error: initializer element is not constant
.lp50xx_regmap_config = lp5036_regmap_config,
^~~~
drivers/leds/leds-lp50xx.c:398:27: note: (near initialization for
'lp50xx_chip_info_tbl[4].lp50xx_regmap_config')
drivers/leds/leds-lp50xx.c:408:27: error: initializer element is not constant
.lp50xx_regmap_config = lp5036_regmap_config,
^~~~
drivers/leds/leds-lp50xx.c:408:27: note: (near initialization for
'lp50xx_chip_info_tbl[5].lp50xx_regmap_config')
vim +358 drivers/leds/leds-lp50xx.c
348
349 static const struct lp50xx_chip_info lp50xx_chip_info_tbl[] = {
350 [LP5009] = {
351 .model_id = LP5009,
352 .num_leds = LP5009_MAX_LEDS,
353 .led_brightness0_reg = LP5012_LED0_BRT,
354 .mix_out0_reg = LP5012_OUT0_CLR,
355 .bank_brt_reg = LP5012_BNK_BRT,
356 .bank_mix_reg = LP5012_BNKA_CLR,
357 .reset_reg = LP5012_RESET,
> 358 .lp50xx_regmap_config = lp5012_regmap_config,
359 },
360 [LP5012] = {
361 .model_id = LP5012,
362 .num_leds = LP5012_MAX_LEDS,
363 .led_brightness0_reg = LP5012_LED0_BRT,
364 .mix_out0_reg = LP5012_OUT0_CLR,
365 .bank_brt_reg = LP5012_BNK_BRT,
366 .bank_mix_reg = LP5012_BNKA_CLR,
367 .reset_reg = LP5012_RESET,
368 .lp50xx_regmap_config = lp5012_regmap_config,
369 },
370 [LP5018] = {
371 .model_id = LP5018,
372 .num_leds = LP5018_MAX_LEDS,
373 .led_brightness0_reg = LP5024_LED0_BRT,
374 .mix_out0_reg = LP5024_OUT0_CLR,
375 .bank_brt_reg = LP5024_BNK_BRT,
376 .bank_mix_reg = LP5024_BNKA_CLR,
377 .reset_reg = LP5024_RESET,
378 .lp50xx_regmap_config = lp5024_regmap_config,
379 },
380 [LP5024] = {
381 .model_id = LP5024,
382 .num_leds = LP5024_MAX_LEDS,
383 .led_brightness0_reg = LP5024_LED0_BRT,
384 .mix_out0_reg = LP5024_OUT0_CLR,
385 .bank_brt_reg = LP5024_BNK_BRT,
386 .bank_mix_reg = LP5024_BNKA_CLR,
387 .reset_reg = LP5024_RESET,
388 .lp50xx_regmap_config = lp5024_regmap_config,
389 },
390
Re: [PATCH 14/15] mm: Align THP mappings for non-DAX
On Tue, Oct 01, 2019 at 10:08:30AM -0600, William Kucharski wrote:
>
>
> > On Oct 1, 2019, at 8:20 AM, Kirill A. Shutemov wrote:
> >
> > On Tue, Oct 01, 2019 at 06:18:28AM -0600, William Kucharski wrote:
> >>
> >>
> >> On 10/1/19 5:32 AM, Kirill A. Shutemov wrote:
> >>> On Tue, Oct 01, 2019 at 05:21:26AM -0600, William Kucharski wrote:
>
>
> > On Oct 1, 2019, at 4:45 AM, Kirill A. Shutemov
> > wrote:
> >
> > On Tue, Sep 24, 2019 at 05:52:13PM -0700, Matthew Wilcox wrote:
> >>
> >> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> >> index cbe7d0619439..670a1780bd2f 100644
> >> --- a/mm/huge_memory.c
> >> +++ b/mm/huge_memory.c
> >> @@ -563,8 +563,6 @@ unsigned long thp_get_unmapped_area(struct file
> >> *filp, unsigned long addr,
> >>
> >>if (addr)
> >>goto out;
> >> - if (!IS_DAX(filp->f_mapping->host) ||
> >> !IS_ENABLED(CONFIG_FS_DAX_PMD))
> >> - goto out;
> >>
> >>addr = __thp_get_unmapped_area(filp, len, off, flags, PMD_SIZE);
> >>if (addr)
> >
> > I think you reducing ASLR without any real indication that THP is
> > relevant
> > for the VMA. We need to know if any huge page allocation will be
> > *attempted* for the VMA or the file.
>
> Without a properly aligned address the code will never even attempt
> allocating
> a THP.
>
> I don't think rounding an address to one that would be properly aligned
> to map
> to a THP if possible is all that detrimental to ASLR and without the
> ability to
> pick an aligned address it's rather unlikely anyone would ever map
> anything to
> a THP unless they explicitly designate an address with MAP_FIXED.
>
> If you do object to the slight reduction of the ASLR address space, what
> alternative would you prefer to see?
> >>>
> >>> We need to know by the time if THP is allowed for this
> >>> file/VMA/process/whatever. Meaning that we do not give up ASLR entropy for
> >>> nothing.
> >>>
> >>> For instance, if THP is disabled globally, there is no reason to align the
> >>> VMA to the THP requirements.
> >>
> >> I understand, but this code is in thp_get_unmapped_area(), which is only
> >> called
> >> if THP is configured and the VMA can support it.
> >>
> >> I don't see it in Matthew's patchset, so I'm not sure if it was
> >> inadvertently
> >> missed in his merge or if he has other ideas for how it would eventually be
> >> called, but in my last patch revision the code calling it in do_mmap()
> >> looked like this:
> >>
> >> #ifdef CONFIG_RO_EXEC_FILEMAP_HUGE_FAULT_THP
> >>/*
> >> * If THP is enabled, it's a read-only executable that is
> >> * MAP_PRIVATE mapped, the length is larger than a PMD page
> >> * and either it's not a MAP_FIXED mapping or the passed address is
> >> * properly aligned for a PMD page, attempt to get an appropriate
> >> * address at which to map a PMD-sized THP page, otherwise call the
> >> * normal routine.
> >> */
> >>if ((prot & PROT_READ) && (prot & PROT_EXEC) &&
> >>(!(prot & PROT_WRITE)) && (flags & MAP_PRIVATE) &&
> >>(!(flags & MAP_FIXED)) && len >= HPAGE_PMD_SIZE) {
> >
> > len and MAP_FIXED is already handled by thp_get_unmapped_area().
> >
> > if (prot & (PROT_READ|PROT_WRITE|PROT_READ) == (PROT_READ|PROT_EXEC) &&
> > (flags & MAP_PRIVATE)) {
>
> It is, but I wanted to avoid even calling it if conditions weren't right.
>
> Checking twice is non-optimal but I didn't want to alter the existing use of
> the routine for anon THP.
It's not used by anon THP. It used for DAX.
> >
> >
> >>addr = thp_get_unmapped_area(file, addr, len, pgoff, flags);
> >>
> >>if (addr && (!(addr & ~HPAGE_PMD_MASK))) {
> >
> > This check is broken.
> >
> > For instance, if pgoff is one, (addr & ~HPAGE_PMD_MASK) has to be equal to
> > PAGE_SIZE to have chance to get a huge page in the mapping.
> >
>
> If the address isn't PMD-aligned, we will never be able to map it with a THP
> anyway.
The opposite is true. I tried to explain it few times, but let's try
again.
If the address here is PMD-aligned, it will get a mismatch with page cache
alignment.
Consider the case with 2 huge pages in page cache, starting at the
beginning of the file.
The key to understanding: huge pages always aligned naturally in page
cache. Page cache lives longer than any mapping of the file.
If user calls mmap(.pgoff = 1) and it returns PMD-aligned address, we will
never have a huge page in the mapping. At the PMD-aligned address you will
get the second 4k of the first huge page and you will have to map it with
PTE. At the second PMD-aligned address of the mapping, the situation will
repeat for the second huge page, again misaligned, PTE-mapped second
Re: [PATCH v6 18/19] PM / devfreq: tegra30: Support variable polling interval
Hi,
On 19. 8. 12. 오전 6:23, Dmitry Osipenko wrote:
> The ACTMON governor is interrupt-driven and currently hardware's polling
> interval is fixed to 16ms in the driver. Devfreq supports variable polling
> interval by the generic governors, let's re-use the generic interface for
> changing of the polling interval. Now the polling interval can be changed
> dynamically via /sys/class/devfreq/devfreq0/polling_interval.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 71 ++-
> 1 file changed, 50 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 8adc0ff48b45..e30314bd571a 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -236,7 +237,7 @@ tegra_actmon_dev_avg_dependency_freq(struct tegra_devfreq
> *tegra,
>struct tegra_devfreq_device *dev)
> {
> return dev->config->avg_dependency_threshold /
> - ACTMON_SAMPLING_PERIOD;
> + tegra->devfreq->profile->polling_ms;
> }
>
> static unsigned long
> @@ -314,8 +315,8 @@ static void tegra_actmon_get_lower_upper(struct
> tegra_devfreq *tegra,
>*/
> *upper = tegra_actmon_account_cpu_freq(tegra, dev, *upper);
>
> - *lower *= ACTMON_SAMPLING_PERIOD;
> - *upper *= ACTMON_SAMPLING_PERIOD;
> + *lower *= tegra->devfreq->profile->polling_ms;
> + *upper *= tegra->devfreq->profile->polling_ms;
> }
>
> static void tegra_devfreq_update_avg_wmark(struct tegra_devfreq *tegra,
> @@ -341,8 +342,8 @@ static void tegra_devfreq_update_avg_wmark(struct
> tegra_devfreq *tegra,
>* result, but this one is probably the least churning, although
>* it may look a bit convoluted.
>*/
> - if (freq * ACTMON_SAMPLING_PERIOD > upper)
> - upper = freq * ACTMON_SAMPLING_PERIOD;
> + if (freq * tegra->devfreq->profile->polling_ms > upper)
> + upper = freq * tegra->devfreq->profile->polling_ms;
>
> /*
>* We want to get interrupts when MCCPU client crosses the
> @@ -420,7 +421,7 @@ static void actmon_isr_device(struct tegra_devfreq *tegra,
> avg_count = device_readl(dev, ACTMON_DEV_AVG_COUNT);
> dev_ctrl = device_readl(dev, ACTMON_DEV_CTRL);
>
> - dev->avg_freq = avg_count / ACTMON_SAMPLING_PERIOD;
> + dev->avg_freq = avg_count / tegra->devfreq->profile->polling_ms;
>
> avg_intr_mask = ACTMON_DEV_INTR_AVG_BELOW_WMARK |
> ACTMON_DEV_INTR_AVG_ABOVE_WMARK;
> @@ -499,7 +500,7 @@ static unsigned long actmon_update_target(struct
> tegra_devfreq *tegra,
>* outdated.
>*/
> avg_count = device_readl(dev, ACTMON_DEV_AVG_COUNT);
> - avg_freq = avg_count / ACTMON_SAMPLING_PERIOD;
> + avg_freq = avg_count / tegra->devfreq->profile->polling_ms;
>
> old_upper = tegra_actmon_upper_freq(tegra, dev->avg_freq);
> new_upper = tegra_actmon_upper_freq(tegra, avg_freq);
> @@ -675,7 +676,7 @@ static int tegra_actmon_cpu_notify_cb(struct
> notifier_block *nb,
>* here for too long, otherwise CPUFreq's core will complain with a
>* warning splat.
>*/
> - delay = msecs_to_jiffies(ACTMON_SAMPLING_PERIOD);
> + delay = msecs_to_jiffies(tegra->devfreq->profile->polling_ms);
> schedule_delayed_work(>cpufreq_update_work, delay);
>
> return NOTIFY_OK;
> @@ -690,7 +691,7 @@ static void tegra_actmon_configure_device(struct
> tegra_devfreq *tegra,
> dev->boost_freq = 0;
>
> dev->avg_freq = clk_get_rate(tegra->emc_clock) / KHZ;
> - device_writel(dev, dev->avg_freq * ACTMON_SAMPLING_PERIOD,
> + device_writel(dev, dev->avg_freq * tegra->devfreq->profile->polling_ms,
> ACTMON_DEV_INIT_AVG);
>
> tegra_devfreq_update_avg_wmark(tegra, dev, dev->avg_freq);
> @@ -725,7 +726,14 @@ static int tegra_actmon_start(struct tegra_devfreq
> *tegra)
> unsigned int i;
> int err;
>
> - actmon_writel(tegra, ACTMON_SAMPLING_PERIOD - 1,
> + if (!tegra->devfreq->stop_polling)
I don't prefer to change the 'stop_polling' on each device driver direclty
without devfreq interface. Don't access it directly.
> + return 0;
> +
> + tegra->devfreq->previous_freq = clk_get_rate(tegra->emc_clock) / KHZ;
> + tegra->devfreq->last_stat_updated = jiffies;
> + tegra->devfreq->stop_polling = false;
ditto.
> +
> + actmon_writel(tegra, tegra->devfreq->profile->polling_ms - 1,
> ACTMON_GLB_PERIOD_CTRL);
>
> /*
> @@ -776,6 +784,11 @@ static void tegra_actmon_stop(struct tegra_devfreq
> *tegra)
> {
> unsigned int i;
>
> + if (tegra->devfreq->stop_polling)
ditto.
> + return;
> +
> + mutex_unlock(>devfreq->lock);
> +
>
Re: [PATCH v5 04/10] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_zone_span()
Hi David,
I love your patch! Perhaps something to improve:
[auto build test WARNING on mmotm/master]
url:
https://github.com/0day-ci/linux/commits/David-Hildenbrand/mm-memory_hotplug-Shrink-zones-before-removing-memory/20191002-054310
base: git://git.cmpxchg.org/linux-mmotm.git master
config: x86_64-randconfig-b002-201939 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
In file included from include/asm-generic/bug.h:5:0,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:9,
from mm/memory_hotplug.c:9:
mm/memory_hotplug.c: In function '__remove_zone':
mm/memory_hotplug.c:471:24: error: 'ZONE_DEVICE' undeclared (first use in
this function); did you mean 'ZONE_MOVABLE'?
if (zone_idx(zone) == ZONE_DEVICE)
^
include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
#define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) :
__trace_if_value(cond))
^~~~
>> mm/memory_hotplug.c:471:2: note: in expansion of macro 'if'
if (zone_idx(zone) == ZONE_DEVICE)
^~
mm/memory_hotplug.c:471:24: note: each undeclared identifier is reported
only once for each function it appears in
if (zone_idx(zone) == ZONE_DEVICE)
^
include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
#define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) :
__trace_if_value(cond))
^~~~
>> mm/memory_hotplug.c:471:2: note: in expansion of macro 'if'
if (zone_idx(zone) == ZONE_DEVICE)
^~
vim +/if +471 mm/memory_hotplug.c
459
460 static void __remove_zone(struct zone *zone, unsigned long start_pfn,
461 unsigned long nr_pages)
462 {
463 struct pglist_data *pgdat = zone->zone_pgdat;
464 unsigned long flags;
465
466 /*
467 * Zone shrinking code cannot properly deal with ZONE_DEVICE. So
468 * we will not try to shrink the zones - which is okay as
469 * set_zone_contiguous() cannot deal with ZONE_DEVICE either
way.
470 */
> 471 if (zone_idx(zone) == ZONE_DEVICE)
472 return;
473
474 pgdat_resize_lock(zone->zone_pgdat, );
475 shrink_zone_span(zone, start_pfn, start_pfn + nr_pages);
476 update_pgdat_span(pgdat);
477 pgdat_resize_unlock(zone->zone_pgdat, );
478 }
479
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] x86/PCI: Remove D0 PME capability on AMD FCH xHCI
[+cc Alan, Mathias, Rafael, Lukas]
On Mon, Sep 02, 2019 at 10:52:52PM +0800, Kai-Heng Feng wrote:
> There's an xHCI device that doesn't wake when a USB 2.0 device gets
> plugged to its USB 3.0 port. The driver's own runtime suspend callback
> was called, PME# signaling was enabled, but it stays at PCI D0:
>
> 00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB
> XHCI Controller [1022:7914] (rev 20) (prog-if 30 [XHCI])
> Subsystem: Dell FCH USB XHCI Controller [1028:087e]
> Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> SERR- Interrupt: pin A routed to IRQ 18
> Region 0: Memory at f0b68000 (64-bit, non-prefetchable) [size=8K]
> Capabilities: [50] Power Management version 3
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
>
> A PCI device can be runtime suspended while still stays at D0 when it
> supports D0 PME# and its ACPI _S0W method reports D0. Though plugging
> USB 3.0 devices can wakeup the xHCI, it doesn't respond to USB 2.0
> devices.
I don't think _S0W and runtime suspend are relevant here. What *is*
relevant is that the device advertises that it can generate PME from
D0, and it apparently does not do so.
Table 10 in the xHCI spec r1.0, sec 4.15.2.3, says the xHC should
assert PME# if enabled and the port's WCE bit is set. Did you ever
confirm that WCE is set?
I assume WCE *is* set because plugging in a USB3 device *does*
generate a PME#, and I don't see anything in Table 10 that says it
would work for USB3 but not USB2.
> So let's disable D0 PME capability on this device to avoid the issue.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203673
> Signed-off-by: Kai-Heng Feng
> ---
> arch/x86/pci/fixup.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index 527e69b12002..0851a05d092f 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -588,6 +588,17 @@ static void pci_fixup_amd_ehci_pme(struct pci_dev *dev)
> }
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x7808, pci_fixup_amd_ehci_pme);
>
> +/*
> + * Device [1022:7914]
> + * D0 PME# doesn't get asserted when plugging USB 2.0 device.
> + */
> +static void pci_fixup_amd_fch_xhci_pme(struct pci_dev *dev)
> +{
> + dev_info(>dev, "PME# does not work under D0, disabling it\n");
Use pci_info() as in the rest of the file.
> + dev->pme_support &= ~(PCI_PM_CAP_PME_D0 >> PCI_PM_CAP_PME_SHIFT);
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x7914,
> pci_fixup_amd_fch_xhci_pme);
> +
> /*
> * Apple MacBook Pro: Avoid [mem 0x7fa0-0x7fbf]
> *
> --
> 2.17.1
>
Re: [PATCH v3 3/4] mm: don't expose non-hugetlb page to fast gup prematurely
On Tue, Oct 01, 2019 at 03:31:51PM -0700, John Hubbard wrote: > On 9/26/19 10:06 PM, Yu Zhao wrote: > > On Thu, Sep 26, 2019 at 08:26:46PM -0700, John Hubbard wrote: > >> On 9/26/19 3:20 AM, Kirill A. Shutemov wrote: > >>> On Wed, Sep 25, 2019 at 04:26:54PM -0600, Yu Zhao wrote: > On Wed, Sep 25, 2019 at 10:25:30AM +0200, Peter Zijlstra wrote: > > On Tue, Sep 24, 2019 at 05:24:58PM -0600, Yu Zhao wrote: > >> ... > > I'm thinking this patch make stuff rather fragile.. Should we instead > > stick the barrier in set_p*d_at() instead? Or rather, make that store a > > store-release? > > I prefer it this way too, but I suspected the majority would be > concerned with the performance implications, especially those > looping set_pte_at()s in mm/huge_memory.c. > >>> > >>> We can rename current set_pte_at() to __set_pte_at() or something and > >>> leave it in places where barrier is not needed. The new set_pte_at()( will > >>> be used in the rest of the places with the barrier inside. > >> > >> +1, sounds nice. I was unhappy about the wide-ranging changes that would > >> have > >> to be maintained. So this seems much better. > > > > Just to be clear that doing so will add unnecessary barriers to one > > of the two paths that share set_pte_at(). > > Good point, maybe there's a better place to do it... > > > > > >>> BTW, have you looked at other levels of page table hierarchy. Do we have > >>> the same issue for PMD/PUD/... pages? > >>> > >> > >> Along the lines of "what other memory barriers might be missing for > >> get_user_pages_fast(), I'm also concerned that the synchronization between > >> get_user_pages_fast() and freeing the page tables might be technically > >> broken, > >> due to missing memory barriers on the get_user_pages_fast() side. Details: > >> > >> gup_fast() disables interrupts, but I think it also needs some sort of > >> memory barrier(s), in order to prevent reads of the page table > >> (gup_pgd_range, > >> etc) from speculatively happening before the interrupts are disabled. > > > > I was under impression switching back from interrupt context is a > > full barrier (otherwise wouldn't we be vulnerable to some side > > channel attacks?), so the reader side wouldn't need explicit rmb. > > > > Documentation/memory-barriers.txt points out: > > INTERRUPT DISABLING FUNCTIONS > - > > Functions that disable interrupts (ACQUIRE equivalent) and enable interrupts > (RELEASE equivalent) will act as compiler barriers only. So if memory or I/O > barriers are required in such a situation, they must be provided from some > other means. > > btw, I'm really sorry I missed your responses over the last 3 or 4 days. > I just tracked down something in our email system that was sometimes > moving some emails to spam (just few enough to escape immediate attention, > argghh!). > I think I killed it off for good now. I wasn't ignoring you. :) Thanks, John. I agree with all you said, including the irq disabling function not being a sufficient smp_rmb(). I was hoping somebody could clarify whether ipi handlers used by tlb flush are sufficient to prevent CPU 1 from seeing any stale data from freed page tables on all supported archs. CPU 1 CPU 2 flush remote tlb by ipi wait for the ipi hanlder free page table disable irq walk page table enable irq I think they should because otherwise tlb flush wouldn't work if CPU 1 still sees stale data from the freed page table, unless there is a really strange CPU cache design I'm not aware of. Quoting comments from x86 ipi handler flush_tlb_func_common(): * read active_mm's tlb_gen. We don't need any explicit barriers * because all x86 flush operations are serializing and the * atomic64_read operation won't be reordered by the compiler. For ppc64 ipi hander radix__flush_tlb_range(), there is an "eieio" instruction: https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/assembler/idalangref_eieio_instrs.html I'm not sure why it's not "sync" -- I'd guess something implicitly works as "sync" already (or it's a bug). I didn't find an ipi handler for tlb flush on arm64. There should be one, otherwise fast gup on arm64 would be broken. Mark?
Re: [PATCH v6 14/19] PM / devfreq: tegra30: Don't enable consecutive-down interrupt on startup
On 19. 8. 12. 오전 6:23, Dmitry Osipenko wrote: > The consecutive-down event tells that we should perform frequency > de-boosting, but boosting is in a reset state on start and hence the > event won't do anything useful for us and it will be just a dummy > interrupt request. > > Signed-off-by: Dmitry Osipenko > --- > drivers/devfreq/tegra30-devfreq.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/devfreq/tegra30-devfreq.c > b/drivers/devfreq/tegra30-devfreq.c > index 5002dca4c403..a0a1ac09a824 100644 > --- a/drivers/devfreq/tegra30-devfreq.c > +++ b/drivers/devfreq/tegra30-devfreq.c > @@ -708,7 +708,6 @@ static void tegra_actmon_configure_device(struct > tegra_devfreq *tegra, > << ACTMON_DEV_CTRL_CONSECUTIVE_ABOVE_WMARK_NUM_SHIFT; > val |= ACTMON_DEV_CTRL_AVG_ABOVE_WMARK_EN; > val |= ACTMON_DEV_CTRL_AVG_BELOW_WMARK_EN; > - val |= ACTMON_DEV_CTRL_CONSECUTIVE_BELOW_WMARK_EN; > val |= ACTMON_DEV_CTRL_CONSECUTIVE_ABOVE_WMARK_EN; > val |= ACTMON_DEV_CTRL_ENB; > > Reviewed-by: Chanwoo Choi -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v6 11/19] PM / devfreq: tegra30: Use CPUFreq notifier
Hi,
On 19. 8. 12. 오전 6:23, Dmitry Osipenko wrote:
> The CPU's client need to take into account that CPUFreq may change
> while memory activity not, staying high. Thus an appropriate frequency
> notifier should be used in addition to the clk-notifier.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 173 ++
> 1 file changed, 153 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index a2623de56d20..a260812f7744 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #include "governor.h"
>
> @@ -34,6 +35,8 @@
> #define ACTMON_DEV_CTRL_CONSECUTIVE_ABOVE_WMARK_EN BIT(30)
> #define ACTMON_DEV_CTRL_ENB BIT(31)
>
> +#define ACTMON_DEV_CTRL_STOP 0x
> +
> #define ACTMON_DEV_UPPER_WMARK 0x4
> #define ACTMON_DEV_LOWER_WMARK 0x8
> #define ACTMON_DEV_INIT_AVG 0xc
> @@ -159,7 +162,10 @@ struct tegra_devfreq {
>
> struct clk *emc_clock;
> unsigned long max_freq;
> - struct notifier_block rate_change_nb;
> + struct notifier_block clk_rate_change_nb;
> +
> + struct delayed_work cpufreq_update_work;
> + struct notifier_block cpu_rate_change_nb;
>
> struct tegra_devfreq_device devices[ARRAY_SIZE(actmon_device_configs)];
>
> @@ -207,10 +213,10 @@ static unsigned long do_percent(unsigned long val,
> unsigned int pct)
> return val * pct / 100;
> }
>
> -static unsigned long actmon_cpu_to_emc_rate(struct tegra_devfreq *tegra)
> +static unsigned long actmon_cpu_to_emc_rate(struct tegra_devfreq *tegra,
> + unsigned int cpu_freq)
> {
> struct tegra_actmon_emc_ratio *ratio = actmon_emc_ratios;
> - unsigned int cpu_freq = cpufreq_quick_get(0);
> unsigned int i;
>
> for (i = 0; i < ARRAY_SIZE(actmon_emc_ratios); i++, ratio++) {
> @@ -244,7 +250,8 @@ tegra_actmon_account_cpu_freq(struct tegra_devfreq *tegra,
> return target_freq;
>
> if (dev->avg_freq > tegra_actmon_dev_avg_dependency_freq(tegra, dev))
> - static_cpu_emc_freq = actmon_cpu_to_emc_rate(tegra);
> + static_cpu_emc_freq = actmon_cpu_to_emc_rate(
> + tegra, cpufreq_quick_get(0));
> else
> static_cpu_emc_freq = 0;
>
> @@ -543,8 +550,8 @@ static irqreturn_t actmon_thread_isr(int irq, void *data)
> return handled ? IRQ_HANDLED : IRQ_NONE;
> }
>
> -static int tegra_actmon_rate_notify_cb(struct notifier_block *nb,
> -unsigned long action, void *ptr)
> +static int tegra_actmon_clk_notify_cb(struct notifier_block *nb,
> + unsigned long action, void *ptr)
> {
> struct clk_notifier_data *data = ptr;
> struct tegra_devfreq_device *dev;
> @@ -555,7 +562,7 @@ static int tegra_actmon_rate_notify_cb(struct
> notifier_block *nb,
> if (action != POST_RATE_CHANGE)
> return NOTIFY_OK;
>
> - tegra = container_of(nb, struct tegra_devfreq, rate_change_nb);
> + tegra = container_of(nb, struct tegra_devfreq, clk_rate_change_nb);
>
> freq = data->new_rate / KHZ;
>
> @@ -586,6 +593,94 @@ static int tegra_actmon_rate_notify_cb(struct
> notifier_block *nb,
> return NOTIFY_OK;
> }
>
> +static void tegra_actmon_delayed_update(struct work_struct *work)
> +{
> + struct tegra_devfreq *tegra = container_of(work, struct tegra_devfreq,
> +cpufreq_update_work.work);
> +
> + mutex_lock(>devfreq->lock);
> + update_devfreq(tegra->devfreq);
> + mutex_unlock(>devfreq->lock);
> +}
> +
> +static unsigned long
> +tegra_actmon_cpufreq_contribution(struct tegra_devfreq *tegra,
> + unsigned int cpu_freq)
> +{
> + unsigned long freq, static_cpu_emc_freq;
> +
> + /* check whether CPU's freq is taken into account at all */
> + freq = tegra_actmon_dev_avg_dependency_freq(tegra,
> + >devices[MCCPU]);
> + if (tegra->devices[MCCPU].avg_freq <= freq)
> + return 0;
> +
> + static_cpu_emc_freq = actmon_cpu_to_emc_rate(tegra, cpu_freq);
> +
> + /* compare static CPU-EMC freq with MCALL */
> + freq = tegra->devices[MCALL].avg_freq +
> +tegra->devices[MCALL].boost_freq;
> +
> + freq = tegra_actmon_upper_freq(tegra, freq);
> +
> + if (freq == tegra->max_freq || freq >= static_cpu_emc_freq)
> + return 0;
> +
> + /* compare static CPU-EMC freq with MCCPU */
> + freq =
[PATCH] mm thp: shrink deferred split THPs harder
The deferred split THPs may get accumulated with some workloads, they
would get shrunk when memory pressure is hit. Now we use DEFAULT_SEEKS
to determine how many objects would get scanned then split if possible,
but actually they are not like other system cache objects, i.e. inode
cache which would incur extra I/O if over reclaimed, the unmapped pages
will not be accessed anymore, so we could shrink them more aggressively.
We could shrink THPs more pro-actively even though memory pressure is not
hit, however, IMHO waiting for memory pressure is still a good
compromise and trade-off. And, we do have simpler ways to shrink these
objects harder until we have to take other means do pro-actively drain.
Change shrinker->seeks to 0 to shrink deferred split THPs harder.
Cc: Kirill A. Shutemov
Cc: Kirill Tkhai
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Hugh Dickins
Cc: Shakeel Butt
Cc: David Rientjes
Signed-off-by: Yang Shi
---
mm/huge_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 3b78910..1d6b1f1 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2955,7 +2955,7 @@ static unsigned long deferred_split_scan(struct shrinker
*shrink,
static struct shrinker deferred_split_shrinker = {
.count_objects = deferred_split_count,
.scan_objects = deferred_split_scan,
- .seeks = DEFAULT_SEEKS,
+ .seeks = 0,
.flags = SHRINKER_NUMA_AWARE | SHRINKER_MEMCG_AWARE |
SHRINKER_NONSLAB,
};
--
1.8.3.1
Re: DVB-T2 Stick
Em Wed, 2 Oct 2019 00:19:05 +0200
Gonsolo escreveu:
> Hi!
>
> > Secondly there are lots of coding style issues, see:
> > https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>
> I addressed most of these except one "#if 0" warning from checkpatch.
>
> > I'm afraid there are many problems with this patch. First of all it looks
> > like support was added for a si2168 tuner but it looks like it will break
> > for any other si2157-type device.
>
>
> Can you give me a hint how to proceed here? I don't know much about
> DVB tuners or kernel development.
>
> I attached the cleaned-up patch for 5.4.0-rc1
First of all, don't attach a patch. Instead, just send it with a decent
emailer (with won't mangle whitespaces) or use git send-email...
Also, please read the Developer's section of our wiki page:
https://linuxtv.org/wiki/index.php/Developer_section
In special, the "Submitting your work" part of it.
>
> Thanks,
> g
> From 6cada6442207a67202e73721692aced665b8fdf0 Mon Sep 17 00:00:00 2001
> From: Gon Solo
> Date: Tue, 1 Oct 2019 21:59:44 +0200
> Subject: [PATCH] DVB-T2 with coding style updates.
>
> ---
> drivers/media/tuners/si2157.c | 44 ++---
> drivers/media/tuners/si2157_priv.h| 8 +
> drivers/media/usb/dvb-usb-v2/af9035.c | 47 ++-
> 3 files changed, 93 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
> index e87040d6eca7..af50e721281b 100644
> --- a/drivers/media/tuners/si2157.c
> +++ b/drivers/media/tuners/si2157.c
> @@ -75,7 +75,7 @@ static int si2157_init(struct dvb_frontend *fe)
> struct si2157_cmd cmd;
> const struct firmware *fw;
> const char *fw_name;
> - unsigned int uitmp, chip_id;
> + unsigned int uitmp;
>
> dev_dbg(>dev, "\n");
>
> @@ -117,7 +117,7 @@ static int si2157_init(struct dvb_frontend *fe)
> if (ret)
> goto err;
> }
> -
> +#if 0
> /* query chip revision */
> memcpy(cmd.args, "\x02", 1);
> cmd.wlen = 1;
> @@ -138,6 +138,8 @@ static int si2157_init(struct dvb_frontend *fe)
> #define SI2141_A10 ('A' << 24 | 41 << 16 | '1' << 8 | '0' << 0)
>
> switch (chip_id) {
> +#endif
> + switch (dev->chip_id) {
You shouldn't just blindly comment out some code, as this will very likely
break support for all other devices supported by the driver...
> case SI2158_A20:
> case SI2148_A20:
> fw_name = SI2158_A20_FIRMWARE;
> @@ -161,9 +163,9 @@ static int si2157_init(struct dvb_frontend *fe)
> goto err;
> }
>
> - dev_info(>dev, "found a 'Silicon Labs Si21%d-%c%c%c'\n",
> - cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
> -
> +// dev_info(>dev, "found a 'Silicon Labs Si21%d-%c%c%c'\n",
> +// cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
> +//
> if (fw_name == NULL)
> goto skip_fw_download;
>
> @@ -456,6 +458,38 @@ static int si2157_probe(struct i2c_client *client,
> memcpy(>ops.tuner_ops, _ops, sizeof(struct dvb_tuner_ops));
> fe->tuner_priv = client;
>
> + /* power up */
> + if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
> + memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
> + cmd.wlen = 9;
> + } else {
> + memcpy(cmd.args,
> + "\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01",
> + 15);
> + cmd.wlen = 15;
> + }
> + cmd.rlen = 1;
> + ret = si2157_cmd_execute(client, );
> + if (ret)
> + goto err;
> + /* query chip revision */
> + /* hack: do it here because after the si2168 gets 0101, commands will
> + * still be executed here but no result
> + */
> + memcpy(cmd.args, "\x02", 1);
> + cmd.wlen = 1;
> + cmd.rlen = 13;
> + ret = si2157_cmd_execute(client, );
> + if (ret)
> + goto err_kfree;
> + dev->chip_id = cmd.args[1] << 24 |
> + cmd.args[2] << 16 |
> + cmd.args[3] << 8 |
> + cmd.args[4] << 0;
> + dev_info(>dev, "found a 'Silicon Labs Si21%d-%c%c%c'\n",
> + cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
> +
> +
... yet, looking on what you've done, it seems that you're actually
adding support for a different tuner at the si2157 driver.
If this is the case, this should be on a separate patch, and in a way
that it will become clear that it won't break support for any existing
device.
Also, please remove the dead code, instead of commenting it out.
> #ifdef CONFIG_MEDIA_CONTROLLER
> if (cfg->mdev) {
> dev->mdev = cfg->mdev;
> diff --git a/drivers/media/tuners/si2157_priv.h
> b/drivers/media/tuners/si2157_priv.h
> index 2bda903358da..0f4090e184e9 100644
> --- a/drivers/media/tuners/si2157_priv.h
> +++ b/drivers/media/tuners/si2157_priv.h
>
Re: [PATCH v5 04/10] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_zone_span()
Hi David,
I love your patch! Yet something to improve:
[auto build test ERROR on mmotm/master]
url:
https://github.com/0day-ci/linux/commits/David-Hildenbrand/mm-memory_hotplug-Shrink-zones-before-removing-memory/20191002-054310
base: git://git.cmpxchg.org/linux-mmotm.git master
config: i386-randconfig-g004-201939 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
mm/memory_hotplug.c: In function '__remove_zone':
>> mm/memory_hotplug.c:471:24: error: 'ZONE_DEVICE' undeclared (first use in
>> this function); did you mean 'ZONE_MOVABLE'?
if (zone_idx(zone) == ZONE_DEVICE)
^~~
ZONE_MOVABLE
mm/memory_hotplug.c:471:24: note: each undeclared identifier is reported
only once for each function it appears in
vim +471 mm/memory_hotplug.c
459
460 static void __remove_zone(struct zone *zone, unsigned long start_pfn,
461 unsigned long nr_pages)
462 {
463 struct pglist_data *pgdat = zone->zone_pgdat;
464 unsigned long flags;
465
466 /*
467 * Zone shrinking code cannot properly deal with ZONE_DEVICE. So
468 * we will not try to shrink the zones - which is okay as
469 * set_zone_contiguous() cannot deal with ZONE_DEVICE either
way.
470 */
> 471 if (zone_idx(zone) == ZONE_DEVICE)
472 return;
473
474 pgdat_resize_lock(zone->zone_pgdat, );
475 shrink_zone_span(zone, start_pfn, start_pfn + nr_pages);
476 update_pgdat_span(pgdat);
477 pgdat_resize_unlock(zone->zone_pgdat, );
478 }
479
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] PCI/IOV: update num_VFs earlier
On Fri, Apr 26, 2019 at 10:11:54AM +0200, CREGUT Pierre IMT/OLN wrote: > I also initially thought that kobject_uevent generated the netlink event > but this is not the case. This is generated by the specific driver in use. > For the Intel i40e driver, this is the call to i40e_do_reset_safe in > i40e_pci_sriov_configure that sends the event. > It is followed by i40e_pci_sriov_enable that calls i40e_alloc_vfs that > finally calls the generic pci_enable_sriov function. I don't know anything about netlink. The script from the bugzilla (https://bugzilla.kernel.org/show_bug.cgi?id=202991) looks like it runs ip monitor dev enp9s0f2 What are the actual netlink events you see? Are they related to a device being removed? When we change num_VFs, I think we have to disable any existing VFs before enabling the new num_VFs, so if you trigger on a netlink "remove" event, I wouldn't be surprised that reading sriov_numvfs would give a zero until the new VFs are enabled. > So the proposed patch works well for the i40e driver (x710 cards) because > the update to num_VFs is fast enough to be committed before the event is > received. It may not work with other cards. The same is true for the zero > value and there is no guarantee for other cards. > > The clean solution would be to lock the device in sriov_numvfs_show. > I guess that there are good reasons why locks have been avoided > in sysfs getter functions so let us explore other approaches. > > We can either return a "not settled" value (-1) or (probably better) > do not return a value but an error (-EAGAIN returned by the show > function). > > To distinguish this "not settled" situation we can either: > * overload the meaning of num_VFs (eg make it negative) > but it is an unsigned short. > * add a bool to pci_sriov struct (rather simple but modifies a well > established structure). > * use the fact that not_settled => device is locked and use > mutex_is_locked as an over approximation. > > The later is not perfect but requires minimal changes to > sriov_numvfs_show: > > if (mutex_is_locked(>mutex)) > return -EAGAIN; I thought this was a good idea, but - It does break the device_lock() encapsulation a little bit: sriov_numvfs_store() uses device_lock(), which happens to be implemented as "mutex_lock(>mutex)", but we really shouldn't rely on that implementation, and - The netlink events are being generated via the NIC driver, and I'm a little hesitant about changing the PCI core to deal with timing issues "over there". > In all cases, the device could be locked or the boolean set just > after the test. But I don't think there is a case where causality > would be violated.Thank you in advance for your recommendations. I will > update the patch according to your instructions. > > Le 06/04/2019 à 00:33, Bjorn Helgaas a écrit : > > On Fri, Mar 29, 2019 at 09:00:58AM +0100, Pierre Crégut wrote: > > > Ensure that iov->num_VFs is set before a netlink message is sent > > > when the number of VFs is changed. Only the path for num_VFs > 0 > > > is affected. The path for num_VFs = 0 is already correct. > > > > > > Monitoring programs can relie on netlink messages to track interface > > > change and query their state in /sys. But when sriov_numvfs is set to a > > > positive value, the netlink message is sent before the value is available > > > in sysfs. The value read after the message is received is always zero. > > Thanks, Pierre! Can you clue me in on where exactly the connection > > from sriov_enable() to netlink is? > > > > I see one side of the race is with sriov_numvfs_show(), but I don't > > know where the netlink message is sent. Is that connected with the > > kobject_uevent(KOBJ_CHANGE)? > > > > One thing this would help with is figuring out exactly how *much* > > earlier we need to set iov->num_VFs. It looks like the current patch > > sets it before we actually enable the VFs, so a user could read > > /sys/.../sriov_numvfs and get the wrong value. Of course, that's > > unavoidable; the question is whether it's OK to get the new value > > *before* it actually takes effect, or whether we want to return a > > stale value until after it takes effect. > > > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=202991 > > > Signed-off-by: Pierre Crégut > > > --- > > > note: the behaviour can be tested with the following shell script also > > > available on the bugzilla (d being the phy device name): > > > > > > ip monitor dev $d | grep --line-buffered "^[0-9]*:" | \ > > > while read line; do cat /sys/class/net/$d/device/sriov_numvfs; done > > > > > > drivers/pci/iov.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c > > > index 3aa115ed3a65..a9655c10e87f 100644 > > > --- a/drivers/pci/iov.c > > > +++ b/drivers/pci/iov.c > > > @@ -351,6 +351,7 @@ static int sriov_enable(struct pci_dev *dev, int > > > nr_virtfn) > > >
Re: [PATCH 1/2] x86: math-emu: check __copy_from_user result
On Tue, Oct 01, 2019 at 04:23:34PM +0200, Arnd Bergmann wrote:
> The new __must_check annotation on __copy_from_user successfully
> identified some code that has lacked the check since at least
> linux-2.1.73:
>
> arch/x86/math-emu/reg_ld_str.c:88:2: error: ignoring return value of function
> declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]
> __copy_from_user(sti_ptr, s, 10);
> ^~~~ ~~
> arch/x86/math-emu/reg_ld_str.c:1129:2: error: ignoring return value of
> function declared with 'warn_unused_result' attribute
> [-Werror,-Wunused-result]
> __copy_from_user(register_base + offset, s, other);
> ^~~~
> arch/x86/math-emu/reg_ld_str.c:1131:3: error: ignoring return value of
> function declared with 'warn_unused_result' attribute
> [-Werror,-Wunused-result]
> __copy_from_user(register_base, s + other, offset);
> ^~~~
>
> In addition, the get_user/put_user helpers do not enforce a return value
> check, but actually still require one. These have been missing
> for even longer.
>
> Change the internal wrappers around get_user/put_user to force
> a signal and add a corresponding wrapper around __copy_from_user
> to check all such cases.
>
> Fixes: 257e458057e5 ("Import 2.1.73")
> Fixes: 9dd819a15162 ("uaccess: add missing __must_check attributes")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Kees Cook
Notes below...
> ---
> arch/x86/math-emu/fpu_system.h | 6 --
> arch/x86/math-emu/reg_ld_str.c | 6 +++---
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/math-emu/fpu_system.h b/arch/x86/math-emu/fpu_system.h
> index f98a0c956764..9b41391867dc 100644
> --- a/arch/x86/math-emu/fpu_system.h
> +++ b/arch/x86/math-emu/fpu_system.h
> @@ -107,6 +107,8 @@ static inline bool seg_writable(struct desc_struct *d)
> #define FPU_access_ok(y,z) if ( !access_ok(y,z) ) \
> math_abort(FPU_info,SIGSEGV)
> #define FPU_abortmath_abort(FPU_info, SIGSEGV)
> +#define FPU_copy_from_user(to, from, n) \
> + do { if (copy_from_user(to, from, n)) FPU_abort; } while (0)
>
> #undef FPU_IGNORE_CODE_SEGV
> #ifdef FPU_IGNORE_CODE_SEGV
> @@ -122,7 +124,7 @@ static inline bool seg_writable(struct desc_struct *d)
> #define FPU_code_access_ok(z) FPU_access_ok((void __user *)FPU_EIP,z)
> #endif
>
> -#define FPU_get_user(x,y) get_user((x),(y))
> -#define FPU_put_user(x,y) put_user((x),(y))
> +#define FPU_get_user(x,y) do { if (get_user((x),(y))) FPU_abort; } while (0)
> +#define FPU_put_user(x,y) do { if (put_user((x),(y))) FPU_abort; } while (0)
>
> #endif
> diff --git a/arch/x86/math-emu/reg_ld_str.c b/arch/x86/math-emu/reg_ld_str.c
> index f3779743d15e..fe6246ff9887 100644
> --- a/arch/x86/math-emu/reg_ld_str.c
> +++ b/arch/x86/math-emu/reg_ld_str.c
> @@ -85,7 +85,7 @@ int FPU_load_extended(long double __user *s, int stnr)
>
> RE_ENTRANT_CHECK_OFF;
> FPU_access_ok(s, 10);
> - __copy_from_user(sti_ptr, s, 10);
> + FPU_copy_from_user(sti_ptr, s, 10);
These access_ok() checks seem redundant everywhere in this file (after
your switch from __copy* to copy*. I mean, I guess, just leave them, but
*shrug*
-Kees
> RE_ENTRANT_CHECK_ON;
>
> return FPU_tagof(sti_ptr);
> @@ -1126,9 +1126,9 @@ void frstor(fpu_addr_modes addr_modes, u_char __user
> *data_address)
> /* Copy all registers in stack order. */
> RE_ENTRANT_CHECK_OFF;
> FPU_access_ok(s, 80);
> - __copy_from_user(register_base + offset, s, other);
> + FPU_copy_from_user(register_base + offset, s, other);
> if (offset)
> - __copy_from_user(register_base, s + other, offset);
> + FPU_copy_from_user(register_base, s + other, offset);
> RE_ENTRANT_CHECK_ON;
>
> for (i = 0; i < 8; i++) {
> --
> 2.20.0
>
--
Kees Cook
[PATCH V4 1/3] drm/panel: simple: Add Logic PD Type 28 display support
Previously, there was an omap panel-dpi driver that would
read generic timings from the device tree and set the display
timing accordingly. This driver was removed so the screen
no longer functions. This patch modifies the panel-simple
file to setup the timings to the same values previously used.
Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
Signed-off-by: Adam Ford
Reviewed-by: Sam Ravnborg
---
V4: No Change
V3: No Change
V2: No Change
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 28fa6ba7b767..8abb31f83ffc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2048,6 +2048,40 @@ static const struct drm_display_mode
mitsubishi_aa070mc01_mode = {
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
};
+static const struct drm_display_mode logicpd_type_28_mode = {
+ .clock = 9000,
+ .hdisplay = 480,
+ .hsync_start = 480 + 3,
+ .hsync_end = 480 + 3 + 42,
+ .htotal = 480 + 3 + 42 + 2,
+
+ .vdisplay = 272,
+ .vsync_start = 272 + 2,
+ .vsync_end = 272 + 2 + 11,
+ .vtotal = 272 + 2 + 11 + 3,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc logicpd_type_28 = {
+ .modes = _type_28_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 105,
+ .height = 67,
+ },
+ .delay = {
+ .prepare = 200,
+ .enable = 200,
+ .unprepare = 200,
+ .disable = 200,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE |
+DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE,
+};
+
static const struct panel_desc mitsubishi_aa070mc01 = {
.modes = _aa070mc01_mode,
.num_modes = 1,
@@ -3264,6 +3298,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "lg,lp129qe",
.data = _lp129qe,
+ }, {
+ .compatible = "logicpd,type28",
+ .data = _type_28,
}, {
.compatible = "mitsubishi,aa070mc01-ca1",
.data = _aa070mc01,
--
2.17.1
Re: [PATCH v6 10/19] PM / devfreq: tegra30: Reduce unnecessary interrupts activity
Hi,
On 19. 8. 12. 오전 6:23, Dmitry Osipenko wrote:
> There are cases where unnecessary ACTMON interrupts could be avoided,
> like when one memory client device requests higher clock rate than the
> other or when clock rate is manually limited using sysfs devfreq
> parameters. These cases could be avoided by tuning upper watermark or
> disabling hardware events when min/max boosting thresholds are reached.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 87 ---
> 1 file changed, 80 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 43d50b4366dd..a2623de56d20 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -312,7 +312,8 @@ static void tegra_actmon_get_lower_upper(struct
> tegra_devfreq *tegra,
> }
>
> static void tegra_devfreq_update_avg_wmark(struct tegra_devfreq *tegra,
> -struct tegra_devfreq_device *dev)
> +struct tegra_devfreq_device *dev,
> +unsigned long freq)
> {
> unsigned long avg_dependency_freq, lower, upper;
>
> @@ -320,6 +321,22 @@ static void tegra_devfreq_update_avg_wmark(struct
> tegra_devfreq *tegra,
>
> avg_dependency_freq = tegra_actmon_dev_avg_dependency_freq(tegra, dev);
>
> + /*
> + * If cumulative EMC frequency selection (MCALL / min_freq) is
> + * higher than the device's, then there is no need to set upper
> + * watermark to a lower value because it will result in unnecessary
> + * upper interrupts.
> + *
> + * Note that average watermarks are also updated after EMC
> + * clock rate change, hence if clock rate goes down, then the
> + * watermarks will be set in accordance to the new rate after
> + * changing the rate. There are other ways to achieve the same
> + * result, but this one is probably the least churning, although
> + * it may look a bit convoluted.
> + */
> + if (freq * ACTMON_SAMPLING_PERIOD > upper)
> + upper = freq * ACTMON_SAMPLING_PERIOD;
> +
> /*
>* We want to get interrupts when MCCPU client crosses the
>* dependency threshold in order to take into / out of account
> @@ -361,7 +378,18 @@ static void tegra_devfreq_update_wmark(struct
> tegra_devfreq *tegra,
> tegra_actmon_get_lower_upper(tegra, dev, freq - 1, , );
>
> delta = do_percent(upper - lower, dev->config->boost_up_threshold);
> - device_writel(dev, lower + delta, ACTMON_DEV_UPPER_WMARK);
Also, this patch edits the added codes on front patch.
This code was added on patch5 and then delete it on this patch.
If it is not necessary, you can remove it on patch5 by refactoring.
> +
> + /*
> + * The memory events count could go a bit higher than the maximum
> + * defined by the OPPs, hence make the upper watermark infinitely
> + * high to avoid unnecessary upper interrupts in that case.
> + */
> + if (freq == tegra->max_freq)
> + upper = ULONG_MAX;
> + else
> + upper = lower + delta;
> +
> + device_writel(dev, upper, ACTMON_DEV_UPPER_WMARK);
I think that the changes of tegra_devfreq_update_avg_wmark() on this patch
can be merged to patch5.
>
> /*
>* Meanwhile the lower mark is based on the average value
> @@ -379,6 +407,7 @@ static void actmon_isr_device(struct tegra_devfreq *tegra,
> struct tegra_devfreq_device *dev)
> {
> u32 intr_status, dev_ctrl, avg_intr_mask, avg_count;
> + unsigned long freq;
>
> intr_status = device_readl(dev, ACTMON_DEV_INTR_STATUS);
> avg_count = device_readl(dev, ACTMON_DEV_AVG_COUNT);
> @@ -389,8 +418,10 @@ static void actmon_isr_device(struct tegra_devfreq
> *tegra,
> avg_intr_mask = ACTMON_DEV_INTR_AVG_BELOW_WMARK |
> ACTMON_DEV_INTR_AVG_ABOVE_WMARK;
>
> - if (intr_status & avg_intr_mask)
> - tegra_devfreq_update_avg_wmark(tegra, dev);
> + if (intr_status & avg_intr_mask) {
> + freq = clk_get_rate(tegra->emc_clock) / KHZ;
> + tegra_devfreq_update_avg_wmark(tegra, dev, freq);
> + }
>
> if (intr_status & ACTMON_DEV_INTR_CONSECUTIVE_UPPER) {
> /*
> @@ -412,6 +443,8 @@ static void actmon_isr_device(struct tegra_devfreq *tegra,
> dev->boost_freq = do_percent(dev->boost_freq,
>dev->config->boost_down_coeff);
>
> + dev_ctrl |= ACTMON_DEV_CTRL_CONSECUTIVE_ABOVE_WMARK_EN;
> +
> if (dev->boost_freq < (ACTMON_BOOST_FREQ_STEP >> 1))
> dev->boost_freq = 0;
> }
> @@ -427,8 +460,16 @@ static void actmon_isr_device(struct tegra_devfreq
> *tegra,
> }
>
> /* no boosting => no need for
Re: [PATCH v6 09/19] PM / devfreq: tegra30: Use kHz units uniformly in the code
On 19. 8. 12. 오전 6:23, Dmitry Osipenko wrote:
> Now that all kHz-conversion related bugs are fixed, we can use the kHz
> uniformly. This makes code cleaner and avoids integer divisions in the
> code, which is useful in a case of Tegra30 that has Cortex A9 CPU that
> doesn't support integer division instructions, hence all divisions are
> actually made in software mode. Another small benefit from this change
> is that now powertop utility correctly displays devfreq's stats, for
> some reason it expects them to be in kHz.
If possible, please specify the benefit result on patch description.
And I have a question. Why do you fix the KHz-conversion issue on one patch?
Actually, in my case, it is difficult to understand that multiple patches
try to fix the KHz-conversion issue. I think that it is possible to
make one patch.
And,
On these series, some codes wad added and then these codes are deleted
on later patch. It looks like that you made the issue and then you fix
the issue by yourself. I think that it is not proper.
Even if you developed the patches on your local environment sequentially
according to the sequence of your issue detection, you better to do
refactoring the patches.
Frankly, I cannot agree that some codes wad added on front patch
and then added codes are deleted on later patch in the same patchset.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 81 +++
> 1 file changed, 49 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index ca499368ee81..43d50b4366dd 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -137,8 +137,11 @@ struct tegra_devfreq_device {
> const struct tegra_devfreq_device_config *config;
> void __iomem *regs;
>
> - /* Average event count sampled in the last interrupt */
> - u32 avg_count;
> + /*
> + * Average event count sampled in the last interrupt and converted
> + * to frequency value.
> + */
> + u32 avg_freq;
>
> /*
>* Extra frequency to increase the target by due to consecutive
> @@ -222,6 +225,14 @@ static unsigned long actmon_cpu_to_emc_rate(struct
> tegra_devfreq *tegra)
> return 0;
> }
>
> +static unsigned long
> +tegra_actmon_dev_avg_dependency_freq(struct tegra_devfreq *tegra,
> + struct tegra_devfreq_device *dev)
> +{
> + return dev->config->avg_dependency_threshold /
> + ACTMON_SAMPLING_PERIOD;
> +}
> +
> static unsigned long
> tegra_actmon_account_cpu_freq(struct tegra_devfreq *tegra,
> struct tegra_devfreq_device *dev,
> @@ -229,13 +240,15 @@ tegra_actmon_account_cpu_freq(struct tegra_devfreq
> *tegra,
> {
> unsigned long static_cpu_emc_freq;
>
> - if (dev->config->avg_dependency_threshold &&
> - dev->config->avg_dependency_threshold < dev->avg_count) {
> + if (!dev->config->avg_dependency_threshold)
> + return target_freq;
> +
> + if (dev->avg_freq > tegra_actmon_dev_avg_dependency_freq(tegra, dev))
> static_cpu_emc_freq = actmon_cpu_to_emc_rate(tegra);
> - target_freq = max(target_freq, static_cpu_emc_freq);
> - }
> + else
> + static_cpu_emc_freq = 0;
>
> - return target_freq;
> + return max(target_freq, static_cpu_emc_freq);
> }
>
> static unsigned long tegra_actmon_lower_freq(struct tegra_devfreq *tegra,
> @@ -261,7 +274,7 @@ static unsigned long tegra_actmon_upper_freq(struct
> tegra_devfreq *tegra,
>
> opp = dev_pm_opp_find_freq_ceil(tegra->devfreq->dev.parent, );
> if (IS_ERR(opp))
> - upper = ULONG_MAX;
> + upper = KHZ_MAX;
> else
> dev_pm_opp_put(opp);
>
> @@ -280,15 +293,12 @@ static void tegra_actmon_get_lower_upper(struct
> tegra_devfreq *tegra,
>* range in a case where target_freq falls into a range of
>* next_possible_opp_freq - 1MHz.
>*/
> - target_freq = round_down(target_freq, 100);
This line was added on patch5. I think that you could fix the KHz-conversion
on patch5 instead of this patch. It is not good way to make the patches.
Because some codes wad added and then these codes are deleted on later patch.
It looks like that you made the issue and then you fix the issue by yourself.
It is difficult to make me to decide this patch is either proper or not.
> + target_freq = round_down(target_freq, 1000);
>
> /* watermarks are set at the borders of the corresponding OPPs */
> *lower = tegra_actmon_lower_freq(tegra, target_freq);
> *upper = tegra_actmon_upper_freq(tegra, target_freq);
>
> - *lower /= KHZ;
> - *upper /= KHZ;
> -
> /*
>* The upper watermark should take into account CPU's frequency
>* because cpu_to_emc_rate() may override the target_freq with
> @@
Re: [PATCH v2 5/5] MIPS: JZ4780: DTS: Add CPU nodes
Hi Alexandre,
On Tue, Oct 01, 2019 at 09:09:48PM +0200, Alexandre GRIVEAUX wrote:
> The JZ4780 have 2 core, adding to DT.
>
> Signed-off-by: Alexandre GRIVEAUX
> ---
> arch/mips/boot/dts/ingenic/jz4780.dtsi | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> index f928329b034b..9c7346724f1f 100644
> --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> @@ -7,6 +7,23 @@
> #size-cells = <1>;
> compatible = "ingenic,jz4780";
>
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + compatible = "ingenic,jz4780";
This should probably be something like ingenic,xburst2. JZ4780 is the
SoC. It also should be a documented binding, but I think it would be
worth holding off on the whole thing until we actually get SMP support
merged - just in case we come up with a binding that doesn't actually
work out.
So I expect I'll just apply patches 1-4 for now.
Thanks for working on it!
Paul
> + device_type = "cpu";
> + reg = <0>;
> + };
> +
> + cpu@1 {
> + compatible = "ingenic,jz4780";
> + device_type = "cpu";
> + reg = <1>;
> + };
> + };
> +
> cpuintc: interrupt-controller {
> #address-cells = <0>;
> #interrupt-cells = <1>;
> --
> 2.20.1
>
Re: Many unexpected warnings with current sparse
It may be related to the following sparse make warning: No rule to make target '/usr/include/x86_64-linux-gnu/bits/huge_val.h', needed by 'sparse-llvm.o' I don't see huge_val.h in the Ubuntu 19 version of libc6-dev Will send you the kernel config - but I am using the default one from the Ubuntu mainline download of 5.4-rc1 On Tue, Oct 1, 2019 at 6:10 PM Luc Van Oostenryck wrote: > > On Tue, Oct 01, 2019 at 11:28:16AM -0500, Steve French wrote: > > Updated sparse to get rid of some unneeded kernel sparse check > > warnings but now get many more > > > > I get 100s of warnings similar to > > > > ./include/linux/quota.h:114:17: error: Expected ( after asm > > ./include/linux/quota.h:114:17: error: got __inline > > > > but that is simply > > default: > > BUG(); > > Hi, > > I don't see this on v5.4-rc1 with defconfig or allyesconfig and > sparse's current version. Any sparse's version since roughly > mid-December should give the same result. > > If you're using an older version of sparse, please upgrade. > Otherwise, please send me your config so that I can take a look at it. > > > Best regards, > -- Luc Van Oostenryck -- Thanks, Steve
Re: [PATCH v3 0/3] Fix typo in RWH_WRITE_LIFE_NOT_SET constant name
On Fri, Sep 20, 2019 at 8:58 AM Eugene Syromiatnikov wrote: > > Hello. > > This is a small fix of a typo (or, more specifically, some remnant of > the old patch version spelling) in RWH_WRITE_LIFE_NOT_SET constant, > which is named as RWF_WRITE_LIFE_NOT_SET currently. Since the name > with "H" is used in man page and everywhere else, it's probably worth > to make the name used in the fcntl.h UAPI header in line with it. > The two follow-up patches update usage sites of this constant in kernel > to use the new spelling. > > The old name is retained as it is part of UAPI now. > > Changes since v2[1]: > * Updated RWF_WRITE_LIFE_NOT_SET constant usage >in drivers/md/raid5-ppl.c:ppl_init_log(). > > Changes since v1[2]: > * Changed format of the commit ID in the commit message of the first patch. > * Removed bogus Signed-off-by that snuck into the resend of the series. Applied to md-next. Thanks, Song
Re: Many unexpected warnings with current sparse
On Tue, Oct 01, 2019 at 11:28:16AM -0500, Steve French wrote: > Updated sparse to get rid of some unneeded kernel sparse check > warnings but now get many more > > I get 100s of warnings similar to > > ./include/linux/quota.h:114:17: error: Expected ( after asm > ./include/linux/quota.h:114:17: error: got __inline > > but that is simply > default: > BUG(); Hi, I don't see this on v5.4-rc1 with defconfig or allyesconfig and sparse's current version. Any sparse's version since roughly mid-December should give the same result. If you're using an older version of sparse, please upgrade. Otherwise, please send me your config so that I can take a look at it. Best regards, -- Luc Van Oostenryck
Re: [PATCH] md/raid0: Fix an error message in raid0_make_request()
On Fri, Sep 20, 2019 at 11:00 PM Dan Carpenter wrote:
>
> The first argument to WARN() is supposed to be a condition. The
> original code will just print the mdname() instead of the full warning
> message.
>
> Fixes: c84a1372df92 ("md/raid0: avoid RAID0 data corruption due to layout
> confusion.")
> Signed-off-by: Dan Carpenter
> ---
> drivers/md/raid0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/md/raid0.c b/drivers/md/raid0.c
> index f61693e59684..3956ea502f97 100644
> --- a/drivers/md/raid0.c
> +++ b/drivers/md/raid0.c
> @@ -615,7 +615,7 @@ static bool raid0_make_request(struct mddev *mddev,
> struct bio *bio)
> tmp_dev = map_sector(mddev, zone, sector, );
> break;
> default:
> - WARN("md/raid0:%s: Invalid layout\n", mdname(mddev));
> + WARN(1, "md/raid0:%s: Invalid layout\n", mdname(mddev));
> bio_io_error(bio);
> return true;
Applied. Thanks for the fix!
Song
[PATCH] ARM: dts: rockchip: Use interpolated brightness tables for veyron
Use interpolated brightness tables (added by commit 573fe6d1c25
("backlight: pwm_bl: Linear interpolation between
brightness-levels") for veyron, instead of specifying every single
step.
Another option would be to switch to a perceptual brightness curve
(CIE 1931), with the caveat that it would change the behavior of
the backlight. Also the concept of a minimum brightness level is
currently not supported for CIE 1931 curves.
Signed-off-by: Matthias Kaehlcke
---
arch/arm/boot/dts/rk3288-veyron-edp.dtsi | 35 ++
arch/arm/boot/dts/rk3288-veyron-jaq.dts| 35 ++
arch/arm/boot/dts/rk3288-veyron-minnie.dts | 35 ++
arch/arm/boot/dts/rk3288-veyron-tiger.dts | 35 ++
4 files changed, 8 insertions(+), 132 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron-edp.dtsi
b/arch/arm/boot/dts/rk3288-veyron-edp.dtsi
index 773bedca872f..e95c89fe0545 100644
--- a/arch/arm/boot/dts/rk3288-veyron-edp.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-edp.dtsi
@@ -41,39 +41,8 @@
backlight: backlight {
compatible = "pwm-backlight";
- brightness-levels = <
- 0 1 2 3 4 5 6 7
- 8 9 10 11 12 13 14 15
-16 17 18 19 20 21 22 23
-24 25 26 27 28 29 30 31
-32 33 34 35 36 37 38 39
-40 41 42 43 44 45 46 47
-48 49 50 51 52 53 54 55
-56 57 58 59 60 61 62 63
-64 65 66 67 68 69 70 71
-72 73 74 75 76 77 78 79
-80 81 82 83 84 85 86 87
-88 89 90 91 92 93 94 95
-96 97 98 99 100 101 102 103
- 104 105 106 107 108 109 110 111
- 112 113 114 115 116 117 118 119
- 120 121 122 123 124 125 126 127
- 128 129 130 131 132 133 134 135
- 136 137 138 139 140 141 142 143
- 144 145 146 147 148 149 150 151
- 152 153 154 155 156 157 158 159
- 160 161 162 163 164 165 166 167
- 168 169 170 171 172 173 174 175
- 176 177 178 179 180 181 182 183
- 184 185 186 187 188 189 190 191
- 192 193 194 195 196 197 198 199
- 200 201 202 203 204 205 206 207
- 208 209 210 211 212 213 214 215
- 216 217 218 219 220 221 222 223
- 224 225 226 227 228 229 230 231
- 232 233 234 235 236 237 238 239
- 240 241 242 243 244 245 246 247
- 248 249 250 251 252 253 254 255>;
+ brightness-levels = <0 255>;
+ num-interpolated-steps = <254>;
default-brightness-level = <128>;
enable-gpios = < RK_PA2 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
index 56ad9a43a6c2..5e10cc644875 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
@@ -21,39 +21,8 @@
{
/* Jaq panel PWM must be >= 3%, so start non-zero brightness at 8 */
- brightness-levels = <
- 0
- 8 9 10 11 12 13 14 15
-16 17 18 19 20 21 22 23
-24 25 26 27 28 29 30 31
-32 33 34 35 36 37 38 39
-40 41 42 43 44 45 46 47
-48 49 50 51 52 53 54 55
-56 57 58 59 60 61 62 63
-64 65 66 67 68 69 70 71
-72 73 74 75 76 77 78 79
-80 81 82 83 84 85 86 87
-88 89 90 91 92 93 94 95
-96 97 98 99 100 101 102 103
- 104 105 106 107 108 109 110 111
- 112 113 114 115 116 117 118 119
- 120 121 122 123 124 125 126 127
- 128 129 130 131 132 133 134 135
- 136 137 138 139 140 141 142 143
- 144 145 146 147 148 149 150 151
- 152 153 154 155 156 157 158 159
- 160 161 162 163 164 165 166 167
- 168 169 170 171 172 173 174 175
- 176 177 178 179 180 181 182 183
- 184 185 186 187 188 189 190 191
- 192 193 194 195 196 197 198 199
- 200 201 202 203 204 205 206 207
- 208 209 210 211 212 213 214 215
- 216 217 218 219 220 221 222 223
- 224 225 226 227 228 229 230 231
- 232 233 234 235 236 237 238 239
-
Re: [PATCH 3/3] PCI: pciehp: Add dmi table for in-band presence disabled
On Tue, Oct 1, 2019 at 4:36 PM Alex G. wrote:
>
>
>
> On 10/1/19 4:14 PM, Stuart Hayes wrote:
> > Some systems have in-band presence detection disabled for hot-plug PCI
> > slots,
> > but do not report this in the slot capabilities 2 (SLTCAP2) register. On
> > these systems, presence detect can become active well after the link is
> > reported to be active, which can cause the slots to be disabled after a
> > device is connected.
> >
> > Add a dmi table to flag these systems as having in-band presence disabled.
> >
> > Signed-off-by: Stuart Hayes
> > ---
> > drivers/pci/hotplug/pciehp_hpc.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/pci/hotplug/pciehp_hpc.c
> > b/drivers/pci/hotplug/pciehp_hpc.c
> > index 1282641c6458..1dd01e752587 100644
> > --- a/drivers/pci/hotplug/pciehp_hpc.c
> > +++ b/drivers/pci/hotplug/pciehp_hpc.c
> > @@ -14,6 +14,7 @@
> >
> > #define dev_fmt(fmt) "pciehp: " fmt
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -26,6 +27,16 @@
> > #include "../pci.h"
> > #include "pciehp.h"
> >
> > +static const struct dmi_system_id inband_presence_disabled_dmi_table[] = {
> > + {
> > + .ident = "Dell System",
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc"),
> > + },
> > + },
> > + {}
> > +};
> > +
>
> I'm not sure that all Dell systems that were ever made or will be made
> have in-band presence disabled on all their hotplug slots.
>
> This was a problem with the NVMe hot-swap bays on 14G servers. I can't
> guarantee that any other slot or machine will need this workaround. The
> best way I found to implement this is to check for the PCI-ID of the
> switches behind the port.
>
> Alex
That is definitely true, not all Dell systems actually disable in-band
presence detect and need this. However, we have a number of systems
that need this, and we don't have the PCI IDs for all of these yet, so
we decided it was preferable to just make all Dell systems wait for
presence detect to go active. Since all of our systems support
presence detect (either in-band or out-of-band), it shouldn't have any
negative effects--on systems that support in-band presence, it will
already be active and it won't spend any extra time waiting for it.
If someone plugs in a device that has hot-plug slots with no support
for presence detect at all (even though Dell doesn't support any), it
should still work--it'll just take an extra second for them to come
up.
Re: [PATCH bpf 0/2] selftests/bpf: test_progs: don't leak fd in bpf
On Tue, Oct 01, 2019 at 10:37:26AM -0700, Brian Vazquez wrote: > This patch series fixes some fd leaks in tcp_rtt and > test_sockopt_inherit bpf prof_tests. > > Brian Vazquez (2): > selftests/bpf: test_progs: don't leak server_fd in tcp_rtt > selftests/bpf: test_progs: don't leak server_fd in > test_sockopt_inherit > > tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c | 2 +- > tools/testing/selftests/bpf/prog_tests/tcp_rtt.c | 3 ++- > 2 files changed, 3 insertions(+), 2 deletions(-) Applied, thanks!
RE: [PATCH 5.2 02/45] smb3: fix unmount hang in open_shroot
-Original Message- From: Sasha Levin Sent: Tuesday, October 1, 2019 3:49 PM > On Tue, Oct 01, 2019 at 08:41:43PM +, Pavel Shilovskiy wrote: > >Hi Greg, > > > >Are you going to apply this patch to the 5.3.y stable kernel? The patch is > >applicable there too. > > I will, yes. Thanks! Best regards, Pavel Shilovsky
Re: [RFC][PATCH] sysctl: Remove the sysctl system call
Kees Cook writes: > On Tue, Oct 01, 2019 at 01:36:32PM -0500, Eric W. Biederman wrote: >> >> This system call has been deprecated almost since it was introduced, and >> in a survey of the linux distributions I can no longer find any of them >> that enable CONFIG_SYSCTL_SYSCALL. The only indication that I can find >> that anyone might care is that a few of the defconfigs in the kernel >> enable CONFIG_SYSCTL_SYSCALL. However this appears in only 31 of 414 >> defconfigs in the kernel, so I suspect this symbols presence is simply >> because it is harmless to include rather than because it is necessary. >> >> As there appear to be no users of the sysctl system call, remove the >> code. As this removes one of the few uses of the internal kernel mount >> of proc I hope this allows for even more simplifications of the proc >> filesystem. > > I'm for it. :) I tripped over this being deprecated over a decade ago. :P > > I think you can actually take this further and remove (or at least > empty) the uapi/linux/sysctl.h file too. I copied everyone who had put this into a defconfig and I will wait a little more to see if anyone screams. I think it is a safe guess that several of the affected configurations are dead (or at least unmaintained) as I received 17 bounces when copying everyone. I would make it a followup that removes uapi/linux/sysctl.h. I don't see anything in it that isn't about the sysctl system call. I will keep it a separate patch as I can imagine something silly that needs the header file to compile. A separate patch would make a revert easier if we find something like that. Eric
[PATCH 3/7] irqchip/irq-bcm2835: Add support for 7211 interrupt controller
BCM7211 has a number of similarities with BCM2836, except the register
offsets are different and the bank bits are also different, account for
all of these differences.
Signed-off-by: Florian Fainelli
---
drivers/irqchip/irq-bcm2835.c | 86 +--
1 file changed, 72 insertions(+), 14 deletions(-)
diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index 418245d31921..55afc3487723 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -57,19 +57,34 @@
#define SHORTCUT_SHIFT 10
#define BANK1_HWIRQBIT(8)
#define BANK2_HWIRQBIT(9)
+#define BANK1_HWIRQ_BCM7211BIT(24)
+#define BANK2_HWIRQ_BCM7211BIT(25)
#define BANK0_VALID_MASK (BANK0_HWIRQ_MASK | BANK1_HWIRQ | BANK2_HWIRQ \
| SHORTCUT1_MASK | SHORTCUT2_MASK)
+#define BANK0_VALID_MASK_BCM7211 (BANK0_HWIRQ_MASK | BANK1_HWIRQ_BCM7211 | \
+ BANK2_HWIRQ_BCM7211 | SHORTCUT1_MASK | \
+ SHORTCUT2_MASK)
#define REG_FIQ_CONTROL0x0c
#define NR_BANKS 3
#define IRQS_PER_BANK 32
+enum armctrl_type {
+ ARMCTRL_BCM2835 = 0,
+ ARMCTRL_BCM2836,
+ ARMCTRL_BCM7211
+};
+
static const int reg_pending[] __initconst = { 0x00, 0x04, 0x08 };
static const int reg_enable[] __initconst = { 0x18, 0x10, 0x14 };
static const int reg_disable[] __initconst = { 0x24, 0x1c, 0x20 };
static const int bank_irqs[] __initconst = { 8, 32, 32 };
+static const int reg_pending_bcm7211[] __initconst = { 0x08, 0x00, 0x04 };
+static const int reg_enable_bcm7211[] __initconst = { 0x18, 0x10, 0x14 };
+static const int reg_disable_bcm7211[] __initconst = { 0x28, 0x20, 0x24 };
+
static const int shortcuts[] = {
7, 9, 10, 18, 19, /* Bank 1 */
21, 22, 23, 24, 25, 30 /* Bank 2 */
@@ -87,6 +102,7 @@ static struct armctrl_ic intc __read_mostly;
static void __exception_irq_entry bcm2835_handle_irq(
struct pt_regs *regs);
static void bcm2836_chained_handle_irq(struct irq_desc *desc);
+static void bcm7211_chained_handle_irq(struct irq_desc *desc);
static void armctrl_mask_irq(struct irq_data *d)
{
@@ -131,11 +147,14 @@ static const struct irq_domain_ops armctrl_ops = {
static int __init armctrl_of_init(struct device_node *node,
struct device_node *parent,
- bool is_2836)
+ enum armctrl_type type)
{
void __iomem *base;
int irq, b, i;
+ if (type > ARMCTRL_BCM7211)
+ return -EINVAL;
+
base = of_iomap(node, 0);
if (!base)
panic("%pOF: unable to map IC registers\n", node);
@@ -146,9 +165,19 @@ static int __init armctrl_of_init(struct device_node *node,
panic("%pOF: unable to create IRQ domain\n", node);
for (b = 0; b < NR_BANKS; b++) {
- intc.pending[b] = base + reg_pending[b];
- intc.enable[b] = base + reg_enable[b];
- intc.disable[b] = base + reg_disable[b];
+ if (type <= ARMCTRL_BCM2836) {
+ intc.pending[b] = base + reg_pending[b];
+ intc.enable[b] = base + reg_enable[b];
+ intc.disable[b] = base + reg_disable[b];
+ } else {
+ intc.pending[b] = base + reg_pending_bcm7211[b];
+ intc.enable[b] = base + reg_enable_bcm7211[b];
+ intc.disable[b] = base + reg_disable_bcm7211[b];
+ }
+
+ if (type == ARMCTRL_BCM7211)
+ armctrl_chip.flags |= IRQCHIP_MASK_ON_SUSPEND |
+ IRQCHIP_SKIP_SET_WAKE;
for (i = 0; i < bank_irqs[b]; i++) {
irq = irq_create_mapping(intc.domain, MAKE_HWIRQ(b, i));
@@ -159,14 +188,19 @@ static int __init armctrl_of_init(struct device_node
*node,
}
}
- if (is_2836) {
+ if (type >= ARMCTRL_BCM2836) {
int parent_irq = irq_of_parse_and_map(node, 0);
if (!parent_irq) {
panic("%pOF: unable to get parent interrupt.\n",
node);
}
- irq_set_chained_handler(parent_irq, bcm2836_chained_handle_irq);
+ if (type == ARMCTRL_BCM2836)
+ irq_set_chained_handler(parent_irq,
+ bcm2836_chained_handle_irq);
+ else
+ irq_set_chained_handler(parent_irq,
+ bcm7211_chained_handle_irq);
} else {
set_handle_irq(bcm2835_handle_irq);
}
@@ -177,13 +211,19 @@ static int __init armctrl_of_init(struct device_node
[PATCH 7/7] irqchip/irq-bcm283x: Add registration prints
With many different kind of interrupt controllers available and used on
7211, add prints to help determine which ones are registered.
Signed-off-by: Florian Fainelli
---
drivers/irqchip/irq-bcm2835.c | 9 +
drivers/irqchip/irq-bcm2836.c | 2 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index 55afc3487723..ae23e9ec86d0 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -76,6 +76,12 @@ enum armctrl_type {
ARMCTRL_BCM7211
};
+static const char *armctrl_type_str[] = {
+ [ARMCTRL_BCM2835] = "BCM2835",
+ [ARMCTRL_BCM2836] = "BCM2836",
+ [ARMCTRL_BCM7211] = "BCM7211",
+};
+
static const int reg_pending[] __initconst = { 0x00, 0x04, 0x08 };
static const int reg_enable[] __initconst = { 0x18, 0x10, 0x14 };
static const int reg_disable[] __initconst = { 0x24, 0x1c, 0x20 };
@@ -205,6 +211,9 @@ static int __init armctrl_of_init(struct device_node *node,
set_handle_irq(bcm2835_handle_irq);
}
+ pr_info("registered %s intc (%pOF)\n", armctrl_type_str[type],
+ node);
+
return 0;
}
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 77fa395c8f6b..b159dc91919d 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -240,6 +240,8 @@ static int __init arm_irqchip_l1_intc_of_init_smp(struct
device_node *node,
set_handle_irq(bcm2836_arm_irqchip_handle_irq);
+ pr_info("Registered BCM2836 intc (%s)\n", node->full_name);
+
return 0;
}
--
2.17.1
[PATCH 6/7] irqchip: Build BCM283X_IRQ for ARCH_BRCMSTB
Now that irq-bcm2835.c and irq-bcm2836.c have been updated to support BCM7211 which is under ARCH_BRCMSTB, build both drivers for ARCH_BRCMSTB. Signed-off-by: Florian Fainelli --- drivers/irqchip/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index d1bb20d23d27..ffd5f986172a 100644 --- a/drivers/irqchip/Kconfig +++ b/drivers/irqchip/Kconfig @@ -116,7 +116,7 @@ config I8259 config BCM283X_IRQ bool select IRQ_DOMAIN - default ARCH_BCM2835 + default ARCH_BCM2835 || ARCH_BRCMSTB config BCM6345_L1_IRQ bool -- 2.17.1
[PATCH 4/7] dt-bindings: interrupt-controller: Add brcm,bcm7211-l1-intc binding
BCM7211 uses a very similar root interrupt controller than what exists on BCM2836, define a specific compatible string to key off specific behavior. Signed-off-by: Florian Fainelli --- .../bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt| 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt index 8ced1696c325..13bef028d6ad 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt @@ -7,7 +7,9 @@ controller. Required properties: -- compatible: Should be "brcm,bcm2836-l1-intc" +- compatible: Should be one of + "brcm,bcm2836-l1-intc" + "brcm,bcm7211-l1-intc" - reg: Specifies base physical address and size of the registers - interrupt-controller:Identifies the node as an interrupt controller -- 2.17.1
Re: [PATCH 5.2 02/45] smb3: fix unmount hang in open_shroot
On Tue, Oct 01, 2019 at 08:41:43PM +, Pavel Shilovskiy wrote: Hi Greg, Are you going to apply this patch to the 5.3.y stable kernel? The patch is applicable there too. I will, yes. -- Thanks, Sasha
[PATCH 5/7] irqchip/irq-bcm2836: Add support for the 7211 interrupt controller
The root interrupt controller on 7211 is about identical to the one
existing on BCM2836, except that the SMP cross call are done through the
standard ARM GIC-400 interrupt controller. This interrupt controller is
used for side band wake-up signals though.
Signed-off-by: Florian Fainelli
---
drivers/irqchip/irq-bcm2836.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 2038693f074c..77fa395c8f6b 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -112,6 +112,8 @@ static int bcm2836_map(struct irq_domain *d, unsigned int
irq,
return -EINVAL;
}
+ chip->flags |= IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_SKIP_SET_WAKE;
+
irq_set_percpu_devid(irq);
irq_domain_set_info(d, irq, hw, chip, d->host_data,
handle_percpu_devid_irq, NULL, NULL);
@@ -216,8 +218,9 @@ static void bcm2835_init_local_timer_frequency(void)
writel(0x8000, intc.base + LOCAL_PRESCALER);
}
-static int __init bcm2836_arm_irqchip_l1_intc_of_init(struct device_node *node,
- struct device_node
*parent)
+static int __init arm_irqchip_l1_intc_of_init_smp(struct device_node *node,
+ struct device_node *parent,
+ bool smp_init)
{
intc.base = of_iomap(node, 0);
if (!intc.base) {
@@ -232,11 +235,27 @@ static int __init
bcm2836_arm_irqchip_l1_intc_of_init(struct device_node *node,
if (!intc.domain)
panic("%pOF: unable to create IRQ domain\n", node);
- bcm2836_arm_irqchip_smp_init();
+ if (smp_init)
+ bcm2836_arm_irqchip_smp_init();
set_handle_irq(bcm2836_arm_irqchip_handle_irq);
+
return 0;
}
+static int __init bcm2836_arm_irqchip_l1_intc_of_init(struct device_node *node,
+ struct device_node
*parent)
+{
+ return arm_irqchip_l1_intc_of_init_smp(node, parent, true);
+}
+
+static int __init bcm7211_arm_irqchip_l1_intc_of_init(struct device_node *node,
+ struct device_node
*parent)
+{
+ return arm_irqchip_l1_intc_of_init_smp(node, parent, false);
+}
+
IRQCHIP_DECLARE(bcm2836_arm_irqchip_l1_intc, "brcm,bcm2836-l1-intc",
bcm2836_arm_irqchip_l1_intc_of_init);
+IRQCHIP_DECLARE(bcm7211_arm_irqchip_l1_intc, "brcm,bcm7211-l1-intc",
+ bcm7211_arm_irqchip_l1_intc_of_init);
--
2.17.1
[PATCH 0/7] irqchip/irq-bcm283x update for BCM7211
Hi Marc, Jason, Thomas, This patch series updates the BCM2835 and BCM2836 interrupt controller drivers to support BCM7211 which can make use of those drivers in some configurations where the ARM GIC is muxed out and the legacy ARM interrupt controller is used instead. Thank you! Florian Fainelli (7): irqchip: Introduce Kconfig symbol to build irq-bcm283x.c dt-bindings: interrupt-controller: Add brcm,bcm7211-armctrl-ic binding irqchip/irq-bcm2835: Add support for 7211 interrupt controller dt-bindings: interrupt-controller: Add brcm,bcm7211-l1-intc binding irqchip/irq-bcm2836: Add support for the 7211 interrupt controller irqchip: Build BCM283X_IRQ for ARCH_BRCMSTB irqchip/irq-bcm283x: Add registration prints .../brcm,bcm2835-armctrl-ic.txt | 6 +- .../brcm,bcm2836-l1-intc.txt | 4 +- drivers/irqchip/Kconfig | 5 + drivers/irqchip/Makefile | 4 +- drivers/irqchip/irq-bcm2835.c | 95 --- drivers/irqchip/irq-bcm2836.c | 27 +- 6 files changed, 119 insertions(+), 22 deletions(-) -- 2.17.1
[PATCH 1/7] irqchip: Introduce Kconfig symbol to build irq-bcm283x.c
Both irq-bcm2835.c and irq-bcm2836.c are currently used with ARCH_BCM2835 but are soon going to be used with ARCH_BRCMSTB, introduce a Kconfig symbol to make that those drivers selected/built by other platforms. Signed-off-by: Florian Fainelli --- drivers/irqchip/Kconfig | 5 + drivers/irqchip/Makefile | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index 80e10f4e213a..d1bb20d23d27 100644 --- a/drivers/irqchip/Kconfig +++ b/drivers/irqchip/Kconfig @@ -113,6 +113,11 @@ config I8259 bool select IRQ_DOMAIN +config BCM283X_IRQ + bool + select IRQ_DOMAIN + default ARCH_BCM2835 + config BCM6345_L1_IRQ bool select GENERIC_IRQ_CHIP diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile index 8d0fcec6ab23..9cf14c7945f6 100644 --- a/drivers/irqchip/Makefile +++ b/drivers/irqchip/Makefile @@ -5,8 +5,8 @@ obj-$(CONFIG_AL_FIC)+= irq-al-fic.o obj-$(CONFIG_ALPINE_MSI) += irq-alpine-msi.o obj-$(CONFIG_ATH79)+= irq-ath79-cpu.o obj-$(CONFIG_ATH79)+= irq-ath79-misc.o -obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o -obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2836.o +obj-$(CONFIG_BCM283X_IRQ) += irq-bcm2835.o +obj-$(CONFIG_BCM283X_IRQ) += irq-bcm2836.o obj-$(CONFIG_DAVINCI_AINTC)+= irq-davinci-aintc.o obj-$(CONFIG_DAVINCI_CP_INTC) += irq-davinci-cp-intc.o obj-$(CONFIG_ARCH_EXYNOS) += exynos-combiner.o -- 2.17.1
[PATCH 2/7] dt-bindings: interrupt-controller: Add brcm,bcm7211-armctrl-ic binding
BCM7211 features a second level interrupt controller similar in nature to BCM2836, with a few modifications to the register offsets, document that specific compatible string. Signed-off-by: Florian Fainelli --- .../interrupt-controller/brcm,bcm2835-armctrl-ic.txt| 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt index 0f1af5a1c12e..0b07845b46e4 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt @@ -12,7 +12,8 @@ interrupt there indicates that the ARMCTRL has an interrupt to handle. Required properties: - compatible : should be "brcm,bcm2835-armctrl-ic" or - "brcm,bcm2836-armctrl-ic" + "brcm,bcm2836-armctrl-ic" or +"brcm,bcm7211-armctrl-ic" - reg : Specifies base physical address and size of the registers. - interrupt-controller : Identifies the node as an interrupt controller - #interrupt-cells : Specifies the number of cells needed to encode an @@ -25,7 +26,8 @@ Required properties: The 2nd cell contains the interrupt number within the bank. Valid values are 0..7 for bank 0, and 0..31 for bank 1. -Additional required properties for brcm,bcm2836-armctrl-ic: +Additional required properties for brcm,bcm2836-armctrl-ic and +brcm,bcm7211-armctrl-ic: - interrupts : Specifies the interrupt on the parent for this interrupt controller to handle. -- 2.17.1
