Re: [PATCH] x86/hpet: Disable HPET on Intel Coffe Lake
Hi Kai-Heng,
On Thu, Aug 29, 2019 at 5:14 PM Kai-Heng Feng
wrote:
>
> Some Coffee Lake platforms have skewed HPET timer once the SoCs entered
> PC10, and marked TSC as unstable clocksource as result.
>
> Harry Pan identified it's a firmware bug [1].
>
> To prevent creating a circular dependency between HPET and TSC, let's
> disable HPET on affected platforms.
Sorry for chiming late.
We have disabled the HPET for Baytrail platforms in
commit 62187910b0fc : x86/intel: Add quirk to disable HPET for the
Baytrail platform
Which added a quirk in
@@ -567,6 +577,12 @@ static struct chipset early_qrk[] __initdata = {
+ /*
+* HPET on current version of Baytrail platform has accuracy
+* problems, disable it for now:
+*/
+ { PCI_VENDOR_ID_INTEL, 0x0f00,
+ PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, force_disable_hpet},
So maybe we can unify the method to disable HPET. (btw, I have no idea
about the healthy info of HPET for Kabylake, just want to comment
on the disabling method).
Thanks,
Feng
>
> [1]: https://lore.kernel.org/lkml/20190516090651.1396-1-harry@intel.com/
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203183
>
> Signed-off-by: Kai-Heng Feng
> ---
> arch/x86/kernel/hpet.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> index c6f791bc481e..07e9ec6f85b6 100644
> --- a/arch/x86/kernel/hpet.c
> +++ b/arch/x86/kernel/hpet.c
> @@ -7,7 +7,9 @@
> #include
> #include
>
> +#include
> #include
> +#include
> #include
>
> #undef pr_fmt
> @@ -806,6 +808,12 @@ static bool __init hpet_counting(void)
> return false;
> }
>
> +static const struct x86_cpu_id hpet_blacklist[] __initconst = {
> + { X86_VENDOR_INTEL, 6, INTEL_FAM6_KABYLAKE_MOBILE },
> + { X86_VENDOR_INTEL, 6, INTEL_FAM6_KABYLAKE_DESKTOP },
> + { }
> +};
> +
> /**
> * hpet_enable - Try to setup the HPET timer. Returns 1 on success.
> */
> @@ -819,6 +827,9 @@ int __init hpet_enable(void)
> if (!is_hpet_capable())
> return 0;
>
> + if (!hpet_force_user && x86_match_cpu(hpet_blacklist))
> + return 0;
> +
> hpet_set_mapping();
> if (!hpet_virt_address)
> return 0;
> --
> 2.17.1
>
Re: [PATCH v7 2/7] kvm: vmx: Define CET VMCS fields and CPUID flags
On Wed, Oct 02, 2019 at 11:04:07AM -0700, Jim Mattson wrote: > On Thu, Sep 26, 2019 at 7:17 PM Yang Weijiang wrote: > > > > CET(Control-flow Enforcement Technology) is an upcoming Intel(R) > > processor feature that blocks Return/Jump-Oriented Programming(ROP) > > attacks. It provides the following capabilities to defend > > against ROP/JOP style control-flow subversion attacks: > > /* > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > > index 9d282fec0a62..1aa86b87b6ab 100644 > > --- a/arch/x86/kvm/cpuid.c > > +++ b/arch/x86/kvm/cpuid.c > > @@ -365,13 +365,13 @@ static inline void do_cpuid_7_mask(struct > > kvm_cpuid_entry2 *entry, int index) > > F(AVX512VBMI) | F(LA57) | F(PKU) | 0 /*OSPKE*/ | > > F(AVX512_VPOPCNTDQ) | F(UMIP) | F(AVX512_VBMI2) | F(GFNI) | > > F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) | F(AVX512_BITALG) > > | > > - F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B); > > + F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B) | F(SHSTK); > > > > /* cpuid 7.0.edx*/ > > const u32 kvm_cpuid_7_0_edx_x86_features = > > F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) | > > F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES) | F(INTEL_STIBP) | > > - F(MD_CLEAR); > > + F(MD_CLEAR) | F(IBT); > > Claiming that SHSTK and IBT are supported in the guest seems premature > as of this change, since you haven't actually done anything to > virtualize the features yet. > OK, will put the flags in other patch. > > /* cpuid 7.1.eax */ > > const u32 kvm_cpuid_7_1_eax_x86_features = > > diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h > > index fbffabad0370..a85800b23e6e 100644 > > --- a/arch/x86/kvm/x86.h > > +++ b/arch/x86/kvm/x86.h > > @@ -298,7 +298,8 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, > > unsigned long cr2, > > * Right now, no XSS states are used on x86 platform, > > * expand the macro for new features. > > */ > > -#define KVM_SUPPORTED_XSS (0) > > +#define KVM_SUPPORTED_XSS (XFEATURE_MASK_CET_USER \ > > + | XFEATURE_MASK_CET_KERNEL) > > If IA32_XSS can dynamically change within the guest, it will have to > be enumerated by KVM_GET_MSR_INDEX_LIST. thanks for pointing it out, need to add IA32_XSS to msrs_to_save list. >(Note that Aaron Lewis is > working on a series which will include that enumeration, if you'd like > to wait.) I'm also not convinced that there is sufficient > virtualization of these features to allow these bits to be set in the > guest IA32_XSS at this point. > It's true CET is working in guest after I added XSS/XSAVES support in KVM and QEMU, but I'd like to look at Aaron's new patch... > > extern u64 host_xcr0; > > > > -- > > 2.17.2 > >
RE: [PATCH 00/20] DPAA fixes
> -Original Message- > From: Jakub Kicinski > Sent: Wednesday, October 9, 2019 7:02 AM > Subject: Re: [PATCH 00/20] DPAA fixes > > On Tue, 8 Oct 2019 15:10:21 +0300, Madalin Bucur wrote: > > Here's a series of fixes and changes for the DPAA 1.x drivers. > > Fixing some boot time dependency issues, removing some dead code, > > changing the buffers used for reception, fixing the DMA devices, > > some cleanups. > > Hi Madalin! > > The title of this series says "DPAA fixes", are these bug fixes? > If so they should target the net tree ([PATCH net]) and contain > appropriate Fixes tags. > > Cleanups should go into the net-next tree ([PATCH net-next]). > > Please try to not post more than 15 patches in one series, it clogs > up the review flow. > > For some of those and other best practices please see: > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html > https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html > > :) > > IMHO there is also no need at all to CC linux-kernel on networking > patches.. Hi Jakub, I should have added the net-next target in the subject. I can split the (minor) fixes from the other changes. I've added "Fixes" tags to the fix patches already. In regards to the patch count, I can send two patch sets but it won't reduce the total... Regards, Madalin
RE: [PATCH] nvmem: imx: scu: fix dependency in Kconfig
> Subject: [PATCH] nvmem: imx: scu: fix dependency in Kconfig > > Fix below error by adding HAVE_ARM_SMCCC dependency in Kconfig > ERROR: "__arm_smccc_smc" [drivers/nvmem/nvmem-imx-ocotp-scu.ko] > undefined! > > Reported-by: kbuild test robot > Signed-off-by: Srinivas Kandagatla > --- > drivers/nvmem/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig index > 8fd425d38d97..fd0716818881 100644 > --- a/drivers/nvmem/Kconfig > +++ b/drivers/nvmem/Kconfig > @@ -50,6 +50,7 @@ config NVMEM_IMX_OCOTP config > NVMEM_IMX_OCOTP_SCU > tristate "i.MX8 SCU On-Chip OTP Controller support" > depends on IMX_SCU > + depends on HAVE_ARM_SMCCC > help > This is a driver for the SCU On-Chip OTP Controller (OCOTP) > available on i.MX8 SoCs. Thanks for the fix. Reviewed-by: Peng Fan Thanks, Peng. > -- > 2.21.0
Re: [kbuild-all] Re: [PATCH] lis3lv02d: switch to using input device polling mode
Hi, On 10/3/19 8:03 AM, Dmitry Torokhov wrote: On Wed, Oct 02, 2019 at 04:59:43PM -0700, Dmitry Torokhov wrote: On Thu, Oct 03, 2019 at 07:30:23AM +0800, kbuild test robot wrote: Hi Dmitry, I love your patch! Yet something to improve: [auto build test ERROR on char-misc/char-misc-testing] [cannot apply to v5.4-rc1 next-20191002] This is weird, I just tried applying it to both next-20191002 and Greg's char-misc/char-misc-testing and it applied cleanly and compiled (on x86). You seem to have tried applying it to this commit: Merge tag 'char-misc-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver updates from Greg KH: "Here is the big char/misc driver pull request for 5.4-rc1... so of it failed because at that time Linus' tree did not have the necessary input changes. I am not sure why you decided to apply the patch to this particular commit. Thanks. Thanks for your comment, robot applied the patch to the head of char-misc/char-misc-testing, It seems the branch was still old at that moment. We'll fix it asap. Best Regards, Rong Chen
RE: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
Hi Paolo, > -Original Message- > From: Paolo Bonzini > Sent: Thursday, September 19, 2019 8:13 PM > To: Marc Zyngier ; Jianyong Wu (Arm Technology China) > ; net...@vger.kernel.org; yangbo...@nxp.com; > john.stu...@linaro.org; t...@linutronix.de; sean.j.christopher...@intel.com; > richardcoch...@gmail.com; Mark Rutland ; Will > Deacon ; Suzuki Poulose > > Cc: linux-kernel@vger.kernel.org; k...@vger.kernel.org; Steve Capper > ; Kaly Xin (Arm Technology China) > ; Justin He (Arm Technology China) > ; nd ; linux-arm- > ker...@lists.infradead.org > Subject: Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm. > > On 19/09/19 13:39, Marc Zyngier wrote: > >> I don't think it's ugly but more important, using tk->tkr_mono.clock > >> is incorrect. See how the x86 code hardcodes _clock, it's the > >> same for ARM. > > Not really. The guest kernel is free to use any clocksource it wishes. > > Understood, in fact it's the same on x86. > > However, for PTP to work, the cycles value returned by the clocksource must > match the one returned by the hypercall. So for ARM > get_device_system_crosststamp must receive the arch timer clocksource, so > that it will return -ENODEV if the active clocksource is anything else. > As ptp_kvm clock has fixed to arm arch system counter in patch set v4, we need check if the current clocksource is system counter when return clock cycle in host, so a helper needed to return the current clocksource. Could I add this helper in next patch set? Thanks Jianyong wu > Paolo > > > In some cases, it is actually desirable (like these broken systems > > that cannot use an in-kernel irqchip...). Maybe it is that on x86 the > > guest only uses the kvm_clock, but that's a much harder sell on ARM. > > The fact that ptp_kvm assumes that the clocksource is fixed doesn't > > seem correct in that case.
Re: [PATCH] mfd: mt6397: fix probe after changing mt6397-core
Should i send patch without the shift (because rest of series gets not merged
in 5.4)?
Am 4. Oktober 2019 17:20:01 MESZ schrieb Lee Jones :
>On Thu, 03 Oct 2019, Frank Wunderlich wrote:
>
>> Part 3 from this series [1] was not merged due to wrong splitting
>> and breaks mt6323 pmic on bananapi-r2
>>
>> dmesg prints this line and at least switch is not initialized on
>bananapi-r2
>>
>> mt6397 1000d000.pwrap:mt6323: unsupported chip: 0x0
>>
>> this patch contains only the probe-changes and chip_data structs
>> from original part 3 by Hsin-Hsiung Wang
>>
>> Fixes: a4872e80ce7d2a1844328176dbf279d0a2b89bdb mfd: mt6397: Extract
>IRQ related code from core driver
>>
>> [1]
>https://patchwork.kernel.org/project/linux-mediatek/list/?series=164155
>>
>> Signed-off-by: Frank Wunderlich
>> ---
>> drivers/mfd/mt6397-core.c | 64
>---
>> 1 file changed, 40 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
>> index 310dae26ddff..b2c325ead1c8 100644
>> --- a/drivers/mfd/mt6397-core.c
>> +++ b/drivers/mfd/mt6397-core.c
>> @@ -129,11 +129,27 @@ static int mt6397_irq_resume(struct device
>*dev)
>> static SIMPLE_DEV_PM_OPS(mt6397_pm_ops, mt6397_irq_suspend,
>> mt6397_irq_resume);
>>
>> +struct chip_data {
>> +u32 cid_addr;
>> +u32 cid_shift;
>> +};
>> +
>> +static const struct chip_data mt6323_core = {
>> +.cid_addr = MT6323_CID,
>> +.cid_shift = 0,
>> +};
>> +
>> +static const struct chip_data mt6397_core = {
>> +.cid_addr = MT6397_CID,
>> +.cid_shift = 0,
>> +};
>
>Will there be other devices which have a !0 CID shift?
>
>--
>Lee Jones [李琼斯]
>Linaro Services Technical Lead
>Linaro.org │ Open source software for ARM SoCs
>Follow Linaro: Facebook | Twitter | Blog
>
>___
>Linux-mediatek mailing list
>linux-media...@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH] cgroup, blkcg: prevent dirty inodes to pin dying memory cgroups
On Tue, Oct 08, 2019 at 10:20:39AM +0200, Jan Kara wrote:
> On Tue 08-10-19 05:38:59, Roman Gushchin wrote:
> > On Tue, Oct 08, 2019 at 03:06:31PM +1100, Dave Chinner wrote:
> > > On Fri, Oct 04, 2019 at 03:11:04PM -0700, Roman Gushchin wrote:
> > > > This is a RFC patch, which is not intended to be merged as is,
> > > > but hopefully will start a discussion which can result in a good
> > > > solution for the described problem.
> > > >
> > > > --
> > > >
> > > > We've noticed that the number of dying cgroups on our production hosts
> > > > tends to grow with the uptime. This time it's caused by the writeback
> > > > code.
> > > >
> > > > An inode which is getting dirty for the first time is associated
> > > > with the wb structure (look at __inode_attach_wb()). It can later
> > > > be switched to another wb under some conditions (e.g. some other
> > > > cgroup is writing a lot of data to the same inode), but generally
> > > > stays associated up to the end of life of the inode structure.
> > > >
> > > > The problem is that the wb structure holds a reference to the original
> > > > memory cgroup. So if the inode was dirty once, it has a good chance
> > > > to pin down the original memory cgroup.
> > > >
> > > > An example from the real life: some service runs periodically and
> > > > updates rpm packages. Each time in a new memory cgroup. Installed
> > > > .so files are heavily used by other cgroups, so corresponding inodes
> > > > tend to stay alive for a long. So do pinned memory cgroups.
> > > > In production I've seen many hosts with 1-2 thousands of dying
> > > > cgroups.
> > > >
> > > > This is not the first problem with the dying memory cgroups. As
> > > > always, the problem is with their relative size: memory cgroups
> > > > are large objects, easily 100x-1000x larger that inodes. So keeping
> > > > a couple of thousands of dying cgroups in memory without a good reason
> > > > (what we easily do with inodes) is quite costly (and is measured
> > > > in tens and hundreds of Mb).
> > > >
> > > > One possible approach to this problem is to switch inodes associated
> > > > with dying wbs to the root wb. Switching is a best effort operation
> > > > which can fail silently, so unfortunately we can't run once over a
> > > > list of associated inodes (even if we'd have such a list). So we
> > > > really have to scan all inodes.
> > > >
> > > > In the proposed patch I schedule a work on each memory cgroup
> > > > deletion, which is probably too often. Alternatively, we can do it
> > > > periodically under some conditions (e.g. the number of dying memory
> > > > cgroups is larger than X). So it's basically a gc run.
> > > >
> > > > I wonder if there are any better ideas?
> > > >
> > > > Signed-off-by: Roman Gushchin
> > > > ---
> > > > fs/fs-writeback.c | 29 +
> > > > mm/memcontrol.c | 5 +
> > > > 2 files changed, 34 insertions(+)
> > > >
> > > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> > > > index 542b02d170f8..4bbc9a200b2c 100644
> > > > --- a/fs/fs-writeback.c
> > > > +++ b/fs/fs-writeback.c
> > > > @@ -545,6 +545,35 @@ static void inode_switch_wbs(struct inode *inode,
> > > > int new_wb_id)
> > > > up_read(>wb_switch_rwsem);
> > > > }
> > > >
> > > > +static void reparent_dirty_inodes_one_sb(struct super_block *sb, void
> > > > *arg)
> > > > +{
> > > > + struct inode *inode, *next;
> > > > +
> > > > + spin_lock(>s_inode_list_lock);
> > > > + list_for_each_entry_safe(inode, next, >s_inodes, i_sb_list)
> > > > {
> > > > + spin_lock(>i_lock);
> > > > + if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE))
> > > > {
> > > > + spin_unlock(>i_lock);
> > > > + continue;
> > > > + }
> > > > +
> > > > + if (inode->i_wb && wb_dying(inode->i_wb)) {
> > > > + spin_unlock(>i_lock);
> > > > + inode_switch_wbs(inode,
> > > > root_mem_cgroup->css.id);
> > > > + continue;
> > > > + }
> > > > +
> > > > + spin_unlock(>i_lock);
> > > > + }
> > > > + spin_unlock(>s_inode_list_lock);
> > >
> > > No idea what the best solution is, but I think this is fundamentally
> > > unworkable. It's not uncommon to have a hundred million cached
> > > inodes these days, often on a single filesystem. Anything that
> > > requires a brute-force system wide inode scan, especially without
> > > conditional reschedule points, is largely a non-starter.
> > >
> > > Also, inode_switch_wbs() is not guaranteed to move the inode to the
> > > destination wb. There can only be WB_FRN_MAX_IN_FLIGHT (1024)
> > > switches in flight at once and switches are run via RCU callbacks,
> > > so I suspect that using inode_switch_wbs() for bulk re-assignment is
> > > going to be a lot more complex than just finding inodes to call
> > > inode_switch_wbs() on
> >
linux-next: Tree for Oct 9
Hi all, Changes since 20191008: The bpf-next tree gained a conflict against the bpf tree. The drm-misc tree gained conflicts against the drm tree and a semantic conflict against the amdgpu tree. The staging tree lost its build failure. Non-merge commits (relative to Linus' tree): 3142 3370 files changed, 105935 insertions(+), 55650 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 314 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 (d5001955c281 Merge tag 'gpio-v5.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio) Merging fixes/master (54ecb8f7028c Linux 5.4-rc1) Merging kbuild-current/fixes (b8d5e105ebbf scripts: setlocalversion: fix a bashism) 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 (60c1b3e25728 ARM: multi_v7_defconfig: Fix SPI_STM32_QSPI support) Merging arm64-fixes/for-next/fixes (3e7c93bd04ed arm64: armv8_deprecated: Checking return value for memory allocation) Merging m68k-current/for-linus (0f1979b402df m68k: Remove ioremap_fullcache()) Merging powerpc-fixes/fixes (3439595d5b85 selftests/powerpc: Fix compile error on tlbie_test due to newer gcc) Merging s390-fixes/fixes (da0c9ea146cb Linux 5.4-rc2) Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (503c9addef61 ptp: fix typo of "mechanism" in Kconfig help text) Merging bpf/master (98beb3edeb97 samples/bpf: Add a workaround for asm_inline) Merging ipsec/master (68ce6688a5ba net: sched: taprio: Fix potential integer overflow in taprio_set_picos_per_byte) Merging netfilter/master (503c9addef61 ptp: fix typo of "mechanism" in Kconfig help text) Merging ipvs/master (503c9addef61 ptp: fix typo of "mechanism" in Kconfig help text) Merging wireless-drivers/master (98d22b01f9f6 rt2x00: remove input-polldev.h header) Merging mac80211/master (dc0c18ed229c mac80211: fix scan when operating on DFS channels in ETSI domains) Merging rdma-fixes/for-rc (0417791536ae RDMA/mlx5: Add missing synchronize_srcu() for MW cases) Merging sound-current/for-linus (130bce3afbbb ALSA: hdac: clear link output stream mapping) Merging sound-asoc-fixes/for-linus (456e6594c461 Merge branch 'asoc-5.4' into asoc-linus) Merging regmap-fixes/for-linus (54ecb8f7028c Linux 5.4-rc1) Merging regulator-fixes/for-linus (4a3ab8e34117 Merge branch 'regulator-5.4' into regulator-linus) Merging spi-fixes/for-linus (fdce5b9c5b56 Merge branch 'spi-5.4' into spi-linus) Merging pci-current/for-linus (54ecb8f7028c Linux 5.4-rc1) Merging driver-core.current/driver-core-linus (82af5b660967 sysfs: Fixes __BIN_ATTR_WO() macro) Merging tty.current/tty-linus (fc64f7abbef2 serial: 8250_omap: Fix gpio check for auto RTS/CTS) Merging usb.current/usb-linus (623170ff5971 usb:cdns3: Fix for CV CH9 running with g_zero driver.) 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 (7d7e21faf
Re: [PATCH v7 10/21] RISC-V: KVM: Handle MMIO exits for VCPU
On Wed, Oct 9, 2019 at 4:14 AM Palmer Dabbelt wrote:
>
> On Mon, 23 Sep 2019 04:12:17 PDT (-0700), pbonz...@redhat.com wrote:
> > On 04/09/19 18:15, Anup Patel wrote:
> >> +unsigned long guest_sstatus =
> >> +vcpu->arch.guest_context.sstatus | SR_MXR;
> >> +unsigned long guest_hstatus =
> >> +vcpu->arch.guest_context.hstatus | HSTATUS_SPRV;
> >> +unsigned long guest_vsstatus, old_stvec, tmp;
> >> +
> >> +guest_sstatus = csr_swap(CSR_SSTATUS, guest_sstatus);
> >> +old_stvec = csr_swap(CSR_STVEC, (ulong)&__kvm_riscv_unpriv_trap);
> >> +
> >> +if (read_insn) {
> >> +guest_vsstatus = csr_read_set(CSR_VSSTATUS, SR_MXR);
> >
> > Is this needed? IIUC SSTATUS.MXR encompasses a wider set of permissions:
> >
> > The HS-level MXR bit makes any executable page readable. {\tt
> > vsstatus}.MXR makes readable those pages marked executable at the VS
> > translation level, but only if readable at the guest-physical
> > translation level.
> >
> > So it should be enough to set SSTATUS.MXR=1 I think. But you also
> > shouldn't set SSTATUS.MXR=1 in the !read_insn case.
> >
> > Also, you can drop the irq save/restore (which is already a save/restore
> > of SSTATUS) since you already write 0 to SSTATUS.SIE in your csr_swap.
> > Perhaps add a BUG_ON(guest_sstatus & SR_SIE) before the csr_swap?
> >
> >> +asm volatile ("\n"
> >> +"csrrw %[hstatus], " STR(CSR_HSTATUS) ", %[hstatus]\n"
> >> +"li %[tilen], 4\n"
> >> +"li %[tscause], 0\n"
> >> +"lhu %[val], (%[addr])\n"
> >> +"andi %[tmp], %[val], 3\n"
> >> +"addi %[tmp], %[tmp], -3\n"
> >> +"bne %[tmp], zero, 2f\n"
> >> +"lhu %[tmp], 2(%[addr])\n"
> >> +"sll %[tmp], %[tmp], 16\n"
> >> +"add %[val], %[val], %[tmp]\n"
> >> +"2: csrw " STR(CSR_HSTATUS) ", %[hstatus]"
> >> +: [hstatus] "+"(guest_hstatus), [val] "=" (val),
> >> + [tmp] "=" (tmp), [tilen] "+" (tilen),
> >> + [tscause] "+" (tscause)
> >> +: [addr] "r" (addr));
> >> +csr_write(CSR_VSSTATUS, guest_vsstatus);
> >
> >>
> >> +#ifndef CONFIG_RISCV_ISA_C
> >> +"li %[tilen], 4\n"
> >> +#else
> >> +"li %[tilen], 2\n"
> >> +#endif
> >
> > Can you use an assembler directive to force using a non-compressed
> > format for ld and lw? This would get rid of tilen, which is costing 6
> > bytes (if I did the RVC math right) in order to save two. :)
> >
> > Paolo
> >
> >> +"li %[tscause], 0\n"
> >> +#ifdef CONFIG_64BIT
> >> +"ld %[val], (%[addr])\n"
> >> +#else
> >> +"lw %[val], (%[addr])\n"
> >> +#endif
> To: a...@brainfault.org
> CC: pbonz...@redhat.com
> CC: Anup Patel
> CC: Paul Walmsley
> CC: rkrc...@redhat.com
> CC: daniel.lezc...@linaro.org
> CC: t...@linutronix.de
> CC: g...@amazon.com
> CC: Atish Patra
> CC: Alistair Francis
> CC: Damien Le Moal
> CC: Christoph Hellwig
> CC: k...@vger.kernel.org
> CC: linux-ri...@lists.infradead.org
> CC: linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v7 10/21] RISC-V: KVM: Handle MMIO exits for VCPU
> In-Reply-To:
>
>
> On Mon, 23 Sep 2019 06:09:43 PDT (-0700), a...@brainfault.org wrote:
> > On Mon, Sep 23, 2019 at 4:42 PM Paolo Bonzini wrote:
> >>
> >> On 04/09/19 18:15, Anup Patel wrote:
> >> > + unsigned long guest_sstatus =
> >> > + vcpu->arch.guest_context.sstatus | SR_MXR;
> >> > + unsigned long guest_hstatus =
> >> > + vcpu->arch.guest_context.hstatus | HSTATUS_SPRV;
> >> > + unsigned long guest_vsstatus, old_stvec, tmp;
> >> > +
> >> > + guest_sstatus = csr_swap(CSR_SSTATUS, guest_sstatus);
> >> > + old_stvec = csr_swap(CSR_STVEC, (ulong)&__kvm_riscv_unpriv_trap);
> >> > +
> >> > + if (read_insn) {
> >> > + guest_vsstatus = csr_read_set(CSR_VSSTATUS, SR_MXR);
> >>
> >> Is this needed? IIUC SSTATUS.MXR encompasses a wider set of permissions:
> >>
> >> The HS-level MXR bit makes any executable page readable. {\tt
> >> vsstatus}.MXR makes readable those pages marked executable at the VS
> >> translation level, but only if readable at the guest-physical
> >> translation level.
> >>
> >> So it should be enough to set SSTATUS.MXR=1 I think. But you also
> >> shouldn't set SSTATUS.MXR=1 in the !read_insn case.
> >
> > I was being overly cautious here. Initially, I thought SSTATUS.MXR
> > applies only to Stage2 and VSSTATUS.MXR applies only to Stage1.
> >
> > I agree with you. The HS-mode should only need to set SSTATUS.MXR.
> >
> >>
> >> Also, you can drop the irq save/restore (which is
Re: [PATCH 1/3] dt-bindings: net: ftgmac100: Document AST2600 compatible
On Wed, 9 Oct 2019, at 15:19, Andrew Jeffery wrote: > > > On Wed, 9 Oct 2019, at 15:08, Benjamin Herrenschmidt wrote: > > On Tue, 2019-10-08 at 22:21 +1030, Andrew Jeffery wrote: > > > The AST2600 contains an FTGMAC100-compatible MAC, although it no- > > > longer > > > contains an MDIO controller. > > > > How do you talk to the PHY then ? > > There are still MDIO controllers, they're just not in the MAC IP on the 2600. Sorry, on reflection that description is a little ambiguous in its use of 'it'. I'll fix that in v2 as well. Does this read better? "The AST2600 contains an FTGMAC100-compatible MAC, although the MAC no-longer contains an MDIO controller." Andrew
[PATCH] pinctrl: sprd: Add PIN_CONFIG_BIAS_DISABLE configuration support
Add PIN_CONFIG_BIAS_DISABLE configuration support for Spreadtrum pin
controller.
Signed-off-by: Baolin Wang
---
drivers/pinctrl/sprd/pinctrl-sprd.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/pinctrl/sprd/pinctrl-sprd.c
b/drivers/pinctrl/sprd/pinctrl-sprd.c
index 7b95bf5..8869843 100644
--- a/drivers/pinctrl/sprd/pinctrl-sprd.c
+++ b/drivers/pinctrl/sprd/pinctrl-sprd.c
@@ -484,6 +484,13 @@ static int sprd_pinconf_get(struct pinctrl_dev *pctldev,
unsigned int pin_id,
SLEEP_PULL_UP_MASK) << 16;
arg |= (reg >> PULL_UP_SHIFT) & PULL_UP_MASK;
break;
+ case PIN_CONFIG_BIAS_DISABLE:
+ if ((reg & (SLEEP_PULL_DOWN | SLEEP_PULL_UP)) ||
+ (reg & (PULL_DOWN | PULL_UP_4_7K | PULL_UP_20K)))
+ return -EINVAL;
+
+ arg = 1;
+ break;
case PIN_CONFIG_SLEEP_HARDWARE_STATE:
arg = 0;
break;
@@ -674,6 +681,16 @@ static int sprd_pinconf_set(struct pinctrl_dev *pctldev,
unsigned int pin_id,
shift = PULL_UP_SHIFT;
}
break;
+ case PIN_CONFIG_BIAS_DISABLE:
+ if (is_sleep_config == true) {
+ val = shift = 0;
+ mask = SLEEP_PULL_DOWN | SLEEP_PULL_UP;
+ } else {
+ val = shift = 0;
+ mask = PULL_DOWN | PULL_UP_20K |
+ PULL_UP_4_7K;
+ }
+ break;
case PIN_CONFIG_SLEEP_HARDWARE_STATE:
continue;
default:
--
1.7.9.5
Re: [PATCH 1/3] dt-bindings: net: ftgmac100: Document AST2600 compatible
On Wed, 9 Oct 2019, at 15:08, Benjamin Herrenschmidt wrote: > On Tue, 2019-10-08 at 22:21 +1030, Andrew Jeffery wrote: > > The AST2600 contains an FTGMAC100-compatible MAC, although it no- > > longer > > contains an MDIO controller. > > How do you talk to the PHY then ? There are still MDIO controllers, they're just not in the MAC IP on the 2600. Andrew
[PATCH V2] arm64: psci: Reduce waiting time of cpu_psci_cpu_kill()
If psci_ops.affinity_info() fails, it will sleep 10ms, which will not
take so long in the right case. Use usleep_range() instead of msleep(),
reduce the waiting time, and give a chance to busy wait before sleep.
Signed-off-by: Yunfeng Ye
---
V1->V2:
- use usleep_range() instead of udelay() after waiting for a while
arch/arm64/kernel/psci.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index c9f72b2..99b3122 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -82,6 +82,7 @@ static void cpu_psci_cpu_die(unsigned int cpu)
static int cpu_psci_cpu_kill(unsigned int cpu)
{
int err, i;
+ unsigned long timeout;
if (!psci_ops.affinity_info)
return 0;
@@ -91,16 +92,24 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
* while it is dying. So, try again a few times.
*/
- for (i = 0; i < 10; i++) {
+ i = 0;
+ timeout = jiffies + msecs_to_jiffies(100);
+ do {
err = psci_ops.affinity_info(cpu_logical_map(cpu), 0);
if (err == PSCI_0_2_AFFINITY_LEVEL_OFF) {
pr_info("CPU%d killed.\n", cpu);
return 0;
}
- msleep(10);
- pr_info("Retrying again to check for CPU kill\n");
- }
+ /* busy-wait max 1ms */
+ if (i++ < 100) {
+ cond_resched();
+ udelay(10);
+ continue;
+ }
+
+ usleep_range(100, 1000);
+ } while (time_before(jiffies, timeout));
pr_warn("CPU%d may not have shut down cleanly (AFFINITY_INFO reports
%d)\n",
cpu, err);
--
2.7.4.3
Re: [PATCH 1/3] dt-bindings: net: ftgmac100: Document AST2600 compatible
On Tue, 2019-10-08 at 22:21 +1030, Andrew Jeffery wrote: > The AST2600 contains an FTGMAC100-compatible MAC, although it no- > longer > contains an MDIO controller. How do you talk to the PHY then ? Cheers, Ben. > Signed-off-by: Andrew Jeffery > --- > Documentation/devicetree/bindings/net/ftgmac100.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/net/ftgmac100.txt > b/Documentation/devicetree/bindings/net/ftgmac100.txt > index 72e7aaf7242e..04cc0191b7dd 100644 > --- a/Documentation/devicetree/bindings/net/ftgmac100.txt > +++ b/Documentation/devicetree/bindings/net/ftgmac100.txt > @@ -9,6 +9,7 @@ Required properties: > > - "aspeed,ast2400-mac" > - "aspeed,ast2500-mac" > + - "aspeed,ast2600-mac" > > - reg: Address and length of the register set for the device > - interrupts: Should contain ethernet controller interrupt
Re: [PATCH] ftgmac100: Disable HW checksum generation on AST2500
On Wed, 2019-09-11 at 14:48 +, Joel Stanley wrote: > Hi Ben, > > On Tue, 10 Sep 2019 at 22:05, Florian Fainelli > wrote: > > > > On 9/10/19 2:37 PM, Vijay Khemka wrote: > > > HW checksum generation is not working for AST2500, specially with > > > IPV6 > > > over NCSI. All TCP packets with IPv6 get dropped. By disabling > > > this > > > it works perfectly fine with IPV6. > > > > > > Verified with IPV6 enabled and can do ssh. > > > > How about IPv4, do these packets have problem? If not, can you > > continue > > advertising NETIF_F_IP_CSUM but take out NETIF_F_IPV6_CSUM? > > > > > > > > Signed-off-by: Vijay Khemka > > > --- > > > drivers/net/ethernet/faraday/ftgmac100.c | 5 +++-- > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/net/ethernet/faraday/ftgmac100.c > > > b/drivers/net/ethernet/faraday/ftgmac100.c > > > index 030fed65393e..591c9725002b 100644 > > > --- a/drivers/net/ethernet/faraday/ftgmac100.c > > > +++ b/drivers/net/ethernet/faraday/ftgmac100.c > > > @@ -1839,8 +1839,9 @@ static int ftgmac100_probe(struct > > > platform_device *pdev) > > > if (priv->use_ncsi) > > > netdev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER; > > > > > > - /* AST2400 doesn't have working HW checksum generation */ > > > - if (np && (of_device_is_compatible(np, "aspeed,ast2400- > > > mac"))) > > > + /* AST2400 and AST2500 doesn't have working HW checksum > > > generation */ > > > + if (np && (of_device_is_compatible(np, "aspeed,ast2400- > > > mac") || > > > +of_device_is_compatible(np, "aspeed,ast2500- > > > mac"))) > > Do you recall under what circumstances we need to disable hardware > checksumming? Any news on this ? AST2400 has no HW checksum logic in HW, AST2500 should work for IPV4 fine, we should only selectively disable it for IPV6. Can you do an updated patch ? Cheers, Ben.
RE: [PATCH 05/10] dt-bindings: usb-xhci: Add r8a774b1 support
Hi Fabrizio-san, > From: Fabrizio Castro, Sent: Tuesday, October 8, 2019 7:39 PM > > Document RZ/G2N (R8A774B1) SoC bindings. > > Signed-off-by: Fabrizio Castro Thank you for the patch! Reviewed-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda
RE: [PATCH 06/10] dt-bindings: usb: renesas_usb3: Document r8a774b1 support
Hi Fabrizio-san, > From: Fabrizio Castro, Sent: Tuesday, October 8, 2019 7:39 PM > > Document RZ/G2N (R8A774B1) SoC bindings. > > Signed-off-by: Fabrizio Castro Thank you for the patch! Reviewed-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda
RE: [PATCH 04/10] dt-bindings: rcar-gen3-phy-usb3: Add r8a774b1 support
Hi Fabrizio-san, > From: Fabrizio Castro, Sent: Tuesday, October 8, 2019 7:39 PM > > Document RZ/G2N (R8A774B1) SoC bindings. > > Signed-off-by: Fabrizio Castro Thank you for the patch! Reviewed-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda
RE: [PATCH 03/10] dt-bindings: usb: renesas_usbhs: Add r8a774b1 support
Hi Fabrizio-san, > From: Fabrizio Castro, Sent: Tuesday, October 8, 2019 7:39 PM > > Document RZ/G2N (R8A774B1) SoC bindings. > > Signed-off-by: Fabrizio Castro Thank you for the patch! Reviewed-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda
RE: [PATCH 02/10] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774b1
Hi Fabrizio-san, > From: Fabrizio Castro, Sent: Tuesday, October 8, 2019 7:39 PM > > This patch adds the binding for r8a774b1 SoC (RZ/G2N). > > Signed-off-by: Fabrizio Castro Thank you for the patch! Reviewed-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda
RE: [PATCH 01/10] dt-bindings: rcar-gen3-phy-usb2: Add r8a774b1 support
Hi Fabrizio-san, > From: Fabrizio Castro, Sent: Tuesday, October 8, 2019 7:39 PM > Document RZ/G2N (R8A774B1) SoC bindings. > > Signed-off-by: Fabrizio Castro > --- Thank you for the patch! Reviewed-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda
RE: [PATCH 2/6] net: can: xilinx_can: Fix flags field initialization for axi can and canps
Hi,
> On 18.3.2019 13.32, Appana Durga Kedareswara rao wrote:
> > AXI CAN IP and CANPS IP supports tx fifo empty feature, this patch
> > updates the flags field for the same.
> >
> > Signed-off-by: Appana Durga Kedareswara rao
> >
> > ---
> > drivers/net/can/xilinx_can.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/net/can/xilinx_can.c
> > b/drivers/net/can/xilinx_can.c index 2de51ac..22569ef 100644
> > --- a/drivers/net/can/xilinx_can.c
> > +++ b/drivers/net/can/xilinx_can.c
> > @@ -1428,6 +1428,7 @@ static const struct dev_pm_ops xcan_dev_pm_ops
> =
> > { };
> >
> > static const struct xcan_devtype_data xcan_zynq_data = {
> > + .flags = XCAN_FLAG_TXFEMP,
> > .bittiming_const = _bittiming_const,
> > .btr_ts2_shift = XCAN_BTR_TS2_SHIFT,
> > .btr_sjw_shift = XCAN_BTR_SJW_SHIFT,
>
> Thanks for catching this, this line seemed to have been incorrectly removed by
> my 9e5f1b273e ("can: xilinx_can: add support for Xilinx CAN FD core").
>
> But:
>
> > @@ -1435,6 +1436,7 @@ static const struct xcan_devtype_data
> > xcan_zynq_data = { };
> >
> > static const struct xcan_devtype_data xcan_axi_data = {
> > + .flags = XCAN_FLAG_TXFEMP,
> > .bittiming_const = _bittiming_const,
> > .btr_ts2_shift = XCAN_BTR_TS2_SHIFT,
> > .btr_sjw_shift = XCAN_BTR_SJW_SHIFT,
>
>
> Are you sure this is right?
> In the documentation [1] there does not seem to be any TXFEMP interrupt, it
> would be interrupt bit 14 but AXI CAN 5.0 seems to only go up to 11.
>
> Or maybe it is undocumented or there is a newer version somewhere?
Sorry for the delay in the reply.
Agree TXFEMP interrupt feature is not supported by the Soft IP CAN.
Since this patch already got applied will send a separate patch to fix this.
Regards,
Kedar.
>
> [1]
> https://www.xilinx.com/support/documentation/ip_documentation/can/v5_0
> /pg096-can.pdf
>
> --
> Anssi Hannula / Bitwise Oy
> +358 503803997
Re: [PATCH 00/20] DPAA fixes
On Tue, 8 Oct 2019 15:10:21 +0300, Madalin Bucur wrote: > Here's a series of fixes and changes for the DPAA 1.x drivers. > Fixing some boot time dependency issues, removing some dead code, > changing the buffers used for reception, fixing the DMA devices, > some cleanups. Hi Madalin! The title of this series says "DPAA fixes", are these bug fixes? If so they should target the net tree ([PATCH net]) and contain appropriate Fixes tags. Cleanups should go into the net-next tree ([PATCH net-next]). Please try to not post more than 15 patches in one series, it clogs up the review flow. For some of those and other best practices please see: https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html https://www.kernel.org/doc/html/latest/process/submitting-patches.html :) IMHO there is also no need at all to CC linux-kernel on networking patches..
RE: [PATCH] usb:cdns3: Fix for CV CH9 running with g_zero driver.
Hi, > >Hi, > >Peter Chen writes: >> On 19-10-07 07:39:11, Pawel Laszczak wrote: >>> Patch fixes issue with Halt Endnpoint Test observed >> >> %s/Endnpoint/Endpoint >> >>> >>> during using g_zero >>> driver as DUT. Bug occurred only on some testing board. >> >> g_zero is legacy, please use configfs function source_sink or loopback >> instead. > >We still want fixes for those ;-) So, if my understanding is correct in new production systems using legacy gadget drivers is not recommended and we are not going to fix any more bugs there. The legacy gadget drivers remains in the kernel only to support the old products. So because we introduce new driver we should not worry about legacy gadget drivers. Is my understanding correct ? pawell > >>> Endpoint can defer transition to Halted state if endpoint has pending >>> requests. >> >> The implementation of halt handling is a little complicated, you may >> consider return -EAGAIN for functional stall through usb_ep_set_halt >> from function driver if the requests are pending, it doesn't need to >> defer such kinds of functional stall. > >-EAGAIN, IIRC is only supposed to be used for IN endpoint stalls. > >-- >balbi
Re: [PATCH] fs/userfaultfd.c: simplify the calculation of new_flags
On Fri, Oct 04, 2019 at 07:28:34PM -0400, Andrea Arcangeli wrote: > On Sat, Oct 05, 2019 at 06:46:40AM +0800, Wei Yang wrote: > > On Wed, Oct 02, 2019 at 08:45:05PM -0400, Andrea Arcangeli wrote: > > >Hello, > > > > > >On Tue, Aug 06, 2019 at 01:38:59PM +0800, Wei Yang wrote: > > >> Finally new_flags equals old vm_flags *OR* vm_flags. > > >> > > >> It is not necessary to mask them first. > > >> > > >> Signed-off-by: Wei Yang > > >> --- > > >> fs/userfaultfd.c | 2 +- > > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > >> > > >> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > > >> index ccbdbd62f0d8..653d8f7c453c 100644 > > >> --- a/fs/userfaultfd.c > > >> +++ b/fs/userfaultfd.c > > >> @@ -1457,7 +1457,7 @@ static int userfaultfd_register(struct > > >> userfaultfd_ctx *ctx, > > >> start = vma->vm_start; > > >> vma_end = min(end, vma->vm_end); > > >> > > >> -new_flags = (vma->vm_flags & ~vm_flags) | vm_flags; > > >> +new_flags = vma->vm_flags | vm_flags; > > >> prev = vma_merge(mm, prev, start, vma_end, new_flags, > > >> vma->anon_vma, vma->vm_file, > > >> vma->vm_pgoff, > > >> vma_policy(vma), > > > > > >And then how do you clear the flags after the above? > > > > > >It must be possible to clear the flags (from > > >UFFDIO_REGISTER_MODE_MISSING|UFFDIO_REGISTER_MODE_WP to only one set > > >or invert). > > > > > >We have no WP support upstream yet, so maybe that's why it looks > > >superfluous in practice, but in theory it isn't because it would then > > >need to be reversed by Peter's (CC'ed) -wp patchset. > > > > > >The register code has already the right placeholder to support -wp and > > >so it's better not to break them. > > > > > >I would recommend reviewing the uffd-wp support and working on testing > > >the uffd-wp code instead of changing the above. > > > > > > > Sorry, I don't get your point. This change is valid to me even from > > arithmetic > > point of view. > > > > vm_flags == VM_UFFD_MISSING | VM_UFFD_WP > > > > The effect of current code is clear these two bits then add them. This > > equals > > to just add these two bits. > > > > I am not sure which part I lost. > > The cleaned removed the "& ~" and that was enough to quickly tell the > cleaned up version was wrong. > > What I should have noticed right away as well is that the code was > already wrong, sorry. That code doesn't require a noop code cleanup, > it requires a fix and the "& ~" needs to stay. > > This isn't going to make any difference upstream until the uffd-wp > support is merged so it is enough to queue it in Peter's queue, or you > can merge it independently. IMHO it's good to have it as independent patch so at least it won't confuse another reader of the master branch. But just in case, I've also queued it in my local tree of uffd-wp. Thanks, -- Peter Xu
[PATCH] KPC2000: kpc2000_spi.c: Fix alignment and style problems.
Fixed alignment and style issues raised by checkpatch.pl
Signed-off-by: Chandra Annamaneni
---
drivers/staging/kpc2000/kpc2000_spi.c | 49 ---
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/kpc2000/kpc2000_spi.c
b/drivers/staging/kpc2000/kpc2000_spi.c
index 3be33c4..a20f2d7 100644
--- a/drivers/staging/kpc2000/kpc2000_spi.c
+++ b/drivers/staging/kpc2000/kpc2000_spi.c
@@ -30,19 +30,27 @@
#include "kpc.h"
static struct mtd_partition p2kr0_spi0_parts[] = {
- { .name = "SLOT_0", .size = 7798784,.offset = 0,
},
- { .name = "SLOT_1", .size = 7798784,.offset =
MTDPART_OFS_NXTBLK},
- { .name = "SLOT_2", .size = 7798784,.offset =
MTDPART_OFS_NXTBLK},
- { .name = "SLOT_3", .size = 7798784,.offset =
MTDPART_OFS_NXTBLK},
- { .name = "CS0_EXTRA", .size = MTDPART_SIZ_FULL, .offset =
MTDPART_OFS_NXTBLK},
+ { .name = "SLOT_0", .size = 7798784,.offset = 0,},
+ { .name = "SLOT_1", .size = 7798784,.offset =
+MTDPART_OFS_NXTBLK},
+ { .name = "SLOT_2", .size = 7798784,.offset =
+MTDPART_OFS_NXTBLK},
+ { .name = "SLOT_3", .size = 7798784,.offset =
+MTDPART_OFS_NXTBLK},
+ { .name = "CS0_EXTRA", .size = MTDPART_SIZ_FULL, .offset =
+MTDPART_OFS_NXTBLK},
};
static struct mtd_partition p2kr0_spi1_parts[] = {
- { .name = "SLOT_4", .size = 7798784,.offset = 0,
},
- { .name = "SLOT_5", .size = 7798784,.offset =
MTDPART_OFS_NXTBLK},
- { .name = "SLOT_6", .size = 7798784,.offset =
MTDPART_OFS_NXTBLK},
- { .name = "SLOT_7", .size = 7798784,.offset =
MTDPART_OFS_NXTBLK},
- { .name = "CS1_EXTRA", .size = MTDPART_SIZ_FULL, .offset =
MTDPART_OFS_NXTBLK},
+ { .name = "SLOT_4", .size = 7798784,.offset = 0,},
+ { .name = "SLOT_5", .size = 7798784,.offset =
+ MTDPART_OFS_NXTBLK},
+ { .name = "SLOT_6", .size = 7798784,.offset =
+ MTDPART_OFS_NXTBLK},
+ { .name = "SLOT_7", .size = 7798784,.offset =
+ MTDPART_OFS_NXTBLK},
+ { .name = "CS1_EXTRA", .size = MTDPART_SIZ_FULL, .offset =
+ MTDPART_OFS_NXTBLK},
};
static struct flash_platform_data p2kr0_spi0_pdata = {
@@ -50,6 +58,7 @@ static struct flash_platform_data p2kr0_spi0_pdata = {
.nr_parts = ARRAY_SIZE(p2kr0_spi0_parts),
.parts =p2kr0_spi0_parts,
};
+
static struct flash_platform_data p2kr0_spi1_pdata = {
.name = "SPI1",
.nr_parts = ARRAY_SIZE(p2kr0_spi1_parts),
@@ -165,7 +174,7 @@ kp_spi_read_reg(struct kp_spi_controller_state *cs, int idx)
u64 val;
addr += idx;
- if ((idx == KP_SPI_REG_CONFIG) && (cs->conf_cache >= 0))
+ if (idx == KP_SPI_REG_CONFIG && cs->conf_cache >= 0)
return cs->conf_cache;
val = readq(addr);
@@ -227,8 +236,7 @@ kp_spi_txrx_pio(struct spi_device *spidev, struct
spi_transfer *transfer)
kp_spi_write_reg(cs, KP_SPI_REG_TXDATA, val);
processed++;
}
- }
- else if (rx) {
+ } else if (rx) {
for (i = 0 ; i < c ; i++) {
char test = 0;
@@ -315,19 +323,18 @@ kp_spi_transfer_one_message(struct spi_master *master,
struct spi_message *m)
if (transfer->speed_hz > KP_SPI_CLK ||
(len && !(rx_buf || tx_buf))) {
dev_dbg(kpspi->dev, " transfer: %d Hz, %d %s%s, %d
bpw\n",
- transfer->speed_hz,
- len,
- tx_buf ? "tx" : "",
- rx_buf ? "rx" : "",
- transfer->bits_per_word);
+ transfer->speed_hz,
+ len,
+ tx_buf ? "tx" : "",
+ rx_buf ? "rx" : "",
+ transfer->bits_per_word);
dev_dbg(kpspi->dev, " transfer -EINVAL\n");
return -EINVAL;
}
if (transfer->speed_hz &&
transfer->speed_hz < (KP_SPI_CLK >> 15)) {
Re: [PATCH v8] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
On Wed, Oct 2, 2019 at 8:18 PM Chris Chiu wrote: > v7: >- Fix reported bug of watchdog stop >- refer to the RxPWDBAll in vendor driver for SNR calculation > v8: >- Add missing break in switch case > > + case WIRELESS_MODE_N_24G: > + case WIRELESS_MODE_N_5G: > + case (WIRELESS_MODE_G | WIRELESS_MODE_N_24G): > + case (WIRELESS_MODE_A | WIRELESS_MODE_N_5G): > + if (priv->tx_paths == 2 && priv->rx_paths == 2) > + ratr_idx = RATEID_IDX_GN_N2SS; > + else > + ratr_idx = RATEID_IDX_GN_N1SS; > + break; Hi, I have fixed the missing break problem in v7. Please let me know if there is any problem. Thanks. Chris
RE: [PATCH V2 1/2] usb: dwc3: Add node to update cache type setting
Hi Rob, Felipe, On Tuesday, September 24, 2019 00:38, Yang Li wrote: > > On Thu, Jul 25, 2019 at 4:56 PM Rob Herring wrote: > > > > On Wed, Jul 24, 2019 at 8:29 PM Ran Wang wrote: > > > > > > Hi Rob, > > > > > > On Thursday, July 25, 2019 04:42 Rob Herring wrote: > > > > > > > > On Fri, Jul 12, 2019 at 02:42:05PM +0800, Ran Wang wrote: > > > > > Some Layerscape paltforms (such as LS1088A, LS2088A, etc) > > > > > encounter USB detect failues when adding dma-coherent to DWC3 > > > > > node. This is because the HW default cache type configuration of > > > > > those SoC are not right, need to be updated in DTS. > > > > > > > > > > Signed-off-by: Ran Wang > > > > > --- > > > > > Change in v2: > > > > > - New file. > > > > > > > > > > Documentation/devicetree/bindings/usb/dwc3.txt | 43 > > > > > ++ > > > > > 1 file changed, 43 insertions(+) > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt > > > > > b/Documentation/devicetree/bindings/usb/dwc3.txt > > > > > index 8e5265e..7bc1cef 100644 > > > > > --- a/Documentation/devicetree/bindings/usb/dwc3.txt > > > > > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt > > > > > @@ -110,6 +110,43 @@ Optional properties: > > > > > - in addition all properties from usb-xhci.txt from the current > > > > > directory > are > > > > > supported as well > > > > > > > > > > +* Cache type nodes (optional) > > > > > + > > > > > +The Cache type node is used to tell how to configure cache type > > > > > +on 4 different transfer types: Data Read, Desc Read, Data Write > > > > > +and Desc write. For each treasfer type, controller has a 4-bit > > > > > +register field to enable different cache type. Quoted from DWC3 > > > > > +data book Table 6-5 > > > > Cache Type Bit Assignments: > > > > > + > > > > > +MBUS_TYPE| bit[3] |bit[2] |bit[1] |bit[0] > > > > > + > > > > > +AHB |Cacheable |Bufferable |Privilegge |Data > > > > > +AXI3 |Write Allocate|Read Allocate|Cacheable |Bufferable > > > > > +AXI4 |Allocate Other|Allocate |Modifiable |Bufferable > > > > > +AXI4 |Other Allocate|Allocate |Modifiable |Bufferable > > > > > +Native |Same as AXI |Same as AXI |Same as AXI|Same as AXI > > > > > +--- > > > > > +- > > > > > +Note: The AHB, AXI3, AXI4, and PCIe busses use different names > > > > > +for certain signals, which have the same meaning: > > > > > + Bufferable = Posted > > > > > + Cacheable = Modifiable = Snoop (negation of No Snoop) > > > > > > > > This should all be implied from the SoC specific compatible strings. > > > > > > Did you mean I could implement a soc driver which can be matched by > compatible of 'fsl,ls1088a-dwc3' which will pass known bus type to DWC3 > driver? > If yes, how to pass? > > > > Yes. The DT match table can have data associated with that compatible > > string. Beyond that, I'm not really familiar with the DWC3 driver. > > Hi Rob, > > It looks like that the current dwc3 binding perfers to define general quirks > in > device tree properties instead of trying to rely on the compatible string to > determine quirks. In this case, can we keep following the existing preference > instead of choosing the other way? Looks like you have different opinions on this solution, so I 'd like to have all opens get settled here to help me find a acceptable solution for both of you. Please let me explain more about this: 1. This feature (configure cache type) is natively from DWC3 IP (we can find it from data book), not a SoC specific feature (more details please see v1 discussion: https://lore.kernel.org/patchwork/patch/851306/) 2. However, in most SoC, the HW default setting looks fine (no need driver help), but some case (like Layerscape) might need driver to do some programming to fix USB no detect issue. That's why I implement this patch. 3. For now, Rob think this should be handled by SoC specific code rather than adding a property to control it (by DWC3 core driver). And Felipe prefer to avoid using glue diver. So I am not sure how to meet this requirements at the same time. Any further suggestion are really appreciated. Thank you. Regards, Ran
Re: [PATCH v2] rtc: Fix the AltCentury value on AMD/Hygon platform
On 2019/10/8 17:44, Alexandre Belloni wrote: > On 08/10/2019 17:37:12+0800, Jinke Fan wrote: >> When using following operations: >> save_control = CMOS_READ(RTC_CONTROL); >> -CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL); >> +CMOS_WRITE((save_control | RTC_SET), RTC_CONTROL); > > Unrelated change. OK, this line change will be cancelled in the patch v3. >> save_freq_select = CMOS_READ(RTC_FREQ_SELECT); >> -CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT); >> + >> +#if defined(CONFIG_CPU_SUP_AMD) || defined(CONFIG_CPU_SUP_HYGON) >> +CMOS_WRITE((save_freq_select & (~RTC_DV0)), RTC_FREQ_SELECT); > > That does break all the other x86 platforms. Yes, it's a mistake. In the patch v3, the modifications will be limited to AMD/Hygon vendor id. -- Best Regards, Jinke Fan
Re: [PATCH 3/3] KVM: x86/vPMU: Add lazy mechanism to release perf_event per vPMC
On 2019/10/8 20:11, Peter Zijlstra wrote:
On Tue, Oct 01, 2019 at 08:33:45PM +0800, Like Xu wrote:
Hi Peter,
On 2019/10/1 16:23, Peter Zijlstra wrote:
On Mon, Sep 30, 2019 at 03:22:57PM +0800, Like Xu wrote:
+ union {
+ u8 event_count :7; /* the total number of created perf_events */
+ bool enable_cleanup :1;
That's atrocious, don't ever create a bitfield with base _Bool.
I saw this kind of usages in the tree such as "struct
arm_smmu_master/tipc_mon_state/regmap_irq_chip".
Because other people do tasteless things doesn't make it right.
I'm not sure is this your personal preference or is there a technical
reason such as this usage is not incompatible with union syntax?
Apparently it 'works', so there is no hard technical reason, but
consider that _Bool is specified as an integer type large enough to
store the values 0 and 1, then consider it as a base type for a
bitfield. That's just disguisting.
It's reasonable. Thanks.
Now, I suppose it 'works', but there is no actual benefit over just
using a single bit of any other base type.
My design point is to save a little bit space without introducing
two variables such as "int event_count & bool enable_cleanup".
Your design is questionable, the structure is _huge_, and your union has
event_count:0 and enable_cleanup:0 as the same bit, which I don't think
was intentional.
Did you perhaps want to write:
struct {
u8 event_count : 7;
u8 event_cleanup : 1;
};
which has a total size of 1 byte and uses the low 7 bits as count and the
msb as cleanup.
Yes, my union here is wrong and let me fix it in the next version.
Also, the structure has plenty holes to stick proper variables in
without further growing it.
Yes, we could benefit from it.
By the way, is the lazy release mechanism looks reasonable to you?
I've no idea how it works.. I don't know much about virt.
[PATCH net-next] act_mirred: Fix mirred_init_module error handling
If tcf_register_action failed, mirred_device_notifier
should be unregistered.
Fixes: 3b87956ea645 ("net sched: fix race in mirred device removal")
Signed-off-by: YueHaibing
---
net/sched/act_mirred.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 9d1bf50..d0d397e 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -479,7 +479,11 @@ static int __init mirred_init_module(void)
return err;
pr_info("Mirror/redirect action on\n");
- return tcf_register_action(_mirred_ops, _net_ops);
+ err = tcf_register_action(_mirred_ops, _net_ops);
+ if (err)
+ unregister_netdevice_notifier(_device_notifier);
+
+ return err;
}
static void __exit mirred_cleanup_module(void)
--
2.7.4
Re: [RFC PATCH 2/3] perf tools: Add support for "report" for some spe events
On 2019/10/4 21:46, James Clark wrote: > Hi Xiaojun, > > I wanted to ask if you are still working on this? > > I've noticed that it doesn't apply cleanly to perf/core anymore and I was > working on re-basing it. > Would you be interested in me posting my progress? > > I was also interested in decoding the "data source" of events and displaying > that information. Does this > clash with any of your current work? > > > Thanks > James > (Sorry, you may have received a lot of this email because I am suddenly not on the mail-list, I need to confirm it.) Hi, James, Sorry, I did not respond in time because of the National Day holiday in China. I am still doing this, but I have been scheduled for other tasks some time ago, so that there is no obvious progress on spe. By the way, you mentioned before that you want the spe event to be in the form of "event:pp" like pebs. Is that the whole framework should be made similar to pebs? Or is it just a modification to the command format? For the former, this may be a bit difficult. For the latter, there is currently no modification to the record part, so "-c -F, etc." is only for instructions rather than events, so it may be misunderstood by users. So I haven't figured out how to do. What do you think of this? Thanks. Xiaojun. > On 09/08/2019 07:12, Tan Xiaojun wrote: >> On 2019/8/9 5:00, Jeremy Linton wrote: >>> Hi, >>> >>> First thanks for posting this! >>> >>> I ran this on our DAWN platform and it does what it says. Its a pretty >>> reasonable start, but I get -1's in the command row rather than "dd" (or >>> similar) and this also results in [unknown] for the shared object and most >>> userspace addresses. This is quite possibly something I'm not doing right, >>> but I didn't spend a lot of time testing/debugging it. >>> >>> I did a quick glance at the code to, and had a couple comments, although >>> I'm not a perf tool expert. >>> >> >> Hi, >> >> Thank you for your reply. >> >> I have only recently started working on this aspect of the perf tool, so >> your reply is very important to me. >> >> I need to be sorry, my example here is not complete, until you said that I >> found that I only posted a part of the example. The complete example is as >> follows: >> >> Example usage: >> >> # perf record -e arm_spe/ts_enable=1,pa_enable=1/ dd if=/dev/zero >> of=/dev/null count=1 >> # perf report >> >> >> ... >> # Samples: 37 of event 'llc-miss' >> # Event count (approx.): 37 >> # >> # Children Self Command Shared Object Symbol >> # ... . >> >> # >> 37.84%37.84% dd [kernel.kallsyms] [k] >> perf_iterate_ctx.constprop.64 >> 16.22%16.22% dd [kernel.kallsyms] [k] copy_page >> 5.41% 5.41% dd [kernel.kallsyms] [k] find_vma >> 5.41% 5.41% dd [kernel.kallsyms] [k] perf_event_mmap >> 5.41% 5.41% dd [kernel.kallsyms] [k] zap_pte_range >> 5.41% 5.41% dd ld-2.28.so [.] _dl_lookup_symbol_x >> 5.41% 5.41% dd libc-2.28.so [.] _nl_intern_locale_data >> 2.70% 2.70% dd [kernel.kallsyms] [k] >> __remove_shared_vm_struct.isra.1 >> 2.70% 2.70% dd [kernel.kallsyms] [k] kmem_cache_free >> 2.70% 2.70% dd [kernel.kallsyms] [k] ttwu_do_wakeup.isra.19 >> 2.70% 2.70% dd dd [.] 0xd9d8 >> 2.70% 2.70% dd ld-2.28.so [.] _dl_relocate_object >> 2.70% 2.70% dd libc-2.28.so [.] __unregister_atfork >> 2.70% 2.70% dd libc-2.28.so [.] _dl_addr >> >> >> # Samples: 8 of event 'tlb-miss' >> # Event count (approx.): 8 >> # >> # Children Self Command Shared Object Symbol >> # ... . >> . >> # >> 12.50%12.50% dd [kernel.kallsyms] [k] __audit_syscall_entry >> 12.50%12.50% dd [kernel.kallsyms] [k] kmem_cache_free >> 12.50%12.50% dd [kernel.kallsyms] [k] >> perf_iterate_ctx.constprop.64 >> 12.50%12.50% dd [kernel.kallsyms] [k] ttwu_do_wakeup.isra.19 >> 12.50%12.50% dd dd [.] 0xd9d8 >> 12.50%12.50% dd libc-2.28.so [.] __unregister_atfork >> 12.50%12.50% dd libc-2.28.so [.] _nl_intern_locale_data >> 12.50%12.50% dd libc-2.28.so [.] vfprintf >> >> >> # Samples: 12 of event 'branch-miss' >> # Event count (approx.): 12 >> # >> # Children Self Command Shared Object Symbol >> # ... . .. >> # >> 16.67%16.67% dd libc-2.28.so [.] read_alias_file >> 8.33% 8.33% dd [kernel.kallsyms]
Re: [PATCH] iwlwifi: fw: don't send GEO_TX_POWER_LIMIT command to FW version 29
Tested and commented on the issue page. Thank you for the correction.
--
Cheers,
You-Sheng Yang
On 2019-10-08 15:17, Luciano Coelho wrote:
> On Tue, 2019-10-08 at 14:05 +0800, You-Sheng Yang wrote:
>> Follow-up for commit fddbfeece9c7 ("iwlwifi: fw: don't send
>> GEO_TX_POWER_LIMIT command to FW version 36"). There is no
>> GEO_TX_POWER_LIMIT command support for all revisions of FW version
>> 29, either.
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204151
>> Signed-off-by: You-Sheng Yang
>> ---
>> drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
>> b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
>> index 32a5e4e5461f..dbba616c19de 100644
>> --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
>> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
>> @@ -889,14 +889,14 @@ static bool iwl_mvm_sar_geo_support(struct iwl_mvm
>> *mvm)
>> * firmware versions. Unfortunately, we don't have a TLV API
>> * flag to rely on, so rely on the major version which is in
>> * the first byte of ucode_ver. This was implemented
>> - * initially on version 38 and then backported to29 and 17.
>> + * initially on version 38 and then backported to 29 and 17.
>> * The intention was to have it in 36 as well, but not all
>> * 8000 family got this feature enabled. The 8000 family is
>> * the only one using version 36, so skip this version
>> - * entirely.
>> + * entirely. All revisions of -29 fw still don't have
>> + * GEO_TX_POWER_LIMIT supported yet.
>> */
>> return IWL_UCODE_SERIAL(mvm->fw->ucode_ver) >= 38 ||
>> - IWL_UCODE_SERIAL(mvm->fw->ucode_ver) == 29 ||
>> IWL_UCODE_SERIAL(mvm->fw->ucode_ver) == 17;
>> }
>
> Thanks for the patch!
>
> But I have investigated this (even) further and now I see that 3168
> doesn't have this command, but 7265D does. The latter also uses -29,
> so we can't blindly disable all -29 versions.
>
> Can you try this instead?
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> index 0d2229319261..38d89ee9bd28 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> @@ -906,8 +906,10 @@ static bool iwl_mvm_sar_geo_support(struct iwl_mvm
> *mvm)
> * entirely.
> */
> return IWL_UCODE_SERIAL(mvm->fw->ucode_ver) >= 38 ||
> - IWL_UCODE_SERIAL(mvm->fw->ucode_ver) == 29 ||
> - IWL_UCODE_SERIAL(mvm->fw->ucode_ver) == 17;
> + IWL_UCODE_SERIAL(mvm->fw->ucode_ver) == 17 ||
> + (IWL_UCODE_SERIAL(mvm->fw->ucode_ver) == 29 &&
> + (mvm->trans->hw_rev &
> +CSR_HW_REV_TYPE_MSK) == CSR_HW_REV_TYPE_7265D);
> }
>
> int iwl_mvm_get_sar_geo_profile(struct iwl_mvm *mvm)
>
>
> --
> Cheers,
> Luca.
>
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] ip6erspan: remove the incorrect mtu limit for ip6erspan
On Tue, 8 Oct 2019 17:56:03 +0800, Haishuang Yan wrote:
> ip6erspan driver calls ether_setup(), after commit 61e84623ace3
> ("net: centralize net_device min/max MTU checking"), the range
> of mtu is [min_mtu, max_mtu], which is [68, 1500] by default.
>
> It causes the dev mtu of the erspan device to not be greater
> than 1500, this limit value is not correct for ip6erspan tap
> device.
>
> Signed-off-by: Haishuang Yan
Applied, but next time please make sure you add a Fixes tag,
and put [PATCH net] in the subject for bug fixes. Thanks!
Re: [EXT] Re: [PATCH] PCI: Enhance the ACS quirk for Cavium devices
Hi Bjorn,
Sorry for the late reply I was off for couple of days.
On 10/8/19 2:32 PM, Bjorn Helgaas wrote:
> External Email
>
> --
> On Tue, Oct 08, 2019 at 08:25:23AM +, Robert Richter wrote:
>> On 04.10.19 14:48:13, Bjorn Helgaas wrote:
>>> commit 37b22fbfec2d
>>> Author: George Cherian
>>> Date: Thu Sep 19 02:43:34 2019 +
>>>
>>> PCI: Apply Cavium ACS quirk to CN99xx and CN11xxx Root Ports
>>>
>>> Add an array of Cavium Root Port device IDs and apply the quirk only
>>> to the
>>> listed devices.
>>>
>>> Instead of applying the quirk to all Root Ports where
>>> "(dev->device & 0xf800) == 0xa000", apply it only to CN88xx 0xa180 and
>>> 0xa170 Root Ports.
All the root ports of CN88xx series will have device id's 0xa180 and 0xa170.
This patch currently targets only CN88xx series and not all of the CN8xxx.
For eg:- 83xx devices don't wont the quirk to be applied as of today.
The quirk
needs to be applied only for TX1 series and not oncteon-tx1 series.
>> No, this can't be removed. It is a match all for all CN8xxx variants
>> (note the 3 'x', all TX1 cores). So all device ids from 0xa000 to
>> 0xa7FF are affected here and need the quirk.
> OK, I'll drop the patch and wait for a new one. Maybe what was needed
> was to keep the "(dev->device & 0xf800) == 0xa000" part and add the
> pci_quirk_cavium_acs_ids[] array in addition?
>
>>> Also apply the quirk to CN99xx (0xaf84) and CN11xxx (0xb884) Root
>>> Ports.
The device id's for all variants of CN99xx is 0xaf84 and CN11xxx will be
0xb884.
So this patch holds good for TX2 as well as TX3 series of processors.
>> I thought the quirk is CN8xxx specific, but I could be wrong here.
>>
>> -Robert
>>
>>>
>>> Link:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_r_20190919024319.GA8792-40dc5-2Deodlnx05.marvell.com=DwIBAg=nKjWec2b6R0mOyPaz7xtfQ=8vKOpC26NZGzQPAMiIlimxyEGCRSJiq-j8yyjPJ6VZ4=Vmml-rx3t63ZbbXZ0XaESAM9yAlexE29R-giTbcj4Qk=57jKIj8BAydbLpftLt5Ssva7vD6GuoCaIpjTi-sB5kU=
>>> Fixes: f2ddaf8dfd4a ("PCI: Apply Cavium ThunderX ACS quirk to more
>>> Root Ports")
>>> Fixes: b404bcfbf035 ("PCI: Add ACS quirk for all Cavium devices")
>>> Signed-off-by: George Cherian
>>> Signed-off-by: Bjorn Helgaas
>>> Cc: sta...@vger.kernel.org # v4.12+
>>>
>>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>>> index 320255e5e8f8..4e5048cb5ec6 100644
>>> --- a/drivers/pci/quirks.c
>>> +++ b/drivers/pci/quirks.c
>>> @@ -4311,17 +4311,24 @@ static int pci_quirk_amd_sb_acs(struct pci_dev
>>> *dev, u16 acs_flags)
>>> #endif
>>> }
>>>
>>> +static const u16 pci_quirk_cavium_acs_ids[] = {
>>> + 0xa180, 0xa170, /* CN88xx family of devices */
>>> + 0xaf84, /* CN99xx family of devices */
>>> + 0xb884, /* CN11xxx family of devices */
>>> +};
>>> +
>>> static bool pci_quirk_cavium_acs_match(struct pci_dev *dev)
>>> {
>>> - /*
>>> -* Effectively selects all downstream ports for whole ThunderX 1
>>> -* family by 0xf800 mask (which represents 8 SoCs), while the lower
>>> -* bits of device ID are used to indicate which subdevice is used
>>> -* within the SoC.
>>> -*/
>>> - return (pci_is_pcie(dev) &&
>>> - (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT) &&
>>> - ((dev->device & 0xf800) == 0xa000));
>>> + int i;
>>> +
>>> + if (!pci_is_pcie(dev) || pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT)
>>> + return false;
>>> +
>>> + for (i = 0; i < ARRAY_SIZE(pci_quirk_cavium_acs_ids); i++)
>>> + if (pci_quirk_cavium_acs_ids[i] == dev->device)
>>> + return true;
>>> +
>>> + return false;
>>> }
>>>
>>> static int pci_quirk_cavium_acs(struct pci_dev *dev, u16 acs_flags)
Re: [BUGFIX PATCH 1/5] selftests: proc: Make va_max 3GB on 32bit arch
On Tue, 8 Oct 2019 20:59:16 +0300
Alexey Dobriyan wrote:
> On Tue, Oct 08, 2019 at 12:10:26AM +0900, Masami Hiramatsu wrote:
> > Currently proc-self-map-files-002.c sets va_max (max test address
> > of user virtual address) to 4GB, but it is too big for 32bit
> > arch and 1UL << 32 is overflow on 32bit long.
> >
> > Make va_max 3GB on 32bit arch like i386 and arm.
>
> IIRC i386 had 1G/3G split, so 3GB would be too much still.
Hmm, would you know what is the best value for that?
i386 can also be configured 3G/1G, 2G/2G and 1G/3G, so it
depends on the build configuration. Would 1G is enough for test?
Thank you,
>
> > --- a/tools/testing/selftests/proc/proc-self-map-files-002.c
> > +++ b/tools/testing/selftests/proc/proc-self-map-files-002.c
>
> > +#if __BITS_PER_LONG == 32
> > +# define VA_MAX (3UL << 30)
> > +#elif __BITS_PER_LONG == 64
> > +# define VA_MAX (1UL << 32)
> > +#else
> > +# define VA_MAX 0
> > +#endif
> > +
> > int main(void)
> > {
> > const int PAGE_SIZE = sysconf(_SC_PAGESIZE);
> > - const unsigned long va_max = 1UL << 32;
> > + const unsigned long va_max = VA_MAX;
>
> This limit doesn't need to be precise, 1GB is "big enough".
--
Masami Hiramatsu
Re: [PATCH] iommu/vt-d: Return the correct dma mask when we are bypassing the IOMMU
Hi,
On 10/8/19 10:33 PM, Arvind Sankar wrote:
We must return a mask covering the full physical RAM when bypassing the
IOMMU mapping. Also, in iommu_need_mapping, we need to check using
dma_direct_get_required_mask to ensure that the device's dma_mask can
cover physical RAM before deciding to bypass IOMMU mapping.
Fixes: 249baa547901 ("dma-mapping: provide a better default
->get_required_mask")
Reported-by: Arvind Sankar
Tested-by: Arvind Sankar
Originally-by: Christoph Hellwig
Signed-off-by: Christoph Hellwig
Fixed-by: Arvind Sankar
Signed-off-by: Arvind Sankar
---
drivers/iommu/intel-iommu.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3f974919d3bd..79e35b3180ac 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3471,7 +3471,7 @@ static bool iommu_need_mapping(struct device *dev)
if (dev->coherent_dma_mask && dev->coherent_dma_mask < dma_mask)
dma_mask = dev->coherent_dma_mask;
- if (dma_mask >= dma_get_required_mask(dev))
+ if (dma_mask >= dma_direct_get_required_mask(dev))
return false;
/*
@@ -3775,6 +3775,13 @@ static int intel_map_sg(struct device *dev, struct
scatterlist *sglist, int nele
return nelems;
}
+static u64 intel_get_required_mask(struct device *dev)
+{
+ if (!iommu_need_mapping(dev))
+ return dma_direct_get_required_mask(dev);
+ return DMA_BIT_MASK(32);
Do you mind explaining why we always return 32 bit here?
Best regards,
Baolu
+}
+
static const struct dma_map_ops intel_dma_ops = {
.alloc = intel_alloc_coherent,
.free = intel_free_coherent,
@@ -3787,6 +3794,7 @@ static const struct dma_map_ops intel_dma_ops = {
.dma_supported = dma_direct_supported,
.mmap = dma_common_mmap,
.get_sgtable = dma_common_get_sgtable,
+ .get_required_mask = intel_get_required_mask,
};
static void
Re: [BUGFIX PATCH] selftests: Use real temporary working directory for archiving
On Tue, 8 Oct 2019 23:39:40 +
wrote:
>
>
> > -Original Message-
> > From: Masami Hiramatsu on Thursday, October 03, 2019 7:13 PM
> >
> > Use real temporary working directory for generating kselftest
> > archive.
> >
> > tools/testing/selftests/kselftest directory has been used for
> > the temporary working directory for making a tar archive from
> > gen_kselftest_tar.sh, and it removes the directory for cleanup.
> >
> > However, since the kselftest directory became a part of the
> > repository, it must not be used as a working dir.
>
> I'm not objecting to the test, but I would like to understand this
> point better. Under normal circumstances (i.e. when not using O= or
> KBUILD_OUTPUT)
> the rest of the kernel directory structure holds generated files.
> What is the issue with using kselftest to hold generated files?
OK, after running ./gen_kselftest_tar.sh in tools/testing/selftests,
I found there is no tools/testing/selftests/kselftest was there.
Actually, this was found when I searched "runner.sh" on the tree
after building kselftest.tar.gz. I couldn't find it and realized that
the gen_kselftest_tar.sh removed kselftest directory.
This is not happen if you run gen_kselftest_tar.sh.
Thank you,
> -- Tim
>
> >
> > Introduce mktemp to prepare a temporary working directory
> > for archiving kselftests.
> >
> > Signed-off-by: Masami Hiramatsu
> > ---
> > tools/testing/selftests/gen_kselftest_tar.sh |8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/testing/selftests/gen_kselftest_tar.sh
> > b/tools/testing/selftests/gen_kselftest_tar.sh
> > index a27e2eec3586..eba1e9987ffc 100755
> > --- a/tools/testing/selftests/gen_kselftest_tar.sh
> > +++ b/tools/testing/selftests/gen_kselftest_tar.sh
> > @@ -38,16 +38,16 @@ main()
> > esac
> > fi
> >
> > - install_dir=./kselftest
> > + tmpdir=`mktemp -d ./install-XX` || exit 1
> >
> > # Run install using INSTALL_KSFT_PATH override to generate install
> > # directory
> > -./kselftest_install.sh
> > -tar $copts kselftest${ext} $install_dir
> > +./kselftest_install.sh $tmpdir
> > +tar $copts kselftest${ext} -C $tmpdir kselftest
> > echo "Kselftest archive kselftest${ext} created!"
> >
> > # clean up install directory
> > -rm -rf kselftest
> > +rm -rf $tmpdir
> > }
> >
> > main "$@"
>
--
Masami Hiramatsu
[PATCH v4 4/5] arm64: tegra: Add XUSB and pad controller on Tegra194
Adds the XUSB pad and XUSB controllers on Tegra194.
Signed-off-by: JC Kuo
---
Changes in v4: none
Changes in v3: none
Changes in v2:
- renamed xhci@361 with usb@361
- moved padctl@352 and usb@361 inside /cbb
- cleaned up "clocks" property of usb@361 node
- added blanks lines to visually separate blocks
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 139 +++
1 file changed, 139 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 3c0cf54f0aab..3c7ea264bc1c 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -487,6 +487,145 @@
status = "disabled";
};
+ xusb_padctl: padctl@352 {
+ compatible = "nvidia,tegra194-xusb-padctl";
+ reg = <0x0352 0x1000>,
+ <0x0354 0x1000>;
+ reg-names = "padctl", "ao";
+
+ resets = < TEGRA194_RESET_XUSB_PADCTL>;
+ reset-names = "padctl";
+
+ status = "disabled";
+
+ pads {
+ usb2 {
+ clocks = < TEGRA194_CLK_USB2_TRK>;
+ clock-names = "trk";
+
+ lanes {
+ usb2-0 {
+ nvidia,function =
"xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function =
"xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function =
"xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-3 {
+ nvidia,function =
"xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ usb3 {
+ lanes {
+ usb3-0 {
+ nvidia,function =
"xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-1 {
+ nvidia,function =
"xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-2 {
+ nvidia,function =
"xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-3 {
+ nvidia,function =
"xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-0 {
+ status = "disabled";
+ };
+
+ usb2-1 {
+ status = "disabled";
+ };
+
+ usb2-2 {
+ status = "disabled";
+ };
+
+ usb2-3 {
+
[PATCH v4 5/5] arm64: tegra: Enable XUSB host in P2972-0000 board
This commit enables XUSB host and pad controller in Tegra194
P2972- board.
Signed-off-by: JC Kuo
---
Changes in v4: none
Changes in v3: none
Changes in v2:
- use capitalization of regulator names
- fix gpio property of VDD_5V_SATA regulator
.../arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 36 ++-
.../boot/dts/nvidia/tegra194-p2972-.dts | 62 +++
2 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
index 4c38426a6969..e7d5e8a30f93 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
@@ -66,6 +66,29 @@
vmmc-supply = <_emmc_3v3>;
};
+ padctl@352 {
+ avdd-usb-supply = <_usb_3v3>;
+ vclamp-usb-supply = <_1v8ao>;
+
+ ports {
+ usb2-1 {
+ vbus-supply = <_5v0_sys>;
+ };
+
+ usb2-3 {
+ vbus-supply = <_5v_sata>;
+ };
+
+ usb3-0 {
+ vbus-supply = <_5v0_sys>;
+ };
+
+ usb3-3 {
+ vbus-supply = <_5v0_sys>;
+ };
+ };
+ };
+
rtc@c2a {
status = "okay";
};
@@ -229,7 +252,7 @@
regulator-max-microvolt =
<330>;
};
- ldo5 {
+ vdd_usb_3v3: ldo5 {
regulator-name = "VDD_USB_3V3";
regulator-min-microvolt =
<330>;
regulator-max-microvolt =
<330>;
@@ -313,5 +336,16 @@
regulator-boot-on;
enable-active-low;
};
+
+ vdd_5v_sata: regulator@4 {
+ compatible = "regulator-fixed";
+ reg = <4>;
+
+ regulator-name = "VDD_5V_SATA";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < TEGRA194_MAIN_GPIO(Z, 1)
GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
};
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
b/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
index d47cd8c4dd24..b60eef64c487 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
@@ -62,6 +62,68 @@
GPIO_ACTIVE_LOW>;
};
};
+ padctl@352 {
+ status = "okay";
+
+ pads {
+ usb2 {
+ lanes {
+ usb2-1 {
+ status = "okay";
+ };
+
+ usb2-3 {
+ status = "okay";
+ };
+ };
+ };
+
+ usb3 {
+ lanes {
+ usb3-0 {
+ status = "okay";
+ };
+
+ usb3-3 {
+ status = "okay";
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-1 {
+ mode = "host";
+ status = "okay";
+ };
+
+ usb2-3 {
+ mode = "host";
+ status = "okay";
+ };
+
+ usb3-0 {
+ nvidia,usb2-companion = <1>;
+ status = "okay";
+ };
[PATCH v4 2/5] phy: tegra: xusb: Add Tegra194 support
Add support for the XUSB pad controller found on Tegra194 SoCs. It is
mostly similar to the same IP found on Tegra186, but the number of
pads exposed differs, as do the programming sequences. Because most of
the Tegra194 XUSB PADCTL registers definition and programming sequence
are the same as Tegra186, Tegra194 XUSB PADCTL can share the same
driver, xusb-tegra186.c, with Tegra186 XUSB PADCTL.
Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it
is possible for some platforms have long signal trace that could not
provide sufficient electrical environment for Gen 2 speed. This patch
introduce a new device node property "nvidia,disable-gen2" that can
be used to specifically disable Gen 2 speed for a particular USB 3.0
port so that the port can be limited to Gen 1 speed and avoid the
instability.
Signed-off-by: JC Kuo
---
Changes in v4: none
Changes in v3: none
Changes in v2:
- removed unnecessary #if/#endif pairs
- introduce new soc->supports_gen2 flag which indicate whether or not
a soc supports USB 3.1 Gen 2 speed
drivers/phy/tegra/Makefile| 1 +
drivers/phy/tegra/xusb-tegra186.c | 74 +++
drivers/phy/tegra/xusb.c | 7 +++
drivers/phy/tegra/xusb.h | 6 +++
4 files changed, 88 insertions(+)
diff --git a/drivers/phy/tegra/Makefile b/drivers/phy/tegra/Makefile
index 320dd389f34d..89b84067cb4c 100644
--- a/drivers/phy/tegra/Makefile
+++ b/drivers/phy/tegra/Makefile
@@ -6,4 +6,5 @@ phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_124_SOC) += xusb-tegra124.o
phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_132_SOC) += xusb-tegra124.o
phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_210_SOC) += xusb-tegra210.o
phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_186_SOC) += xusb-tegra186.o
+phy-tegra-xusb-$(CONFIG_ARCH_TEGRA_194_SOC) += xusb-tegra186.o
obj-$(CONFIG_PHY_TEGRA194_P2U) += phy-tegra194-p2u.o
diff --git a/drivers/phy/tegra/xusb-tegra186.c
b/drivers/phy/tegra/xusb-tegra186.c
index 3b60270f2009..74baa1dbca6c 100644
--- a/drivers/phy/tegra/xusb-tegra186.c
+++ b/drivers/phy/tegra/xusb-tegra186.c
@@ -64,6 +64,11 @@
#define SSPX_ELPG_CLAMP_EN_EARLY(x) BIT(1 + (x) * 3)
#define SSPX_ELPG_VCORE_DOWN(x) BIT(2 + (x) * 3)
+#define XUSB_PADCTL_SS_PORT_CFG0x2c
+#define PORTX_SPEED_SUPPORT_SHIFT(x) ((x) * 4)
+#define PORTX_SPEED_SUPPORT_MASK (0x3)
+#define PORT_SPEED_SUPPORT_GEN1(0x0)
+
#define XUSB_PADCTL_USB2_OTG_PADX_CTL0(x) (0x88 + (x) * 0x40)
#define HS_CURR_LEVEL(x) ((x) & 0x3f)
#define TERM_SEL BIT(25)
@@ -622,6 +627,15 @@ static int tegra186_usb3_phy_power_on(struct phy *phy)
padctl_writel(padctl, value, XUSB_PADCTL_SS_PORT_CAP);
+ if (padctl->soc->supports_gen2 && port->disable_gen2) {
+ value = padctl_readl(padctl, XUSB_PADCTL_SS_PORT_CFG);
+ value &= ~(PORTX_SPEED_SUPPORT_MASK <<
+ PORTX_SPEED_SUPPORT_SHIFT(index));
+ value |= (PORT_SPEED_SUPPORT_GEN1 <<
+ PORTX_SPEED_SUPPORT_SHIFT(index));
+ padctl_writel(padctl, value, XUSB_PADCTL_SS_PORT_CFG);
+ }
+
value = padctl_readl(padctl, XUSB_PADCTL_ELPG_PROGRAM_1);
value &= ~SSPX_ELPG_VCORE_DOWN(index);
padctl_writel(padctl, value, XUSB_PADCTL_ELPG_PROGRAM_1);
@@ -896,6 +910,66 @@ const struct tegra_xusb_padctl_soc
tegra186_xusb_padctl_soc = {
EXPORT_SYMBOL_GPL(tegra186_xusb_padctl_soc);
#endif
+#if IS_ENABLED(CONFIG_ARCH_TEGRA_194_SOC)
+static const char * const tegra194_xusb_padctl_supply_names[] = {
+ "avdd-usb",
+ "vclamp-usb",
+};
+
+static const struct tegra_xusb_lane_soc tegra194_usb2_lanes[] = {
+ TEGRA186_LANE("usb2-0", 0, 0, 0, usb2),
+ TEGRA186_LANE("usb2-1", 0, 0, 0, usb2),
+ TEGRA186_LANE("usb2-2", 0, 0, 0, usb2),
+ TEGRA186_LANE("usb2-3", 0, 0, 0, usb2),
+};
+
+static const struct tegra_xusb_pad_soc tegra194_usb2_pad = {
+ .name = "usb2",
+ .num_lanes = ARRAY_SIZE(tegra194_usb2_lanes),
+ .lanes = tegra194_usb2_lanes,
+ .ops = _usb2_pad_ops,
+};
+
+static const struct tegra_xusb_lane_soc tegra194_usb3_lanes[] = {
+ TEGRA186_LANE("usb3-0", 0, 0, 0, usb3),
+ TEGRA186_LANE("usb3-1", 0, 0, 0, usb3),
+ TEGRA186_LANE("usb3-2", 0, 0, 0, usb3),
+ TEGRA186_LANE("usb3-3", 0, 0, 0, usb3),
+};
+
+static const struct tegra_xusb_pad_soc tegra194_usb3_pad = {
+ .name = "usb3",
+ .num_lanes = ARRAY_SIZE(tegra194_usb3_lanes),
+ .lanes = tegra194_usb3_lanes,
+ .ops = _usb3_pad_ops,
+};
+
+static const struct tegra_xusb_pad_soc * const tegra194_pads[] = {
+ _usb2_pad,
+ _usb3_pad,
+};
+
+const struct tegra_xusb_padctl_soc tegra194_xusb_padctl_soc = {
+ .num_pads = ARRAY_SIZE(tegra194_pads),
+ .pads = tegra194_pads,
+ .ports = {
+ .usb2 = {
+ .ops =
[PATCH v4 3/5] dt-bindings: phy: tegra: Add Tegra194 support
Extend the bindings to cover the set of features found in Tegra194. Note that, technically, there are four more supplies connected to the XUSB pad controller (DVDD_PEX, DVDD_PEX_PLL, HVDD_PEX and HVDD_PEX_PLL) , but the power sequencing requirements of Tegra194 require these to be under the control of the PMIC. Tegra194 XUSB PADCTL supports up to USB 3.1 Gen 2 speed, however, it is possible for some platforms have long signal trace that could not provide sufficient electrical environment for Gen 2 speed. To deal with this, a new device node property "nvidia,disable-gen2" was added to Tegra194 that be used to specifically disable Gen 2 speed for a particular USB 3.0 port so that the port can be limited to Gen 1 speed and avoid the instability. Signed-off-by: JC Kuo --- Changes in v4: none Changes in v3: none Changes in v2: - fix a typo .../bindings/phy/nvidia,tegra124-xusb-padctl.txt | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt index 9fb682e47c29..59d870fa42e9 100644 --- a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt @@ -37,6 +37,7 @@ Required properties: - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl" - Tegra210: "nvidia,tegra210-xusb-padctl" - Tegra186: "nvidia,tegra186-xusb-padctl" + - Tegra194: "nvidia,tegra194-xusb-padctl" - reg: Physical base address and length of the controller's registers. - resets: Must contain an entry for each entry in reset-names. - reset-names: Must include the following entries: @@ -62,6 +63,10 @@ For Tegra186: - vclamp-usb-supply: Bias rail for USB pad. Must supply 1.8 V. - vddio-hsic-supply: HSIC PHY power supply. Must supply 1.2 V. +For Tegra194: +- avdd-usb-supply: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must supply + 3.3 V. +- vclamp-usb-supply: Bias rail for USB pad. Must supply 1.8 V. Pad nodes: == @@ -154,6 +159,11 @@ For Tegra210, the list of valid PHY nodes is given below: - sata: sata-0 - functions: "usb3-ss", "sata" +For Tegra194, the list of valid PHY nodes is given below: +- usb2: usb2-0, usb2-1, usb2-2, usb2-3 + - functions: "xusb" +- usb3: usb3-0, usb3-1, usb3-2, usb3-3 + - functions: "xusb" Port nodes: === @@ -221,6 +231,9 @@ Optional properties: is internal. In the absence of this property the port is considered to be external. +- nvidia,disable-gen2: A boolean property whose presence determines that a port + should be limited to USB 3.1 Gen 1. This property is only for Tegra194. + For Tegra124 and Tegra132, the XUSB pad controller exposes the following ports: - 3x USB2: usb2-0, usb2-1, usb2-2 @@ -233,6 +246,9 @@ For Tegra210, the XUSB pad controller exposes the following ports: - 2x HSIC: hsic-0, hsic-1 - 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3 +For Tegra194, the XUSB pad controller exposes the following ports: +- 4x USB2: usb2-0, usb2-1, usb2-2, usb2-3 +- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3 Examples: = -- 2.17.1
[PATCH v4 1/5] phy: tegra: xusb: Protect Tegra186 soc with config
As xusb-tegra186.c will be reused for Tegra194, it would be good to
protect Tegra186 soc data with CONFIG_ARCH_TEGRA_186_SOC. This commit
also reshuffles Tegra186 soc data single CONFIG_ARCH_TEGRA_186_SOC
will be sufficient.
Signed-off-by: JC Kuo
---
Changes in v4: none
Changes in v3: none
Changes in v2:
- new patch to protect Tegra186 soc data with config
drivers/phy/tegra/xusb-tegra186.c | 70 ---
1 file changed, 36 insertions(+), 34 deletions(-)
diff --git a/drivers/phy/tegra/xusb-tegra186.c
b/drivers/phy/tegra/xusb-tegra186.c
index 6f3afaf9398f..3b60270f2009 100644
--- a/drivers/phy/tegra/xusb-tegra186.c
+++ b/drivers/phy/tegra/xusb-tegra186.c
@@ -503,19 +503,6 @@ static const char * const tegra186_usb2_functions[] = {
"xusb",
};
-static const struct tegra_xusb_lane_soc tegra186_usb2_lanes[] = {
- TEGRA186_LANE("usb2-0", 0, 0, 0, usb2),
- TEGRA186_LANE("usb2-1", 0, 0, 0, usb2),
- TEGRA186_LANE("usb2-2", 0, 0, 0, usb2),
-};
-
-static const struct tegra_xusb_pad_soc tegra186_usb2_pad = {
- .name = "usb2",
- .num_lanes = ARRAY_SIZE(tegra186_usb2_lanes),
- .lanes = tegra186_usb2_lanes,
- .ops = _usb2_pad_ops,
-};
-
static int tegra186_usb2_port_enable(struct tegra_xusb_port *port)
{
return 0;
@@ -765,27 +752,6 @@ static const char * const tegra186_usb3_functions[] = {
"xusb",
};
-static const struct tegra_xusb_lane_soc tegra186_usb3_lanes[] = {
- TEGRA186_LANE("usb3-0", 0, 0, 0, usb3),
- TEGRA186_LANE("usb3-1", 0, 0, 0, usb3),
- TEGRA186_LANE("usb3-2", 0, 0, 0, usb3),
-};
-
-static const struct tegra_xusb_pad_soc tegra186_usb3_pad = {
- .name = "usb3",
- .num_lanes = ARRAY_SIZE(tegra186_usb3_lanes),
- .lanes = tegra186_usb3_lanes,
- .ops = _usb3_pad_ops,
-};
-
-static const struct tegra_xusb_pad_soc * const tegra186_pads[] = {
- _usb2_pad,
- _usb3_pad,
-#if 0 /* TODO implement */
- _hsic_pad,
-#endif
-};
-
static int
tegra186_xusb_read_fuse_calibration(struct tegra186_xusb_padctl *padctl)
{
@@ -862,6 +828,7 @@ static const struct tegra_xusb_padctl_ops
tegra186_xusb_padctl_ops = {
.remove = tegra186_xusb_padctl_remove,
};
+#if IS_ENABLED(CONFIG_ARCH_TEGRA_186_SOC)
static const char * const tegra186_xusb_padctl_supply_names[] = {
"avdd-pll-erefeut",
"avdd-usb",
@@ -869,6 +836,40 @@ static const char * const
tegra186_xusb_padctl_supply_names[] = {
"vddio-hsic",
};
+static const struct tegra_xusb_lane_soc tegra186_usb2_lanes[] = {
+ TEGRA186_LANE("usb2-0", 0, 0, 0, usb2),
+ TEGRA186_LANE("usb2-1", 0, 0, 0, usb2),
+ TEGRA186_LANE("usb2-2", 0, 0, 0, usb2),
+};
+
+static const struct tegra_xusb_pad_soc tegra186_usb2_pad = {
+ .name = "usb2",
+ .num_lanes = ARRAY_SIZE(tegra186_usb2_lanes),
+ .lanes = tegra186_usb2_lanes,
+ .ops = _usb2_pad_ops,
+};
+
+static const struct tegra_xusb_lane_soc tegra186_usb3_lanes[] = {
+ TEGRA186_LANE("usb3-0", 0, 0, 0, usb3),
+ TEGRA186_LANE("usb3-1", 0, 0, 0, usb3),
+ TEGRA186_LANE("usb3-2", 0, 0, 0, usb3),
+};
+
+static const struct tegra_xusb_pad_soc tegra186_usb3_pad = {
+ .name = "usb3",
+ .num_lanes = ARRAY_SIZE(tegra186_usb3_lanes),
+ .lanes = tegra186_usb3_lanes,
+ .ops = _usb3_pad_ops,
+};
+
+static const struct tegra_xusb_pad_soc * const tegra186_pads[] = {
+ _usb2_pad,
+ _usb3_pad,
+#if 0 /* TODO implement */
+ _hsic_pad,
+#endif
+};
+
const struct tegra_xusb_padctl_soc tegra186_xusb_padctl_soc = {
.num_pads = ARRAY_SIZE(tegra186_pads),
.pads = tegra186_pads,
@@ -893,6 +894,7 @@ const struct tegra_xusb_padctl_soc tegra186_xusb_padctl_soc
= {
.num_supplies = ARRAY_SIZE(tegra186_xusb_padctl_supply_names),
};
EXPORT_SYMBOL_GPL(tegra186_xusb_padctl_soc);
+#endif
MODULE_AUTHOR("JC Kuo ");
MODULE_DESCRIPTION("NVIDIA Tegra186 XUSB Pad Controller driver");
--
2.17.1
[PATCH v4 0/5] add Tegra194 XUSB host and pad controller support
This series introduces support for Tegra194 XUSB host and pad controller. Tegra194 XUSB host and pad controller are highly similar to the controllers found on Tegra186. Therefore, it's possible to resue xhci-tegra.c and xusb-tegra186.c for Tegra194. Changelog: v4: xhci: tegra: Parameterize mailbox register addresses - removed from v4 as it has been accepted in v3 usb: host: xhci-tegra: Add Tegra194 XHCI support - removed from v4 as it has been accepted in v3 phy: tegra: xusb: Add Tegra194 support - no change dt-bindings: phy: tegra: Add Tegra194 support - no change arm64: tegra: Add XUSB and pad controller on Tegra194 - no change arm64: tegra: Add XUSB and pad controller on Tegra194 - no change arm64: tegra: Enable XUSB host in P2972- board - no change v3: add change log to cover latter v2: xhci: tegra: Parameterize mailbox register addresses - no change usb: host: xhci-tegra: Add Tegra194 XHCI support - no change phy: tegra: xusb: Protect Tegra186 soc with config - new patch to protect Tegra186 soc data with config phy: tegra: xusb: Add Tegra194 support - removed unnecessary #if/#endif pairs - introduce new soc->supports_gen2 flag which indicate whether or not a soc supports USB 3.1 Gen 2 speed dt-bindings: phy: tegra: Add Tegra194 support - fix a typo arm64: tegra: Add XUSB and pad controller on Tegra194 - renamed xhci@361 with usb@361 - moved padctl@352 and usb@361 inside /cbb - cleaned up "clocks" property of usb@361 node - added blanks lines to visually separate blocks arm64: tegra: Enable XUSB host in P2972- board - use capitalization of regulator names - fix gpio property of VDD_5V_SATA regulator JC Kuo (5): phy: tegra: xusb: Protect Tegra186 soc with config phy: tegra: xusb: Add Tegra194 support dt-bindings: phy: tegra: Add Tegra194 support arm64: tegra: Add XUSB and pad controller on Tegra194 arm64: tegra: Enable XUSB host in P2972- board .../phy/nvidia,tegra124-xusb-padctl.txt | 16 ++ .../arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 36 - .../boot/dts/nvidia/tegra194-p2972-.dts | 62 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 139 + drivers/phy/tegra/Makefile| 1 + drivers/phy/tegra/xusb-tegra186.c | 144 +- drivers/phy/tegra/xusb.c | 7 + drivers/phy/tegra/xusb.h | 6 + 8 files changed, 376 insertions(+), 35 deletions(-) -- 2.17.1
Re: [RFC PATCH 2/3] perf tools: Add support for "report" for some spe events
On 2019/10/4 21:46, James Clark wrote: > Hi Xiaojun, > > I wanted to ask if you are still working on this? > > I've noticed that it doesn't apply cleanly to perf/core anymore and I was > working on re-basing it. > Would you be interested in me posting my progress? > > I was also interested in decoding the "data source" of events and displaying > that information. Does this > clash with any of your current work? > > > Thanks > James > Hi, James, Sorry, I did not respond in time because of the National Day holiday in China. I am still doing this, but I have been scheduled for other tasks some time ago, so that there is no obvious progress on spe. By the way, you mentioned before that you want the spe event to be in the form of "event:pp" like pebs. Is that the whole framework should be made similar to pebs? Or is it just a modification to the command format? For the former, this may be a bit difficult. For the latter, there is currently no modification to the record part, so "-c -F, etc." is only for instructions rather than events, so it may be misunderstood by users. So I haven't figured out how to do. What do you think of this? Thanks. Xiaojun. > On 09/08/2019 07:12, Tan Xiaojun wrote: >> On 2019/8/9 5:00, Jeremy Linton wrote: >>> Hi, >>> >>> First thanks for posting this! >>> >>> I ran this on our DAWN platform and it does what it says. Its a pretty >>> reasonable start, but I get -1's in the command row rather than "dd" (or >>> similar) and this also results in [unknown] for the shared object and most >>> userspace addresses. This is quite possibly something I'm not doing right, >>> but I didn't spend a lot of time testing/debugging it. >>> >>> I did a quick glance at the code to, and had a couple comments, although >>> I'm not a perf tool expert. >>> >> >> Hi, >> >> Thank you for your reply. >> >> I have only recently started working on this aspect of the perf tool, so >> your reply is very important to me. >> >> I need to be sorry, my example here is not complete, until you said that I >> found that I only posted a part of the example. The complete example is as >> follows: >> >> Example usage: >> >> # perf record -e arm_spe/ts_enable=1,pa_enable=1/ dd if=/dev/zero >> of=/dev/null count=1 >> # perf report >> >> >> ... >> # Samples: 37 of event 'llc-miss' >> # Event count (approx.): 37 >> # >> # Children Self Command Shared Object Symbol >> # ... . >> >> # >> 37.84%37.84% dd [kernel.kallsyms] [k] >> perf_iterate_ctx.constprop.64 >> 16.22%16.22% dd [kernel.kallsyms] [k] copy_page >> 5.41% 5.41% dd [kernel.kallsyms] [k] find_vma >> 5.41% 5.41% dd [kernel.kallsyms] [k] perf_event_mmap >> 5.41% 5.41% dd [kernel.kallsyms] [k] zap_pte_range >> 5.41% 5.41% dd ld-2.28.so [.] _dl_lookup_symbol_x >> 5.41% 5.41% dd libc-2.28.so [.] _nl_intern_locale_data >> 2.70% 2.70% dd [kernel.kallsyms] [k] >> __remove_shared_vm_struct.isra.1 >> 2.70% 2.70% dd [kernel.kallsyms] [k] kmem_cache_free >> 2.70% 2.70% dd [kernel.kallsyms] [k] ttwu_do_wakeup.isra.19 >> 2.70% 2.70% dd dd [.] 0xd9d8 >> 2.70% 2.70% dd ld-2.28.so [.] _dl_relocate_object >> 2.70% 2.70% dd libc-2.28.so [.] __unregister_atfork >> 2.70% 2.70% dd libc-2.28.so [.] _dl_addr >> >> >> # Samples: 8 of event 'tlb-miss' >> # Event count (approx.): 8 >> # >> # Children Self Command Shared Object Symbol >> # ... . >> . >> # >> 12.50%12.50% dd [kernel.kallsyms] [k] __audit_syscall_entry >> 12.50%12.50% dd [kernel.kallsyms] [k] kmem_cache_free >> 12.50%12.50% dd [kernel.kallsyms] [k] >> perf_iterate_ctx.constprop.64 >> 12.50%12.50% dd [kernel.kallsyms] [k] ttwu_do_wakeup.isra.19 >> 12.50%12.50% dd dd [.] 0xd9d8 >> 12.50%12.50% dd libc-2.28.so [.] __unregister_atfork >> 12.50%12.50% dd libc-2.28.so [.] _nl_intern_locale_data >> 12.50%12.50% dd libc-2.28.so [.] vfprintf >> >> >> # Samples: 12 of event 'branch-miss' >> # Event count (approx.): 12 >> # >> # Children Self Command Shared Object Symbol >> # ... . .. >> # >> 16.67%16.67% dd libc-2.28.so [.] read_alias_file >> 8.33% 8.33% dd [kernel.kallsyms] [k] __arch_copy_from_user >> 8.33% 8.33% dd [kernel.kallsyms] [k] __arch_copy_to_user >> 8.33%
[PATCH 1/2] arm64: dts: imx8mq-evk: Adjust nodes following alphabetical sort
Adjust some nodes to make them follow alphabetical sort except
iomuxc node which is put at the end of file because of its huge
pinctrl data.
Signed-off-by: Anson Huang
---
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 46 ++--
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index 0595812..6ede46f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -115,15 +115,6 @@
};
};
- {
- pinctrl-names = "default";
- pinctrl-0 = <_sai2>;
- assigned-clocks = < IMX8MQ_AUDIO_PLL1_BYPASS>, <
IMX8MQ_CLK_SAI2>;
- assigned-clock-parents = < IMX8MQ_AUDIO_PLL1>, <
IMX8MQ_AUDIO_PLL1_OUT>;
- assigned-clock-rates = <0>, <24576000>;
- status = "okay";
-};
-
{
pinctrl-names = "default";
pinctrl-0 = <_wifi_reset>;
@@ -242,6 +233,29 @@
power-supply = <_reg>;
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_qspi>;
+ status = "okay";
+
+ n25q256a: flash@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "micron,n25q256a", "jedec,spi-nor";
+ spi-max-frequency = <2900>;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_sai2>;
+ assigned-clocks = < IMX8MQ_AUDIO_PLL1_BYPASS>, <
IMX8MQ_CLK_SAI2>;
+ assigned-clock-parents = < IMX8MQ_AUDIO_PLL1>, <
IMX8MQ_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <0>, <24576000>;
+ status = "okay";
+};
+
_pwrkey {
status = "okay";
};
@@ -261,20 +275,6 @@
status = "okay";
};
- {
- pinctrl-names = "default";
- pinctrl-0 = <_qspi>;
- status = "okay";
-
- n25q256a: flash@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "micron,n25q256a", "jedec,spi-nor";
- spi-max-frequency = <2900>;
- };
-};
-
{
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <_usdhc1>;
--
2.7.4
[PATCH 2/2] arm64: dts: imx8mn-ddr4-evk: Move iomuxc node to end of file
All nodes are better to follow alphabetical sort except iomuxc
which has huge pinctrl data, better to put it at the end of
file.
Signed-off-by: Anson Huang
---
arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts | 304 +++---
1 file changed, 152 insertions(+), 152 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
index d78d657..1b90faac 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
@@ -43,158 +43,6 @@
cpu-supply = <_reg>;
};
- {
- pinctrl-names = "default";
-
- pinctrl_fec1: fec1grp {
- fsl,pins = <
- MX8MN_IOMUXC_ENET_MDC_ENET1_MDC 0x3
- MX8MN_IOMUXC_ENET_MDIO_ENET1_MDIO 0x3
- MX8MN_IOMUXC_ENET_TD3_ENET1_RGMII_TD3 0x1f
- MX8MN_IOMUXC_ENET_TD2_ENET1_RGMII_TD2 0x1f
- MX8MN_IOMUXC_ENET_TD1_ENET1_RGMII_TD1 0x1f
- MX8MN_IOMUXC_ENET_TD0_ENET1_RGMII_TD0 0x1f
- MX8MN_IOMUXC_ENET_RD3_ENET1_RGMII_RD3 0x91
- MX8MN_IOMUXC_ENET_RD2_ENET1_RGMII_RD2 0x91
- MX8MN_IOMUXC_ENET_RD1_ENET1_RGMII_RD1 0x91
- MX8MN_IOMUXC_ENET_RD0_ENET1_RGMII_RD0 0x91
- MX8MN_IOMUXC_ENET_TXC_ENET1_RGMII_TXC 0x1f
- MX8MN_IOMUXC_ENET_RXC_ENET1_RGMII_RXC 0x91
- MX8MN_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL 0x91
- MX8MN_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL 0x1f
- MX8MN_IOMUXC_SAI2_RXC_GPIO4_IO220x19
- >;
- };
-
- pinctrl_gpio_led: gpioledgrp {
- fsl,pins = <
- MX8MN_IOMUXC_NAND_READY_B_GPIO3_IO160x19
- >;
- };
-
- pinctrl_i2c1: i2c1grp {
- fsl,pins = <
- MX8MN_IOMUXC_I2C1_SCL_I2C1_SCL 0x41c3
- MX8MN_IOMUXC_I2C1_SDA_I2C1_SDA 0x41c3
- >;
- };
-
- pinctrl_pmic: pmicirq {
- fsl,pins = <
- MX8MN_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x41
- >;
- };
-
- pinctrl_reg_usdhc2_vmmc: regusdhc2vmmc {
- fsl,pins = <
- MX8MN_IOMUXC_SD2_RESET_B_GPIO2_IO19 0x41
- >;
- };
-
- pinctrl_uart2: uart2grp {
- fsl,pins = <
- MX8MN_IOMUXC_UART2_RXD_UART2_DCE_RX 0x140
- MX8MN_IOMUXC_UART2_TXD_UART2_DCE_TX 0x140
- >;
- };
-
- pinctrl_usdhc2_gpio: usdhc2grpgpio {
- fsl,pins = <
- MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x1c4
- >;
- };
-
- pinctrl_usdhc2: usdhc2grp {
- fsl,pins = <
- MX8MN_IOMUXC_SD2_CLK_USDHC2_CLK 0x190
- MX8MN_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d0
- MX8MN_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d0
- MX8MN_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0
- MX8MN_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0
- MX8MN_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0
- MX8MN_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0
- >;
- };
-
- pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
- fsl,pins = <
- MX8MN_IOMUXC_SD2_CLK_USDHC2_CLK 0x194
- MX8MN_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4
- MX8MN_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d4
- MX8MN_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4
- MX8MN_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4
- MX8MN_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4
- MX8MN_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0
- >;
- };
-
- pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
- fsl,pins = <
- MX8MN_IOMUXC_SD2_CLK_USDHC2_CLK 0x196
- MX8MN_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6
- MX8MN_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d6
- MX8MN_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6
- MX8MN_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6
- MX8MN_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6
- MX8MN_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0
- >;
- };
-
- pinctrl_usdhc3: usdhc3grp {
- fsl,pins = <
- MX8MN_IOMUXC_NAND_WE_B_USDHC3_CLK
0x4190
- MX8MN_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d0
-
Re: [PATCH] usb: cdns3: Fix dequeue implementation.
On 19-10-08 08:01:19, Pawel Laszczak wrote:
> >>
> >> diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
> >> index 2ca280f4c054..9050b380ab83 100644
> >> --- a/drivers/usb/cdns3/gadget.c
> >> +++ b/drivers/usb/cdns3/gadget.c
> >> @@ -1145,6 +1145,14 @@ static void cdns3_transfer_completed(struct
> >> cdns3_device *priv_dev,
> >>request = cdns3_next_request(_ep->pending_req_list);
> >>priv_req = to_cdns3_request(request);
> >>
> >> + trb = priv_ep->trb_pool + priv_ep->dequeue;
> >> +
> >> + /* Request was dequeued and TRB was changed to TRB_LINK. */
> >> + if (TRB_FIELD_TO_TYPE(trb->control) == TRB_LINK) {
> >> + trace_cdns3_complete_trb(priv_ep, trb);
> >> + cdns3_move_deq_to_next_trb(priv_req);
> >> + }
> >
> >If the request was dequeued, it should not be at request list, isn't it?
>
> Yes
> The dequeued request was removed from pending list but TRB associated with it
> was changed to Link TRB so it should be ignored in cdns3_transfer_completed
> function.
>
I see, you are right. Except for the typo, otherwise:
Reviewed-by: Peter Chen
Peter
> Pawel
>
> >
> >Peter
> >> +
> >>/* Re-select endpoint. It could be changed by other CPU during
> >> * handling usb_gadget_giveback_request.
> >> */
> >> @@ -2067,6 +2075,7 @@ int cdns3_gadget_ep_dequeue(struct usb_ep *ep,
> >>struct usb_request *req, *req_temp;
> >>struct cdns3_request *priv_req;
> >>struct cdns3_trb *link_trb;
> >> + u8 req_on_hw_ring = 0;
> >>unsigned long flags;
> >>int ret = 0;
> >>
> >> @@ -2083,8 +2092,10 @@ int cdns3_gadget_ep_dequeue(struct usb_ep *ep,
> >>
> >>list_for_each_entry_safe(req, req_temp, _ep->pending_req_list,
> >> list) {
> >> - if (request == req)
> >> + if (request == req) {
> >> + req_on_hw_ring = 1;
> >>goto found;
> >> + }
> >>}
> >>
> >>list_for_each_entry_safe(req, req_temp, _ep->deferred_req_list,
> >> @@ -2096,27 +2107,21 @@ int cdns3_gadget_ep_dequeue(struct usb_ep *ep,
> >>goto not_found;
> >>
> >> found:
> >> -
> >> - if (priv_ep->wa1_trb == priv_req->trb)
> >> - cdns3_wa1_restore_cycle_bit(priv_ep);
> >> -
> >>link_trb = priv_req->trb;
> >> - cdns3_move_deq_to_next_trb(priv_req);
> >> - cdns3_gadget_giveback(priv_ep, priv_req, -ECONNRESET);
> >> -
> >> - /* Update ring */
> >> - request = cdns3_next_request(_ep->deferred_req_list);
> >> - if (request) {
> >> - priv_req = to_cdns3_request(request);
> >>
> >> + /* Update ring only if removed request is on pending_req_list list */
> >> + if (req_on_hw_ring) {
> >>link_trb->buffer = TRB_BUFFER(priv_ep->trb_pool_dma +
> >> (priv_req->start_trb * TRB_SIZE));
> >>link_trb->control = (link_trb->control & TRB_CYCLE) |
> >> - TRB_TYPE(TRB_LINK) | TRB_CHAIN | TRB_TOGGLE;
> >> - } else {
> >> - priv_ep->flags |= EP_UPDATE_EP_TRBADDR;
> >> + TRB_TYPE(TRB_LINK) | TRB_CHAIN;
> >> +
> >> + if (priv_ep->wa1_trb == priv_req->trb)
> >> + cdns3_wa1_restore_cycle_bit(priv_ep);
> >>}
> >>
> >> + cdns3_gadget_giveback(priv_ep, priv_req, -ECONNRESET);
> >> +
> >> not_found:
> >>spin_unlock_irqrestore(_dev->lock, flags);
> >>return ret;
> >
> >--
> >
> >Thanks,
> >Peter Chen
--
Thanks,
Peter Chen
Re: [PATCH] usb:cdns3: Fix for CV CH9 running with g_zero driver.
On 19-10-08 15:58:57, Felipe Balbi wrote: > > Hi, > > Peter Chen writes: > > On 19-10-07 07:39:11, Pawel Laszczak wrote: > >> Patch fixes issue with Halt Endnpoint Test observed > > > > %s/Endnpoint/Endpoint > > > >> > >> during using g_zero > >> driver as DUT. Bug occurred only on some testing board. > > > > g_zero is legacy, please use configfs function source_sink or loopback > > instead. > > We still want fixes for those ;-) Yes, g_zero also uses source_sink and loopback, we just suggest the user configfs instead of legacy modules. > > >> Endpoint can defer transition to Halted state if endpoint has pending > >> requests. > > > > The implementation of halt handling is a little complicated, you may > > consider return -EAGAIN for functional stall through usb_ep_set_halt > > from function driver if the requests are pending, it doesn't need to > > defer such kinds of functional stall. > > -EAGAIN, IIRC is only supposed to be used for IN endpoint stalls. > Yes, you are right. -- Thanks, Peter Chen
Re: [PATCH v3 0/7] add Tegra194 XUSB host and pad controller support
On 10/8/19 7:29 PM, Thierry Reding wrote: > On Mon, Oct 07, 2019 at 01:03:11PM +0200, Greg KH wrote: >> On Sat, Oct 05, 2019 at 12:28:59AM +0800, JC Kuo wrote: >>> Hi, >>> >>> This series introduces support for Tegra194 XUSB host and pad >>> controller. Tegra194 XUSB host and pad controller are highly >>> similar to the controllers found on Tegra186. Therefore, it's >>> possible to resue xhci-tegra.c and xusb-tegra186.c for Tegra194. >> >> I've taken patches 1 and 2 through my USB tree. If you want/need me to >> take the others, please get acks from those maintainers on them so I can >> do so. > > I can pick up patches 6 and 7 into the Tegra tree. There are a few > patches in there already that conflict with the DT changes in this > series and those will be easier to resolve in the Tegra tree. > > JC, I noticed that you didn't Cc Kishon as the PHY subsystem maintainer. > Please resend the series with Kishon added in the To: line to make sure > he sees them and can apply or ack them. > > Given that Greg's already applied patches 1 and 2, maybe leave them out > of the series. Thanks Thierry. I will send v4 accordingly. > > Thierry >
Re: [PATCH] rcu: Avoid to modify mask_ofl_ipi in sync_rcu_exp_select_node_cpus()
On Tue, Oct 08, 2019 at 01:01:21PM -0400, Joel Fernandes wrote:
> On Tue, Oct 08, 2019 at 06:35:45PM +0200, Marco Elver wrote:
> > On Tue, 8 Oct 2019 at 18:30, Joel Fernandes wrote:
> > >
> > > On Tue, Oct 08, 2019 at 01:01:40PM +0800, Boqun Feng wrote:
> > > > "mask_ofl_ipi" is used for iterate CPUs which IPIs are needed to send
> > > > to, however in the IPI sending loop, "mask_ofl_ipi" along with another
> > > > variable "mask_ofl_test" might also get modified to record which CPU's
> > > > quiesent state can be reported by sync_rcu_exp_select_node_cpus(). Two
> > > > variables seems to be redundant for such a propose, so this patch clean
> > > > things a little by solely using "mask_ofl_test" for recording and
> > > > "mask_ofl_ipi" for iteration. This would improve the readibility of the
> > > > IPI sending loop in sync_rcu_exp_select_node_cpus().
> > > >
> > > > Signed-off-by: Boqun Feng
> > > > ---
> > >
> > > Reviewed-by: Joel Fernandes (Google)
> > >
> > > thanks,
> > >
> > > - Joel
> >
> > Acked-by: Marco Elver
> >
Thank you both!
> > If this is the official patch for the fix to the KCSAN reported
> > data-race, it'd be great to include the tag:
> > Reported-by: syzbot+134336b86f728d6e5...@syzkaller.appspotmail.com
> > so the bot knows this was fixed.
>
> It is just an optimization that got triggerred due to debugging of the
> reported issue but does (should) not fix the issue.
>
Right.
> Boqun, are you going to be posting another patch which just uses mask_ofl_ipi
> in the for_each(..) loop? (without using _snap) as Paul suggested?
>
IIUC, Paul already has this fix along with other ->expmask queued in his
dev branch:
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?h=dev=4e4fefe0630dcf7415d62e6d9171c8f209444376
, and with the proper "Reported-by" tag to give syzbot credit.
Regards,
Boqun
> Paul mentioned other places where rnp->expmask is locklessly accessed so I
> think that may be fixed separately (such as the stall-warning code). Paul,
> were you planning on fixing all such accesses together (other than this code)
> or should I look into it more? I guess for the stall case, KCSAN would have
> to trigger stalls to see those issues.
>
> thanks,
>
> - Joel
>
> >
> > Thanks!
> > -- Marco
> >
> > > > kernel/rcu/tree_exp.h | 13 ++---
> > > > 1 file changed, 6 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> > > > index 69c5aa64fcfd..212470018752 100644
> > > > --- a/kernel/rcu/tree_exp.h
> > > > +++ b/kernel/rcu/tree_exp.h
> > > > @@ -387,10 +387,10 @@ static void sync_rcu_exp_select_node_cpus(struct
> > > > work_struct *wp)
> > > > }
> > > > ret = smp_call_function_single(cpu, rcu_exp_handler,
> > > > NULL, 0);
> > > > put_cpu();
> > > > - if (!ret) {
> > > > - mask_ofl_ipi &= ~mask;
> > > > + /* The CPU responses the IPI, and will report QS itself */
> > > > + if (!ret)
> > > > continue;
> > > > - }
> > > > +
> > > > /* Failed, raced with CPU hotplug operation. */
> > > > raw_spin_lock_irqsave_rcu_node(rnp, flags);
> > > > if ((rnp->qsmaskinitnext & mask) &&
> > > > @@ -401,13 +401,12 @@ static void sync_rcu_exp_select_node_cpus(struct
> > > > work_struct *wp)
> > > > schedule_timeout_uninterruptible(1);
> > > > goto retry_ipi;
> > > > }
> > > > - /* CPU really is offline, so we can ignore it. */
> > > > - if (!(rnp->expmask & mask))
> > > > - mask_ofl_ipi &= ~mask;
> > > > + /* CPU really is offline, and we need its QS to pass GP.
> > > > */
> > > > + if (rnp->expmask & mask)
> > > > + mask_ofl_test |= mask;
> > > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> > > > }
> > > > /* Report quiescent states for those that went offline. */
> > > > - mask_ofl_test |= mask_ofl_ipi;
> > > > if (mask_ofl_test)
> > > > rcu_report_exp_cpu_mult(rnp, mask_ofl_test, false);
> > > > }
> > > > --
> > > > 2.23.0
> > > >
Re: [PATCH v5 0/9] Enable Sub-page Write Protection Support
On Tue, Sep 17, 2019 at 04:52:55PM +0800, Yang, Weijiang wrote:
Hi, Paolo,
Could you review this v5 patch at your convenience?
Thanks a lot!
> EPT-Based Sub-Page write Protection(SPP)is a HW capability which allows
> Virtual Machine Monitor(VMM) to specify write-permission for guest
> physical memory at a sub-page(128 byte) granularity. When this
> capability is enabled, the CPU enforces write-access check for sub-pages
> within a 4KB page.
>
> The feature is targeted to provide fine-grained memory protection for
> usages such as device virtualization, memory check-point and VM
> introspection etc.
>
> SPP is active when the "sub-page write protection" (bit 23) is 1 in
> Secondary VM-Execution Controls. The feature is backed with a Sub-Page
> Permission Table(SPPT), SPPT is referenced via a 64-bit control field
> called Sub-Page Permission Table Pointer (SPPTP) which contains a
> 4K-aligned physical address.
>
> To enable SPP for certain physical page, the gfn should be first mapped
> to a 4KB entry, then set bit 61 of the corresponding EPT leaf entry.
> While HW walks EPT, if bit 61 is set, it traverses SPPT with the guset
> physical address to find out the sub-page permissions at the leaf entry.
> If the corresponding bit is set, write to sub-page is permitted,
> otherwise, SPP induced EPT violation is generated.
>
> This patch serial passed SPP function test and selftest on Ice-Lake platform.
>
> Please refer to the SPP introduction document in this patch set and
> Intel SDM for details:
>
> Intel SDM:
> https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
>
> SPP selftest patch:
> https://lkml.org/lkml/2019/6/18/1197
>
> Previous patch:
> https://lkml.org/lkml/2019/8/14/97
>
> Patch 1: Introduction to SPP.
> Patch 2: Add SPP related flags and control bits.
> Patch 3: Functions for SPPT setup.
> Patch 4: Add SPP access bitmaps for memslots.
> Patch 5: Introduce SPP {init,set,get} functions
> Patch 6: Implement User space access IOCTLs.
> Patch 7: Set up SPP paging table at vm-entry/exit.
> Patch 8: Enable lazy mode SPPT setup.
> Patch 9: Handle SPP protected pages when VM memory changes
>
>
> Change logs:
>
> V5 -> V4:
> 1. Enable SPP support for Hugepage(1GB/2MB) to extend application.
> 2. Make SPP miss vm-exit handler as the unified place to set up SPPT.
> 3. If SPP protected pages are access-tracked or dirty-page-tracked,
> store SPP flag in reserved address bit, restore it in
> fast_page_fault() handler.
> 4. Move SPP specific functions to vmx/spp.c and vmx/spp.h
> 5. Rebased code to kernel v5.3
> 6. Other change suggested by KVM community.
>
> V3 -> V4:
> 1. Modified documentation to make it consistent with patches.
> 2. Allocated SPPT root page in init_spp() instead of vmx_set_cr3() to
> avoid SPPT miss error.
> 3. Added back co-developers and sign-offs.
>
> V2 -> V3:
> 1. Rebased patches to kernel 5.1 release
> 2. Deferred SPPT setup to EPT fault handler if the page is not
> available while set_subpage() is being called.
> 3. Added init IOCTL to reduce extra cost if SPP is not used.
> 4. Refactored patch structure, cleaned up cross referenced functions.
> 5. Added code to deal with memory swapping/migration/shrinker cases.
>
> V2 -> V1:
> 1. Rebased to 4.20-rc1
> 2. Move VMCS change to a separated patch.
> 3. Code refine and Bug fix
>
>
> Yang Weijiang (9):
> Documentation: Introduce EPT based Subpage Protection
> vmx: spp: Add control flags for Sub-Page Protection(SPP)
> mmu: spp: Add SPP Table setup functions
> mmu: spp: Add functions to create/destroy SPP bitmap block
> mmu: spp: Introduce SPP {init,set,get} functions
> x86: spp: Introduce user-space SPP IOCTLs
> vmx: spp: Set up SPP paging table at vm-entry/exit
> mmu: spp: Enable Lazy mode SPP protection
> mmu: spp: Handle SPP protected pages when VM memory changes
>
> Documentation/virtual/kvm/spp_kvm.txt | 178 +++
> arch/x86/include/asm/cpufeatures.h| 1 +
> arch/x86/include/asm/kvm_host.h | 10 +-
> arch/x86/include/asm/vmx.h| 10 +
> arch/x86/include/uapi/asm/vmx.h | 2 +
> arch/x86/kernel/cpu/intel.c | 4 +
> arch/x86/kvm/mmu.c| 78 ++-
> arch/x86/kvm/mmu.h| 2 +
> arch/x86/kvm/vmx/capabilities.h | 5 +
> arch/x86/kvm/vmx/spp.c| 651 ++
> arch/x86/kvm/vmx/spp.h| 27 ++
> arch/x86/kvm/vmx/vmx.c| 99
> arch/x86/kvm/x86.c| 51 ++
> include/uapi/linux/kvm.h | 17 +
> 14 files changed, 1133 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/virtual/kvm/spp_kvm.txt
> create mode 100644 arch/x86/kvm/vmx/spp.c
> create mode 100644 arch/x86/kvm/vmx/spp.h
>
> --
> 2.17.2
Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
On Tue, 2019-10-08 at 07:58 -0400, Alex Ghiti wrote: > On 10/7/19 8:46 PM, Atish Patra wrote: > > On Mon, 2019-10-07 at 05:11 -0400, Alex Ghiti wrote: > > > On 10/4/19 10:12 PM, Atish Patra wrote: > > > > On Thu, 2019-08-08 at 02:17 -0400, Alexandre Ghiti wrote: > > > > > In order to avoid wasting user address space by using bottom- > > > > > up > > > > > mmap > > > > > allocation scheme, prefer top-down scheme when possible. > > > > > > > > > > Before: > > > > > root@qemuriscv64:~# cat /proc/self/maps > > > > > 0001-00016000 r-xp fe:00 > > > > > 6389 /bin/cat.coreutils > > > > > 00016000-00017000 r--p 5000 fe:00 > > > > > 6389 /bin/cat.coreutils > > > > > 00017000-00018000 rw-p 6000 fe:00 > > > > > 6389 /bin/cat.coreutils > > > > > 00018000-00039000 rw-p 00:00 0 [heap] > > > > > 156000-16d000 r-xp fe:00 7193 /lib/ld- > > > > > 2.28.so > > > > > 16d000-16e000 r--p 00016000 fe:00 7193 /lib/ld- > > > > > 2.28.so > > > > > 16e000-16f000 rw-p 00017000 fe:00 7193 /lib/ld- > > > > > 2.28.so > > > > > 16f000-17 rw-p 00:00 0 > > > > > 17-172000 r-xp 00:00 0 [vdso] > > > > > 174000-176000 rw-p 00:00 0 > > > > > 176000-1555674000 r-xp fe:00 7187 /lib/libc- > > > > > 2.28.so > > > > > 1555674000-1555678000 r--p 000fd000 fe:00 7187 /lib/libc- > > > > > 2.28.so > > > > > 1555678000-155567a000 rw-p 00101000 fe:00 7187 /lib/libc- > > > > > 2.28.so > > > > > 155567a000-15556a rw-p 00:00 0 > > > > > 3fffb9-3fffbb1000 rw-p 00:00 0 [stack] > > > > > > > > > > After: > > > > > root@qemuriscv64:~# cat /proc/self/maps > > > > > 0001-00016000 r-xp fe:00 > > > > > 6389 /bin/cat.coreutils > > > > > 00016000-00017000 r--p 5000 fe:00 > > > > > 6389 /bin/cat.coreutils > > > > > 00017000-00018000 rw-p 6000 fe:00 > > > > > 6389 /bin/cat.coreutils > > > > > 2de81000-2dea2000 rw-p 00:00 0 [heap] > > > > > 3ff7eb6000-3ff7ed8000 rw-p 00:00 0 > > > > > 3ff7ed8000-3ff7fd6000 r-xp fe:00 7187 /lib/libc- > > > > > 2.28.so > > > > > 3ff7fd6000-3ff7fda000 r--p 000fd000 fe:00 7187 /lib/libc- > > > > > 2.28.so > > > > > 3ff7fda000-3ff7fdc000 rw-p 00101000 fe:00 7187 /lib/libc- > > > > > 2.28.so > > > > > 3ff7fdc000-3ff7fe2000 rw-p 00:00 0 > > > > > 3ff7fe4000-3ff7fe6000 r-xp 00:00 0 [vdso] > > > > > 3ff7fe6000-3ff7ffd000 r-xp fe:00 7193 /lib/ld- > > > > > 2.28.so > > > > > 3ff7ffd000-3ff7ffe000 r--p 00016000 fe:00 7193 /lib/ld- > > > > > 2.28.so > > > > > 3ff7ffe000-3ff7fff000 rw-p 00017000 fe:00 7193 /lib/ld- > > > > > 2.28.so > > > > > 3ff7fff000-3ff800 rw-p 00:00 0 > > > > > 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] > > > > > > > > > > Signed-off-by: Alexandre Ghiti > > > > > Acked-by: Paul Walmsley > > > > > Reviewed-by: Christoph Hellwig > > > > > Reviewed-by: Kees Cook > > > > > Reviewed-by: Luis Chamberlain > > > > > --- > > > > >arch/riscv/Kconfig | 12 > > > > >1 file changed, 12 insertions(+) > > > > > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > > > > index 59a4727ecd6c..87dc5370becb 100644 > > > > > --- a/arch/riscv/Kconfig > > > > > +++ b/arch/riscv/Kconfig > > > > > @@ -54,6 +54,18 @@ config RISCV > > > > > select EDAC_SUPPORT > > > > > select ARCH_HAS_GIGANTIC_PAGE > > > > > select ARCH_WANT_HUGE_PMD_SHARE if 64BIT > > > > > + select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU > > > > > + select HAVE_ARCH_MMAP_RND_BITS > > > > > + > > > > > +config ARCH_MMAP_RND_BITS_MIN > > > > > + default 18 if 6legacy_va_layout4BIT > > > > > + default 8 > > > > > + > > > > > +# max bits determined by the following formula: > > > > > +# VA_BITS - PAGE_SHIFT - 3 > > > > > +config ARCH_MMAP_RND_BITS_MAX > > > > > + default 24 if 64BIT # SV39 based > > > > > + default 17 > > > > > > > > > >config MMU > > > > > def_bool y > > > > With this patch, I am not able to boot a Fedora Linux(a Gnome > > > > desktop > > > > image) on RISC-V hardware (Unleashed + Microsemi Expansion > > > > board). > > > > The > > > > booting gets stuck right after systemd starts. > > > > > > > > https://paste.fedoraproject.org/paste/TOrUMqqKH-pGFX7CnfajDg > > > > > > > > Reverting just this patch allow to boot Fedora successfully on > > > > specific > > > > RISC-V hardware. I have not root caused the issue but it looks > > > > like > > > > it > > > > might have messed userpsace mapping. > > > It might have messed userspace mapping but not enough to make > > > userspace > > > completely broken > > > as systemd does some things. I would try to boot in legacy > > > layout: > > > if > > > you can try to set sysctl legacy_va_layout > > > at boottime, it will map userspace as it was before (bottom-up). > > > If > > > that >
[PATCH] seq_file: move seq_read() flushing into a function
Consolidate some duplicated bookkeeping from seq_read() into a
function.
Signed-off-by: Vito Caputo
---
fs/seq_file.c | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 1600034a929b..e5d2bccf5ac4 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -141,6 +141,25 @@ static int traverse(struct seq_file *m, loff_t offset)
return !m->buf ? -ENOMEM : -EAGAIN;
}
+static int flush(struct seq_file *m, char __user **buf, size_t *size, size_t
*copied)
+{
+ int err = 0;
+ size_t n;
+
+ if (!m->count)
+ return err;
+ n = min(m->count, *size);
+ err = copy_to_user(*buf, m->buf + m->from, n);
+ if (err)
+ return err;
+ m->count -= n;
+ m->from += n;
+ *size -= n;
+ *buf += n;
+ *copied += n;
+ return err;
+}
+
/**
* seq_read - ->read() method for sequential files.
* @file: the file to read from
@@ -154,7 +173,6 @@ ssize_t seq_read(struct file *file, char __user *buf,
size_t size, loff_t *ppos)
{
struct seq_file *m = file->private_data;
size_t copied = 0;
- size_t n;
void *p;
int err = 0;
@@ -207,15 +225,9 @@ ssize_t seq_read(struct file *file, char __user *buf,
size_t size, loff_t *ppos)
}
/* if not empty - flush it first */
if (m->count) {
- n = min(m->count, size);
- err = copy_to_user(buf, m->buf + m->from, n);
+ err = flush(m, , , );
if (err)
goto Efault;
- m->count -= n;
- m->from += n;
- size -= n;
- buf += n;
- copied += n;
if (!size)
goto Done;
}
@@ -273,13 +285,9 @@ ssize_t seq_read(struct file *file, char __user *buf,
size_t size, loff_t *ppos)
}
}
m->op->stop(m, p);
- n = min(m->count, size);
- err = copy_to_user(buf, m->buf, n);
+ err = flush(m, , , );
if (err)
goto Efault;
- copied += n;
- m->count -= n;
- m->from = n;
Done:
if (!copied)
copied = err;
--
2.11.0
Re: [PATCH v2 0/2] Avoid regmap debugfs collisions in qcom llcc driver
Quoting Bjorn Andersson (2019-10-08 16:55:04)
> On Tue 08 Oct 16:45 PDT 2019, Stephen Boyd wrote:
> > @@ drivers/soc/qcom/llcc-slice.c
> >
> > static struct llcc_drv_data *drv_data = (void *) -EPROBE_DEFER;
> >
> > --static const struct regmap_config llcc_regmap_config = {
> > +-static struct regmap_config llcc_regmap_config = {
> > -.reg_bits = 32,
> > -.reg_stride = 4,
> > -.val_bits = 32,
> > @@ drivers/soc/qcom/llcc-slice.c: static struct regmap
> > *qcom_llcc_init_mmio(struct
> > {
> > struct resource *res;
> > void __iomem *base;
> > -+static struct regmap_config llcc_regmap_config = {
> > ++struct regmap_config llcc_regmap_config = {
>
> Now that this isn't static I like the end result better. Not sure about
> the need for splitting it in two patches, but if Evan is happy I'll take
> it.
>
Well I split it into bug fix and micro-optimization so backport choices
can be made. But yeah, I hope Evan is happy enough to provide a
reviewed-by tag!
RE: [EXT] Re: [RESEND PATCH v5 4/4] mailbox: imx: add support for imx v1 mu
Hi Daniel:
> -Original Message-
> From: Daniel Baluta
> Sent: 2019年10月8日 15:26
> To: Richard Zhu
> Cc: jassisinghb...@gmail.com; Oleksij Rempel ;
> Daniel Baluta ; Aisheng Dong
> ; dl-linux-imx ; Linux Kernel
> Mailing List ; linux-arm-kernel
>
> Subject: [EXT] Re: [RESEND PATCH v5 4/4] mailbox: imx: add support for imx v1
> mu
>
>
> Hi Richard,
>
> Can you please rebase and resend this patch series?
>
[Richard Zhu] No problem, I would resend this patch-set later.
Best Regards
Richard Zhu
> On Mon, Aug 5, 2019 at 10:21 PM Daniel Baluta
> wrote:
> >
> > On Mon, Aug 5, 2019 at 8:16 AM Richard Zhu
> wrote:
> > >
> > > There is a version 1.0 MU on i.MX7ULP platform.
> > > One new version ID register is added, and it's offset is 0.
> > > TRn registers are defined at the offset 0x20 ~ 0x2C.
> > > RRn registers are defined at the offset 0x40 ~ 0x4C.
> > > SR/CR registers are defined at 0x60/0x64.
> > > Extend this driver to support it.
> > >
> > > Signed-off-by: Richard Zhu
> > > Suggested-by: Oleksij Rempel
> > > Reviewed-by: Dong Aisheng
> > > Reviewed-by: Oleksij Rempel
> >
> > Very clean solution. Thanks Richard!
> >
> > Reviewed-by: Daniel Baluta
> >
> > > ---
> > > drivers/mailbox/imx-mailbox.c | 55
> > > ++-
> > > 1 file changed, 38 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/mailbox/imx-mailbox.c
> > > b/drivers/mailbox/imx-mailbox.c index afe625e..2cdcdc5 100644
> > > --- a/drivers/mailbox/imx-mailbox.c
> > > +++ b/drivers/mailbox/imx-mailbox.c
> > > @@ -12,19 +12,11 @@
> > > #include
> > > #include
> > >
> > > -/* Transmit Register */
> > > -#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
> > > -/* Receive Register */
> > > -#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
> > > -/* Status Register */
> > > -#define IMX_MU_xSR 0x20
> > > #define IMX_MU_xSR_GIPn(x) BIT(28 + (3 - (x)))
> > > #define IMX_MU_xSR_RFn(x) BIT(24 + (3 - (x)))
> > > #define IMX_MU_xSR_TEn(x) BIT(20 + (3 - (x)))
> > > #define IMX_MU_xSR_BRDIP BIT(9)
> > >
> > > -/* Control Register */
> > > -#define IMX_MU_xCR 0x24
> > > /* General Purpose Interrupt Enable */
> > > #define IMX_MU_xCR_GIEn(x) BIT(28 + (3 - (x)))
> > > /* Receive Interrupt Enable */
> > > @@ -44,6 +36,13 @@ enum imx_mu_chan_type {
> > > IMX_MU_TYPE_RXDB, /* Rx doorbell */
> > > };
> > >
> > > +struct imx_mu_dcfg {
> > > + u32 xTR[4]; /* Transmit Registers */
> > > + u32 xRR[4]; /* Receive Registers */
> > > + u32 xSR;/* Status Register */
> > > + u32 xCR;/* Control Register */
> > > +};
> > > +
> > > struct imx_mu_con_priv {
> > > unsigned intidx;
> > > char
> irq_desc[IMX_MU_CHAN_NAME_SIZE];
> > > @@ -61,12 +60,27 @@ struct imx_mu_priv {
> > > struct mbox_chanmbox_chans[IMX_MU_CHANS];
> > >
> > > struct imx_mu_con_priv con_priv[IMX_MU_CHANS];
> > > + const struct imx_mu_dcfg*dcfg;
> > > struct clk *clk;
> > > int irq;
> > >
> > > boolside_b;
> > > };
> > >
> > > +static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = {
> > > + .xTR= {0x0, 0x4, 0x8, 0xc},
> > > + .xRR= {0x10, 0x14, 0x18, 0x1c},
> > > + .xSR= 0x20,
> > > + .xCR= 0x24,
> > > +};
> > > +
> > > +static const struct imx_mu_dcfg imx_mu_cfg_imx7ulp = {
> > > + .xTR= {0x20, 0x24, 0x28, 0x2c},
> > > + .xRR= {0x40, 0x44, 0x48, 0x4c},
> > > + .xSR= 0x60,
> > > + .xCR= 0x64,
> > > +};
> > > +
> > > static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller
> > > *mbox) {
> > > return container_of(mbox, struct imx_mu_priv, mbox); @@
> > > -88,10 +102,10 @@ static u32 imx_mu_xcr_rmw(struct imx_mu_priv *priv,
> u32 set, u32 clr)
> > > u32 val;
> > >
> > > spin_lock_irqsave(>xcr_lock, flags);
> > > - val = imx_mu_read(priv, IMX_MU_xCR);
> > > + val = imx_mu_read(priv, priv->dcfg->xCR);
> > > val &= ~clr;
> > > val |= set;
> > > - imx_mu_write(priv, val, IMX_MU_xCR);
> > > + imx_mu_write(priv, val, priv->dcfg->xCR);
> > > spin_unlock_irqrestore(>xcr_lock, flags);
> > >
> > > return val;
> > > @@ -111,8 +125,8 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
> > > struct imx_mu_con_priv *cp = chan->con_priv;
> > > u32 val, ctrl, dat;
> > >
> > > - ctrl = imx_mu_read(priv, IMX_MU_xCR);
> > > - val = imx_mu_read(priv, IMX_MU_xSR);
> > > + ctrl = imx_mu_read(priv, priv->dcfg->xCR);
> > > + val = imx_mu_read(priv, priv->dcfg->xSR);
> > >
> > > switch (cp->type) {
> > > case IMX_MU_TYPE_TX:
> > > @@ -138,10 +152,10 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
> > > imx_mu_xcr_rmw(priv, 0,
[PATCH -next] usb: typec: add dependency for TYPEC_HD3SS3220
If CONFIG_TYPEC_HD3SS3220=y, CONFIG_USB_ROLE_SWITCH=m, below errors
can be found:
drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_remove':
hd3ss3220.c:(.text+0x64): undefined reference to `usb_role_switch_put'
drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_dr_set':
hd3ss3220.c:(.text+0x154): undefined reference to `usb_role_switch_set_role'
drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_set_role':
hd3ss3220.c:(.text+0x294): undefined reference to `usb_role_switch_set_role'
hd3ss3220.c:(.text+0x2f4): undefined reference to `usb_role_switch_set_role'
hd3ss3220.c:(.text+0x348): undefined reference to `usb_role_switch_set_role'
hd3ss3220.c:(.text+0x390): undefined reference to `usb_role_switch_set_role'
drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_probe':
hd3ss3220.c:(.text+0x5e8): undefined reference to `fwnode_usb_role_switch_get'
hd3ss3220.c:(.text+0x8a4): undefined reference to `usb_role_switch_put'
make: *** [vmlinux] Error 1
This patch add dependency USB_ROLE_SWITCH for TYPEC_HD3SS3220.
Fixes: 1c48c759ef4b ("usb: typec: driver for TI HD3SS3220 USB Type-C DRP port
controller")
Reported-by: Hulk Robot
Signed-off-by: Mao Wenan
---
drivers/usb/typec/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index aceb2af..b4f2aac 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -53,6 +53,7 @@ source "drivers/usb/typec/ucsi/Kconfig"
config TYPEC_HD3SS3220
tristate "TI HD3SS3220 Type-C DRP Port controller driver"
depends on I2C
+ depends on USB_ROLE_SWITCH
help
Say Y or M here if your system has TI HD3SS3220 Type-C DRP Port
controller driver.
--
2.7.4
[PATCH] rpmsg: glink: Remove channel decouple from rpdev release
If a channel is being rapidly restarted and the kobj release worker is
busy, there is a chance the the rpdev_release function will run after
the channel struct itself has been released.
There should not be a need to decouple the channel from rpdev in the
rpdev release since that should only happen from the channel close
commands.
Signed-off-by: Chris Lew
---
drivers/rpmsg/qcom_glink_native.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/rpmsg/qcom_glink_native.c
b/drivers/rpmsg/qcom_glink_native.c
index 621f1afd4d6b..836a0bd99d11 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -1350,9 +1350,7 @@ static const struct rpmsg_endpoint_ops glink_endpoint_ops
= {
static void qcom_glink_rpdev_release(struct device *dev)
{
struct rpmsg_device *rpdev = to_rpmsg_device(dev);
- struct glink_channel *channel = to_glink_channel(rpdev->ept);
- channel->rpdev = NULL;
kfree(rpdev);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v2 2/2] mmc: sdhci-of-arasan: Add Support for Intel LGM SDXC
From: Ramuthevar Vadivel Murugan
The current arasan sdhci PHY configuration isn't compatible
with the PHY on Intel's LGM(Lightning Mountain) SoC devices.
Therefore, add a new compatible, to adapt the Intel's LGM
SDXC PHY with arasan-sdhc controller to configure the PHY.
Signed-off-by: Ramuthevar Vadivel Murugan
Acked-by: Adrian Hunter
---
drivers/mmc/host/sdhci-of-arasan.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 7023cbec4017..55de839a8a5e 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -120,6 +120,12 @@ static const struct sdhci_arasan_soc_ctl_map
intel_lgm_emmc_soc_ctl_map = {
.hiword_update = false,
};
+static const struct sdhci_arasan_soc_ctl_map intel_lgm_sdxc_soc_ctl_map = {
+ .baseclkfreq = { .reg = 0x80, .width = 8, .shift = 2 },
+ .clockmultiplier = { .reg = 0, .width = -1, .shift = -1 },
+ .hiword_update = false,
+};
+
/**
* sdhci_arasan_syscon_write - Write to a field in soc_ctl registers
*
@@ -384,6 +390,11 @@ static struct sdhci_arasan_of_data intel_lgm_emmc_data = {
.pdata = _arasan_cqe_pdata,
};
+static struct sdhci_arasan_of_data intel_lgm_sdxc_data = {
+ .soc_ctl_map = _lgm_sdxc_soc_ctl_map,
+ .pdata = _arasan_cqe_pdata,
+};
+
#ifdef CONFIG_PM_SLEEP
/**
* sdhci_arasan_suspend - Suspend method for the driver
@@ -489,6 +500,10 @@ static const struct of_device_id sdhci_arasan_of_match[] =
{
.compatible = "intel,lgm-sdhci-5.1-emmc",
.data = _lgm_emmc_data,
},
+ {
+ .compatible = "intel,lgm-sdhci-5.1-sdxc",
+ .data = _lgm_sdxc_data,
+ },
/* Generic compatible below here */
{
.compatible = "arasan,sdhci-8.9a",
--
2.11.0
[PATCH v2 1/2] dt-bindings: mmc: sdhci-of-arasan: Add new compatible for Intel LGM SDXC
From: Ramuthevar Vadivel Murugan
Add a new compatible to use the sdhc-arasan host controller driver
with the SDXC PHY to support on Intel's Lightning Mountain(LGM) SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index 7ca0aa7ccc0b..eb78d9a28c8b 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -19,6 +19,8 @@ Required Properties:
Note: This binding has been deprecated and moved to [5].
- "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1": Intel LGM eMMC PHY
For this device it is strongly suggested to include
arasan,soc-ctl-syscon.
+- "intel,lgm-sdhci-5.1-sdxc", "arasan,sdhci-5.1": Intel LGM SDXC PHY
+ For this device it is strongly suggested to include
arasan,soc-ctl-syscon.
[5] Documentation/devicetree/bindings/mmc/sdhci-am654.txt
@@ -97,3 +99,18 @@ Example:
phy-names = "phy_arasan";
arasan,soc-ctl-syscon = <>;
};
+
+ sdxc: sdhci@ec60 {
+ compatible = "arasan,sdhci-5.1", "intel,lgm-sdhci-5.1-sdxc";
+ reg = <0xec60 0x300>;
+ interrupt-parent = <>;
+ interrupts = <43 1>;
+ clocks = < LGM_CLK_SDIO>, < LGM_CLK_NGI>,
+< LGM_GCLK_SDXC>;
+ clock-names = "clk_xin", "clk_ahb", "gate";
+ clock-output-names = "sdxc_cardclock";
+ #clock-cells = <0>;
+ phys = <_phy>;
+ phy-names = "phy_arasan";
+ arasan,soc-ctl-syscon = <>;
+ };
--
2.11.0
[PATCH v2 0/2] mmc: sdhci-of-arasan: Add Support for Intel LGM SDXC
The current arasan sdhci PHY configuration isn't compatible with the PHY on Intel's LGM(Lightning Mountain) SoC devices. Therefore, add a new compatible, to adapt the Intel's LGM SDXC PHY with arasan-sdhc controller to configure the PHY. Linux code base : V5.4-rc1 Ramuthevar Vadivel Murugan (2): dt-bindings: mmc: sdhci-of-arasan: Add new compatible for Intel LGM SDXC mmc: sdhci-of-arasan: Add Support for Intel LGM SDXC changes from v1: - commit message updated - Acked-by tag added Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 17 + drivers/mmc/host/sdhci-of-arasan.c | 15 +++ 2 files changed, 32 insertions(+) -- 2.11.0
Re: KASAN: use-after-free Read in nl8NUM_dump_wpan_phy
syzbot has bisected this bug to:
commit 75cdbdd089003cd53560ff87b690ae911fa7df8e
Author: Jiri Pirko
Date: Sat Oct 5 18:04:37 2019 +
net: ieee802154: have genetlink code to parse the attrs during dumpit
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14620210e0
start commit: 056ddc38 Merge branch 'stmmac-next'
git tree: net-next
final crash:https://syzkaller.appspot.com/x/report.txt?x=16620210e0
console output: https://syzkaller.appspot.com/x/log.txt?x=12620210e0
kernel config: https://syzkaller.appspot.com/x/.config?x=d9be300620399522
dashboard link: https://syzkaller.appspot.com/bug?extid=495688b736534bb6c6ad
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10e256c360
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=175ecdfb60
Reported-by: syzbot+495688b736534bb6c...@syzkaller.appspotmail.com
Fixes: 75cdbdd08900 ("net: ieee802154: have genetlink code to parse the
attrs during dumpit")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH v2 6/6] rpmsg: glink: Free pending deferred work on remove
On 10/4/2019 3:27 PM, Bjorn Andersson wrote:
By just cancelling the deferred rx worker during GLINK instance teardown
any pending deferred commands are leaked, so free them.
Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver")
Cc: sta...@vger.kernel.org
Tested-by: Srinivas Kandagatla
Signed-off-by: Bjorn Andersson
---
Acked-By: Chris Lew
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 0/4] HiSilicon hip08 uncore PMU events additions
Hi John, Thanks for your nice work, these are useful for performance profiling if anyone is unfamiliar with the uncore PMU events on hip08. For this patchset, please feel free to add Reviewed-by: Shaokun Zhang Thanks, Shaokun On 2019/9/4 23:54, John Garry wrote: > This patchset adds some missing uncore PMU events for the hip08 arm64 > platform. > > The missing events were originally mentioned in > https://lkml.org/lkml/2019/6/14/645, when upstreaming the JSONs initially. > > It also includes a fix for a DDRC eventname. > > John Garry (4): > perf jevents: Fix Hisi hip08 DDRC PMU eventname > perf jevents: Add some missing events for Hisi hip08 DDRC PMU > perf jevents: Add some missing events for Hisi hip08 L3C PMU > perf jevents: Add some missing events for Hisi hip08 HHA PMU > > .../arm64/hisilicon/hip08/uncore-ddrc.json| 16 +- > .../arm64/hisilicon/hip08/uncore-hha.json | 23 +++- > .../arm64/hisilicon/hip08/uncore-l3c.json | 56 +++ > 3 files changed, 93 insertions(+), 2 deletions(-) >
Re: [PATCH 0/3] net: ftgmac100: Ungate RCLK for RMII on ASPEED MACs
On Wed, 9 Oct 2019 at 00:38, Florian Fainelli wrote: > > > > On 10/8/2019 4:51 AM, Andrew Jeffery wrote: > > Hello, > > > > This series slightly extends the devicetree binding and driver for the > > FTGMAC100 to describe an optional RMII RCLK gate in the clocks property. > > Currently it's necessary for the kernel to ungate RCLK on the AST2600 in > > NCSI > > configurations as u-boot does not yet support NCSI (which uses the RMII). > > RMII as in Reduced MII or Reverse MII in that context? Reduced MII ( https://en.wikipedia.org/wiki/NC-SI#Hardware_interface ) Cheers, Joel
RE: [PATCH V10 0/2] mailbox: arm: introduce smc triggered mailbox
Hi Jassi, > Subject: [PATCH V10 0/2] mailbox: arm: introduce smc triggered mailbox Are you fine with this patch set? Thanks, Peng. > > From: Peng Fan > > V10: > - Add R-b tag from Andre, Rob and Florian > - Two minor fixes > - Drop "passed from consumers" in patch 1/2 per Andre's comments > - Drop interrupts.h in patch 2/2 per Andre's comments > > V9: > - Add Florian's R-b tag in patch 1/2 > - Mark arm,func-id as a required property per Andre's comments in patch > 1/2. > - Make invoke_smc_mbox_fn as a private entry in a channal per Florian's >comments in pach 2/2 > - Include linux/types.h in arm-smccc-mbox.h in patch 2/2 > - Drop function_id from arm_smccc_mbox_cmd since func-id is from DT >in patch 2/2/. > >Andre, > I have marked arm,func-id as a required property and dropped > function-id > from client, please see whether you are happy with the patchset. > Hope we could finalize and get patches land in. > >Thanks, >Peng. > > V8: > Add missed arm-smccc-mbox.h > > V7: > Typo fix > #mbox-cells changed to 0 > Add a new header file arm-smccc-mbox.h > Use ARM_SMCCC_IS_64 > > Andre, > The function_id is still kept in arm_smccc_mbox_cmd, because arm,func-id > property is optional, so clients could pass function_id to mbox driver. > > V6: > Switch to per-channel a mbox controller > Drop arm,num-chans, transports, method > Add arm,hvc-mbox compatible > Fix smc/hvc args, drop client id and use correct type. > https://patchwork.kernel.org/cover/11146641/ > > V5: > yaml fix > https://patchwork.kernel.org/cover/7741/ > > V4: > yaml fix for num-chans in patch 1/2. > https://patchwork.kernel.org/cover/6521/ > > V3: > Drop interrupt > Introduce transports for mem/reg usage > Add chan-id for mem usage > Convert to yaml format > https://patchwork.kernel.org/cover/11043541/ > > V2: > This is a modified version from Andre Przywara's patch series > https://lore.kernel.org/patchwork/cover/812997/. > The modification are mostly: > Introduce arm,num-chans > Introduce arm_smccc_mbox_cmd > txdone_poll and txdone_irq are both set to false arm,func-ids are kept, but as > an optional property. > Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI. > Introduce interrupts notification. > > [1] is a draft implementation of i.MX8MM SCMI ATF implementation that use > smc as mailbox, power/clk is included, but only part of clk has been > implemented to work with hardware, power domain only supports get name > for now. > > The traditional Linux mailbox mechanism uses some kind of dedicated > hardware IP to signal a condition to some other processing unit, typically a > dedicated management processor. > This mailbox feature is used for instance by the SCMI protocol to signal a > request for some action to be taken by the management processor. > However some SoCs does not have a dedicated management core to provide > those services. In order to service TEE and to avoid linux shutdown power and > clock that used by TEE, need let firmware to handle power and clock, the > firmware here is ARM Trusted Firmware that could also run SCMI service. > > The existing SCMI implementation uses a rather flexible shared memory > region to communicate commands and their parameters, it still requires a > mailbox to actually trigger the action. > > This patch series provides a Linux mailbox compatible service which uses smc > calls to invoke firmware code, for instance taking care of SCMI requests. > The actual requests are still communicated using the standard SCMI way of > shared memory regions, but a dedicated mailbox hardware IP can be replaced > via this new driver. > > This simple driver uses the architected SMC calling convention to trigger > firmware services, also allows for using "HVC" calls to call into hypervisors > or > firmware layers running in the EL2 exception level. > > Patch 1 contains the device tree binding documentation, patch 2 introduces > the actual mailbox driver. > > Please note that this driver just provides a generic mailbox mechanism, It > could support synchronous TX/RX, or synchronous TX with asynchronous RX. > And while providing SCMI services was the reason for this exercise, this > driver > is in no way bound to this use case, but can be used generically where the OS > wants to signal a mailbox condition to firmware or a hypervisor. > Also the driver is in no way meant to replace any existing firmware interface, > but actually to complement existing interfaces. > > [1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi > > > > Peng Fan (2): > dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox > mailbox: introduce ARM SMC based mailbox > > .../devicetree/bindings/mailbox/arm-smc.yaml | 96 > > drivers/mailbox/Kconfig| 7 + > drivers/mailbox/Makefile | 2 + > drivers/mailbox/arm-smc-mailbox.c | 166 >
Re: [PATCH v2 5/6] rpmsg: glink: Don't send pending rx_done during remove
On 10/4/2019 3:27 PM, Bjorn Andersson wrote:
Attempting to transmit rx_done messages after the GLINK instance is
being torn down will cause use after free and memory leaks. So cancel
the intent_work and free up the pending intents.
With this there are no concurrent accessors of the channel left during
qcom_glink_native_remove() and there is therefor no need to hold the
spinlock during this operation - which would prohibit the use of
cancel_work_sync() in the release function. So remove this.
Fixes: 1d2ea36eead9 ("rpmsg: glink: Add rx done command")
Cc: sta...@vger.kernel.org
Tested-by: Srinivas Kandagatla
Signed-off-by: Bjorn Andersson
---
Acked-By: Chris Lew
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v2] of: Make of_dma_get_range() work on bus nodes
On Tue, Oct 8, 2019 at 3:52 PM Nicolas Saenz Julienne wrote: > > Hi Rob/Robin, > > On Tue, 2019-10-08 at 14:52 -0500, Rob Herring wrote: > > From: Robin Murphy > > > > Since the "dma-ranges" property is only valid for a node representing a > > bus, of_dma_get_range() currently assumes the node passed in is a leaf > > representing a device, and starts the walk from its parent. In cases > > like PCI host controllers on typical FDT systems, however, where the PCI > > endpoints are probed dynamically the initial leaf node represents the > > 'bus' itself, and this logic means we fail to consider any "dma-ranges" > > describing the host bridge itself. Rework the logic such that > > of_dma_get_range() also works correctly starting from a bus node > > containing "dma-ranges". > > > > While this does mean "dma-ranges" could incorrectly be in a device leaf > > node, there isn't really any way in this function to ensure that a leaf > > node is or isn't a bus node. > > Sorry, I'm not totally sure if this is what you're pointing out with the last > sentence. But, what about the case of a bus configuring a device which also > happens to be a memory mapped bus (say a PCI platform device). It'll get it's > dma config based on its own dma-ranges which is not what we want. What I was trying to say is we just can't tell if we should be looking in the current node or the parent. 'dma-ranges' in a leaf node can be correct or incorrect. Your example is a bit different. I'm not sure that case is valid or can ever work if it is. It's certainly valid that a PCI bridge's parent has dma-ranges and now we'll actually handle any translation. The bridge itself is not a DMA-capable device, but just passing thru DMA. Do we ever need to know the parent's dma-ranges in that case? Or to put it another way, is looking at anything other than leaf dma-ranges useful? Rob
Re: [PATCH v2 2/6] rpmsg: glink: Fix use after free in open_ack TIMEOUT case
On 10/4/2019 3:26 PM, Bjorn Andersson wrote:
From: Arun Kumar Neelakantam
Extra channel reference put when remote sending OPEN_ACK after timeout
causes use-after-free while handling next remote CLOSE command.
Remove extra reference put in timeout case to avoid use-after-free.
Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver")
Cc: sta...@vger.kernel.org
Tested-by: Srinivas Kandagatla
Signed-off-by: Arun Kumar Neelakantam
Signed-off-by: Bjorn Andersson
---
Acked-By: Chris Lew
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v2 6/9] RISC-V: entry: Remove unneeded need_resched() loop
On Mon, 23 Sep 2019, Valentin Schneider wrote: > Since the enabling and disabling of IRQs within preempt_schedule_irq() > is contained in a need_resched() loop, we don't need the outer arch > code loop. > > Reviewed-by: Palmer Dabbelt > Signed-off-by: Valentin Schneider > Cc: Albert Ou > Cc: linux-ri...@lists.infradead.org Thanks, queued for v5.4-rc. - Paul
Re: [PATCH v2 1/6] rpmsg: glink: Fix reuse intents memory leak issue
On 10/4/2019 3:26 PM, Bjorn Andersson wrote:
From: Arun Kumar Neelakantam
Memory allocated for re-usable intents are not freed during channel
cleanup which causes memory leak in system.
Check and free all re-usable memory to avoid memory leak.
Fixes: 933b45da5d1d ("rpmsg: glink: Add support for TX intents")
Cc: sta...@vger.kernel.org
Tested-by: Srinivas Kandagatla
Signed-off-by: Arun Kumar Neelakantam
Reported-by: Srinivas Kandagatla
Signed-off-by: Bjorn Andersson
---
Acked-By: Chris Lew
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 0/3] net: ftgmac100: Ungate RCLK for RMII on ASPEED MACs
On 10/8/2019 4:51 AM, Andrew Jeffery wrote: > Hello, > > This series slightly extends the devicetree binding and driver for the > FTGMAC100 to describe an optional RMII RCLK gate in the clocks property. > Currently it's necessary for the kernel to ungate RCLK on the AST2600 in NCSI > configurations as u-boot does not yet support NCSI (which uses the RMII). RMII as in Reduced MII or Reverse MII in that context? > > Please review! > > Andrew > > Andrew Jeffery (3): > dt-bindings: net: ftgmac100: Document AST2600 compatible > dt-bindings: net: ftgmac100: Describe clock properties > net: ftgmac100: Ungate RCLK for RMII on ASPEED MACs > > .../devicetree/bindings/net/ftgmac100.txt | 7 > drivers/net/ethernet/faraday/ftgmac100.c | 35 +++ > 2 files changed, 35 insertions(+), 7 deletions(-) > -- Florian
Re: [PATCH net-next 0/6] net: hns3: add some new feature
On Tue, 8 Oct 2019 09:20:03 +0800, Huazhong Tan wrote: > This patch-set includes some new features for the HNS3 ethernet > controller driver. > > [patch 01/06] adds support for configuring VF link status on the host. > > [patch 02/06] adds support for configuring VF spoof check. > > [patch 03/06] adds support for configuring VF trust. > > [patch 04/06] adds support for configuring VF bandwidth on the host. > > [patch 05/06] adds support for configuring VF MAC on the host. > > [patch 06/06] adds support for tx-scatter-gather-fraglist. Applied.
[PATCH v2] media: vimc: Make capture devices and subdevices use different link_validates
Instead of validating the links to capture devices and subdevices with
the same function, use the default v4l function for links between
subdevices and only use a different function for validating between
capture device and subdevice.
This change should also ease future work to associate multiple mbus
codes for the same pixelformat in vimc_pix_map.
These changes were tested with
v4l2-compliance SHA: 3f806630e2ecbcebe31872b865c5c4b42f111a99, 64 bits
and passed all tests:
Grand Total for vimc device /dev/media0: 451, Succeeded: 451, Failed: 0,
Warnings: 0
Signed-off-by: Nícolas F. R. A. Prado
---
Changes in v2:
- Remove blank lines
- Rename vimc_cap_link_validate to vimc_vdev_link_validate and move it back to
vimc-common.c
- Fix style issue on vimc_get_pix_format header
- Remove vimc_get_pix_format declaration from vimc-common.h
drivers/media/platform/vimc/vimc-capture.c | 2 +-
drivers/media/platform/vimc/vimc-common.c | 86 +++---
drivers/media/platform/vimc/vimc-common.h | 4 +-
3 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/drivers/media/platform/vimc/vimc-capture.c
b/drivers/media/platform/vimc/vimc-capture.c
index 602f80323031..75daebd625a8 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -322,7 +322,7 @@ static const struct vb2_ops vimc_cap_qops = {
};
static const struct media_entity_operations vimc_cap_mops = {
- .link_validate = vimc_link_validate,
+ .link_validate = vimc_vdev_link_validate,
};
static void vimc_cap_release(struct video_device *vdev)
diff --git a/drivers/media/platform/vimc/vimc-common.c
b/drivers/media/platform/vimc/vimc-common.c
index a3120f4f7a90..a67813e750d9 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -247,35 +247,35 @@ int vimc_pipeline_s_stream(struct media_entity *ent, int
enable)
}
EXPORT_SYMBOL_GPL(vimc_pipeline_s_stream);
-static int vimc_get_mbus_format(struct media_pad *pad,
- struct v4l2_subdev_format *fmt)
+int vimc_get_pix_format(struct media_pad *pad, struct v4l2_pix_format *fmt)
{
if (is_media_entity_v4l2_subdev(pad->entity)) {
struct v4l2_subdev *sd =
media_entity_to_v4l2_subdev(pad->entity);
+ struct v4l2_subdev_format sd_fmt;
+ const struct vimc_pix_map *pix_map;
int ret;
- fmt->which = V4L2_SUBDEV_FORMAT_ACTIVE;
- fmt->pad = pad->index;
+ sd_fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ sd_fmt.pad = pad->index;
- ret = v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt);
+ ret = v4l2_subdev_call(sd, pad, get_fmt, NULL, _fmt);
if (ret)
return ret;
+ v4l2_fill_pix_format(fmt, _fmt.format);
+ pix_map = vimc_pix_map_by_code(sd_fmt.format.code);
+ fmt->pixelformat = pix_map->pixelformat;
} else if (is_media_entity_v4l2_video_device(pad->entity)) {
struct video_device *vdev = container_of(pad->entity,
struct video_device,
entity);
struct vimc_ent_device *ved = video_get_drvdata(vdev);
- const struct vimc_pix_map *vpix;
- struct v4l2_pix_format vdev_fmt;
if (!ved->vdev_get_format)
return -ENOIOCTLCMD;
- ved->vdev_get_format(ved, _fmt);
- vpix = vimc_pix_map_by_pixelformat(vdev_fmt.pixelformat);
- v4l2_fill_mbus_format(>format, _fmt, vpix->code);
+ ved->vdev_get_format(ved, fmt);
} else {
return -EINVAL;
}
@@ -283,16 +283,16 @@ static int vimc_get_mbus_format(struct media_pad *pad,
return 0;
}
-int vimc_link_validate(struct media_link *link)
+int vimc_vdev_link_validate(struct media_link *link)
{
- struct v4l2_subdev_format source_fmt, sink_fmt;
+ struct v4l2_pix_format source_fmt, sink_fmt;
int ret;
- ret = vimc_get_mbus_format(link->source, _fmt);
+ ret = vimc_get_pix_format(link->source, _fmt);
if (ret)
return ret;
- ret = vimc_get_mbus_format(link->sink, _fmt);
+ ret = vimc_get_pix_format(link->sink, _fmt);
if (ret)
return ret;
@@ -301,21 +301,21 @@ int vimc_link_validate(struct media_link *link)
"%s:snk:%dx%d (0x%x, %d, %d, %d, %d)\n",
/* src */
link->source->entity->name,
- source_fmt.format.width, source_fmt.format.height,
- source_fmt.format.code, source_fmt.format.colorspace,
- source_fmt.format.quantization, source_fmt.format.xfer_func,
-
Re: [PATCH 2/3] dt-bindings: net: ftgmac100: Describe clock properties
On Tue, 8 Oct 2019, at 23:12, Joel Stanley wrote: > On Tue, 8 Oct 2019 at 11:50, Andrew Jeffery wrote: > > > > Critically, the AST2600 requires ungating the RMII RCLK if e.g. NCSI is > > in use. > > > > Signed-off-by: Andrew Jeffery > > --- > > Documentation/devicetree/bindings/net/ftgmac100.txt | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/net/ftgmac100.txt > > b/Documentation/devicetree/bindings/net/ftgmac100.txt > > index 04cc0191b7dd..c443b0b84be5 100644 > > --- a/Documentation/devicetree/bindings/net/ftgmac100.txt > > +++ b/Documentation/devicetree/bindings/net/ftgmac100.txt > > @@ -24,6 +24,12 @@ Optional properties: > > - no-hw-checksum: Used to disable HW checksum support. Here for backward > >compatibility as the driver now should have correct defaults based on > >the SoC. > > +- clocks: In accordance with the generic clock bindings. Must describe the > > MAC > > + IP clock, and optionally an RMII RCLK gate for the AST2600. > > or AST2500. > > With that fixed you can add my ack. I'll do a v2 and fix the comments in the driver patch as well. Cheers, Andrew
[PATCH] arm64: defconfig: Enable Qualcomm remoteproc dependencies
Enable the the power domains, reset controllers and remote block device memory access drivers necessary to boot the Audio, Compute and Modem DSPs on Qualcomm SDM845. None of the power domains are system critical, but needs to be builtin as the driver core prohibits probe deferal past late initcall. Signed-off-by: Bjorn Andersson --- arch/arm64/configs/defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index c9a867ac32d4..42f042ba1039 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -732,10 +732,13 @@ CONFIG_RPMSG_QCOM_GLINK_SMEM=m CONFIG_RPMSG_QCOM_SMD=y CONFIG_RASPBERRYPI_POWER=y CONFIG_IMX_SCU_SOC=y +CONFIG_QCOM_AOSS_QMP=y CONFIG_QCOM_COMMAND_DB=y CONFIG_QCOM_GENI_SE=y CONFIG_QCOM_GLINK_SSR=m +CONFIG_QCOM_RMTFS_MEM=m CONFIG_QCOM_RPMH=y +CONFIG_QCOM_RPMHPD=y CONFIG_QCOM_SMEM=y CONFIG_QCOM_SMD_RPM=y CONFIG_QCOM_SMP2P=y @@ -780,6 +783,8 @@ CONFIG_PWM_ROCKCHIP=y CONFIG_PWM_SAMSUNG=y CONFIG_PWM_SUN4I=m CONFIG_PWM_TEGRA=m +CONFIG_RESET_QCOM_AOSS=y +CONFIG_RESET_QCOM_PDC=m CONFIG_RESET_TI_SCI=y CONFIG_PHY_XGENE=y CONFIG_PHY_SUN4I_USB=y -- 2.18.0
[RFC PATCH] interconnect: Replace of_icc_get() with icc_get() and reduce DT binding
Quoting Stephen Boyd:
> Quoting David Dai (2019-09-27 10:16:07)
> > On 9/25/2019 6:28 AM, Stephen Boyd wrote:
> > > Quoting Bjorn Andersson (2019-09-24 22:59:33)
> > >> On Tue 24 Sep 22:41 PDT 2019, Stephen Boyd wrote:
> > >>
> > >>> The DT binding could also be simplified somewhat. Currently a path needs
> > >>> to be specified in DT for each and every use case that is possible for a
> > >>> device to want. Typically the path is to memory, which looks to be
> > >>> reserved for in the binding with the "dma-mem" named path, but sometimes
> > >>> the path is from a device to the CPU or more generically from a device
> > >>> to another device which could be a CPU, cache, DMA master, or another
> > >>> device if some sort of DMA to DMA scenario is happening. Let's remove
> > >>> the pair part of the binding so that we just list out a device's
> > >>> possible endpoints on the bus or busses that it's connected to.
> > >>>
> > >>> If the kernel wants to figure out what the path is to memory or the CPU
> > >>> or a cache or something else it should be able to do that by finding the
> > >>> node for the "destination" endpoint, extracting that node's
> > >>> "interconnects" property, and deriving the path in software. For
> > >>> example, we shouldn't need to write out each use case path by path in DT
> > >>> for each endpoint node that wants to set a bandwidth to memory. We
> > >>> should just be able to indicate what endpoint(s) a device sits on based
> > >>> on the interconnect provider in the system and then walk the various
> > >>> interconnects to find the path from that source endpoint to the
> > >>> destination endpoint.
> > >>>
> > >> But doesn't this implies that the other end of the path is always some
> > >> specific node, e.g. DDR? With a single node how would you describe
> > >> CPU->LLCC or GPU->OCIMEM?
> > > By only specifying the endpoint the device uses it describes what the
> > > hardware block interfaces with. It doesn't imply that there's only one
> > > other end of the path. It implies that the paths should be discoverable
> > > by walking the interconnect graph given some source device node and
> > > target device node. In most cases the target device node will be a DDR
> > > controller node, but sometimes it could be LLCC or OCIMEM. We may need
> > > to add some sort of "get the DDR controller device" API or work it into
> > > the interconnect API somehow to indicate what target endpoint is
> > > desired. By not listing all those paths in DT we gain flexibility to add
> > > more paths later on without having to update or tweak DT to describe
> > > more paths/routes through the interconnect.
> >
> >
> > I'm unsure that using the target device node or target source device is
> > the correct way to represent the constraints that the consumers apply on
> > the interconnects. While it's true the traffic is intended for the
> > targeted devices, the constraints(QoS or BW) are for the interconnect or
> > specifically the paths that span across the ports of various
> > interconnects(NoC devices in this case). I think having both src and dst
> > properties is still the simplest way to achieve the flexibility that we
> > require to set the constraints for ports(that may not have a target
> > device defined in DT or exists as some intermediate port across multiple
> > interconnects).
>
>
> The need for paths described in DT may make sense for certain cases but
> that seems to be the minority. My guess is that maybe an OPP binding
> would need to describe the path to apply the bandwidth to. Otherwise I
> don't see what the need is for. Maybe you can list out more scenarios?
>
> Either way, the binding has been designed to cover all the possibilities
> by just saying that we have to describe at least two points for an
> 'interconnect'. It is a path based binding. I'd rather see us have an
> endpoint based binding with the option to fallback to paths if we need
> to constrain something. Maybe this can be a new property that is used
> the majority of the time?
>
> gpu@f00 {
> interconnect-endpoints =3D < GPU_SLAVE_PORT>, < GPU_MASTER_PORT0>,
> < GPU_MASTER_PORT1>;
> interconnect-endpoint-names =3D "slave", "master0", "master1";
> };
>
> (Or we can invert it and make interconnect-paths be non-standard)
>
> The property would describe what's going to this device and how it's
> integrated into the SoC. This is similar to how we describe what port is
> connected to a device with the of graph binding or how we only list the
> clk or regulator that goes to a device and not the whole path to the
> root of the respective tree.
>
> There can be a driver API that gets these port numbers out and
> constructs a path to another struct device or struct device_node. I
> imagine that 90% of the time a driver is going to request some bandwidth
> from their master port (or ports) to the DDR controller. We could either
> make the DDR controller a device that can be globally acquired or
> integrate it deeply
Re: [PATCH] NFC: pn533: fix use-after-free and memleaks
On Mon, 7 Oct 2019 18:40:59 +0200, Johan Hovold wrote:
> The driver would fail to deregister and its class device and free
> related resources on late probe errors.
>
> Reported-by: syzbot+cb035c75c03dbe34b...@syzkaller.appspotmail.com
> Fixes: 32ecc75ded72 ("NFC: pn533: change order operations in dev registation")
> Cc: stable# 4.11
> Signed-off-by: Johan Hovold
Applied to net, thank you
Re: [PATCH v2] arm64: lse: fix LSE atomics with LLVM's integrated assembler
On Tue, Oct 08, 2019 at 04:59:25PM -0700, 'Sami Tolvanen' via Clang Built Linux wrote: > On Tue, Oct 8, 2019 at 4:31 PM Andrew Murray wrote: > > This looks good to me. I can build and boot in a model with both Clang > > (9.0.6) and GCC (7.3.1) and boot a guest without anything going bang. > > Great, thank you for testing this! > > > Though when I build with AS=clang, e.g. > > > > make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CC=clang AS=clang Image > > Note that this patch only fixes issues with inline assembly, which > should at some point allow us to drop -no-integrated-as from clang > builds. I believe there are still other fixes needed before AS=clang > works. > > > I get errors like this: > > > > CC init/main.o > > In file included from init/main.c:17: > > In file included from ./include/linux/module.h:9: > > In file included from ./include/linux/list.h:9: > > In file included from ./include/linux/kernel.h:12: > > In file included from ./include/linux/bitops.h:26: > > In file included from ./arch/arm64/include/asm/bitops.h:26: > > In file included from ./include/asm-generic/bitops/atomic.h:5: > > In file included from ./include/linux/atomic.h:7: > > In file included from ./arch/arm64/include/asm/atomic.h:16: > > In file included from ./arch/arm64/include/asm/cmpxchg.h:14: > > In file included from ./arch/arm64/include/asm/lse.h:13: > > In file included from ./include/linux/jump_label.h:117: > > ./arch/arm64/include/asm/jump_label.h:24:20: error: expected a symbol > > reference in '.long' directive > > " .align 3 \n\t" > > ^ > > :4:21: note: instantiated into assembly here > > .long 1b - ., "" - . > >^ > > > > I'm assuming that I'm doing something wrong? > > No, this particular issue will be fixed in clang 10: > https://github.com/ClangBuiltLinux/linux/issues/500 > > Sami I believe that it should be fixed with AOSP's Clang 9.0.8 or upstream Clang 9.0.0. Cheers, Nathan
Re: [PATCH v2] arm64: lse: fix LSE atomics with LLVM's integrated assembler
On Tue, Oct 8, 2019 at 4:31 PM Andrew Murray wrote: > This looks good to me. I can build and boot in a model with both Clang > (9.0.6) and GCC (7.3.1) and boot a guest without anything going bang. Great, thank you for testing this! > Though when I build with AS=clang, e.g. > > make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CC=clang AS=clang Image Note that this patch only fixes issues with inline assembly, which should at some point allow us to drop -no-integrated-as from clang builds. I believe there are still other fixes needed before AS=clang works. > I get errors like this: > > CC init/main.o > In file included from init/main.c:17: > In file included from ./include/linux/module.h:9: > In file included from ./include/linux/list.h:9: > In file included from ./include/linux/kernel.h:12: > In file included from ./include/linux/bitops.h:26: > In file included from ./arch/arm64/include/asm/bitops.h:26: > In file included from ./include/asm-generic/bitops/atomic.h:5: > In file included from ./include/linux/atomic.h:7: > In file included from ./arch/arm64/include/asm/atomic.h:16: > In file included from ./arch/arm64/include/asm/cmpxchg.h:14: > In file included from ./arch/arm64/include/asm/lse.h:13: > In file included from ./include/linux/jump_label.h:117: > ./arch/arm64/include/asm/jump_label.h:24:20: error: expected a symbol > reference in '.long' directive > " .align 3 \n\t" > ^ > :4:21: note: instantiated into assembly here > .long 1b - ., "" - . >^ > > I'm assuming that I'm doing something wrong? No, this particular issue will be fixed in clang 10: https://github.com/ClangBuiltLinux/linux/issues/500 Sami
Re: [PATCH v2 0/2] Avoid regmap debugfs collisions in qcom llcc driver
On Tue 08 Oct 16:45 PDT 2019, Stephen Boyd wrote:
> Now a two part series. These patches fix a debugfs name collision for
> the llcc regmaps and moves the config to a local variable to save on
> image size.
>
> Changes from v1
> (https://lkml.kernel.org/r/20191004233132.194336-1-swb...@chromium.org):
> * New second patch
> * Dropped static
> * See range-diff below!
>
> Stephen Boyd (2):
> soc: qcom: llcc: Name regmaps to avoid collisions
> soc: qcom: llcc: Move regmap config to local variable
>
> drivers/soc/qcom/llcc-slice.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> Cc: Venkata Narendra Kumar Gutta
> Cc: Evan Green
>
> Range-diff against v1:
> -: > 1: 07bc0e8bdb6e soc: qcom: llcc: Name regmaps to avoid
> collisions
> 1: 0c54fc8a7ed6 ! 2: 5c4446e36783 soc: qcom: llcc: Name regmaps to avoid
> collisions
> @@ Metadata
> Author: Stephen Boyd
>
> ## Commit message ##
> -soc: qcom: llcc: Name regmaps to avoid collisions
> +soc: qcom: llcc: Move regmap config to local variable
>
> -We'll end up with debugfs collisions if we don't give names to the
> -regmaps created inside this driver. Copy the template config over
> into
> -this function and give the regmap the same name as the resource name.
> +This is now a global variable that we're modifying to fix the name.
> +That isn't terribly thread safe and it's not necessary to be a
> global so
> +let's just move this to a local variable instead. This saves space in
> +the symtab and actually reduces kernel image size because the regmap
> +config is large and we can replace the initialization of that
> structure
> +with a memset and a few member assignments.
>
> -Fixes: 7f9c136216c7 ("soc: qcom: Add broadcast base for Last Level
> Cache Controller (LLCC)")
> -Cc: Venkata Narendra Kumar Gutta
> -Cc: Evan Green
> Signed-off-by: Stephen Boyd
>
> ## drivers/soc/qcom/llcc-slice.c ##
> @@ drivers/soc/qcom/llcc-slice.c
>
> static struct llcc_drv_data *drv_data = (void *) -EPROBE_DEFER;
>
> --static const struct regmap_config llcc_regmap_config = {
> +-static struct regmap_config llcc_regmap_config = {
> -.reg_bits = 32,
> -.reg_stride = 4,
> -.val_bits = 32,
> @@ drivers/soc/qcom/llcc-slice.c: static struct regmap
> *qcom_llcc_init_mmio(struct
> {
> struct resource *res;
> void __iomem *base;
> -+static struct regmap_config llcc_regmap_config = {
> ++struct regmap_config llcc_regmap_config = {
Now that this isn't static I like the end result better. Not sure about
the need for splitting it in two patches, but if Evan is happy I'll take
it.
Regards,
Bjorn
> +.reg_bits = 32,
> +.reg_stride = 4,
> +.val_bits = 32,
> @@ drivers/soc/qcom/llcc-slice.c: static struct regmap
> *qcom_llcc_init_mmio(struct
>
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
> if (!res)
> -@@ drivers/soc/qcom/llcc-slice.c: static struct regmap
> *qcom_llcc_init_mmio(struct platform_device *pdev,
> - if (IS_ERR(base))
> - return ERR_CAST(base);
> -
> -+llcc_regmap_config.name = name;
> - return devm_regmap_init_mmio(>dev, base,
> _regmap_config);
> - }
> -
>
> base-commit: 8b0eed9f6e36a5488967b0acc51444d658dd711b
> --
> Sent by a computer through tubes
>
[PATCH] ASoC: jz4740: Remove unused match variable
After commit 67ad656bdd70 ("ASoC: jz4740: Use
of_device_get_match_data()"), the match local variable is unused and the
compiler rightly warns.
sound/soc/jz4740/jz4740-i2s.c: In function 'jz4740_i2s_dev_probe':
sound/soc/jz4740/jz4740-i2s.c:500:29: warning: unused variable 'match'
[-Wunused-variable]
500 | const struct of_device_id *match;
Drop it.
Reported-by: Stephen Rothwell
Cc: Arnd Bergmann
Cc: Geert Uytterhoeven
Cc: Paul Cercueil
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Rob Herring
Cc: Frank Rowand
Cc:
Fixes: 67ad656bdd70 ("ASoC: jz4740: Use of_device_get_match_data()")
Signed-off-by: Stephen Boyd
---
Can also be squashed. Sorry I missed this warning in the compile log.
sound/soc/jz4740/jz4740-i2s.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/jz4740/jz4740-i2s.c b/sound/soc/jz4740/jz4740-i2s.c
index d2dab4d24b87..38d48d101783 100644
--- a/sound/soc/jz4740/jz4740-i2s.c
+++ b/sound/soc/jz4740/jz4740-i2s.c
@@ -497,7 +497,6 @@ static int jz4740_i2s_dev_probe(struct platform_device
*pdev)
struct jz4740_i2s *i2s;
struct resource *mem;
int ret;
- const struct of_device_id *match;
i2s = devm_kzalloc(>dev, sizeof(*i2s), GFP_KERNEL);
if (!i2s)
base-commit: 442630f691a1537b7e0cc35e3d580222077549cb
--
Sent by a computer through tubes
Re: [PATCH v2 3/3] phy: qcom-qmp: Add SM8150 QMP UFS PHY support
On Tue 08 Oct 00:46 PDT 2019, Jack Pham wrote: > On Fri, Sep 06, 2019 at 10:40:17AM +0530, Vinod Koul wrote: [..] > I was thinking of taking a stab at USB if I get time, not sure if that's > already on your or somebody's (Bjorn?) radar. > We only have remote access to the hardware, making it rather tedious to do USB. So it's all yours! :) Regards, Bjorn
[PATCH v2 1/2] soc: qcom: llcc: Name regmaps to avoid collisions
We'll end up with debugfs collisions if we don't give names to the
regmaps created by this driver. Change the name of the config before
registering it so we don't collide in debugfs.
Fixes: 7f9c136216c7 ("soc: qcom: Add broadcast base for Last Level Cache
Controller (LLCC)")
Cc: Venkata Narendra Kumar Gutta
Cc: Evan Green
Signed-off-by: Stephen Boyd
---
drivers/soc/qcom/llcc-slice.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/llcc-slice.c b/drivers/soc/qcom/llcc-slice.c
index 9090ea12eaf3..4a6111635f82 100644
--- a/drivers/soc/qcom/llcc-slice.c
+++ b/drivers/soc/qcom/llcc-slice.c
@@ -48,7 +48,7 @@
static struct llcc_drv_data *drv_data = (void *) -EPROBE_DEFER;
-static const struct regmap_config llcc_regmap_config = {
+static struct regmap_config llcc_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
@@ -323,6 +323,7 @@ static struct regmap *qcom_llcc_init_mmio(struct
platform_device *pdev,
if (IS_ERR(base))
return ERR_CAST(base);
+ llcc_regmap_config.name = name;
return devm_regmap_init_mmio(>dev, base, _regmap_config);
}
--
Sent by a computer through tubes
[PATCH v2 2/2] soc: qcom: llcc: Move regmap config to local variable
This is now a global variable that we're modifying to fix the name.
That isn't terribly thread safe and it's not necessary to be a global so
let's just move this to a local variable instead. This saves space in
the symtab and actually reduces kernel image size because the regmap
config is large and we can replace the initialization of that structure
with a memset and a few member assignments.
Cc: Venkata Narendra Kumar Gutta
Cc: Evan Green
Signed-off-by: Stephen Boyd
---
drivers/soc/qcom/llcc-slice.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/qcom/llcc-slice.c b/drivers/soc/qcom/llcc-slice.c
index 4a6111635f82..50aea3f0be41 100644
--- a/drivers/soc/qcom/llcc-slice.c
+++ b/drivers/soc/qcom/llcc-slice.c
@@ -48,13 +48,6 @@
static struct llcc_drv_data *drv_data = (void *) -EPROBE_DEFER;
-static struct regmap_config llcc_regmap_config = {
- .reg_bits = 32,
- .reg_stride = 4,
- .val_bits = 32,
- .fast_io = true,
-};
-
/**
* llcc_slice_getd - get llcc slice descriptor
* @uid: usecase_id for the client
@@ -314,6 +307,12 @@ static struct regmap *qcom_llcc_init_mmio(struct
platform_device *pdev,
{
struct resource *res;
void __iomem *base;
+ struct regmap_config llcc_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .fast_io = true,
+ };
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
if (!res)
--
Sent by a computer through tubes
Re: [PATCH 4.19 001/106] tpm: use tpm_try_get_ops() in tpm-sysfs.c.
On Tue, Oct 08, 2019 at 02:51:20PM +0200, Pavel Machek wrote: > For example this did not have any locking, and is now protected by > > get_device(>dev); > > down_read(>ops_sem); > > . Is that intended? Is this known to fix any bugs? It is, sysfs code can otherwise race when ops is set NULL in class shutdown. /Jarkko
[PATCH v2 0/2] Avoid regmap debugfs collisions in qcom llcc driver
Now a two part series. These patches fix a debugfs name collision for
the llcc regmaps and moves the config to a local variable to save on
image size.
Changes from v1
(https://lkml.kernel.org/r/20191004233132.194336-1-swb...@chromium.org):
* New second patch
* Dropped static
* See range-diff below!
Stephen Boyd (2):
soc: qcom: llcc: Name regmaps to avoid collisions
soc: qcom: llcc: Move regmap config to local variable
drivers/soc/qcom/llcc-slice.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Cc: Venkata Narendra Kumar Gutta
Cc: Evan Green
Range-diff against v1:
-: > 1: 07bc0e8bdb6e soc: qcom: llcc: Name regmaps to avoid
collisions
1: 0c54fc8a7ed6 ! 2: 5c4446e36783 soc: qcom: llcc: Name regmaps to avoid
collisions
@@ Metadata
Author: Stephen Boyd
## Commit message ##
-soc: qcom: llcc: Name regmaps to avoid collisions
+soc: qcom: llcc: Move regmap config to local variable
-We'll end up with debugfs collisions if we don't give names to the
-regmaps created inside this driver. Copy the template config over into
-this function and give the regmap the same name as the resource name.
+This is now a global variable that we're modifying to fix the name.
+That isn't terribly thread safe and it's not necessary to be a global
so
+let's just move this to a local variable instead. This saves space in
+the symtab and actually reduces kernel image size because the regmap
+config is large and we can replace the initialization of that structure
+with a memset and a few member assignments.
-Fixes: 7f9c136216c7 ("soc: qcom: Add broadcast base for Last Level
Cache Controller (LLCC)")
-Cc: Venkata Narendra Kumar Gutta
-Cc: Evan Green
Signed-off-by: Stephen Boyd
## drivers/soc/qcom/llcc-slice.c ##
@@ drivers/soc/qcom/llcc-slice.c
static struct llcc_drv_data *drv_data = (void *) -EPROBE_DEFER;
--static const struct regmap_config llcc_regmap_config = {
+-static struct regmap_config llcc_regmap_config = {
- .reg_bits = 32,
- .reg_stride = 4,
- .val_bits = 32,
@@ drivers/soc/qcom/llcc-slice.c: static struct regmap
*qcom_llcc_init_mmio(struct
{
struct resource *res;
void __iomem *base;
-+ static struct regmap_config llcc_regmap_config = {
++ struct regmap_config llcc_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
@@ drivers/soc/qcom/llcc-slice.c: static struct regmap
*qcom_llcc_init_mmio(struct
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
if (!res)
-@@ drivers/soc/qcom/llcc-slice.c: static struct regmap
*qcom_llcc_init_mmio(struct platform_device *pdev,
- if (IS_ERR(base))
- return ERR_CAST(base);
-
-+ llcc_regmap_config.name = name;
- return devm_regmap_init_mmio(>dev, base, _regmap_config);
- }
-
base-commit: 8b0eed9f6e36a5488967b0acc51444d658dd711b
--
Sent by a computer through tubes
Re: [PATCH 5.4 regression fix] Input: soc_button_array - partial revert of support for newer surface devices
On Sat, Oct 05, 2019 at 12:55:51PM +0200, Hans de Goede wrote:
> Commit c394159310d0 ("Input: soc_button_array - add support for newer
> surface devices") not only added support for the MSHW0040 ACPI HID,
> but for some reason it also makes changes to the error handling of the
> soc_button_lookup_gpio() call in soc_button_device_create(). Note ideally
> this seamingly unrelated change would have been made in a separate commit,
> with a message explaining the what and why of this change.
>
> I guess this change may have been added to deal with -EPROBE_DEFER errors,
> but in case of the existing support for PNP0C40 devices, treating
> -EPROBE_DEFER as any other error is deliberate, see the comment this
> commit adds for why.
>
> The actual returning of -EPROBE_DEFER to the caller of soc_button_probe()
> introduced by the new error checking causes a serious regression:
>
> On devices with so called virtual GPIOs soc_button_lookup_gpio() will
> always return -EPROBE_DEFER for these fake GPIOs, when this happens
> during the second call of soc_button_device_create() we already have
> successfully registered our first child. This causes the kernel to think
> we are making progress with probing things even though we unregister the
> child before again before we return the -EPROBE_DEFER. Since we are making
> progress the kernel will retry deferred-probes again immediately ending
> up stuck in a loop with the following showing in dmesg:
>
> [ 124.022697] input: gpio-keys as
> /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6537
> [ 124.040764] input: gpio-keys as
> /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6538
> [ 124.056967] input: gpio-keys as
> /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6539
> [ 124.072143] input: gpio-keys as
> /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6540
> [ 124.092373] input: gpio-keys as
> /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6541
> [ 124.108065] input: gpio-keys as
> /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6542
> [ 124.128483] input: gpio-keys as
> /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6543
> [ 124.147141] input: gpio-keys as
> /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6544
> [ 124.165070] input: gpio-keys as
> /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6545
> [ 124.179775] input: gpio-keys as
> /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6546
> [ 124.202726] input: gpio-keys as
> /devices/platform/INTCFD9:00/gpio-keys.0.auto/input/input6547
>
>
> And 1 CPU core being stuck at 100% and udev hanging since it is waiting
> for the modprobe of soc_button_array to return.
>
> This patch reverts the soc_button_lookup_gpio() error handling changes,
> fixing this regression.
>
> Fixes: c394159310d0 ("Input: soc_button_array - add support for newer surface
> devices")
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205031
> Cc: Maximilian Luz
> Signed-off-by: Hans de Goede
Applied, thank you.
> ---
> drivers/input/misc/soc_button_array.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/input/misc/soc_button_array.c
> b/drivers/input/misc/soc_button_array.c
> index 97e3639e99d0..97761421d6dd 100644
> --- a/drivers/input/misc/soc_button_array.c
> +++ b/drivers/input/misc/soc_button_array.c
> @@ -92,11 +92,18 @@ soc_button_device_create(struct platform_device *pdev,
> continue;
>
> gpio = soc_button_lookup_gpio(>dev, info->acpi_index);
> - if (gpio < 0 && gpio != -ENOENT) {
> - error = gpio;
> - goto err_free_mem;
> - } else if (!gpio_is_valid(gpio)) {
> - /* Skip GPIO if not present */
> + if (!gpio_is_valid(gpio)) {
> + /*
> + * Skip GPIO if not present. Note we deliberately
> + * ignore -EPROBE_DEFER errors here. On some devices
> + * Intel is using so called virtual GPIOs which are not
> + * GPIOs at all but some way for AML code to check some
> + * random status bits without need a custom opregion.
> + * In some cases the resources table we parse points to
> + * such a virtual GPIO, since these are not real GPIOs
> + * we do not have a driver for these so they will never
> + * show up, therefor we ignore -EPROBE_DEFER.
> + */
> continue;
> }
>
> --
> 2.23.0
>
--
Dmitry
Re: [PATCH] ARC: mm: remove __ARCH_USE_5LEVEL_HACK
On Tue, Oct 08, 2019 at 09:38:36PM +, Vineet Gupta wrote: > Add the intermediate p4d accessors to make it 5 level compliant. > > Thi sis non-functional change anyways since ARC has software page walker ^ Typo. > with 2 lookup levels (pgd -> pte) > > Signed-off-by: Vineet Gupta > --- > arch/arc/include/asm/pgtable.h | 1 - > arch/arc/mm/fault.c| 10 -- > 2 files changed, 8 insertions(+), 3 deletions(-) Have you tested it with CONFIG_HIGHMEM=y? alloc_kmap_pgtable() has to be converted too. -- Kirill A. Shutemov
Re: [PATCH 4.19 002/106] tpm: Fix TPM 1.2 Shutdown sequence to prevent future TPM operations
> > --- a/drivers/char/tpm/tpm-chip.c
> > +++ b/drivers/char/tpm/tpm-chip.c
> > @@ -187,12 +187,13 @@ static int tpm_class_shutdown(struct device *dev)
> > {
> > struct tpm_chip *chip = container_of(dev, struct tpm_chip, dev);
> >
> > + down_write(>ops_sem);
> > if (chip->flags & TPM_CHIP_FLAG_TPM2) {
> > - down_write(>ops_sem);
> > tpm2_shutdown(chip, TPM2_SU_CLEAR);
> > chip->ops = NULL;
> > - up_write(>ops_sem);
> > }
> > + chip->ops = NULL;
> > + up_write(>ops_sem);
> >
> > return 0;
> > }
>
> Still can be improved -- chip->ops = NULL; is done twice, copy inside
> the if {} is redundant...
Thanks. I can update this.
/Jarkko
RE: [BUGFIX PATCH] selftests: Use real temporary working directory for archiving
> -Original Message-
> From: Masami Hiramatsu on Thursday, October 03, 2019 7:13 PM
>
> Use real temporary working directory for generating kselftest
> archive.
>
> tools/testing/selftests/kselftest directory has been used for
> the temporary working directory for making a tar archive from
> gen_kselftest_tar.sh, and it removes the directory for cleanup.
>
> However, since the kselftest directory became a part of the
> repository, it must not be used as a working dir.
I'm not objecting to the test, but I would like to understand this
point better. Under normal circumstances (i.e. when not using O= or
KBUILD_OUTPUT)
the rest of the kernel directory structure holds generated files.
What is the issue with using kselftest to hold generated files?
-- Tim
>
> Introduce mktemp to prepare a temporary working directory
> for archiving kselftests.
>
> Signed-off-by: Masami Hiramatsu
> ---
> tools/testing/selftests/gen_kselftest_tar.sh |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/testing/selftests/gen_kselftest_tar.sh
> b/tools/testing/selftests/gen_kselftest_tar.sh
> index a27e2eec3586..eba1e9987ffc 100755
> --- a/tools/testing/selftests/gen_kselftest_tar.sh
> +++ b/tools/testing/selftests/gen_kselftest_tar.sh
> @@ -38,16 +38,16 @@ main()
> esac
> fi
>
> - install_dir=./kselftest
> + tmpdir=`mktemp -d ./install-XX` || exit 1
>
> # Run install using INSTALL_KSFT_PATH override to generate install
> # directory
> -./kselftest_install.sh
> -tar $copts kselftest${ext} $install_dir
> +./kselftest_install.sh $tmpdir
> +tar $copts kselftest${ext} -C $tmpdir kselftest
> echo "Kselftest archive kselftest${ext} created!"
>
> # clean up install directory
> -rm -rf kselftest
> +rm -rf $tmpdir
> }
>
> main "$@"
Re: [PATCH] riscv: Fix memblock reservation for device tree blob
On Tue, 08 Oct 2019 16:31:17 PDT (-0700), a...@eecs.berkeley.edu wrote:
On 2019-10-08 15:38:15 -0700, Palmer Dabbelt wrote:
On Fri, 20 Sep 2019 21:34:57 PDT (-0700), a...@brainfault.org wrote:
> On Sat, Sep 21, 2019 at 6:30 AM Albert Ou wrote:
>>
>> This fixes an error with how the FDT blob is reserved in memblock.
>> An incorrect physical address calculation exposed the FDT header to
>> unintended corruption, which typically manifested with of_fdt_raw_init()
>> faulting during late boot after fdt_totalsize() returned a wrong value.
>> Systems with smaller physical memory sizes more frequently trigger this
>> issue, as the kernel is more likely to allocate from the DMA32 zone
>> where bbl places the DTB after the kernel image.
>>
>> Commit 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
>> changed the mapping of the DTB to reside in the fixmap area.
>> Consequently, early_init_fdt_reserve_self() cannot be used anymore in
>> setup_bootmem() since it relies on __pa() to derive a physical address,
>> which does not work with dtb_early_va that is no longer a valid kernel
>> logical address.
>>
>> The reserved[0x1] region shows the effect of the pointer underflow
>> resulting from the __pa(initial_boot_params) offset subtraction:
>>
>> [0.00] MEMBLOCK configuration:
>> [0.00] memory size = 0x1fe0 reserved size =
0x00a2e514
>> [0.00] memory.cnt = 0x1
>> [0.00] memory[0x0] [0x8020-0x9fff],
0x1fe0 bytes flags: 0x0
>> [0.00] reserved.cnt = 0x2
>> [0.00] reserved[0x0] [0x8020-0x80c2dfeb],
0x00a2dfec bytes flags: 0x0
>> [0.00] reserved[0x1] [0xfff08010-0xfff080100527],
0x0528 bytes flags: 0x0
>>
>> With the fix applied:
>>
>> [0.00] MEMBLOCK configuration:
>> [0.00] memory size = 0x1fe0 reserved size =
0x00a2e514
>> [0.00] memory.cnt = 0x1
>> [0.00] memory[0x0] [0x8020-0x9fff],
0x1fe0 bytes flags: 0x0
>> [0.00] reserved.cnt = 0x2
>> [0.00] reserved[0x0] [0x8020-0x80c2dfeb],
0x00a2dfec bytes flags: 0x0
>> [0.00] reserved[0x1] [0x80e0-0x80e00527],
0x0528 bytes flags: 0x0
>
> Thanks for catching this issue.
>
> Most of us did not notice this issue most likely because:
> 1. We generally have good enough RAM on QEMU and SiFive Unleashed
> 2. Most of people use OpenSBI FW_JUMP on QEMU and U-Boot on
> SiFive Unleashed to boot in Linux which places FDT quite far away
> from Linux kernel end
>
> Linux ARM64 kernel also uses FIXMAP to access FDT and over there
> as well early_init_fdt_reserve_self() is not used.
>
>>
>> Fixes: 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
>> Signed-off-by: Albert Ou
>> ---
>> arch/riscv/mm/init.c | 13 -
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
>> index f0ba713..52d007c 100644
>> --- a/arch/riscv/mm/init.c
>> +++ b/arch/riscv/mm/init.c
>> @@ -11,6 +11,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -82,6 +83,8 @@ static void __init setup_initrd(void)
>> }
>> #endif /* CONFIG_BLK_DEV_INITRD */
>>
>> +static phys_addr_t __dtb_pa __initdata;
>
> May be dtb_early_pa will be more consistent name
> instead of __dtb_pa because it matches dtb_early_va
> used below.
>
>> +
>> void __init setup_bootmem(void)
>> {
>> struct memblock_region *reg;
>> @@ -117,7 +120,12 @@ void __init setup_bootmem(void)
>> setup_initrd();
>> #endif /* CONFIG_BLK_DEV_INITRD */
>>
>> - early_init_fdt_reserve_self();
>> + /*
>> +* Avoid using early_init_fdt_reserve_self() since __pa() does
>> +* not work for DTB pointers that are fixmap addresses
>> +*/
>> + memblock_reserve(__dtb_pa, fdt_totalsize(dtb_early_va));
>> +
>> early_init_fdt_scan_reserved_mem();
>> memblock_allow_resize();
>> memblock_dump_all();
>> @@ -333,6 +341,7 @@ static uintptr_t __init best_map_size(phys_addr_t base,
phys_addr_t size)
>> "not use absolute addressing."
>> #endif
>>
>> +
>
> Please remove this newline addition.
>
>> asmlinkage void __init setup_vm(uintptr_t dtb_pa)
>> {
>> uintptr_t va, end_va;
>> @@ -393,6 +402,8 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
>>
>> /* Save pointer to DTB for early FDT parsing */
>> dtb_early_va = (void *)fix_to_virt(FIX_FDT) + (dtb_pa & ~PAGE_MASK);
>> + /* Save physical address for memblock reservation */
>> + __dtb_pa = dtb_pa;
>> }
>>
>> static void __init setup_vm_final(void)
>> --
>> 2.7.4
>>
>>
>> ___
>> linux-riscv mailing list
>> linux-ri...@lists.infradead.org
>>
Re: [PATCH v2] arm64: lse: fix LSE atomics with LLVM's integrated assembler
On Tue, Oct 08, 2019 at 02:27:30PM -0700, Sami Tolvanen wrote:
> Unlike gcc, clang considers each inline assembly block to be independent
> and therefore, when using the integrated assembler for inline assembly,
> any preambles that enable features must be repeated in each block.
>
> This change defines __LSE_PREAMBLE and adds it to each inline assembly
> block that has LSE instructions, which allows them to be compiled also
> with clang's assembler.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/671
> Signed-off-by: Sami Tolvanen
This looks good to me. I can build and boot in a model with both Clang
(9.0.6) and GCC (7.3.1) and boot a guest without anything going bang.
Though when I build with AS=clang, e.g.
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CC=clang AS=clang Image
I get errors like this:
CC init/main.o
In file included from init/main.c:17:
In file included from ./include/linux/module.h:9:
In file included from ./include/linux/list.h:9:
In file included from ./include/linux/kernel.h:12:
In file included from ./include/linux/bitops.h:26:
In file included from ./arch/arm64/include/asm/bitops.h:26:
In file included from ./include/asm-generic/bitops/atomic.h:5:
In file included from ./include/linux/atomic.h:7:
In file included from ./arch/arm64/include/asm/atomic.h:16:
In file included from ./arch/arm64/include/asm/cmpxchg.h:14:
In file included from ./arch/arm64/include/asm/lse.h:13:
In file included from ./include/linux/jump_label.h:117:
./arch/arm64/include/asm/jump_label.h:24:20: error: expected a symbol reference
in '.long' directive
" .align 3 \n\t"
^
:4:21: note: instantiated into assembly here
.long 1b - ., "" - .
^
I'm assuming that I'm doing something wrong?
Thanks,
Andrew Murray
> ---
> v2:
> - Add a preamble to inline assembly blocks that use LSE instead
>of allowing the compiler to emit LSE instructions everywhere.
>
> ---
> arch/arm64/include/asm/atomic_lse.h | 19 +++
> arch/arm64/include/asm/lse.h| 6 +++---
> 2 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/atomic_lse.h
> b/arch/arm64/include/asm/atomic_lse.h
> index c6bd87d2915b..3ee600043042 100644
> --- a/arch/arm64/include/asm/atomic_lse.h
> +++ b/arch/arm64/include/asm/atomic_lse.h
> @@ -14,6 +14,7 @@
> static inline void __lse_atomic_##op(int i, atomic_t *v)
> \
> {\
> asm volatile( \
> + __LSE_PREAMBLE \
> "" #asm_op " %w[i], %[v]\n" \
> : [i] "+r" (i), [v] "+Q" (v->counter) \
> : "r" (v)); \
> @@ -30,6 +31,7 @@ ATOMIC_OP(add, stadd)
> static inline int __lse_atomic_fetch_##op##name(int i, atomic_t *v) \
> {\
> asm volatile( \
> + __LSE_PREAMBLE \
> "" #asm_op #mb " %w[i], %w[i], %[v]" \
> : [i] "+r" (i), [v] "+Q" (v->counter) \
> : "r" (v) \
> @@ -58,6 +60,7 @@ static inline int __lse_atomic_add_return##name(int i,
> atomic_t *v) \
> u32 tmp;\
> \
> asm volatile( \
> + __LSE_PREAMBLE \
> " ldadd" #mb "%w[i], %w[tmp], %[v]\n" \
> " add %w[i], %w[i], %w[tmp]" \
> : [i] "+r" (i), [v] "+Q" (v->counter), [tmp] "=" (tmp)\
> @@ -77,6 +80,7 @@ ATOMIC_OP_ADD_RETURN(, al, "memory")
> static inline void __lse_atomic_and(int i, atomic_t *v)
> {
> asm volatile(
> + __LSE_PREAMBLE
> " mvn %w[i], %w[i]\n"
> " stclr %w[i], %[v]"
> : [i] "+" (i), [v] "+Q" (v->counter)
> @@ -87,6 +91,7 @@ static inline void __lse_atomic_and(int i, atomic_t *v)
> static inline int __lse_atomic_fetch_and##name(int i, atomic_t *v) \
> {\
> asm volatile( \
> + __LSE_PREAMBLE \
> " mvn %w[i], %w[i]\n" \
> " ldclr" #mb "%w[i],
Re: [PATCH] riscv: Fix memblock reservation for device tree blob
On 2019-10-08 15:38:15 -0700, Palmer Dabbelt wrote:
> On Fri, 20 Sep 2019 21:34:57 PDT (-0700), a...@brainfault.org wrote:
> > On Sat, Sep 21, 2019 at 6:30 AM Albert Ou wrote:
> >>
> >> This fixes an error with how the FDT blob is reserved in memblock.
> >> An incorrect physical address calculation exposed the FDT header to
> >> unintended corruption, which typically manifested with of_fdt_raw_init()
> >> faulting during late boot after fdt_totalsize() returned a wrong value.
> >> Systems with smaller physical memory sizes more frequently trigger this
> >> issue, as the kernel is more likely to allocate from the DMA32 zone
> >> where bbl places the DTB after the kernel image.
> >>
> >> Commit 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
> >> changed the mapping of the DTB to reside in the fixmap area.
> >> Consequently, early_init_fdt_reserve_self() cannot be used anymore in
> >> setup_bootmem() since it relies on __pa() to derive a physical address,
> >> which does not work with dtb_early_va that is no longer a valid kernel
> >> logical address.
> >>
> >> The reserved[0x1] region shows the effect of the pointer underflow
> >> resulting from the __pa(initial_boot_params) offset subtraction:
> >>
> >> [0.00] MEMBLOCK configuration:
> >> [0.00] memory size = 0x1fe0 reserved size =
> >> 0x00a2e514
> >> [0.00] memory.cnt = 0x1
> >> [0.00] memory[0x0] [0x8020-0x9fff],
> >> 0x1fe0 bytes flags: 0x0
> >> [0.00] reserved.cnt = 0x2
> >> [0.00] reserved[0x0] [0x8020-0x80c2dfeb],
> >> 0x00a2dfec bytes flags: 0x0
> >> [0.00] reserved[0x1] [0xfff08010-0xfff080100527],
> >> 0x0528 bytes flags: 0x0
> >>
> >> With the fix applied:
> >>
> >> [0.00] MEMBLOCK configuration:
> >> [0.00] memory size = 0x1fe0 reserved size =
> >> 0x00a2e514
> >> [0.00] memory.cnt = 0x1
> >> [0.00] memory[0x0] [0x8020-0x9fff],
> >> 0x1fe0 bytes flags: 0x0
> >> [0.00] reserved.cnt = 0x2
> >> [0.00] reserved[0x0] [0x8020-0x80c2dfeb],
> >> 0x00a2dfec bytes flags: 0x0
> >> [0.00] reserved[0x1] [0x80e0-0x80e00527],
> >> 0x0528 bytes flags: 0x0
> >
> > Thanks for catching this issue.
> >
> > Most of us did not notice this issue most likely because:
> > 1. We generally have good enough RAM on QEMU and SiFive Unleashed
> > 2. Most of people use OpenSBI FW_JUMP on QEMU and U-Boot on
> > SiFive Unleashed to boot in Linux which places FDT quite far away
> > from Linux kernel end
> >
> > Linux ARM64 kernel also uses FIXMAP to access FDT and over there
> > as well early_init_fdt_reserve_self() is not used.
> >
> >>
> >> Fixes: 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages")
> >> Signed-off-by: Albert Ou
> >> ---
> >> arch/riscv/mm/init.c | 13 -
> >> 1 file changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> >> index f0ba713..52d007c 100644
> >> --- a/arch/riscv/mm/init.c
> >> +++ b/arch/riscv/mm/init.c
> >> @@ -11,6 +11,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include
> >> #include
> >> @@ -82,6 +83,8 @@ static void __init setup_initrd(void)
> >> }
> >> #endif /* CONFIG_BLK_DEV_INITRD */
> >>
> >> +static phys_addr_t __dtb_pa __initdata;
> >
> > May be dtb_early_pa will be more consistent name
> > instead of __dtb_pa because it matches dtb_early_va
> > used below.
> >
> >> +
> >> void __init setup_bootmem(void)
> >> {
> >> struct memblock_region *reg;
> >> @@ -117,7 +120,12 @@ void __init setup_bootmem(void)
> >> setup_initrd();
> >> #endif /* CONFIG_BLK_DEV_INITRD */
> >>
> >> - early_init_fdt_reserve_self();
> >> + /*
> >> +* Avoid using early_init_fdt_reserve_self() since __pa() does
> >> +* not work for DTB pointers that are fixmap addresses
> >> +*/
> >> + memblock_reserve(__dtb_pa, fdt_totalsize(dtb_early_va));
> >> +
> >> early_init_fdt_scan_reserved_mem();
> >> memblock_allow_resize();
> >> memblock_dump_all();
> >> @@ -333,6 +341,7 @@ static uintptr_t __init best_map_size(phys_addr_t
> >> base, phys_addr_t size)
> >> "not use absolute addressing."
> >> #endif
> >>
> >> +
> >
> > Please remove this newline addition.
> >
> >> asmlinkage void __init setup_vm(uintptr_t dtb_pa)
> >> {
> >> uintptr_t va, end_va;
> >> @@ -393,6 +402,8 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
> >>
> >> /* Save pointer to DTB for early FDT parsing */
> >> dtb_early_va = (void *)fix_to_virt(FIX_FDT) + (dtb_pa &
> >> ~PAGE_MASK);
> >> + /* Save physical address for memblock reservation */
> >> +
Re: [PATCH] lib/list-test: add a test for the 'list' doubly linked list
On Mon, Oct 7, 2019 at 6:03 PM Kees Cook wrote:
(...)
> > +
> > +static void list_init_test(struct kunit *test)
> > +{
> > + /* Test the different ways of initialising a list. */
> > + struct list_head list1 = LIST_HEAD_INIT(list1);
> > + struct list_head list2;
> > + LIST_HEAD(list3);
> > +
> > + INIT_LIST_HEAD();
>
> Can you also add different storage locations and initial contents tests?
> For example:
>
> struct list_head *list4;
> struct list_head *list5;
>
> list4 = kzalloc(sizeof(*list4));
> INIT_LIST_HEAD(list4);
>
> list5 = kmalloc(sizeof(*list5));
> memset(list4, 0xff, sizeof(*list5));
> INIT_LIST_HEAD(list5);
>
>
> KUNIT_EXPECT_TRUE(test, list_empty_careful());
> KUNIT_EXPECT_TRUE(test, list_empty_careful());
>
> kfree(list4);
> kfree(list5);
>
> Then we know it's not an accident that INIT_LIST_HEAD() works when both
> all-zeros and all-0xFF initial contents are there. :)
Will do.
> > +static void list_entry_test(struct kunit *test)
> > +{
> > + struct list_test_struct test_struct;
>
> I guess this is not a missing initialization here because this is just
> testing the container_of() wrapper macro?
>
Yeah: we shouldn't be doing any memory accesses here, just the pointer
manipulation, so it shouldn't matter.
I can add a comment pointing this out, or just initialise it anyway.
> > +
> > + KUNIT_EXPECT_PTR_EQ(test, _struct,
> > list_entry(&(test_struct.list), struct list_test_struct, list));
> > +}
> > +
> > +static void list_first_entry_test(struct kunit *test)
> > +{
> > + struct list_test_struct test_struct1, test_struct2;
> > + static LIST_HEAD(list);
>
> This is this static?
>
Oops, this doesn't need to be static. I'll fix this (and the others)
for the next version.
> > +static void list_for_each_test(struct kunit *test)
> > +{
> > + struct list_head entries[3], *cur;
> > + LIST_HEAD(list);
> > + int i = 0;
> > +
> > + list_add_tail([0], );
> > + list_add_tail([1], );
> > + list_add_tail([2], );
> > +
> > + list_for_each(cur, ) {
> > + KUNIT_EXPECT_PTR_EQ(test, cur, [i]);
> > + i++;
> > + }
> > +
> > + KUNIT_EXPECT_EQ(test, i, 3);
> > +}
> > +
> > +static void list_for_each_prev_test(struct kunit *test)
> > +{
> > + struct list_head entries[3], *cur;
> > + LIST_HEAD(list);
> > + int i = 2;
> > +
> > + list_add_tail([0], );
> > + list_add_tail([1], );
> > + list_add_tail([2], );
> > +
> > + list_for_each_prev(cur, ) {
> > + KUNIT_EXPECT_PTR_EQ(test, cur, [i]);
> > + i--;
> > + }
> > +
> > + KUNIT_EXPECT_EQ(test, i, -1);
>
> Both of these tests test that the list contained the correct number of
> entries, not that anything about ordering was established. I would load
> values into these with the list_test_struct and test that the counting
> matches the expected ordering.
>
These tests do check the order of the entries (the order of the list
should match the order of the entries array, and KUNIT_EXPECT_PTR_EQ()
is verifying that the entries[i] is correct).
It would be possible to actually use list_test_struct like with the
list_for_each_entry tests, but since list_for_each just returns the
list_head, it didn't seem useful, so long as the list_head pointers
match.
> > +}
> > +
> > +static void list_for_each_safe_test(struct kunit *test)
> > +{
> > + struct list_head entries[3], *cur, *n;
> > + LIST_HEAD(list);
> > + int i = 0;
> > +
> > +
> > + list_add_tail([0], );
> > + list_add_tail([1], );
> > + list_add_tail([2], );
> > +
> > + list_for_each_safe(cur, n, ) {
> > + KUNIT_EXPECT_PTR_EQ(test, cur, [i]);
> > + list_del([i]);
> > + i++;
> > + }
> > +
> > + KUNIT_EXPECT_EQ(test, i, 3);
>
> I would expect an is_empty() test here too.
>
Will do.
> > +}
> > +
> > +static void list_for_each_prev_safe_test(struct kunit *test)
> > +{
> > + struct list_head entries[3], *cur, *n;
> > + LIST_HEAD(list);
> > + int i = 2;
> > +
> > + list_add_tail([0], );
> > + list_add_tail([1], );
> > + list_add_tail([2], );
> > +
> > + list_for_each_prev_safe(cur, n, ) {
> > + KUNIT_EXPECT_PTR_EQ(test, cur, [i]);
> > + list_del([i]);
> > + i--;
> > + }
>
> Same thing here.
>
Will do.
> > +static void list_for_each_entry_test(struct kunit *test)
> > +{
> > + struct list_test_struct entries[5], *cur;
> > + static LIST_HEAD(list);
> > + int i = 0;
> > +
> > + for (i = 0; i < 5; ++i) {
> > + entries[i].data = i;
> > + list_add_tail([i].list, );
> > + }
> > +
> > + i = 0;
> > +
> > + list_for_each_entry(cur, , list) {
> > + KUNIT_EXPECT_EQ(test, cur->data, i);
> > + i++;
> > + }
> > +}
> > +
> > +static void list_for_each_entry_reverse_test(struct kunit
[PATCH] cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown
From: Rafael J. Wysocki
It is incorrect to set the cpufreq syscore shutdown callback pointer
to cpufreq_suspend(), because that function cannot be run in the
syscore stage of system shutdown for two reasons: (a) it may attempt
to carry out actions depending on devices that have already been shut
down at that point and (b) the RCU synchronization carried out by it
may not be able to make progress then.
The latter issue has been present since commit 45975c7d21a1 ("rcu:
Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds"),
but the former one has always been there regardless.
Fix that by dropping cpufreq_syscore_ops altogether and making
device_shutdown() call cpufreq_suspend() directly before shutting
down devices, which is along the lines of what system-wide power
management does.
Fixes: 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU
PREEMPT builds")
Reported-by: Ville Syrjälä
Tested-by: Ville Syrjälä
Signed-off-by: Rafael J. Wysocki
---
drivers/base/core.c |3 +++
drivers/cpufreq/cpufreq.c | 10 --
2 files changed, 3 insertions(+), 10 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -2737,14 +2737,6 @@ int cpufreq_unregister_driver(struct cpu
}
EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
-/*
- * Stop cpufreq at shutdown to make sure it isn't holding any locks
- * or mutexes when secondary CPUs are halted.
- */
-static struct syscore_ops cpufreq_syscore_ops = {
- .shutdown = cpufreq_suspend,
-};
-
struct kobject *cpufreq_global_kobject;
EXPORT_SYMBOL(cpufreq_global_kobject);
@@ -2756,8 +2748,6 @@ static int __init cpufreq_core_init(void
cpufreq_global_kobject = kobject_create_and_add("cpufreq",
_subsys.dev_root->kobj);
BUG_ON(!cpufreq_global_kobject);
- register_syscore_ops(_syscore_ops);
-
return 0;
}
module_param(off, int, 0444);
Index: linux-pm/drivers/base/core.c
===
--- linux-pm.orig/drivers/base/core.c
+++ linux-pm/drivers/base/core.c
@@ -9,6 +9,7 @@
*/
#include
+#include
#include
#include
#include
@@ -3179,6 +3180,8 @@ void device_shutdown(void)
wait_for_device_probe();
device_block_probing();
+ cpufreq_suspend();
+
spin_lock(_kset->list_lock);
/*
* Walk the devices list backward, shutting down each in turn.
Re: [PATCH] tpm: add check after commands attribs tab allocation
On Mon, Oct 07, 2019 at 02:46:37PM -0700, Tadeusz Struk wrote:
> devm_kcalloc() can fail and return NULL so we need to check for that.
>
> Fixes: 58472f5cd4f6f ("tpm: validate TPM 2.0 commands")
> Signed-off-by: Tadeusz Struk
Thank you.
Cc: sta...@vger.kernel.org
Reviewed-by: Jarkko Sakkinen
/Jarkko
Re: [PATCH v4 0/2] mm/memory-failure: Poison read receives SIGKILL instead of SIGBUS issue
Hi Jane, I think that this patchset is good enough and ready to be merged. Andrew, could you consider queuing this series into your tree? Thanks, Naoya Horiguchi On Tue, Oct 08, 2019 at 11:13:23AM -0700, Jane Chu wrote: > Hi, Naoya, > > What is the status of the patches? > Is there anything I need to do from my end ? > > Regards, > -jane > > On 8/6/2019 10:25 AM, Jane Chu wrote: > > Change in v4: > > - remove trailing white space > > > > Changes in v3: > > - move **tk cleanup to its own patch > > > > Changes in v2: > > - move 'tk' allocations internal to add_to_kill(), suggested by Dan; > > - ran checkpatch.pl check, pointed out by Matthew; > > - Noaya pointed out that v1 would have missed the SIGKILL > > if "tk->addr == -EFAULT", since the code returns early. > > Incorporated Noaya's suggestion, also, skip VMAs where > > "tk->size_shift == 0" for zone device page, and deliver SIGBUS > > when "tk->size_shift != 0" so the payload is helpful; > > - added Suggested-by: Naoya Horiguchi > > > > Jane Chu (2): > >mm/memory-failure.c clean up around tk pre-allocation > >mm/memory-failure: Poison read receives SIGKILL instead of SIGBUS if > > mmaped more than once > > > > mm/memory-failure.c | 62 > > ++--- > > 1 file changed, 26 insertions(+), 36 deletions(-) > > >
Re: [RFC/RFT][PATCH v8] cpuidle: New timer events oriented governor for tickless systems
On Tuesday, October 8, 2019 12:49:01 PM CEST Rafael J. Wysocki wrote:
> On Tue, Oct 8, 2019 at 11:51 AM Rafael J. Wysocki wrote:
> >
> > On Tue, Oct 8, 2019 at 8:20 AM Doug Smythies wrote:
> > >
> > > On 2019.10.06 08:34 Rafael J. Wysocki wrote:
> > > > On Sun, Oct 6, 2019 at 4:46 PM Doug Smythies
> > > > wrote:
> > > >> On 2019.10.01 02:32 Rafael J. Wysocki wrote:
> > > >>> On Sun, Sep 29, 2019 at 6:05 PM Doug Smythies
> > > >>> wrote:
> > > On 2019.09.26 09:32 Doug Smythies wrote:
> > >
> > > > If the deepest idle state is disabled, the system
> > > > can become somewhat unstable, with anywhere between no problem
> > > > at all, to the occasional temporary jump using a lot more
> > > > power for a few seconds, to a permanent jump using a lot more
> > > > power continuously. I have been unable to isolate the exact
> > > > test load conditions under which this will occur. However,
> > > > temporarily disabling and then enabling other idle states
> > > > seems to make for a somewhat repeatable test. It is important
> > > > to note that the issue occurs with only ever disabling the deepest
> > > > idle state, just not reliably.
> > > >
> > > > I want to know how you want to proceed before I do a bunch of
> > > > regression testing.
> > >
> > > >> I do not think I stated it clearly before: The problem here is that
> > > >> some CPUs
> > > >> seem to get stuck in idle state 0, and when they do power consumption
> > > >> spikes,
> > > >> often by several hundred % and often indefinitely.
> > > >
> > > > That indeed has not been clear to me, thanks for the clarification!
> > >
> > > >
> > > >> I made a hack job automated test:
> > > >> Kernel tests fail rate
> > > >> 5.4-rc16616 13.45%
> > > >> 5.3 23764.50%
> > > >> 5.3-teov7 121360.00% <<< teo.c reverted and teov7
> > > >> put in its place.
> > > >> 5.4-rc1-ds 111680.00% <<< [old] proposed patch (> 7
> > > >> hours test time)
> > >
> > >
> > >5.4-rc1-ds12 4224 0.005 <<< new proposed patch
> > >
> > > >>
> > > >> [old] Proposed patch (on top of kernel 5.4-rc1): [deleted]
> > >
> > > > This change may cause the deepest state to be selected even if its
> > > > "hits" metric is less than the "misses" one AFAICS, in which case the
> > > > max_early_index state should be selected instead.
> > > >
> > > > It looks like the max_early_index computation is broken when the
> > > > deepest state is disabled.
> > >
> > > O.K. Thanks for your quick reply, and insight.
> > >
> > > I think long durations always need to be counted, but currently if
> > > the deepest idle state is disabled, they are not.
> > > How about this?:
> > > (test results added above, more tests pending if this might be a path
> > > forward.)
> > >
> > > diff --git a/drivers/cpuidle/governors/teo.c
> > > b/drivers/cpuidle/governors/teo.c
> > > index b5a0e49..a970d2c 100644
> > > --- a/drivers/cpuidle/governors/teo.c
> > > +++ b/drivers/cpuidle/governors/teo.c
> > > @@ -155,10 +155,12 @@ static void teo_update(struct cpuidle_driver *drv,
> > > struct cpuidle_device *dev)
> > >
> > > cpu_data->states[i].early_hits -= early_hits >>
> > > DECAY_SHIFT;
> > >
> > > - if (drv->states[i].target_residency <= sleep_length_us) {
> > > - idx_timer = i;
> > > - if (drv->states[i].target_residency <=
> > > measured_us)
> > > - idx_hit = i;
> > > + if (!(drv->states[i].disabled ||
> > > dev->states_usage[i].disable)){
> > > + if (drv->states[i].target_residency <=
> > > sleep_length_us) {
> > > + idx_timer = i;
> > > + if (drv->states[i].target_residency <=
> > > measured_us)
> > > + idx_hit = i;
> > > + }
> >
> > What if the state is enabled again after some time?
>
> Actually, the states are treated as "bins" here, so for the metrics it
> doesn't matter whether or not they are enabled at the moment.
>
> > > }
> > > }
> > >
> > > @@ -256,39 +258,25 @@ static int teo_select(struct cpuidle_driver *drv,
> > > struct cpuidle_device *dev,
> > > struct cpuidle_state *s = >states[i];
> > > struct cpuidle_state_usage *su = >states_usage[i];
> > >
> > > - if (s->disabled || su->disable) {
> > > - /*
> > > -* If the "early hits" metric of a disabled state
> > > is
> > > -* greater than the current maximum, it should be
> > > taken
> > > -* into account, because it would be a mistake to
> > > select
> > > -* a deeper state with lower "early hits" metric.
> > > The
> > > -
