Re: Linux 4.18-rc7
On Mon, 30 Jul 2018 at 03:39, Linus Torvalds
wrote:
>
> So unless something odd happens, this should be the last rc for 4.18.
>
> Nothing particularly odd happened this last week - we got the usual
> random set of various minor fixes all over. About two thirds of it is
> drivers - networking, staging and usb stands out, but there's a little
> bit of stuff all over (clk, block, gpu, nvme..).
>
> Outside of drivers, the bulk is some core networking stuff, with
> random changes elsewhere (minor arch updates, filesystems, core
> kernel, test scripts).
>
> The appended shortlog gives a flavor of the details.
>
> Linus
>
> ---
> Kirill A. Shutemov (3):
> mm: introduce vma_init()
> mm: use vma_init() to initialize VMAs on stack and data segments
> mm: fix vma_is_anonymous() false-positives
Hi, I have run into AOSP userspace crash with v4.18-rc7, leading to
above mm patches. bfd40eaff5ab ("mm: fix vma_is_anonymous()
false-positives") to be specific. The same userspace is working fine
with v4.18-rc6.
I didn't yet look into what is going wrong from userspace point of
view, but I just wanted to give you a heads up on this. I'll be happy
to assist in further debugging/diagnosis if required.
Here is the crash log from logcat, if it helps:
F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG : Build fingerprint:
'Android/db410c32_only/db410c32_only:Q/OC-MR1/102:userdebug/test-key
F DEBUG : Revision: '0'
F DEBUG : ABI: 'arm'
F DEBUG : pid: 2261, tid: 2261, name: zygote >>> zygote <<<
F DEBUG : signal 7 (SIGBUS), code 2 (BUS_ADRERR), fault addr 0xec8
.. ..
F DEBUG : backtrace:
F DEBUG : #00 pc 1c04 /system/lib/libc.so (memset+48)
F DEBUG : #01 pc 0010c513 /system/lib/libart.so
(create_mspace_with_base+82)
F DEBUG : #02 pc 0015c601 /system/lib/libart.so
(art::gc::space::DlMallocSpace::CreateMspace(void*, unsigned int,
unsigned int)+40)
F DEBUG : #03 pc 0015c3ed /system/lib/libart.so
(art::gc::space::DlMallocSpace::CreateFromMemMap(art::MemMap*,
std::__1::basic_string, std::__1::allocator> const&, unsigned int,
unsigned int, unsigned int, unsigned int, bool)+36)
F DEBUG : #04 pc 0013c9ab /system/lib/libart.so
(art::gc::Heap::Heap(unsigned int, unsigned int, unsigned int,
unsigned int, double, double, unsigned int, unsigned int,
std::__1::basic_string,
std::__1::allocator> const&, art::InstructionSet,
art::gc::CollectorType, art::gc::CollectorType,
art::gc::space::LargeObjectSpaceType, unsigned int, unsigned int,
unsigned int, bool, unsigned int, unsigned int, bool, bool, bool,
bool, bool, bool, bool, bool, bool, bool, bool, unsigned long
long)+1674)
DEBUG : #05 pc 00318201 /system/lib/libart.so
(art::Runtime::Init(art::RuntimeArgumentMap&&)+7036)
DEBUG : #06 pc 0031af19 /system/lib/libart.so
(art::Runtime::Create(std::__1::vector, std::__1::allocator>, void const*>,
std::__1::allocator, std::__1::allocator>, void
const*>>> const&, bool)+68)
F DEBUG : #07 pc 0023c353 /system/lib/libart.so (JNI_CreateJavaVM+658)
F DEBUG : #08 pc 205f /system/lib/libandroid_runtime.so
(android::AndroidRuntime::startVm(_JavaVM**, _JNIEnv**, bool)+5038)
F DEBUG : #09 pc 2381 /system/lib/libandroid_runtime.so
(android::AndroidRuntime::start(char const*,
android::Vector const&, bool)+196)
F DEBUG : #10 pc 046b /system/bin/app_process32 (main+702)
Regards,
Amit Pundir
Re: Linux 4.18-rc7
On Mon, 30 Jul 2018 at 18:31, Kirill A. Shutemov wrote:
>
> On Mon, Jul 30, 2018 at 12:17:46PM +0530, Amit Pundir wrote:
> > On Mon, 30 Jul 2018 at 03:39, Linus Torvalds
> > wrote:
> > >
> > > So unless something odd happens, this should be the last rc for 4.18.
> > >
> > > Nothing particularly odd happened this last week - we got the usual
> > > random set of various minor fixes all over. About two thirds of it is
> > > drivers - networking, staging and usb stands out, but there's a little
> > > bit of stuff all over (clk, block, gpu, nvme..).
> > >
> > > Outside of drivers, the bulk is some core networking stuff, with
> > > random changes elsewhere (minor arch updates, filesystems, core
> > > kernel, test scripts).
> > >
> > > The appended shortlog gives a flavor of the details.
> > >
> > > Linus
> > >
> > > ---
> > > Kirill A. Shutemov (3):
> > > mm: introduce vma_init()
> > > mm: use vma_init() to initialize VMAs on stack and data segments
> > > mm: fix vma_is_anonymous() false-positives
> >
> > Hi, I have run into AOSP userspace crash with v4.18-rc7, leading to
> > above mm patches. bfd40eaff5ab ("mm: fix vma_is_anonymous()
> > false-positives") to be specific. The same userspace is working fine
> > with v4.18-rc6.
> >
> > I didn't yet look into what is going wrong from userspace point of
> > view, but I just wanted to give you a heads up on this. I'll be happy
> > to assist in further debugging/diagnosis if required.
>
> Youling reported basically the same bug with zygote crashing, but on
> x86-64.
>
> I think I missed vma_set_anonymous() somewhere, but I fail to see where.
>
> Could you check if removing 'vma->vm_ops = &dummy_vm_ops;" from vma_init
> makes the problem go away?
Yes removing 'vma->vm_ops = &dummy_vm_ops;" from vma_init() works.
Crash is gone with that change.
>
> Any chance the code that crashes can be run under strace?
Running strace on zygote is going to be a pain. I can check logcat
again and see if any other relatively less complex process is crashing
with similar backtrace and try to run that with strace if that is
still required.
Regards,
Amit Pundir
>
> > Here is the crash log from logcat, if it helps:
> > F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
> > F DEBUG : Build fingerprint:
> > 'Android/db410c32_only/db410c32_only:Q/OC-MR1/102:userdebug/test-key
> > F DEBUG : Revision: '0'
> > F DEBUG : ABI: 'arm'
> > F DEBUG : pid: 2261, tid: 2261, name: zygote >>> zygote <<<
> > F DEBUG : signal 7 (SIGBUS), code 2 (BUS_ADRERR), fault addr 0xec8
> > .. ..
> > F DEBUG : backtrace:
> > F DEBUG : #00 pc 1c04 /system/lib/libc.so (memset+48)
> > F DEBUG : #01 pc 0010c513 /system/lib/libart.so
> > (create_mspace_with_base+82)
> > F DEBUG : #02 pc 0015c601 /system/lib/libart.so
> > (art::gc::space::DlMallocSpace::CreateMspace(void*, unsigned int,
> > unsigned int)+40)
> > F DEBUG : #03 pc 0015c3ed /system/lib/libart.so
> > (art::gc::space::DlMallocSpace::CreateFromMemMap(art::MemMap*,
> > std::__1::basic_string > 1::char_traits, std::__1::allocator> const&, unsigned int,
> > unsigned int, unsigned int, unsigned int, bool)+36)
> > F DEBUG : #04 pc 0013c9ab /system/lib/libart.so
> > (art::gc::Heap::Heap(unsigned int, unsigned int, unsigned int,
> > unsigned int, double, double, unsigned int, unsigned int,
> > std::__1::basic_string,
> > std::__1::allocator> const&, art::InstructionSet,
> > art::gc::CollectorType, art::gc::CollectorType,
> > art::gc::space::LargeObjectSpaceType, unsigned int, unsigned int,
> > unsigned int, bool, unsigned int, unsigned int, bool, bool, bool,
> > bool, bool, bool, bool, bool, bool, bool, bool, unsigned long
> > long)+1674)
> > DEBUG : #05 pc 00318201 /system/lib/libart.so
> > (art::Runtime::Init(art::RuntimeArgumentMap&&)+7036)
> > DEBUG : #06 pc 0031af19 /system/lib/libart.so
> > (art::Runtime::Create(std::__1::vector > std::__1::char_traits, std::__1::allocator>, void const*>,
> > std::__1::allocator > std::__1::char_traits, std::__1::allocator>, void
> > const*>>> const&, bool)+68)
> > F DEBUG : #07 pc 0023c353 /system/lib/libart.so
> > (JNI_CreateJavaVM+658)
> > F DEBUG : #08 pc 205f /system/lib/libandroid_runtime.so
> > (android::AndroidRuntime::startVm(_JavaVM**, _JNIEnv**, bool)+5038)
> > F DEBUG : #09 pc 2381 /system/lib/libandroid_runtime.so
> > (android::AndroidRuntime::start(char const*,
> > android::Vector const&, bool)+196)
> > F DEBUG : #10 pc 046b /system/bin/app_process32 (main+702)
> >
> > Regards,
> > Amit Pundir
> >
>
> --
> Kirill A. Shutemov
Re: Linux 4.18-rc7
On Tue, 31 Jul 2018 at 09:55, John Stultz wrote: > > On Mon, Jul 30, 2018 at 8:26 PM, Hugh Dickins wrote: > > On Mon, 30 Jul 2018, Linus Torvalds wrote: > >> On Mon, Jul 30, 2018 at 2:53 PM Hugh Dickins wrote: > >> > > >> > I have no problem with reverting -rc7's vma_is_anonymous() series. > >> > >> I don't think we need to revert the whole series: I think the rest are > >> all fairly obvious cleanups, and shouldn't really have any semantic > >> changes. > > > > Okay. > > > >> > >> It's literally only that last patch in the series that then changes > >> that meaning of "vm_ops". And I don't really _mind_ that last step > >> either, but since we don't know exactly what it was that it broke, and > >> we're past rc7, I don't think we really have any option but the revert > >> it. > > > > It took me a long time to grasp what was happening, that that last > > patch bfd40eaff5ab was fixing. Not quite explained in the commit. > > > > I think it was that by mistakenly passing the vma_is_anonymous() test, > > create_huge_pmd() gave the MAP_PRIVATE kcov mapping a THP (instead of > > COWing pages from kcov); which the truncate then had to split, and in > > going to do so, again hit the mistaken vma_is_anonymous() test, BUG. > > > >> > >> And if we revert it, I think we need to just remove the > >> VM_BUG_ON_VMA() that it was supposed to fix. Because I do think that > >> it is quite likely that the real bug is that overzealous BUG_ON(), > >> since I can't see any reason why anonymous mappings should be special > >> there. > > > > Yes, that probably has to go: but it's not clear what state it leaves > > us in, with an anon THP being split by a truncate, without the expected > > locking; I don't remember offhand, probably a subtler bug than that BUG, > > which you may or may not consider an improvement. > > > > I fear that Kirill has not missed inserting a vma_set_anonymous() from > > somewhere that it should be, but rather that zygote is working with some > > special mapping which used to satisfy vma_is_anonymous(), faults supplying > > backing pages, but now comes out as !vma_is_anonymous(), so do_fault() > > finds !dummy_vm_ops.fault hence SIGBUS. > > I've been only casually following this thread (mostly just glad Amit > caught it and I could avoid having to bisect the issue in my own > Android testing), but this bit starting to shake a few old cobwebs > loose in my brain. > > I'm wondering if Zygote is utilizing ashmem here, and we're somehow > traversing ashmem purged memory, or due to some setup issue the > initial traverse isn't being zero-filled as expected? > > ashmem ranges are created using: shmem_file_setup() and shmem_zero_setup() > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n377 > > > If we purge pages, it punches it out with: > vfs_fallocate(range->asma->file, > FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, > start, end - start); > here: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n447 > > But in ashmem_pin(), we don't do anything other then returning if we > purged any page in the range. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n577 > > And I believe the future assumption is the if we traverse those pages > they will be zero filled (if purged or even during the initial > traversal after mmap) > > Its been a long time, and I've not looked at the code in question but > it sounds from Hugh's comments above that we might instead get a > SIGBUS here. > > Looking more at the problematic patch.. > Amit: Does adding something like (whitespace damaged, apologies): > > index a1a0025..1af6915 100644 > --- a/drivers/staging/android/ashmem.c > +++ b/drivers/staging/android/ashmem.c > @@ -402,7 +402,8 @@ static int ashmem_mmap(struct file *file, struct > vm_area_struct *vma) > fput(asma->file); > goto out; > } > - } > + } else > + vma_set_anonymous(vma); > > if (vma->vm_file) > fput(vma->vm_file); > This ashmem change ^^ worked too. Regards, Amit Pundir > > Seem to resolve it? (Sorry, I'd test it myself, but I'm away from my > desk for the night). > thanks > -john
Re: Linux 4.18-rc7
On Wed, 1 Aug 2018 at 22:45, Linus Torvalds
wrote:
>
> I'd like to get this sorted out asap, although at this point I still
> think that I'll have to do an rc8 even though I feel like we may have
> caught everything.
No AOSP regressions in my limited smoke testing so far with
current HEAD: 6b4703768268 ("Merge branch 'fixes' of
git://git.armlinux.org.uk/~rmk/linux-arm"). Thanks.
Regards,
Amit Pundir
[PATCH] usb: f_fs: Prevent gadget unbind if it is already unbound
From: Hemant Kumar Upon usb composition switch there is possibility of ep0 file release happening after gadget driver bind. In case of composition switch from adb to a non-adb composition gadget will never gets bound again resulting into failure of usb device enumeration. Fix this issue by checking FFS_FL_BOUND flag and avoid extra gadget driver unbind if it is already done as part of composition switch. This fixes adb reconnection error reported on Android running v4.4 and above kernel versions. Verified on Hikey running vanilla v4.15-rc7 + few out of tree Mali patches. Reviewed-at: https://android-review.googlesource.com/#/c/582632/ Cc: Felipe Balbi Cc: Greg KH Cc: Michal Nazarewicz Cc: John Stultz Cc: Dmitry Shmidt Cc: Badhri Cc: Android Kernel Team Cc: sta...@vger.kernel.org Signed-off-by: Hemant Kumar [AmitP: Cherry-picked it from android-4.14 and updated the commit log] Signed-off-by: Amit Pundir --- drivers/usb/gadget/function/f_fs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index b6cf5ab5a0a1..f9bd351637cd 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -3700,7 +3700,8 @@ static void ffs_closed(struct ffs_data *ffs) ci = opts->func_inst.group.cg_item.ci_parent->ci_parent; ffs_dev_unlock(); - unregister_gadget_item(ci); + if (test_bit(FFS_FL_BOUND, &ffs->flags)) + unregister_gadget_item(ci); return; done: ffs_dev_unlock(); -- 2.7.4
Re: [PATCH 4.14 29/45] cgroup/cpuset: remove circular dependency deadlock
On Fri, 12 Oct 2018 at 16:35, Greg Kroah-Hartman
wrote:
>
> On Thu, Oct 11, 2018 at 08:33:34PM +0100, Sudip Mukherjee wrote:
> > Hi Greg,
> >
> > On Thu, Oct 11, 2018 at 4:54 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > 4.14-stable review patch. If anyone has any objections, please let me
> > > know.
> > >
> > > --
> > >
> > > From: Prateek Sood
> > >
> > > commit aa24163b2ee5c92120e32e99b5a93143a0f4258e upstream.
> >
> > This has been already reverted in upstream.
> > bdfbbda90aeb ("Revert "cgroup/cpuset: remove circular dependency deadlock"")
> >
> > Might be better to add e8b3f8db7aad ("workqueue/hotplug: simplify
> > workqueue_offline_cpu()") instead which is mentioned in the revert
> > commit.
>
> Good point. I'm dropping this patch for now.
>
> Amit, can you test the above patch instead and figure out why you wanted
> to add a patch to the tree that ended up being reverted? :)
Sorry I goofed up here. Thank you Sudip for catching this.
I forgot to look up for the upstream followup fixes for the patches
which I submitted lately and missed out on this Revert.
msm-4.9 tree, which I'm currently looking at, didn't revert this
particular patch either. It did cherry-pick e8b3f8db7aad
("workqueue/hotplug: simplify workqueue_offline_cpu()") as well
though.
About e8b3f8db7aad ("workqueue/hotplug: simplify workqueue_offline_cpu()"):
commit e8b3f8db7aad99fcc5234fc5b89984ff6620de3d
Author: Lai Jiangshan
Date: Fri Dec 1 22:20:36 2017 +0800
workqueue/hotplug: simplify workqueue_offline_cpu()
Since the recent cpu/hotplug refactoring, workqueue_offline_cpu() is
guaranteed to run on the local cpu which is going offline.
This also fixes the following deadlock by removing work item
scheduling and flushing from CPU hotplug path.
http://lkml.kernel.org/r/1504764252-29091-1-git-send-email-prs...@codeaurora.org
This patch applies cleanly to 4.14.y and 4.9.y. But I'm confused if
this particular patch alone is good enough for these stable kernels,
since the commit message talks about some "recent cpu/hotplug
refactoring" dependency(?).
Regards,
Amit Pundir
>
> thanks,
>
> greg k-h
>
> >
> > --
> > Regards
> > Sudip
Re: [PATCH 4.9 00/71] 4.9.134-stable review
Hi,
On Tue, 16 Oct 2018 at 22:52, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.9.134 release.
> There are 71 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
..
> Paul Burton
> MIPS: VDSO: Always map near top of user memory
This patch broke stable-rc/linux-4.9.y build on kernelci
https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.133-72-gda849e5647be/,
mostly because of missing mips_gic_present() definition. It is added
in 582e2b4aecda ("MIPS: GIC: Introduce asm/mips-gic.h with accessor
functions"), which need to be backported too because it doesn't apply
cleanly on linux-4.9.y.
Regards,
Amit Pundir
>
> Jann Horn
> mm/vmstat.c: fix outdated vmstat_text
>
> Daniel Rosenberg
> ext4: Fix error code in ext4_xattr_set_entry()
>
> Amber Lin
> drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7
>
> Vitaly Kuznetsov
> x86/kvm/lapic: always disable MMIO interface in x2APIC mode
>
> Nicolas Ferre
> ARM: dts: at91: add new compatibility string for macb on sama5d3
>
> Nicolas Ferre
> net: macb: disable scatter-gather for macb on sama5d3
>
> Jongsung Kim
> stmmac: fix valid numbers of unicast filter entries
>
> Yu Zhao
> sound: enable interrupt after dma buffer initialization
>
> Dan Carpenter
> scsi: qla2xxx: Fix an endian bug in fcpcmd_is_corrupted()
>
> Laura Abbott
> scsi: iscsi: target: Don't use stack buffer for scatterlist
>
> Tony Lindgren
> mfd: omap-usb-host: Fix dts probe of children
>
> Lei Yang
> selftests: memory-hotplug: add required configs
>
> Lei Yang
> selftests/efivarfs: add required kernel configs
>
> Danny Smith
> ASoC: sigmadsp: safeload should not have lower byte limit
>
> Pierre-Louis Bossart
> ASoC: wm8804: Add ACPI support
>
>
> -
>
> Diffstat:
>
> Documentation/devicetree/bindings/net/macb.txt | 1 +
> Documentation/networking/ip-sysctl.txt | 13 +-
> Makefile | 4 +-
> arch/arm/boot/dts/sama5d3_emac.dtsi| 2 +-
> arch/mips/include/asm/processor.h | 10 +-
> arch/mips/kernel/process.c | 25 +
> arch/mips/kernel/vdso.c| 18 +-
> arch/powerpc/include/asm/book3s/64/pgtable.h | 4 +-
> arch/x86/include/asm/pgtable_types.h | 2 +-
> arch/x86/include/uapi/asm/kvm.h| 1 +
> arch/x86/kvm/lapic.c | 22 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 2 +-
> drivers/i2c/busses/i2c-scmi.c | 1 +
> drivers/mfd/omap-usb-host.c| 11 +-
> drivers/net/bonding/bond_main.c| 43 +-
> drivers/net/dsa/bcm_sf2.c | 12 +-
> drivers/net/ethernet/broadcom/bcmsysport.c | 22 +-
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 13 +-
> drivers/net/ethernet/cadence/macb.c| 8 +
> drivers/net/ethernet/hisilicon/hns/hnae.c | 2 +-
> drivers/net/ethernet/hisilicon/hns/hns_enet.c | 30 +-
> drivers/net/ethernet/marvell/mvpp2.c | 10 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic.h| 8 +-
> .../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c| 3 +-
> .../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.h| 3 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.h | 3 +-
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 12 +-
> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 +-
> drivers/net/team/team.c| 5 +
> drivers/net/usb/qmi_wwan.c | 1 +
> drivers/net/usb/smsc75xx.c | 1 +
> drivers/scsi/qla2xxx/qla_target.h | 4 +-
> drivers/target/iscsi/iscsi_target.c| 22 +-
> drivers/usb/host/xhci-hub.c| 18 +-
> drivers/video/fbdev/aty/atyfb.h| 3 +-
> drivers/video/fbdev/aty/atyfb_base.c | 7 +-
> drivers/video/fbdev/aty/mach64_ct.c| 10 +-
> fs/ext4/xattr.c| 2 +-
> include/linux/netdevice.h | 7 +
> include/linux/rhashtable.h | 4 +-
> include/linux/skbuff.h | 34 +-
> include/net/bonding.h | 7 +-
> include/net/inet_frag.h| 133 +++--
>
Re: [PATCH v3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
Hi,
On Fri, 12 Feb 2021 at 23:11, AngeloGioacchino Del Regno
wrote:
>
> Il 12/02/21 10:24, Amit Pundir ha scritto:
> > Hi,
> >
> > On Thu, 11 Feb 2021 at 00:25, AngeloGioacchino Del Regno
> > wrote:
> >>
> >> Il 10/02/21 09:18, Amit Pundir ha scritto:
> >>> From: Sumit Semwal
> >>>
> >>> Enabling the Display panel for beryllium requires DSI
> >>> labibb regulators and panel dts nodes to be added.
> >>> It is also required to keep some of the regulators as
> >>> always-on.
> >>>
> >>> Signed-off-by: Sumit Semwal
> >>> Signed-off-by: Amit Pundir
> >>> ---
> >>
> >> Hello!
> >> Your patch looks good, however, I have a few concerns...
> >>
> >>> v3: Addressed Konrad's concerns. Configured labibb regulators
> >>> explicitly based on downstream microvolt values. Display
> >>> comes up fine with default discharge-resistor-kohms and
> >>> soft-start-us properties, so didn't touch them.
> >>> Smoke tested on next-20210209.
> >>> v2: Rebased to mainline (v5.11-rc6) and fixed build warnings.
> >>>
> >>>.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 64
> >>> ++
> >>>1 file changed, 64 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> >>> b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> >>> index 86cbae63eaf7..5ac049a247e1 100644
> >>> --- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> >>> +++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> >>> @@ -157,6 +157,14 @@
> >>>regulator-initial-mode = ;
> >>>};
> >>>
> >>> + vreg_l14a_1p8: ldo14 {
> >>> + regulator-min-microvolt = <180>;
> >>> + regulator-max-microvolt = <180>;
> >>> + regulator-initial-mode = ;
> >>> + regulator-boot-on;
> >>> + regulator-always-on;
> >>> + };
> >>> +
> >>>vreg_l17a_1p3: ldo17 {
> >>>regulator-min-microvolt = <1304000>;
> >>>regulator-max-microvolt = <1304000>;
> >>> @@ -191,6 +199,7 @@
> >>>regulator-min-microvolt = <120>;
> >>>regulator-max-microvolt = <120>;
> >>>regulator-initial-mode = ;
> >>> + regulator-boot-on;
> >>>};
> >>>};
> >>>};
> >>> @@ -200,6 +209,43 @@
> >>>firmware-name = "qcom/sdm845/cdsp.mdt";
> >>>};
> >>>
> >>> +&dsi0 {
> >>> + status = "okay";
> >>> + vdda-supply = <&vreg_l26a_1p2>;
> >>> +
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> +
> >>> + panel@0 {
> >>> + compatible = "tianma,fhd-video";
> >>> + reg = <0>;
> >>> + vddi0-supply = <&vreg_l14a_1p8>;
> >>> + vddpos-supply = <&lab>;
> >>> + vddneg-supply = <&ibb>;
> >>> +
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> +
> >>> + reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
> >>> +
> >>> + port {
> >>> + tianma_nt36672a_in_0: endpoint {
> >>> + remote-endpoint = <&dsi0_out>;
> >>> + };
> >>> + };
> >>> + };
> >>> +};
> >>> +
> >>> +&dsi0_out {
> >>> + remote-endpoint = <&tianma_nt36672a_in_0>;
> >>> + data-lanes = <0 1 2 3>;
> >>> +};
> >>> +
> >>> +&dsi0_phy {
> >>> + status = "okay";
> >>> + vdds-supply = <&vreg_l1a_0p875>;
> >>> +};
> >>> +
> >>>
[PATCH v2 0/3] Few NFC fixes from android-4.14 tree
Hi, Submitting v2 of NFC fixes I picked up from android-4.14 tree[1] for review and comments. Again like to point out that I have not feature tested these patches at all. Only made small cosmetic changes to the original patches (removed Android-only tag and internal bug ID) and build tested for arm, before posting them here for review. Really appreciate any comments or feedback on how to take it forward. Changes since v1: * Dropped "NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler" patch for now. I'm yet to verify if the additional aid_len and params_len checks for buffer size are really required, and I didn't want to hold up this patch series for one patch alone. * Dropped redundant __func__ use dev_dbg() in "NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver" patch. Also drivers/nfc/fdp/ is full of __func__ parameter usage in dev_dbg(), so submitting a new patch separately to clean that up. Regards, Amit Pundir [1] https://android.googlesource.com/kernel/common/+log/android-4.14 Suren Baghdasaryan (3): NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ NFC: Fix possible memory corruption when handling SHDLC I-Frame commands NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver drivers/nfc/fdp/fdp.c | 22 +++--- drivers/nfc/fdp/i2c.c | 29 ++--- drivers/nfc/st21nfca/dep.c | 3 ++- net/nfc/hci/core.c | 10 ++ 4 files changed, 41 insertions(+), 23 deletions(-) -- 2.7.4
[PATCH v2 3/3] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver
From: Suren Baghdasaryan
Possible buffer overflow when reading next_read_size bytes into
tmp buffer after next_read_size was extracted from a previous packet.
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
---
v2:
Remove redundant __func__ from dev_dgb().
drivers/nfc/fdp/i2c.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index c4da50e..b80d1ad 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -176,6 +176,15 @@ static int fdp_nci_i2c_read(struct fdp_i2c_phy *phy,
struct sk_buff **skb)
/* Packet that contains a length */
if (tmp[0] == 0 && tmp[1] == 0) {
phy->next_read_size = (tmp[2] << 8) + tmp[3] + 3;
+ /*
+* Ensure next_read_size does not exceed sizeof(tmp)
+* for reading that many bytes during next iteration
+*/
+ if (phy->next_read_size > FDP_NCI_I2C_MAX_PAYLOAD) {
+ dev_dbg(&client->dev, "corrupted packet\n");
+ phy->next_read_size = 5;
+ goto flush;
+ }
} else {
phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
--
2.7.4
[PATCH v2 2/3] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Suren Baghdasaryan
When handling SHDLC I-Frame commands "pipe" field used for indexing
into an array should be checked before usage. If left unchecked it
might access memory outside of the array of size NFC_HCI_MAX_PIPES(127).
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
---
v2:
Resend. No changes.
net/nfc/hci/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/net/nfc/hci/core.c b/net/nfc/hci/core.c
index ac8030c4..19cb2e4 100644
--- a/net/nfc/hci/core.c
+++ b/net/nfc/hci/core.c
@@ -209,6 +209,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
create_info = (struct hci_create_pipe_resp *)skb->data;
+ if (create_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
/* Save the new created pipe and bind with local gate,
* the description for skb->data[3] is destination gate id
* but since we received this cmd from host controller, we
@@ -232,6 +237,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
delete_info = (struct hci_delete_pipe_noti *)skb->data;
+ if (delete_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
hdev->pipes[delete_info->pipe].gate = NFC_HCI_INVALID_GATE;
hdev->pipes[delete_info->pipe].dest_host = NFC_HCI_INVALID_HOST;
break;
--
2.7.4
[PATCH v2 1/3] NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ
From: Suren Baghdasaryan
Out of bounds kernel accesses in st21nfca's NFC HCI layer
might happen when handling ATR_REQ events if user-specified
atr_req->length is bigger than the buffer size. In
that case memcpy() inside st21nfca_tm_send_atr_res() will
read extra bytes resulting in OOB read from the kernel heap.
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
---
v2:
Resend. No changes.
drivers/nfc/st21nfca/dep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/st21nfca/dep.c b/drivers/nfc/st21nfca/dep.c
index fd08be2..3420c51 100644
--- a/drivers/nfc/st21nfca/dep.c
+++ b/drivers/nfc/st21nfca/dep.c
@@ -217,7 +217,8 @@ static int st21nfca_tm_recv_atr_req(struct nfc_hci_dev
*hdev,
atr_req = (struct st21nfca_atr_req *)skb->data;
- if (atr_req->length < sizeof(struct st21nfca_atr_req)) {
+ if (atr_req->length < sizeof(struct st21nfca_atr_req) ||
+ atr_req->length > skb->len) {
r = -EPROTO;
goto exit;
}
--
2.7.4
[PATCH] NFC: fdp: Remove __func__ parameter from dev_dbg() call
Remove redundant __func__ parameter from dev_dgb() calls.
Signed-off-by: Amit Pundir
---
drivers/nfc/fdp/fdp.c | 22 +++---
drivers/nfc/fdp/i2c.c | 20 +---
2 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
index d5784a4..3251346 100644
--- a/drivers/nfc/fdp/fdp.c
+++ b/drivers/nfc/fdp/fdp.c
@@ -249,7 +249,7 @@ static int fdp_nci_open(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
r = info->phy_ops->enable(info->phy);
@@ -261,7 +261,7 @@ static int fdp_nci_close(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
return 0;
}
@@ -270,7 +270,7 @@ static int fdp_nci_send(struct nci_dev *ndev, struct
sk_buff *skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
if (atomic_dec_and_test(&info->data_pkt_counter))
info->data_pkt_counter_cb(ndev);
@@ -283,7 +283,7 @@ int fdp_nci_recv_frame(struct nci_dev *ndev, struct sk_buff
*skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
return nci_recv_frame(ndev, skb);
}
EXPORT_SYMBOL(fdp_nci_recv_frame);
@@ -498,7 +498,7 @@ static int fdp_nci_setup(struct nci_dev *ndev)
int r;
u8 patched = 0;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
r = nci_core_init(ndev);
if (r)
@@ -609,7 +609,7 @@ static int fdp_nci_core_reset_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
info->setup_reset_ntf = 1;
wake_up(&info->setup_wq);
@@ -622,7 +622,7 @@ static int fdp_nci_prop_patch_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
info->setup_patch_ntf = 1;
info->setup_patch_status = skb->data[0];
wake_up(&info->setup_wq);
@@ -637,7 +637,7 @@ static int fdp_nci_prop_patch_rsp_packet(struct nci_dev
*ndev,
struct device *dev = &info->phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -650,7 +650,7 @@ static int
fdp_nci_prop_set_production_data_rsp_packet(struct nci_dev *ndev,
struct device *dev = &info->phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -695,7 +695,7 @@ static int fdp_nci_core_get_config_rsp_packet(struct
nci_dev *ndev,
dev_dbg(dev, "OTP version %d\n", info->otp_version);
dev_dbg(dev, "RAM version %d\n", info->ram_version);
dev_dbg(dev, "key index %d\n", info->key_index);
- dev_dbg(dev, "%s: status 0x%x\n", __func__, rsp->status);
+ dev_dbg(dev, "status 0x%x\n", rsp->status);
nci_req_complete(ndev, rsp->status);
@@ -798,7 +798,7 @@ void fdp_nci_remove(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
+ dev_dbg(dev, "\n");
nci_unregister_device(ndev);
nci_free_device(ndev);
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index b80d1ad..3138730 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -57,7 +57,7 @@ static int fdp_nci_i2c_enable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(&phy->i2c_dev->dev, "%s\n", __func__);
+ dev_dbg(&phy->i2c_dev->dev, "\n");
fdp_nci_i2c_reset(phy);
return 0;
@@ -67,7 +67,7
[PATCH v2] NFC: fdp: Remove __func__ from dev_dbg()
Remove redundant __func__ parameter from dev_dgb() calls.
v2:
Deleted empty dev_dbg() trace calls, which are redundant if
function tracer is enabled.
Signed-off-by: Amit Pundir
---
drivers/nfc/fdp/fdp.c | 18 +++---
drivers/nfc/fdp/i2c.c | 17 -
2 files changed, 7 insertions(+), 28 deletions(-)
diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
index d5784a4..f64a6fd 100644
--- a/drivers/nfc/fdp/fdp.c
+++ b/drivers/nfc/fdp/fdp.c
@@ -249,8 +249,6 @@ static int fdp_nci_open(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
r = info->phy_ops->enable(info->phy);
return r;
@@ -261,7 +259,6 @@ static int fdp_nci_close(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
return 0;
}
@@ -270,8 +267,6 @@ static int fdp_nci_send(struct nci_dev *ndev, struct
sk_buff *skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
if (atomic_dec_and_test(&info->data_pkt_counter))
info->data_pkt_counter_cb(ndev);
@@ -283,7 +278,6 @@ int fdp_nci_recv_frame(struct nci_dev *ndev, struct sk_buff
*skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
return nci_recv_frame(ndev, skb);
}
EXPORT_SYMBOL(fdp_nci_recv_frame);
@@ -498,8 +492,6 @@ static int fdp_nci_setup(struct nci_dev *ndev)
int r;
u8 patched = 0;
- dev_dbg(dev, "%s\n", __func__);
-
r = nci_core_init(ndev);
if (r)
goto error;
@@ -609,7 +601,6 @@ static int fdp_nci_core_reset_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
info->setup_reset_ntf = 1;
wake_up(&info->setup_wq);
@@ -622,7 +613,6 @@ static int fdp_nci_prop_patch_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
info->setup_patch_ntf = 1;
info->setup_patch_status = skb->data[0];
wake_up(&info->setup_wq);
@@ -637,7 +627,7 @@ static int fdp_nci_prop_patch_rsp_packet(struct nci_dev
*ndev,
struct device *dev = &info->phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -650,7 +640,7 @@ static int
fdp_nci_prop_set_production_data_rsp_packet(struct nci_dev *ndev,
struct device *dev = &info->phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -695,7 +685,7 @@ static int fdp_nci_core_get_config_rsp_packet(struct
nci_dev *ndev,
dev_dbg(dev, "OTP version %d\n", info->otp_version);
dev_dbg(dev, "RAM version %d\n", info->ram_version);
dev_dbg(dev, "key index %d\n", info->key_index);
- dev_dbg(dev, "%s: status 0x%x\n", __func__, rsp->status);
+ dev_dbg(dev, "status 0x%x\n", rsp->status);
nci_req_complete(ndev, rsp->status);
@@ -798,8 +788,6 @@ void fdp_nci_remove(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
nci_unregister_device(ndev);
nci_free_device(ndev);
}
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index c4da50e..f355ab2 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -57,7 +57,6 @@ static int fdp_nci_i2c_enable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(&phy->i2c_dev->dev, "%s\n", __func__);
fdp_nci_i2c_reset(phy);
return 0;
@@ -67,7 +66,6 @@ static void fdp_nci_i2c_disable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(&phy->i2c_dev->dev, "%s\n", __func__);
fdp_nci_i2c_reset(phy);
}
@@ -113,8 +111,8 @@ sta
Re: [PATCH v3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
Hi,
On Thu, 11 Feb 2021 at 00:25, AngeloGioacchino Del Regno
wrote:
>
> Il 10/02/21 09:18, Amit Pundir ha scritto:
> > From: Sumit Semwal
> >
> > Enabling the Display panel for beryllium requires DSI
> > labibb regulators and panel dts nodes to be added.
> > It is also required to keep some of the regulators as
> > always-on.
> >
> > Signed-off-by: Sumit Semwal
> > Signed-off-by: Amit Pundir
> > ---
>
> Hello!
> Your patch looks good, however, I have a few concerns...
>
> > v3: Addressed Konrad's concerns. Configured labibb regulators
> > explicitly based on downstream microvolt values. Display
> > comes up fine with default discharge-resistor-kohms and
> > soft-start-us properties, so didn't touch them.
> > Smoke tested on next-20210209.
> > v2: Rebased to mainline (v5.11-rc6) and fixed build warnings.
> >
> > .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 64
> > ++
> > 1 file changed, 64 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> > b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> > index 86cbae63eaf7..5ac049a247e1 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> > +++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> > @@ -157,6 +157,14 @@
> > regulator-initial-mode = ;
> > };
> >
> > + vreg_l14a_1p8: ldo14 {
> > + regulator-min-microvolt = <180>;
> > + regulator-max-microvolt = <180>;
> > + regulator-initial-mode = ;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +
> > vreg_l17a_1p3: ldo17 {
> > regulator-min-microvolt = <1304000>;
> > regulator-max-microvolt = <1304000>;
> > @@ -191,6 +199,7 @@
> > regulator-min-microvolt = <120>;
> > regulator-max-microvolt = <120>;
> > regulator-initial-mode = ;
> > + regulator-boot-on;
> > };
> > };
> > };
> > @@ -200,6 +209,43 @@
> > firmware-name = "qcom/sdm845/cdsp.mdt";
> > };
> >
> > +&dsi0 {
> > + status = "okay";
> > + vdda-supply = <&vreg_l26a_1p2>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + panel@0 {
> > + compatible = "tianma,fhd-video";
> > + reg = <0>;
> > + vddi0-supply = <&vreg_l14a_1p8>;
> > + vddpos-supply = <&lab>;
> > + vddneg-supply = <&ibb>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
> > +
> > + port {
> > + tianma_nt36672a_in_0: endpoint {
> > + remote-endpoint = <&dsi0_out>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&dsi0_out {
> > + remote-endpoint = <&tianma_nt36672a_in_0>;
> > + data-lanes = <0 1 2 3>;
> > +};
> > +
> > +&dsi0_phy {
> > + status = "okay";
> > + vdds-supply = <&vreg_l1a_0p875>;
> > +};
> > +
> > &gcc {
> > protected-clocks = ,
> > ,
> > @@ -215,6 +261,24 @@
> > };
> > };
> >
> > +&ibb {
> > + regulator-min-microvolt = <460>;
> > + regulator-max-microvolt = <600>;
> > +};
> > +
>
> I think you want to also configure overvoltage and overcurrent
> protection values for both LAB and IBB, as these regulators may be a bit
> dangerous if used without.
Can you point me to the relevant DT properties please. I didn't find
any DT properties which set the over voltage/current protection
properties explicitly in upstream as well as in downstream kernel.
Plus I also do not see "regulator-min/max-microamp" values set
downstream, otherwise I'd have used that as well atleast.
Regards,
Amit Pundir
> Besides that, even if it wouldn't be that dangerous, since the
> protection features are present, it would be nice to configure them
> properly as in the rare event that something bad happens, you would be
> able to save the hardware (or at least have a chance to!).
>
> > +&lab {
> > + regulator-min-microvolt = <460>;
> > + regulator-max-microvolt = <600>;
> > +};
> > +
>
> Same here.
>
> Yours,
> -- Angelo
>
> > +&mdss {
> > + status = "okay";
> > +};
> > +
> > +&mdss_mdp {
> > + status = "okay";
> > +};
> > +
> > &mss_pil {
> > status = "okay";
> > firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
> >
>
[PATCH v3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
From: Sumit Semwal
Enabling the Display panel for beryllium requires DSI
labibb regulators and panel dts nodes to be added.
It is also required to keep some of the regulators as
always-on.
Signed-off-by: Sumit Semwal
Signed-off-by: Amit Pundir
---
v3: Addressed Konrad's concerns. Configured labibb regulators
explicitly based on downstream microvolt values. Display
comes up fine with default discharge-resistor-kohms and
soft-start-us properties, so didn't touch them.
Smoke tested on next-20210209.
v2: Rebased to mainline (v5.11-rc6) and fixed build warnings.
.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 64 ++
1 file changed, 64 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
index 86cbae63eaf7..5ac049a247e1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
@@ -157,6 +157,14 @@
regulator-initial-mode = ;
};
+ vreg_l14a_1p8: ldo14 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-initial-mode = ;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
vreg_l17a_1p3: ldo17 {
regulator-min-microvolt = <1304000>;
regulator-max-microvolt = <1304000>;
@@ -191,6 +199,7 @@
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
regulator-initial-mode = ;
+ regulator-boot-on;
};
};
};
@@ -200,6 +209,43 @@
firmware-name = "qcom/sdm845/cdsp.mdt";
};
+&dsi0 {
+ status = "okay";
+ vdda-supply = <&vreg_l26a_1p2>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "tianma,fhd-video";
+ reg = <0>;
+ vddi0-supply = <&vreg_l14a_1p8>;
+ vddpos-supply = <&lab>;
+ vddneg-supply = <&ibb>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
+
+ port {
+ tianma_nt36672a_in_0: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+};
+
+&dsi0_out {
+ remote-endpoint = <&tianma_nt36672a_in_0>;
+ data-lanes = <0 1 2 3>;
+};
+
+&dsi0_phy {
+ status = "okay";
+ vdds-supply = <&vreg_l1a_0p875>;
+};
+
&gcc {
protected-clocks = ,
,
@@ -215,6 +261,24 @@
};
};
+&ibb {
+ regulator-min-microvolt = <460>;
+ regulator-max-microvolt = <600>;
+};
+
+&lab {
+ regulator-min-microvolt = <460>;
+ regulator-max-microvolt = <600>;
+};
+
+&mdss {
+ status = "okay";
+};
+
+&mdss_mdp {
+ status = "okay";
+};
+
&mss_pil {
status = "okay";
firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
--
2.7.4
Re: [PATCH v2] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
Hi,
On Mon, 8 Feb 2021 at 20:11, Konrad Dybcio wrote:
>
>
> >>> + ports {
> >>> + port@1 {
> >>> + endpoint {
> >>> + remote-endpoint = <&tianma_nt36672a_in_0>;
> >>> + data-lanes = <0 1 2 3>;
> >>> + };
> >>> + };
> >>> + };
> >> The endpoint has a label, you can simply use &dsi0_out {};.
> > I didn't get what you meant there. Care to point to some reference dts
> > snippet please?
>
> sdm845.dtsi, L4139 as of v5.11-rc7:
>
>
> port@1 {
> reg = <1>;
> dsi0_out: endpoint {
> };
> };
>
>
> This means you can essentially do:
>
> &dsi0_out {
>
> remote-endpoint = <&tianma_nt36672a_in_0>;
> lanes = <0 1 2 3>;
>
> };
>
>
> in your dt :)
>
Thank you. Added in v3.
>
> >>> + vddpos-supply = <&lab>;
> >>> + vddneg-supply = <&ibb>;
> >> With Angelo's latest series [1] merged in, I reckon you should explicitly
> >> configure lab/ibb (like in [2]),
> >> as wrong settings (which CAN BE SET BY THE BOOTLOADER in some instances!!)
> >> can lead to hardware damage.
> > So iirc in the case of beryllium device, these regulators are pre set
> > by the bootloader and I can't find any reference of we
> > setting/resetting it explicitly to switch ON the panel and display. So
> > far default lab/ibb nodes are working fine for us and I'm hesitant to
> > tinker around anything regulator related that can potentially damage
> > the hardware. Having said that, I do see lab/ibb nodes being set in
> > the downstream dts, with relevant soft-start and discharge-resistor
> > properties and I can try switching to that once the new lab/ibb
> > changes land upstream.
> >
> > Regards,
> > Amit Pundir
> >
> I understand your concerns, however we actually did find out that at least
> one device had LAB/IBB set up by the bootloader in a way that could
> potentially damage the electronics, so I'm just making you aware. If it works
> as-is, it's probably OK.
Device seem to be booting fine with downstream labibb regulator node
changes, hence added them in v3 as well. Smoke tested on
5.11.0-rc7-next-20210209.
Regards,
Amit Pundir
>
>
> Konrad
>
[PATCH] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
From: Sumit Semwal
Enabling the Display panel for beryllium phone (Xiaomi
Pocophone F1) requires DSI labibb regulators and panel
dts nodes to be added. It is also required to keep some
of the regulators as always-on.
Signed-off-by: Sumit Semwal
Signed-off-by: Amit Pundir
---
.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 55 ++
1 file changed, 55 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
index cd15ae0347e8..e09effa555f1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
@@ -160,6 +160,14 @@
regulator-initial-mode = ;
};
+ vreg_l14a_1p88: ldo14 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-initial-mode = ;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
vreg_l17a_1p3: ldo17 {
regulator-min-microvolt = <1304000>;
regulator-max-microvolt = <1304000>;
@@ -194,6 +202,7 @@
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
regulator-initial-mode = ;
+ regulator-boot-on;
};
};
};
@@ -207,6 +216,44 @@
firmware-name = "qcom/sdm845/cdsp.mdt";
};
+&dsi0 {
+ status = "okay";
+ vdda-supply = <&vreg_l26a_1p2>;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&tianma_nt36672a_in_0>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+
+ panel@0 {
+ compatible = "tianma,fhd-video";
+ reg = <0>;
+ vddi0-supply = <&vreg_l14a_1p88>;
+ vddpos-supply = <&lab>;
+ vddneg-supply = <&ibb>;
+
+ reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port {
+ tianma_nt36672a_in_0: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+};
+
+&dsi0_phy {
+ status = "okay";
+ vdds-supply = <&vreg_l1a_0p875>;
+};
+
&gcc {
protected-clocks = ,
,
@@ -274,6 +321,14 @@
};
+&mdss {
+ status = "okay";
+};
+
+&mdss_mdp {
+ status = "okay";
+};
+
&mss_pil {
status = "okay";
firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
--
2.7.4
Re: [PATCH] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
Argh.. This patch is not formatted on top of mainline. It doesn't
apply cleanly. Sorry about that. I'll fix that in the next version.
Regards,
Amit Pundir
On Wed, 3 Feb 2021 at 15:29, Amit Pundir wrote:
>
> From: Sumit Semwal
>
> Enabling the Display panel for beryllium phone (Xiaomi
> Pocophone F1) requires DSI labibb regulators and panel
> dts nodes to be added. It is also required to keep some
> of the regulators as always-on.
>
> Signed-off-by: Sumit Semwal
> Signed-off-by: Amit Pundir
> ---
> .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 55
> ++
> 1 file changed, 55 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> index cd15ae0347e8..e09effa555f1 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> @@ -160,6 +160,14 @@
> regulator-initial-mode = ;
> };
>
> + vreg_l14a_1p88: ldo14 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-initial-mode = ;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> vreg_l17a_1p3: ldo17 {
> regulator-min-microvolt = <1304000>;
> regulator-max-microvolt = <1304000>;
> @@ -194,6 +202,7 @@
> regulator-min-microvolt = <120>;
> regulator-max-microvolt = <120>;
> regulator-initial-mode = ;
> + regulator-boot-on;
> };
> };
> };
> @@ -207,6 +216,44 @@
> firmware-name = "qcom/sdm845/cdsp.mdt";
> };
>
> +&dsi0 {
> + status = "okay";
> + vdda-supply = <&vreg_l26a_1p2>;
> +
> + ports {
> + port@1 {
> + endpoint {
> + remote-endpoint = <&tianma_nt36672a_in_0>;
> + data-lanes = <0 1 2 3>;
> + };
> + };
> + };
> +
> + panel@0 {
> + compatible = "tianma,fhd-video";
> + reg = <0>;
> + vddi0-supply = <&vreg_l14a_1p88>;
> + vddpos-supply = <&lab>;
> + vddneg-supply = <&ibb>;
> +
> + reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port {
> + tianma_nt36672a_in_0: endpoint {
> + remote-endpoint = <&dsi0_out>;
> + };
> + };
> + };
> +};
> +
> +&dsi0_phy {
> + status = "okay";
> + vdds-supply = <&vreg_l1a_0p875>;
> +};
> +
> &gcc {
> protected-clocks = ,
>,
> @@ -274,6 +321,14 @@
>
> };
>
> +&mdss {
> + status = "okay";
> +};
> +
> +&mdss_mdp {
> + status = "okay";
> +};
> +
> &mss_pil {
> status = "okay";
> firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
> --
> 2.7.4
>
Re: [PATCH] ath10k: Introduce a devicetree quirk to skip host cap QMI requests
Hi Kalle, On Mon, 7 Dec 2020 at 22:25, Kalle Valo wrote: > > This is firmware version specific, right? There's also enum > ath10k_fw_features which is embedded within firmware-N.bin, we could add > a new flag there. But that means that a correct firmware-N.bin is needed > for each firmware version, not sure if that would work out. Just > throwing out ideas here. Apologies for this late reply. I was out for a while. If by that (the firmware version) you mean "QC_IMAGE_VERSION_STRING", then that may be a bit tricky. Pocophone F1 use the same firmware family version (WLAN.HL.2.0.XXX), used by Dragonboard 845c (which has Wi-Fi working upstream). Regards, Amit Pundir > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH v2] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
From: Sumit Semwal
Enabling the Display panel for beryllium phone (Xiaomi
Pocophone F1) requires DSI labibb regulators and panel
dts nodes to be added. It is also required to keep some
of the regulators as always-on.
Signed-off-by: Sumit Semwal
Signed-off-by: Amit Pundir
---
v2: Rebased to mainline (v5.11-rc6) and fixed build warnings.
.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 58 ++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
index 86cbae63eaf7..034246b5c529 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
@@ -157,6 +157,14 @@
regulator-initial-mode = ;
};
+ vreg_l14a_1p88: ldo14 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-initial-mode = ;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
vreg_l17a_1p3: ldo17 {
regulator-min-microvolt = <1304000>;
regulator-max-microvolt = <1304000>;
@@ -191,6 +199,7 @@
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
regulator-initial-mode = ;
+ regulator-boot-on;
};
};
};
@@ -200,6 +209,47 @@
firmware-name = "qcom/sdm845/cdsp.mdt";
};
+&dsi0 {
+ status = "okay";
+ vdda-supply = <&vreg_l26a_1p2>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&tianma_nt36672a_in_0>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+
+ panel@0 {
+ compatible = "tianma,fhd-video";
+ reg = <0>;
+ vddi0-supply = <&vreg_l14a_1p88>;
+ vddpos-supply = <&lab>;
+ vddneg-supply = <&ibb>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
+
+ port {
+ tianma_nt36672a_in_0: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+};
+
+&dsi0_phy {
+ status = "okay";
+ vdds-supply = <&vreg_l1a_0p875>;
+};
+
&gcc {
protected-clocks = ,
,
@@ -215,6 +265,14 @@
};
};
+&mdss {
+ status = "okay";
+};
+
+&mdss_mdp {
+ status = "okay";
+};
+
&mss_pil {
status = "okay";
firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
--
2.7.4
Re: [PATCH v2] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
Hi Konrad,
On Thu, 4 Feb 2021 at 19:46, Konrad Dybcio wrote:
>
> Hi!
>
> >vreg_l14a_1p88: ldo14 {
> >+ regulator-min-microvolt = <180>;
> >+ regulator-max-microvolt = <180>;
>
> Should probably be renamed to vreg_l14a_1p8 then.
ack.
>
>
> >+ ports {
> >+ port@1 {
> >+ endpoint {
> >+ remote-endpoint = <&tianma_nt36672a_in_0>;
> >+ data-lanes = <0 1 2 3>;
> >+ };
> >+ };
> >+ };
>
> The endpoint has a label, you can simply use &dsi0_out {};.
I didn't get what you meant there. Care to point to some reference dts
snippet please?
>
> >+ vddpos-supply = <&lab>;
> >+ vddneg-supply = <&ibb>;
>
> With Angelo's latest series [1] merged in, I reckon you should explicitly
> configure lab/ibb (like in [2]),
> as wrong settings (which CAN BE SET BY THE BOOTLOADER in some instances!!)
> can lead to hardware damage.
So iirc in the case of beryllium device, these regulators are pre set
by the bootloader and I can't find any reference of we
setting/resetting it explicitly to switch ON the panel and display. So
far default lab/ibb nodes are working fine for us and I'm hesitant to
tinker around anything regulator related that can potentially damage
the hardware. Having said that, I do see lab/ibb nodes being set in
the downstream dts, with relevant soft-start and discharge-resistor
properties and I can try switching to that once the new lab/ibb
changes land upstream.
Regards,
Amit Pundir
>
>
>
> Konrad
>
> [1]
> https://lore.kernel.org/linux-arm-msm/20210119174421.226541-1-angelogioacchino.delre...@somainline.org/
> [2]
> https://github.com/SoMainline/linux/commit/4f4853b2e252b5f9d03e90119110aac80258fc53
Re: [PATCH] dma-pool: Do not allocate pool memory from CMA
001 returned > status 0x > [1.780871] ALSA device list: > [1.783960] No soundcards found. > [1.787633] Waiting for root device PARTUUID=45a8dd8a-02... > > I am unsure if it is related to the issue that Amit is having or > if that makes sense at all but I can reliably reproduce it. > > v5.8-rc1: OK > v5.8-rc1 + d9765e41d8e9e: OK > v5.8-rc1 + "of_address: Add bus type match for pci ranges parser": OK > v5.8-rc1 + both: BROKEN > > I wanted to test the series to see if this fixes anything. If you would > prefer a different thread for this or further information, please let > me know. Hi Nathan, Here is the patch series: https://lists.linuxfoundation.org/pipermail/iommu/2020-July/047008.html https://lists.linuxfoundation.org/pipermail/iommu/2020-July/047010.html I hope it works for you, it didn't work for me. More details in this thread here: https://lists.linuxfoundation.org/pipermail/iommu/2020-July/047009.html Regards, Amit Pundir > > Cheers, > Nathan
[PATCH v2] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Add initial dts support for Xiaomi Poco F1 (Beryllium).
This initial support is based on upstream Dragonboard 845c
(sdm845) device. With this dts, Beryllium boots AOSP up to
ADB shell over USB-C.
Supported functionality includes UFS, USB-C (peripheral),
microSD card and Vol+/Vol-/power keys. Bluetooth should work
too but couldn't be verified from adb command line, it is
verified when enabled from UI with few WIP display patches.
Just like initial db845c support, initializing the SMMU is
clearing the mapping used for the splash screen framebuffer,
which causes the device to hang during boot and recovery
needs a hard power reset. This can be worked around using:
fastboot oem select-display-panel none
To switch ON the display back run:
fastboot oem select-display-panel
But this only works on Beryllium devices running bootloader
version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
Android-9 based release. Newer bootloader version do not
support switching OFF the display panel at all. So we need
a few additional smmu patches (under review) from here to
boot to shell:
https://github.com/pundiramit/linux/commits/beryllium-mainline
Signed-off-by: Amit Pundir
---
v2: Updated machine compatible string for seemingly inevitable
future quirks.
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 321 ++
2 files changed, 322 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 0f2c33d611df..3ef1b48bc0cb 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-beryllium.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
new file mode 100644
index ..714c5157d9f8
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
@@ -0,0 +1,321 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "sdm845.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+
+/ {
+ model = "Xiaomi Technologies Inc. Beryllium";
+ compatible = "xiaomi,beryllium", "qcom,sdm845";
+
+ /* required for bootloader to select correct board */
+ qcom,board-id = <69 0>;
+ qcom,msm-id = <321 0x20001>;
+
+ aliases {
+ hsuart0 = &uart6;
+ };
+
+ dc12v: dc12v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "DC12V";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&vol_up_pin_a>;
+
+ vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <&pm8998_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ vbat: vbat-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT";
+
+ vin-supply = <&dc12v>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vbat_som: vbat-som-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT_SOM";
+
+ vin-supply = <&dc12v>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vdc_3v3: vdc-3v3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VDC_3V3";
+ vin-supply = <&dc12v>;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vdc_5v: vdc-5v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VDC_5V";
+
+
Re: [RFC v2 03/11] tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state
Hi Rajendra, On Wed, 12 Aug 2020 at 11:18, Rajendra Nayak wrote: > > > On 8/12/2020 7:03 AM, John Stultz wrote: > > On Tue, Aug 11, 2020 at 4:11 PM John Stultz wrote: > >> > >> On Wed, Mar 20, 2019 at 2:49 AM Rajendra Nayak > >> wrote: > >>> > >>> geni serial needs to express a perforamnce state requirement on CX > >>> depending on the frequency of the clock rates. Use OPP table from > >>> DT to register with OPP framework and use dev_pm_opp_set_rate() to > >>> set the clk/perf state. > >>> > >>> Signed-off-by: Rajendra Nayak > >>> Signed-off-by: Stephen Boyd > >>> --- > >>> drivers/tty/serial/qcom_geni_serial.c | 15 +-- > >>> 1 file changed, 13 insertions(+), 2 deletions(-) > >>> > >> > >> Hey, > >>I just wanted to follow up on this patch, as I've bisected it > >> (a5819b548af0) down as having broken qca bluetooth on the Dragonboard > >> 845c. > >> > >> I haven't yet had time to debug it yet, but wanted to raise the issue > >> in case anyone else has seen similar trouble. > > > > So I dug in a bit further, and this chunk seems to be causing the issue: > >> @@ -961,7 +963,7 @@ static void qcom_geni_serial_set_termios(struct > >> uart_port *uport, > >> goto out_restart_rx; > >> > >> uport->uartclk = clk_rate; > >> - clk_set_rate(port->se.clk, clk_rate); > >> + dev_pm_opp_set_rate(port->dev, clk_rate); > >> ser_clk_cfg = SER_CLK_EN; > >> ser_clk_cfg |= clk_div << CLK_DIV_SHFT; > >> > > > > > > With that applied, I see the following errors in dmesg and bluetooth > > fails to function: > > [4.763467] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: > > failed to find OPP for freq 10240 (-34) > > [4.773493] qcom_geni_serial 898000.serial: dev_pm_opp_set_rate: > > failed to find OPP for freq 10240 (-34) > > > > With just that chunk reverted on linus/HEAD, bluetooth seems to work ok. > > This seems like the same issue that was also reported on venus [1] because the > clock frequency tables apparently don;t exactly match the achievable clock > frequencies (which we also used to construct the OPP tables) > > Can you try updating the OPP table for QUP to have 10240 instead of the > current 1 and see if that fixes it? That worked. Thanks. Should this change be common to base sdm845.dtsi or platform specific dts? For what it's worth, we see this BT breakage on PocoF1 phone too. Regards, Amit Pundir > > [1] https://lkml.org/lkml/2020/7/27/507 > > > > > thanks > > -john > > > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] arm64: dts: sdm845: Fixup OPP table for all qup devices
On Wed, 12 Aug 2020 at 15:52, Rajendra Nayak wrote:
>
> This OPP table was based on the clock VDD-FMAX tables seen in
> downstream code, however it turns out the downstream clock
> driver does update these tables based on later/production
> rev of the chip and whats seen in the tables belongs to an
> early engineering rev of the SoC.
> Fix up the OPP tables such that it now matches with the
> production rev of sdm845 SoC.
>
> Fixes: 13cadb34e593 ("arm64: dts: sdm845: Add OPP table for all qup
> devices")
Fixes BT on Xiaomi Poco F1 phone running AOSP.
Tested-by: Amit Pundir
> Reported-by: John Stultz
> Signed-off-by: Rajendra Nayak
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 2884577..eca81cf 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -1093,8 +1093,8 @@
> qup_opp_table: qup-opp-table {
> compatible = "operating-points-v2";
>
> - opp-1920 {
> - opp-hz = /bits/ 64 <1920>;
> + opp-5000 {
> + opp-hz = /bits/ 64 <5000>;
> required-opps = <&rpmhpd_opp_min_svs>;
> };
>
> @@ -1107,6 +1107,11 @@
> opp-hz = /bits/ 64 <1>;
> required-opps = <&rpmhpd_opp_svs>;
> };
> +
> + opp-12800 {
> + opp-hz = /bits/ 64 <12800>;
> + required-opps = <&rpmhpd_opp_nom>;
> + };
> };
>
> qupv3_id_0: geniqup@8c {
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
Re:
On Fri, 7 Aug 2020 at 04:02, Konrad Dybcio wrote:
>
> Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1
> (Beryllium)
>
> >// This removed_region is needed to boot the device
> > // TODO: Find out the user of this reserved memory
> > removed_region: memory@88f0 {
>
> This region seems to belong to the Trust Zone. When Linux tries to access it,
> TZ bites and shuts the device down.
That is totally possible. Plus it falls right in between TZ and QSEE
reserved-memory regions. However, I do not find any credible source
of information which can confirm this. So I'm hesitant to update the
TODO item in the above comment.
>
> Konrad
[PATCH v3] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Add initial dts support for Xiaomi Poco F1 (Beryllium).
This initial support is based on upstream Dragonboard 845c
(sdm845) device. With this dts, Beryllium boots AOSP up to
ADB shell over USB-C.
Supported functionality includes UFS, USB-C (peripheral),
microSD card and Vol+/Vol-/power keys. Bluetooth should work
too but couldn't be verified from adb command line, it is
verified when enabled from UI with few WIP display patches.
Just like initial db845c support, initializing the SMMU is
clearing the mapping used for the splash screen framebuffer,
which causes the device to hang during boot and recovery
needs a hard power reset. This can be worked around using:
fastboot oem select-display-panel none
To switch ON the display back run:
fastboot oem select-display-panel
But this only works on Beryllium devices running bootloader
version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
Android-9 based release. Newer bootloader version do not
support switching OFF the display panel at all. So we need
a few additional smmu patches (under review) from here to
boot to shell:
https://github.com/pundiramit/linux/commits/beryllium-mainline
Signed-off-by: Amit Pundir
---
v3: Added a reserved-memory region from downstream kernel to fix
a boot regression with recent dma-pool changes in v5.8-rc6.
v2: Updated machine compatible string for seemingly inevitable
future quirks.
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 331 ++
2 files changed, 332 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 0f2c33d611df..3ef1b48bc0cb 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-beryllium.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
new file mode 100644
index ..af66459712fe
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
@@ -0,0 +1,331 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "sdm845.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+
+/ {
+ model = "Xiaomi Technologies Inc. Beryllium";
+ compatible = "xiaomi,beryllium", "qcom,sdm845";
+
+ /* required for bootloader to select correct board */
+ qcom,board-id = <69 0>;
+ qcom,msm-id = <321 0x20001>;
+
+ aliases {
+ hsuart0 = &uart6;
+ };
+
+ dc12v: dc12v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "DC12V";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&vol_up_pin_a>;
+
+ vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <&pm8998_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ vbat: vbat-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT";
+
+ vin-supply = <&dc12v>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vbat_som: vbat-som-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT_SOM";
+
+ vin-supply = <&dc12v>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vdc_3v3: vdc-3v3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VDC_3V3";
+ vin-supply = <&dc12v>;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vdc_5v: v
Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
On Wed, 5 Aug 2020 at 16:21, Amit Pundir wrote:
>
> Add initial dts support for Xiaomi Poco F1 (Beryllium).
>
> This initial support is based on upstream Dragonboard 845c
> (sdm845) device. With this dts, Beryllium boots AOSP up to
> ADB shell over USB-C.
>
> Supported functionality includes UFS, USB-C (peripheral),
> microSD card and Vol+/Vol-/power keys. Bluetooth should work
> too but couldn't be verified from adb command line, it is
> verified when enabled from UI with few WIP display patches.
>
> Just like initial db845c support, initializing the SMMU is
> clearing the mapping used for the splash screen framebuffer,
> which causes the device to hang during boot and recovery
> needs a hard power reset. This can be worked around using:
>
> fastboot oem select-display-panel none
>
> To switch ON the display back run:
>
> fastboot oem select-display-panel
>
> But this only works on Beryllium devices running bootloader
> version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
> Android-9 based release. Newer bootloader version do not
> support switching OFF the display panel at all. So we need
> a few additional smmu patches (under review) from here to
> boot to shell:
> https://github.com/pundiramit/linux/commits/beryllium-mainline
>
> Signed-off-by: Amit Pundir
> ---
> v4: Added more downstream reserved memory regions. It probably
> need more work, but for now I see adsp/cdsp/wlan remoteprocs
> powering up properly. Also removed the regulator nodes not
> required for the device, as suggested by Bjorn.
Forgot to mention that I added couple of clocks to protected clocks in v4,
which need for display to work.
> v3: Added a reserved-memory region from downstream kernel to fix
> a boot regression with recent dma-pool changes in v5.8-rc6.
> v2: Updated machine compatible string for seemingly inevitable
> future quirks.
>
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 383
> ++
> 2 files changed, 384 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile
> b/arch/arm64/boot/dts/qcom/Makefile
> index 0f2c33d611df..3ef1b48bc0cb 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
> +dtb-$(CONFIG_ARCH_QCOM)+= sdm845-beryllium.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
> dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> new file mode 100644
> index ..0f9f61bf9fa4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
> @@ -0,0 +1,383 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include
> +#include "sdm845.dtsi"
> +#include "pm8998.dtsi"
> +#include "pmi8998.dtsi"
> +
> +/ {
> + model = "Xiaomi Technologies Inc. Beryllium";
> + compatible = "xiaomi,beryllium", "qcom,sdm845";
> +
> + /* required for bootloader to select correct board */
> + qcom,board-id = <69 0>;
> + qcom,msm-id = <321 0x20001>;
> +
> + aliases {
> + hsuart0 = &uart6;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&vol_up_pin_a>;
> +
> + vol-up {
> + label = "Volume Up";
> + linux,code = ;
> + gpios = <&pm8998_gpio 6 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + vreg_s4a_1p8: vreg-s4a-1p8 {
> + compatible = "regulator-fixed";
> + regulator-name = "vreg_s4a_1p8";
> +
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + };
> +};
> +
> +&adsp_pas {
> + status = "okay";
> + firmware-name = "qcom/sdm845/adsp.mdt";
> +};
> +
> +&
[PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Add initial dts support for Xiaomi Poco F1 (Beryllium).
This initial support is based on upstream Dragonboard 845c
(sdm845) device. With this dts, Beryllium boots AOSP up to
ADB shell over USB-C.
Supported functionality includes UFS, USB-C (peripheral),
microSD card and Vol+/Vol-/power keys. Bluetooth should work
too but couldn't be verified from adb command line, it is
verified when enabled from UI with few WIP display patches.
Just like initial db845c support, initializing the SMMU is
clearing the mapping used for the splash screen framebuffer,
which causes the device to hang during boot and recovery
needs a hard power reset. This can be worked around using:
fastboot oem select-display-panel none
To switch ON the display back run:
fastboot oem select-display-panel
But this only works on Beryllium devices running bootloader
version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
Android-9 based release. Newer bootloader version do not
support switching OFF the display panel at all. So we need
a few additional smmu patches (under review) from here to
boot to shell:
https://github.com/pundiramit/linux/commits/beryllium-mainline
Signed-off-by: Amit Pundir
---
v4: Added more downstream reserved memory regions. It probably
need more work, but for now I see adsp/cdsp/wlan remoteprocs
powering up properly. Also removed the regulator nodes not
required for the device, as suggested by Bjorn.
v3: Added a reserved-memory region from downstream kernel to fix
a boot regression with recent dma-pool changes in v5.8-rc6.
v2: Updated machine compatible string for seemingly inevitable
future quirks.
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 383 ++
2 files changed, 384 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 0f2c33d611df..3ef1b48bc0cb 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-beryllium.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
new file mode 100644
index ..0f9f61bf9fa4
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
@@ -0,0 +1,383 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "sdm845.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+
+/ {
+ model = "Xiaomi Technologies Inc. Beryllium";
+ compatible = "xiaomi,beryllium", "qcom,sdm845";
+
+ /* required for bootloader to select correct board */
+ qcom,board-id = <69 0>;
+ qcom,msm-id = <321 0x20001>;
+
+ aliases {
+ hsuart0 = &uart6;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&vol_up_pin_a>;
+
+ vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <&pm8998_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ vreg_s4a_1p8: vreg-s4a-1p8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_s4a_1p8";
+
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+};
+
+&adsp_pas {
+ status = "okay";
+ firmware-name = "qcom/sdm845/adsp.mdt";
+};
+
+&apps_rsc {
+ pm8998-rpmh-regulators {
+ compatible = "qcom,pm8998-rpmh-regulators";
+ qcom,pmic-id = "a";
+
+ vreg_l1a_0p875: ldo1 {
+ regulator-min-microvolt = <88>;
+ regulator-max-microvolt = <88>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l5a_0p8: ldo5 {
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <80>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l7a_1p8: ldo7 {
+ regulator-min-microvolt = <18
Re: [PATCH v2 1/2] arm64: dts: qcom: sdm845: Move reserved-memory to devices
On Sat, 13 Mar 2021 at 05:13, Bjorn Andersson
wrote:
>
> The reserved-memory regions used for carrying firmware to be run on the
> various cores and co-processors in a Qualcomm platform differs in size,
> placement and presence based on each device's feature set and security
> configuration.
>
> Rather than providing some basic set that works on the MTP and then
> piecemeal patch this up on the various devices, push the configuration
> of these regions out to the individual device dts files.
>
Smoke tested on sdm845-xiaomi-beryllium.
Tested-by: Amit Pundir
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v1:
> - Added lost memory-region to the db845c wlan node, as spotted by Doug.
>
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi| 90 +--
> arch/arm64/boot/dts/qcom/sdm845-db845c.dts| 87 ++
> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 87 ++
> .../boot/dts/qcom/sdm845-oneplus-common.dtsi | 78 +++-
> .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 45 ++
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 83 -
> .../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 86 ++
> 7 files changed, 431 insertions(+), 125 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> index 216a74f0057c..71ef92fd8909 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> @@ -153,36 +153,66 @@ panel_in_edp: endpoint {
> * all modifications to the memory map (from sdm845.dtsi) in one place.
> */
>
> -/*
> - * Our mpss_region is 8MB bigger than the default one and that conflicts
> - * with venus_mem and cdsp_mem.
> - *
> - * For venus_mem we'll delete and re-create at a different address.
> - *
> - * cdsp_mem isn't used on cheza right now so we won't bother re-creating it;
> but
> - * that also means we need to delete cdsp_pas.
> - */
> -/delete-node/ &venus_mem;
> -/delete-node/ &cdsp_mem;
> -/delete-node/ &cdsp_pas;
> -/delete-node/ &gpu_mem;
> -
> -/* Increase the size from 120 MB to 128 MB */
> -&mpss_region {
> - reg = <0 0x8e00 0 0x800>;
> -};
> -
> -/* Increase the size from 2MB to 8MB */
> -&rmtfs_mem {
> - reg = <0 0x88f0 0 0x80>;
> -};
> -
> / {
> reserved-memory {
> + tz_mem: memory@8620 {
> + reg = <0 0x8620 0 0x2d0>;
> + no-map;
> + };
> +
> + rmtfs_mem: memory@88f0 {
> + compatible = "qcom,rmtfs-mem";
> + reg = <0 0x88f0 0 0x80>;
> + no-map;
> +
> + qcom,client-id = <1>;
> + qcom,vmid = <15>;
> + };
> +
> + ipa_fw_mem: memory@8c40 {
> + reg = <0 0x8c40 0 0x1>;
> + no-map;
> + };
> +
> + ipa_gsi_mem: memory@8c41 {
> + reg = <0 0x8c41 0 0x5000>;
> + no-map;
> + };
> +
> + adsp_mem: memory@8c50 {
> + reg = <0 0x8c50 0 0x1a0>;
> + no-map;
> + };
> +
> + wlan_msa_mem: memory@8df0 {
> + reg = <0 0x8df0 0 0x10>;
> + no-map;
> + };
> +
> + mpss_region: memory@8e00 {
> + reg = <0 0x8e00 0 0x800>;
> + no-map;
> + };
> +
> venus_mem: memory@9600 {
> reg = <0 0x9600 0 0x50>;
> no-map;
> };
> +
> + mba_region: memory@9650 {
> + reg = <0 0x9650 0 0x20>;
> + no-map;
> + };
> +
> + slpi_mem: memory@9670 {
> + reg = <0 0x9670 0 0x140>;
> + no-map;
> + };
> +
> + spss_mem: memory@97b0 {
> + reg = <0 0x97b0 0 0x10>;
> + no-map;
> + };
> };
> };
>
> @@ -206,7 +236,6 @@ flash@0 {
> };
> };
>
> -
> &apps_rsc {
> pm
Re: [PATCH v3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
Hi Angelo,
On Thu, 11 Feb 2021 at 00:25, AngeloGioacchino Del Regno
wrote:
>
> Il 10/02/21 09:18, Amit Pundir ha scritto:
> > From: Sumit Semwal
> >
> > Enabling the Display panel for beryllium requires DSI
> > labibb regulators and panel dts nodes to be added.
> > It is also required to keep some of the regulators as
> > always-on.
> >
> > Signed-off-by: Sumit Semwal
> > Signed-off-by: Amit Pundir
> > ---
>
> Hello!
> Your patch looks good, however, I have a few concerns...
>
> > +&ibb {
> > + regulator-min-microvolt = <460>;
> > + regulator-max-microvolt = <600>;
> > +};
> > +
>
> I think you want to also configure overvoltage and overcurrent
> protection values for both LAB and IBB, as these regulators may be a bit
> dangerous if used without.
It turned out I can't boot if I set regulator-max-microamp lab/ibb
values from downstream DT. Verified it a few times and same result.
Here is the decompiled downstream DTB for reference:
https://pastebin.ubuntu.com/p/4nPxzq6zf7/, just in case.
I'm not sure if over current protection value is tied to max-microamp,
but I added it anyway along with pull-down and soft-start properties
in next version of this patch.
Regards,
Amit Pundir
> Besides that, even if it wouldn't be that dangerous, since the
> protection features are present, it would be nice to configure them
> properly as in the rare event that something bad happens, you would be
> able to save the hardware (or at least have a chance to!).
>
> > +&lab {
> > + regulator-min-microvolt = <460>;
> > + regulator-max-microvolt = <600>;
> > +};
> > +
>
> Same here.
>
> Yours,
> -- Angelo
[PATCH v4] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
From: Sumit Semwal
Enabling the Display panel for beryllium requires DSI
labibb regulators and panel dts nodes to be added.
It is also required to keep some of the regulators as
always-on.
Signed-off-by: Sumit Semwal
Signed-off-by: Amit Pundir
Reviewed-by: Konrad Dybcio
---
v4: Added Konrad's reviewed-by from v3. Added over current
protection, pull-down and soft-start properties. Couldn't
boot with downstream max-microamp values, so skipped it.
Smoke tested on v5.12-rc5.
v3: Addressed Konrad's concerns. Configured labibb regulators
explicitly based on downstream microvolt values. Display
comes up fine with default discharge-resistor-kohms and
soft-start-us properties, so didn't touch them.
Smoke tested on next-20210209.
v2: Rebased to mainline (v5.11-rc6) and fixed build warnings.
.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 71 +++
1 file changed, 71 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
index 86cbae63eaf7..7d029425336e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
@@ -157,6 +157,14 @@ vreg_l13a_2p95: ldo13 {
regulator-initial-mode = ;
};
+ vreg_l14a_1p8: ldo14 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-initial-mode = ;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
vreg_l17a_1p3: ldo17 {
regulator-min-microvolt = <1304000>;
regulator-max-microvolt = <1304000>;
@@ -191,6 +199,7 @@ vreg_l26a_1p2: ldo26 {
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
regulator-initial-mode = ;
+ regulator-boot-on;
};
};
};
@@ -200,6 +209,43 @@ &cdsp_pas {
firmware-name = "qcom/sdm845/cdsp.mdt";
};
+&dsi0 {
+ status = "okay";
+ vdda-supply = <&vreg_l26a_1p2>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "tianma,fhd-video";
+ reg = <0>;
+ vddi0-supply = <&vreg_l14a_1p8>;
+ vddpos-supply = <&lab>;
+ vddneg-supply = <&ibb>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
+
+ port {
+ tianma_nt36672a_in_0: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+};
+
+&dsi0_out {
+ remote-endpoint = <&tianma_nt36672a_in_0>;
+ data-lanes = <0 1 2 3>;
+};
+
+&dsi0_phy {
+ status = "okay";
+ vdds-supply = <&vreg_l1a_0p875>;
+};
+
&gcc {
protected-clocks = ,
,
@@ -215,6 +261,31 @@ zap-shader {
};
};
+&ibb {
+ regulator-min-microvolt = <460>;
+ regulator-max-microvolt = <600>;
+ regulator-over-current-protection;
+ regulator-pull-down;
+ regulator-soft-start;
+ qcom,discharge-resistor-kohms = <300>;
+};
+
+&lab {
+ regulator-min-microvolt = <460>;
+ regulator-max-microvolt = <600>;
+ regulator-over-current-protection;
+ regulator-pull-down;
+ regulator-soft-start;
+};
+
+&mdss {
+ status = "okay";
+};
+
+&mdss_mdp {
+ status = "okay";
+};
+
&mss_pil {
status = "okay";
firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
--
2.25.1
Re: [Freedreno] [PATCH 3/3] drm/msm/dpu: add support for clk and bw scaling for display
Hi Kalyan, On Tue, 24 Nov 2020 at 18:27, wrote: > > On 2020-11-08 23:25, Amit Pundir wrote: > > On Tue, 4 Aug 2020 at 21:09, Rob Clark wrote: > >> > >> On Thu, Jul 16, 2020 at 4:36 AM Kalyan Thota > >> wrote: > >> > > >> > This change adds support to scale src clk and bandwidth as > >> > per composition requirements. > >> > > >> > Interconnect registration for bw has been moved to mdp > >> > device node from mdss to facilitate the scaling. > >> > > >> > Changes in v1: > >> > - Address armv7 compilation issues with the patch (Rob) > >> > > >> > Signed-off-by: Kalyan Thota > >> > >> Reviewed-by: Rob Clark > >> > > > > Hi Kalyan, Rob, > > > > This patch broke the display on the PocoF1 phone > > (sdm845-xiaomi-beryllium.dts) running AOSP. > > I can boot to UI but the display is frozen soon after that and > > dmesg is full of following errors: > > > > [drm:dpu_core_perf_crtc_update:397] [dpu error]crtc-65: failed to > > update bus bw vote > > [drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth: > > 7649746kb > 680kb > > [drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance > > check -7 > > [drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth: > > 7649746kb > 680kb > > [drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance > > check -7 > > [drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth: > > 7649746kb > 680kb > > [drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance > > check -7 > > > > Here is the full dmesg https://pastebin.ubuntu.com/p/PcSdNgMnYw/. > > Georgi pointed out following patch but it didn't help, > > https://lore.kernel.org/dri-devel/20201027102304.945424-1-dmitry.barysh...@linaro.org/ > > Am I missing any other followup fix? > > > > Regards, > > Amit Pundir > > __ > > Hi Amit, > > Apologies for the delay. No worries at all. > > I have gone through the logs and referred to the below panel file for > the timings. > https://github.com/Matheus-Garbelini/Kernel-Sphinx-Pocophone-F1/blob/master/arch/arm64/boot/dts/qcom/dsi-panel-tianma-fhd-nt36672a-video.dtsi > > if the above is correct file, then below could be the possible root > cause. > > The panel back porch and pw is less and it is causing the prefill bw > requirement to shoot up per layer as currently we are not considering > front porch in the calculation. can you please try the attached patch in > the email as a solution and provide me the feedback, i'll post it as a > formal change. The attached patch worked for me. Thanks a lot for looking closely into this issue. Regards, Amit Pundir > > Thanks, > Kalyan > > _ > > Freedreno mailing list > > freedr...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [v1] drm/msm/dpu: consider vertical front porch in the prefill bw calculation
On Wed, 25 Nov 2020 at 15:33, Kalyan Thota wrote: > > In case of panels with low vertical back porch, the prefill bw > requirement will be high as we will have less time(vbp+pw) to > fetch and fill the hw latency buffers before start of first line > in active period. > > For ex: > Say hw_latency_line_buffers = 24, and if blanking vbp+pw = 10 > Here we need to fetch 24 lines of data in 10 line times. > This will increase the bw to the ratio of linebuffers to blanking. > > DPU hw can also fetch data during vertical front porch provided > interface prefetch is enabled. Use vfp in the prefill calculation > as dpu driver enables prefetch if the blanking is not sufficient > to fill the latency lines. Tested on Xiaomi Poco F1 (sdm845). Tested-by: Amit Pundir > > Signed-off-by: Kalyan Thota > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > index 7ea90d2..315b999 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > @@ -151,7 +151,7 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane, > u64 plane_bw; > u32 hw_latency_lines; > u64 scale_factor; > - int vbp, vpw; > + int vbp, vpw, vfp; > > pstate = to_dpu_plane_state(plane->state); > mode = &plane->state->crtc->mode; > @@ -164,6 +164,7 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane, > fps = drm_mode_vrefresh(mode); > vbp = mode->vtotal - mode->vsync_end; > vpw = mode->vsync_end - mode->vsync_start; > + vfp = mode->vsync_start - mode->vdisplay; > hw_latency_lines = dpu_kms->catalog->perf.min_prefill_lines; > scale_factor = src_height > dst_height ? > mult_frac(src_height, 1, dst_height) : 1; > @@ -176,7 +177,13 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane, > src_width * hw_latency_lines * fps * fmt->bpp * > scale_factor * mode->vtotal; > > - do_div(plane_prefill_bw, (vbp+vpw)); > + if ((vbp+vpw) > hw_latency_lines) > + do_div(plane_prefill_bw, (vbp+vpw)); > + else if ((vbp+vpw+vfp) < hw_latency_lines) > + do_div(plane_prefill_bw, (vbp+vpw+vfp)); > + else > + do_div(plane_prefill_bw, hw_latency_lines); > + > > pstate->plane_fetch_bw = max(plane_bw, plane_prefill_bw); > } > -- > 2.7.4 >
Re: [PATCH] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add audio support
On Sun, 14 Mar 2021 at 22:32, Joel Selvaraj wrote:
>
> This patch adds audio support for Xiaomi Poco F1 phone. Phone's primary
> Mic and 3.5mm Headphone jack are handled through the SDM845 sound card
> and WCD9340 codec.
>
Tested-by: Amit Pundir
> Signed-off-by: Joel Selvaraj
> ---
> .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 117 ++
> 1 file changed, 117 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> index 86cbae63eaf7..5b5786595cdb 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> @@ -5,6 +5,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include "sdm845.dtsi"
> #include "pm8998.dtsi"
> #include "pmi8998.dtsi"
> @@ -240,6 +242,28 @@ resin {
> };
> };
>
> +/* QUAT I2S Uses 1 I2S SD Line for audio on TAS2559/60 amplifiers */
> +&q6afedai {
> + qi2s@22 {
> + reg = <22>;
> + qcom,sd-lines = <0>;
> + };
> +};
> +
> +&q6asmdai {
> + dai@0 {
> + reg = <0>;
> + };
> +
> + dai@1 {
> + reg = <1>;
> + };
> +
> + dai@2 {
> + reg = <2>;
> + };
> +};
> +
> &qupv3_id_0 {
> status = "okay";
> };
> @@ -257,6 +281,73 @@ &sdhc_2 {
> cd-gpios = <&tlmm 126 GPIO_ACTIVE_HIGH>;
> };
>
> +&sound {
> + compatible = "qcom,db845c-sndcard";
> + pinctrl-0 = <&quat_mi2s_active
> + &quat_mi2s_sd0_active>;
> + pinctrl-names = "default";
> + model = "Xiaomi Poco F1";
> + audio-routing =
> + "RX_BIAS", "MCLK",
> + "AMIC1", "MIC BIAS1",
> + "AMIC2", "MIC BIAS2",
> + "AMIC3", "MIC BIAS3",
> + "MM_DL1", "MultiMedia1 Playback",
> + "MM_DL2", "MultiMedia2 Playback",
> + "MultiMedia3 Capture", "MM_UL3";
> +
> + mm1-dai-link {
> + link-name = "MultiMedia1";
> + cpu {
> + sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>;
> + };
> + };
> +
> + mm2-dai-link {
> + link-name = "MultiMedia2";
> + cpu {
> + sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA2>;
> + };
> + };
> +
> + mm3-dai-link {
> + link-name = "MultiMedia3";
> + cpu {
> + sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA3>;
> + };
> + };
> +
> + slim-dai-link {
> + link-name = "SLIM Playback";
> + cpu {
> + sound-dai = <&q6afedai SLIMBUS_0_RX>;
> + };
> +
> + platform {
> + sound-dai = <&q6routing>;
> + };
> +
> + codec {
> + sound-dai = <&wcd9340 0>;
> + };
> + };
> +
> + slimcap-dai-link {
> + link-name = "SLIM Capture";
> + cpu {
> + sound-dai = <&q6afedai SLIMBUS_0_TX>;
> + };
> +
> + platform {
> + sound-dai = <&q6routing>;
> + };
> +
> + codec {
> + sound-dai = <&wcd9340 1>;
> + };
> + };
> +};
> +
> &tlmm {
> gpio-reserved-ranges = <0 4>, <81 4>;
>
> @@ -285,6 +376,15 @@ sdc2_card_det_n: sd-card-det-n {
> function = "gpio";
> bias-pull-up;
> };
> +
> + wcd_intr_default: wcd_intr_default {
> + pins = <54>;
> + function = "gpio";
> +
> + input-enable;
> + bias-pull-down;
> + drive-strength = <2>;
> + };
> };
>
> &uart6 {
> @@ -345,6 +445,23 @@ &usb_1_qmpphy {
> vdda-pll-supply = <&vreg_l1a_0p875>;
> };
>
> +&wcd9340{
> + pinctrl-0 = <&wcd_intr_default>;
> + pinctrl-names = "default";
> + clock-names = "extclk";
> + clocks = <&rpmhcc RPMH_LN_BB_CLK2>;
> + reset-gpios = <&tlmm 64 0>;
> + vdd-buck-supply = <&vreg_s4a_1p8>;
> + vdd-buck-sido-supply = <&vreg_s4a_1p8>;
> + vdd-tx-supply = <&vreg_s4a_1p8>;
> + vdd-rx-supply = <&vreg_s4a_1p8>;
> + vdd-io-supply = <&vreg_s4a_1p8>;
> + qcom,micbias1-microvolt = <270>;
> + qcom,micbias2-microvolt = <180>;
> + qcom,micbias3-microvolt = <270>;
> + qcom,micbias4-microvolt = <270>;
> +};
> +
> &wifi {
> status = "okay";
>
> --
> 2.25.1
>
Re: [PATCH v9 0/3] Add Novatek NT36xxx touchscreen driver
On Thu, 29 Oct 2020 at 06:32, wrote: > > From: AngeloGioacchino Del Regno > > This patch series adds support for the Novatek NT36xxx Series' In-Cell > touchscreen (integrated into the DriverIC). > > This patch series has been tested against the following devices: > - Sony Xperia 10(SDM630 Ganges Kirin) > - Sony Xperia 10 Plus (SDM636 Ganges Mermaid) > Tested the patch series on Xiaomi Poco F1 (SDM845 Beryllium, Novatek NT36672A IC). For the whole series: Tested-by: Amit Pundir Regards, Amit Pundir > Changes in v2: > - Fixed sparse warnings from lkp kernel test robot > > Changes in v3 (as requested by Dmitry Torokhov): > - Using shorthand u16/u32 (sorry for the overlook!) > - Now using more input and touchscreen APIs > - Fixed useless workqueue involvements > - Removed useless locking > - Switched reads and writes to use regmap > - Moved header contents to nt36xxx.c > - Fixed reset gpio handling > - Other cleanups > - P.S.: Thanks, Dmitry! > > Changes in v4: > - Fixed regmap read length for CRC_ERR_FLAG final check > - Fixed YAML binding, as requested by Krzysztof Kozlowski > > Changes in v5: > - Replaced subsystem maintainer's name with .. mine, > usage of additionalProperties to unevaluatedProperties > and a typo fix for reset-gpios as per Rob Herring's review > - Changed compatible string as per Krzysztof K. request > - Renamed the novatek,nt36xxx.yaml file to just nt36xxx.yaml > in order to now reflect the driver name instead of the DT > compatible > - Fixed blank line at EOF > > Changes in v6: > - Removed include of_gpio.h, added mod_devicetable.h and > gpio/consumer.h > - Added kerneldoc to relevant functions/enum > - Used traditional patterns for error checking where possible > - Documented calls to usleep/msleep > - Using be16_to_cpu / get_unaligned_be16 where possible > - Added helper for CRC error check on retrieved buffer > - Decreased indentation in the CRC reboot recovery function > - Removed instances of error code sum > - Dropped all likely/unlikely optimization as per request > - Removed redundant reset_gpio checks > - Dropped of_match_ptr and ifdefs for CONFIG_OF > > Changes in v7: > - Fixed typo in nt36xxx.c > > Changes in v8: > - Fixed typo reset-gpio -> reset-gpios in dt-bindings > > Changes in v9: > - Includes are now sorted > - Used proposed sizeof variable instead of sizeof type > - Fixed a return value check for common pattern > - Added NULL check to devm_kasprintf call > - Returning ret on probe function to be consistent > > AngeloGioacchino Del Regno (3): > dt-bindings: Add vendor prefix for Novatek Microelectronics Corp. > Input: Add Novatek NT36xxx touchscreen driver > dt-bindings: touchscreen: Add binding for Novatek NT36xxx series > driver > > .../bindings/input/touchscreen/nt36xxx.yaml | 59 ++ > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > drivers/input/touchscreen/Kconfig | 12 + > drivers/input/touchscreen/Makefile| 1 + > drivers/input/touchscreen/nt36xxx.c | 894 ++ > drivers/input/touchscreen/nt36xxx.h | 122 +++ > 6 files changed, 1090 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/input/touchscreen/nt36xxx.yaml > create mode 100644 drivers/input/touchscreen/nt36xxx.c > create mode 100644 drivers/input/touchscreen/nt36xxx.h > > -- > 2.28.0 >
Re: [PATCH v9 0/3] Add Novatek NT36xxx touchscreen driver
Hi,
On Thu, 29 Oct 2020 at 06:32, wrote:
>
> From: AngeloGioacchino Del Regno
>
> This patch series adds support for the Novatek NT36xxx Series' In-Cell
> touchscreen (integrated into the DriverIC).
>
> This patch series has been tested against the following devices:
> - Sony Xperia 10(SDM630 Ganges Kirin)
> - Sony Xperia 10 Plus (SDM636 Ganges Mermaid)
Tested the patch series on Xiaomi Poco F1 (SDM845 Beryllium) using
Novatek NT36672A IC. May I suggest adding "novatek,nt36672a" in the
list of compatible of_device_id{} as well.
Regards,
Amit Pundir
>
> Changes in v2:
> - Fixed sparse warnings from lkp kernel test robot
>
> Changes in v3 (as requested by Dmitry Torokhov):
> - Using shorthand u16/u32 (sorry for the overlook!)
> - Now using more input and touchscreen APIs
> - Fixed useless workqueue involvements
> - Removed useless locking
> - Switched reads and writes to use regmap
> - Moved header contents to nt36xxx.c
> - Fixed reset gpio handling
> - Other cleanups
> - P.S.: Thanks, Dmitry!
>
> Changes in v4:
> - Fixed regmap read length for CRC_ERR_FLAG final check
> - Fixed YAML binding, as requested by Krzysztof Kozlowski
>
> Changes in v5:
> - Replaced subsystem maintainer's name with .. mine,
> usage of additionalProperties to unevaluatedProperties
> and a typo fix for reset-gpios as per Rob Herring's review
> - Changed compatible string as per Krzysztof K. request
> - Renamed the novatek,nt36xxx.yaml file to just nt36xxx.yaml
> in order to now reflect the driver name instead of the DT
> compatible
> - Fixed blank line at EOF
>
> Changes in v6:
> - Removed include of_gpio.h, added mod_devicetable.h and
> gpio/consumer.h
> - Added kerneldoc to relevant functions/enum
> - Used traditional patterns for error checking where possible
> - Documented calls to usleep/msleep
> - Using be16_to_cpu / get_unaligned_be16 where possible
> - Added helper for CRC error check on retrieved buffer
> - Decreased indentation in the CRC reboot recovery function
> - Removed instances of error code sum
> - Dropped all likely/unlikely optimization as per request
> - Removed redundant reset_gpio checks
> - Dropped of_match_ptr and ifdefs for CONFIG_OF
>
> Changes in v7:
> - Fixed typo in nt36xxx.c
>
> Changes in v8:
> - Fixed typo reset-gpio -> reset-gpios in dt-bindings
>
> Changes in v9:
> - Includes are now sorted
> - Used proposed sizeof variable instead of sizeof type
> - Fixed a return value check for common pattern
> - Added NULL check to devm_kasprintf call
> - Returning ret on probe function to be consistent
>
> AngeloGioacchino Del Regno (3):
> dt-bindings: Add vendor prefix for Novatek Microelectronics Corp.
> Input: Add Novatek NT36xxx touchscreen driver
> dt-bindings: touchscreen: Add binding for Novatek NT36xxx series
> driver
>
> .../bindings/input/touchscreen/nt36xxx.yaml | 59 ++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> drivers/input/touchscreen/Kconfig | 12 +
> drivers/input/touchscreen/Makefile| 1 +
> drivers/input/touchscreen/nt36xxx.c | 894 ++
> drivers/input/touchscreen/nt36xxx.h | 122 +++
> 6 files changed, 1090 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/touchscreen/nt36xxx.yaml
> create mode 100644 drivers/input/touchscreen/nt36xxx.c
> create mode 100644 drivers/input/touchscreen/nt36xxx.h
>
> --
> 2.28.0
>
[PATCH v2] ath10k: qmi: Skip host capability request for Xiaomi Poco F1
Workaround to get WiFi working on Xiaomi Poco F1 (sdm845)
phone. We get a non-fatal QMI_ERR_MALFORMED_MSG_V01 error
message in ath10k_qmi_host_cap_send_sync(), but we can still
bring up WiFi services successfully on AOSP if we ignore it.
We suspect either the host cap is not implemented or there
may be firmware specific issues. Firmware version is
QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1
qcom,snoc-host-cap-8bit-quirk didn't help. If I use this
quirk, then the host capability request does get accepted,
but we run into fatal "msa info req rejected" error and
WiFi interface doesn't come up.
Attempts are being made to debug the failure reasons but no
luck so far. Hence this device specific workaround instead
of checking for QMI_ERR_MALFORMED_MSG_V01 error message.
Tried ath10k/WCN3990/hw1.0/wlanmdsp.mbn from the upstream
linux-firmware project but it didn't help and neither did
building board-2.bin file from stock bdwlan* files.
This workaround will be removed once we have a viable fix.
Thanks to postmarketOS guys for catching this.
Signed-off-by: Amit Pundir
---
We dropped this workaround last time in the favor of
a generic dts quirk to skip host cap check. But that
is under under discussion for a while now,
https://lkml.org/lkml/2020/9/25/1119, so resending
this short term workaround for the time being.
v2: ath10k-check complained about a too long line last
time, so moved the comment to a new line.
drivers/net/wireless/ath/ath10k/qmi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c
b/drivers/net/wireless/ath/ath10k/qmi.c
index ae6b1f402adf..1c58b0ff1d29 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -653,7 +653,9 @@ static int ath10k_qmi_host_cap_send_sync(struct ath10k_qmi
*qmi)
/* older FW didn't support this request, which is not fatal */
if (resp.resp.result != QMI_RESULT_SUCCESS_V01 &&
- resp.resp.error != QMI_ERR_NOT_SUPPORTED_V01) {
+ resp.resp.error != QMI_ERR_NOT_SUPPORTED_V01 &&
+ /* Xiaomi Poco F1 workaround */
+ !of_machine_is_compatible("xiaomi,beryllium")) {
ath10k_err(ar, "host capability request rejected: %d\n",
resp.resp.error);
ret = -EINVAL;
goto out;
--
2.7.4
[RFC][PATCH] epoll: allow EPOLLWAKEUP flag if PM_SLEEP is enabled
I stumbled upon ENOMEM error from epoll_ctl() while bringing up Android-4.4 on a device that does not yet support PM_SLEEP. While looking into the problem, I found that ep_create_wakeup_source() reports ENOMEM if wakeup_source_register() returns NULL. ep_create_wakeup_source() assumes that NULL is only returned if we run into ENOMEM but NULL is also returned when CONFIG_PM_SLEEP is disabled. If CONFIG_PM_SLEEP is disabled, stripping the EPOLLWAKEUP flag seems to be a reasonable solution here, allowing the call to succeed, while dropping the wakeup logic. While returning EINVAL might also be a good solution, stripping the flag seems to follow the established behavior, as is done when the process doesn't have sufficient capabilities to block suspend. I'd appreciate any thoughts or feedback! Signed-off-by: Amit Pundir --- fs/eventpoll.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 473e09d..7a83079 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -1820,7 +1820,8 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd, goto error_tgt_fput; /* Check if EPOLLWAKEUP is allowed */ - if ((epds.events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND)) + if ((epds.events & EPOLLWAKEUP) && + (!capable(CAP_BLOCK_SUSPEND) || !IS_ENABLED(CONFIG_PM_SLEEP))) epds.events &= ~EPOLLWAKEUP; /* -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH v2] epoll: allow EPOLLWAKEUP flag if PM_SLEEP is enabled
ep_create_wakeup_source() reports ENOMEM if wakeup_source_register()
returns NULL. ep_create_wakeup_source() assumes that NULL is only
returned if we run into ENOMEM but NULL is also returned when
CONFIG_PM_SLEEP is disabled.
Signed-off-by: Amit Pundir
---
Changed in v2:
Using static inline functions instead of #ifdefs
---
fs/eventpoll.c |3 +--
include/uapi/linux/eventpoll.h | 12
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 473e09d..10f9c43 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1820,8 +1820,7 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd,
goto error_tgt_fput;
/* Check if EPOLLWAKEUP is allowed */
- if ((epds.events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
- epds.events &= ~EPOLLWAKEUP;
+ ep_epollwakeup_check(&epds.events);
/*
* We have to check that the file structure underneath the file
descriptor
diff --git a/include/uapi/linux/eventpoll.h b/include/uapi/linux/eventpoll.h
index 2c267bc..1d139c2 100644
--- a/include/uapi/linux/eventpoll.h
+++ b/include/uapi/linux/eventpoll.h
@@ -62,4 +62,16 @@ struct epoll_event {
} EPOLL_PACKED;
+#ifdef CONFIG_PM_SLEEP
+static inline void ep_epollwakeup_check(__u32 *epev)
+{
+ if ((*epev & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
+ *epev &= ~EPOLLWAKEUP;
+}
+#else
+static inline void ep_epollwakeup_check(__u32 *epev)
+{
+ *epev &= ~EPOLLWAKEUP;
+}
+#endif
#endif /* _UAPI_LINUX_EVENTPOLL_H */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] epoll: allow EPOLLWAKEUP flag if PM_SLEEP is enabled
On 13 November 2013 05:29, Rafael J. Wysocki wrote:
> On Wednesday, November 13, 2013 02:22:28 AM Amit Pundir wrote:
>> ep_create_wakeup_source() reports ENOMEM
>
> That needs to be fixed too. I suppose we can make the
> wakeup_source_register()
> stub for CONFIG_PM_SLEEP unset return ERR_PTR(-ENOSYS) or something like that
> and ep_create_wakeup_source() return that instead of -ENOMEM. It looks like
> eventpoll.c is the only user of it built for CONFIG_PM_SLEEP unset, but that
> needs to be double checked.
Instead of modifying wakeup_source_register() stub, what if I make
ep_create_wakeup_source() static inline as well and use its stub to
return -ENOSYS when CONFIG_PM_SLEEP is not set?
ep_create_wakeup_source() is used only in fs/eventpoll.c anyway.
>
>> if wakeup_source_register()
>> returns NULL. ep_create_wakeup_source() assumes that NULL is only
>> returned if we run into ENOMEM but NULL is also returned when
>> CONFIG_PM_SLEEP is disabled.
>>
>> Signed-off-by: Amit Pundir
>> ---
>> Changed in v2:
>> Using static inline functions instead of #ifdefs
>> ---
>> fs/eventpoll.c |3 +--
>> include/uapi/linux/eventpoll.h | 12
>> 2 files changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
>> index 473e09d..10f9c43 100644
>> --- a/fs/eventpoll.c
>> +++ b/fs/eventpoll.c
>> @@ -1820,8 +1820,7 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd,
>> goto error_tgt_fput;
>>
>> /* Check if EPOLLWAKEUP is allowed */
>> - if ((epds.events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
>> - epds.events &= ~EPOLLWAKEUP;
>> + ep_epollwakeup_check(&epds.events);
>
> The "check" part of the name kind of suggests that the function will not
> change
> things. What about ep_adjust_epollwakeup() or something along these lines?
I see couple of ep_set_* functions in eventpoll.c. Does it make sense
to have something like ep_set_epollwakeup()?
>
> And why don't you pass a pointer to epds to it? Wouldn't it be cleaner this
> way?
Ok.
Regards,
Amit Pundir
>
>>
>> /*
>>* We have to check that the file structure underneath the file
>> descriptor
>> diff --git a/include/uapi/linux/eventpoll.h b/include/uapi/linux/eventpoll.h
>> index 2c267bc..1d139c2 100644
>> --- a/include/uapi/linux/eventpoll.h
>> +++ b/include/uapi/linux/eventpoll.h
>> @@ -62,4 +62,16 @@ struct epoll_event {
>> } EPOLL_PACKED;
>>
>>
>> +#ifdef CONFIG_PM_SLEEP
>> +static inline void ep_epollwakeup_check(__u32 *epev)
>> +{
>> + if ((*epev & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
>> + *epev &= ~EPOLLWAKEUP;
>> +}
>> +#else
>> +static inline void ep_epollwakeup_check(__u32 *epev)
>> +{
>> + *epev &= ~EPOLLWAKEUP;
>> +}
>> +#endif
>> #endif /* _UAPI_LINUX_EVENTPOLL_H */
>
> Thanks!
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] PM: Print pending wakeup IRQ preventing suspend
From: Todd Poynor
Currently when a pending wakeup irq stops suspend, it can be difficult
to determine why suspend was prevented and which IRQ was actually
responsible. In order to help debug such situation, this patch prints the
IRQ number and action name of that pending wakeup irq.
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: linux...@vger.kernel.org
Cc: Android Kernel Team
Acked-by: Pavel Machek
Signed-off-by: Todd Poynor
[Amit Pundir: Reworded the commit message]
Signed-off-by: Amit Pundir
---
Resending this patch assuming that it might have got lost in between merge
window rush last time and now people might have some time to look at it.
kernel/irq/pm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index abcd6ca..c2bc8d9 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -109,8 +109,13 @@ int check_wakeup_irqs(void)
* can abort suspend.
*/
if (irqd_is_wakeup_set(&desc->irq_data)) {
- if (desc->depth == 1 && desc->istate & IRQS_PENDING)
+ if (desc->depth == 1 && desc->istate & IRQS_PENDING) {
+ pr_info("Wakeup IRQ %d %s pending, suspend
aborted\n",
+ irq,
+ desc->action && desc->action->name ?
+ desc->action->name : "");
return -EBUSY;
+ }
continue;
}
/*
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] PM: Print wall time at suspend entry and exit
From: Todd Poynor
Existing timestamps in a dmesg only log suspend activities
(e.g. filesystem syncs, freezing/unfreezing tasks etc) while the
system has already started to enter/exit the suspend state.
Sometimes it is handy to have suspend entry/exit overhead
information while debugging suspend issues. This patch print
markers with wall timestamps at suspend Entry and Exit in
the kernel log. These timestamps can be used to compute how
long the system spent in low-power suspend state plus the
entry/exit overhead.
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: linux...@vger.kernel.org
Cc: Android Kernel Team
Signed-off-by: Todd Poynor
[Amit Pundir: Reworded the commit message]
Signed-off-by: Amit Pundir
---
Resending this patch assuming that it might have got lost in between merge
window rush last time and now people might have some time to look at it.
kernel/power/suspend.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 18c6219..5390c6c 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -443,6 +444,18 @@ static int enter_state(suspend_state_t state)
return error;
}
+static void pm_suspend_marker(char *annotation)
+{
+ struct timespec ts;
+ struct rtc_time tm;
+
+ getnstimeofday(&ts);
+ rtc_time_to_tm(ts.tv_sec, &tm);
+ pr_info("PM: suspend %s %d-%02d-%02d %02d:%02d:%02d.%09lu UTC\n",
+ annotation, tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
+ tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
+}
+
/**
* pm_suspend - Externally visible function for suspending the system.
* @state: System sleep state to enter.
@@ -457,6 +470,7 @@ int pm_suspend(suspend_state_t state)
if (state <= PM_SUSPEND_ON || state >= PM_SUSPEND_MAX)
return -EINVAL;
+ pm_suspend_marker("entry");
error = enter_state(state);
if (error) {
suspend_stats.fail++;
@@ -464,6 +478,7 @@ int pm_suspend(suspend_state_t state)
} else {
suspend_stats.success++;
}
+ pm_suspend_marker("exit");
return error;
}
EXPORT_SYMBOL(pm_suspend);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v2] epoll: allow EPOLLWAKEUP flag if PM_SLEEP is enabled
On 14 November 2013 03:14, Rafael J. Wysocki wrote: > On Wednesday, November 13, 2013 01:35:38 PM Amit Pundir wrote: >> On 13 November 2013 05:29, Rafael J. Wysocki wrote: >> > On Wednesday, November 13, 2013 02:22:28 AM Amit Pundir wrote: >> >> ep_create_wakeup_source() reports ENOMEM >> > >> > That needs to be fixed too. I suppose we can make the >> > wakeup_source_register() >> > stub for CONFIG_PM_SLEEP unset return ERR_PTR(-ENOSYS) or something like >> > that >> > and ep_create_wakeup_source() return that instead of -ENOMEM. It looks >> > like >> > eventpoll.c is the only user of it built for CONFIG_PM_SLEEP unset, but >> > that >> > needs to be double checked. >> >> Instead of modifying wakeup_source_register() stub, what if I make >> ep_create_wakeup_source() static inline as well and use its stub to >> return -ENOSYS when CONFIG_PM_SLEEP is not set? >> ep_create_wakeup_source() is used only in fs/eventpoll.c anyway. > > Well, you can do that too. > On second thought we may skip modifying ep_create_wakeup_source() or wakeup_source_register() altogether because once we drop EPOLLWAKEUP from epoll events mask(if PM_SLEEP is unset) then I don't see us running into ep_create_wakeup_source() again. And the only reason for ep_create_wakeup_source() failure will be -ENOMEM as far as I can see. >> >> if wakeup_source_register() >> >> returns NULL. ep_create_wakeup_source() assumes that NULL is only >> >> returned if we run into ENOMEM but NULL is also returned when >> >> CONFIG_PM_SLEEP is disabled. >> >> >> >> Signed-off-by: Amit Pundir >> >> --- >> >> Changed in v2: >> >> Using static inline functions instead of #ifdefs >> >> --- >> >> fs/eventpoll.c |3 +-- >> >> include/uapi/linux/eventpoll.h | 12 >> >> 2 files changed, 13 insertions(+), 2 deletions(-) >> >> >> >> diff --git a/fs/eventpoll.c b/fs/eventpoll.c >> >> index 473e09d..10f9c43 100644 >> >> --- a/fs/eventpoll.c >> >> +++ b/fs/eventpoll.c >> >> @@ -1820,8 +1820,7 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, >> >> fd, >> >> goto error_tgt_fput; >> >> >> >> /* Check if EPOLLWAKEUP is allowed */ >> >> - if ((epds.events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND)) >> >> - epds.events &= ~EPOLLWAKEUP; >> >> + ep_epollwakeup_check(&epds.events); >> > >> > The "check" part of the name kind of suggests that the function will not >> > change >> > things. What about ep_adjust_epollwakeup() or something along these lines? >> >> I see couple of ep_set_* functions in eventpoll.c. Does it make sense >> to have something like ep_set_epollwakeup()? > > This particular one doesn't really set anything. I suppose that a name like > "ep_take_care_of_epollwakeup" might be somewhat closer to what it really does > ... I'm running out of ideas on this one, lets go with "ep_take_care_of_epollwakeup". Regards, Amit Pundir > > Thanks! > > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] epoll: drop EPOLLWAKEUP if PM_SLEEP is disabled
Drop EPOLLWAKEUP from epoll events mask if CONFIG_PM_SLEEP is disabled.
Signed-off-by: Amit Pundir
---
Changes in v3:
Renamed ep_epollwakeup_check() to ep_take_care_of_epollwakeup().
Didn't update ep_create_wakeup_source() to return -ENOSYS if PM_SLEEP is unset.
---
fs/eventpoll.c |3 +--
include/uapi/linux/eventpoll.h | 13 -
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 473e09d..dbf382b 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1820,8 +1820,7 @@ SYSCALL_DEFINE4(epoll_ctl, int, epfd, int, op, int, fd,
goto error_tgt_fput;
/* Check if EPOLLWAKEUP is allowed */
- if ((epds.events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
- epds.events &= ~EPOLLWAKEUP;
+ ep_take_care_of_epollwakeup(&epds);
/*
* We have to check that the file structure underneath the file
descriptor
diff --git a/include/uapi/linux/eventpoll.h b/include/uapi/linux/eventpoll.h
index 2c267bc..bc81fb2 100644
--- a/include/uapi/linux/eventpoll.h
+++ b/include/uapi/linux/eventpoll.h
@@ -61,5 +61,16 @@ struct epoll_event {
__u64 data;
} EPOLL_PACKED;
-
+#ifdef CONFIG_PM_SLEEP
+static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
+{
+ if ((epev->events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND))
+ epev->events &= ~EPOLLWAKEUP;
+}
+#else
+static inline void ep_take_care_of_epollwakeup(struct epoll_event *epev)
+{
+ epev->events &= ~EPOLLWAKEUP;
+}
+#endif
#endif /* _UAPI_LINUX_EVENTPOLL_H */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 2/2] PM: Suspend: Print wall time at suspend entry and exit
From: Todd Poynor
Existing printk timestamps in a dmesg only log suspend activities
(e.g. filesystem syncs, freezing/unfreezing tasks etc) while the
system has already started to enter/exit the suspend state. Sometimes
it is handy to have suspend entry/exit overhead information while
debugging suspend issues. This patch print markers with wall
timestamps at suspend Entry and Exit in the kernel log. These
timestamps can be used to compute how long the system spent in
low-power suspend state plus the entry/exit overhead.
This patch comes from the Android patch set, where its been used to
help diagnose battery life problems in various Android-based devices.
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: linux...@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Cc: Sumit Semwal
Signed-off-by: Todd Poynor
[Amit Pundir: Reworded the commit message]
Signed-off-by: Amit Pundir
---
The original patch was submitted to linux-pm couple of years back but
I could not trace any feedback or activity thereafter. Hence I'm
resubmitting this change.
kernel/power/suspend.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index ed35a47..28726b6 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -417,6 +418,18 @@ static int enter_state(suspend_state_t state)
return error;
}
+static void pm_suspend_marker(char *annotation)
+{
+ struct timespec ts;
+ struct rtc_time tm;
+
+ getnstimeofday(&ts);
+ rtc_time_to_tm(ts.tv_sec, &tm);
+ pr_info("PM: suspend %s %d-%02d-%02d %02d:%02d:%02d.%09lu UTC\n",
+ annotation, tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
+ tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
+}
+
/**
* pm_suspend - Externally visible function for suspending the system.
* @state: System sleep state to enter.
@@ -431,6 +444,7 @@ int pm_suspend(suspend_state_t state)
if (state <= PM_SUSPEND_ON || state >= PM_SUSPEND_MAX)
return -EINVAL;
+ pm_suspend_marker("entry");
error = enter_state(state);
if (error) {
suspend_stats.fail++;
@@ -438,6 +452,7 @@ int pm_suspend(suspend_state_t state)
} else {
suspend_stats.success++;
}
+ pm_suspend_marker("exit");
return error;
}
EXPORT_SYMBOL(pm_suspend);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 1/2] PM: Print pending wakeup IRQ preventing suspend to dmesg
From: Todd Poynor
Currently when a pending wakeup irq stops suspend, it can be difficult
to determine why suspend was prevented and which IRQ was actually
responsible.
In order to help debug these situations, this patch prints the IRQ
number and action name of that pending wakeup irq which prevents suspend.
This patch comes from the Android patch set, where its been used to debug
suspend problems.
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: linux...@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Cc: Sumit Semwal
Signed-off-by: Todd Poynor
[Amit Pundir: Reworded the commit message]
Signed-off-by: Amit Pundir
---
kernel/irq/pm.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index abcd6ca..c2bc8d9 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -109,8 +109,13 @@ int check_wakeup_irqs(void)
* can abort suspend.
*/
if (irqd_is_wakeup_set(&desc->irq_data)) {
- if (desc->depth == 1 && desc->istate & IRQS_PENDING)
+ if (desc->depth == 1 && desc->istate & IRQS_PENDING) {
+ pr_info("Wakeup IRQ %d %s pending, suspend
aborted\n",
+ irq,
+ desc->action && desc->action->name ?
+ desc->action->name : "");
return -EBUSY;
+ }
continue;
}
/*
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 0/2] Minor Suspend debugging patches from Android
Couple of PM patches from Android tree printing Suspend debug messages. These messages are used to help debug PM related issues on Android based devices and look useful enough to troubleshoot PM issues on generic Linux devices as well. I'd greatly appreciate any feedback or comments! Todd Poynor (2): PM: Print pending wakeup IRQ preventing suspend to dmesg PM: Suspend: Print wall time at suspend entry and exit kernel/irq/pm.c|7 ++- kernel/power/suspend.c | 15 +++ 2 files changed, 21 insertions(+), 1 deletion(-) Cc: Todd Poynor Cc: Pavel Machek Cc: Thomas Gleixner Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: linux...@vger.kernel.org Cc: Android Kernel Team Cc: John Stultz Cc: Sumit Semwal -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 1/2] usb: gadget: configfs: add MTP function
This MTP function is based on years of work originally done in the Android kernel tree by: Mike Lockwood Benoit Goby Colin Cross Arve Hjønnevåg Peter Oh Greg Hackmann Badhri Jagan Sridharan I've folded the series up to make it easier to review, and to provide a coherent patch description. Post Gingerbread (Android v2.3), Android dropped USB Mass Storage in favor of Media Transfer Protocal (MTP), which is widely used for transferring media files to digital music players and similar applications. This USB gadget function implements MTP functionalty. Historically this function has been a part of Android composite gadget driver. Android composite driver was Android's solution for dynamic gadget function switching prior to the ConfigFS gadget being merged. There were failed few attempts in past http://marc.info/?l=linux-usb&m=132451695808552 to upstream Android composite driver as well. Now this Android MTP gadget function has been re-implemented so as to be used as a generic ConfigFS function instead. Again, many thanks to Mike, Benoit, Colin, Arve, Peter, Greg and Badhri, as they are the real authors of this work. However, I've folded their patches together and modified it enough that I don't want them to be blamed for any mistakes I've made condensing their patches down. Cc: Mike Lockwood Cc: Benoit Goby Cc: Colin Cross Cc: Arve Hjønnevåg Cc: Peter Oh Cc: Greg Hackmann Cc: Badhri Jagan Sridharan Cc: Android Kernel Team Cc: Greg Kroah-Hartman Cc: Jonathan Corbet Cc: Felipe Balbi Cc: Andrzej Pietrasiewicz Cc: Laurent Pinchart Cc: Yegor Yefremov Cc: Philippe Reynes Cc: John Stultz Cc: Sumit Semwal Signed-off-by: Amit Pundir --- Documentation/ABI/testing/configfs-usb-gadget-mtp |7 + Documentation/usb/gadget-testing.txt | 24 + drivers/usb/gadget/Kconfig| 13 + drivers/usb/gadget/function/Makefile |2 + drivers/usb/gadget/function/f_mtp.c | 1365 + include/linux/usb/f_mtp.h | 23 + include/uapi/linux/usb/f_mtp.h| 61 + 7 files changed, 1495 insertions(+) create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-mtp create mode 100644 drivers/usb/gadget/function/f_mtp.c create mode 100644 include/linux/usb/f_mtp.h create mode 100644 include/uapi/linux/usb/f_mtp.h diff --git a/Documentation/ABI/testing/configfs-usb-gadget-mtp b/Documentation/ABI/testing/configfs-usb-gadget-mtp new file mode 100644 index 000..6738bee --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-mtp @@ -0,0 +1,7 @@ +What: /config/usb-gadget/gadget/functions/mtp.name +Date: Aug 2015 +KernelVersion: 4.2 +Description: The purpose of this directory is to create and remove it. + + A corresponding USB function instance is created/removed. + There are no attributes here. diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 5926780..7fb8494d4 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -20,6 +20,7 @@ provided by gadgets. 17. UAC2 function 18. UVC function 19. PRINTER function +20. MTP function 1. ACM function @@ -771,3 +772,26 @@ host: More advanced testing can be done with the prn_example described in Documentation/usb/gadget-printer.txt. + +20. MTP function +=== + +The function is provided by usb_f_mtp.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "mtp". +The function directory is intentionally empty and has no attributes as such. + +After creating the mtp function directory, link mtp function with the gadget +configuration by creating symbolic link, enable the gadget by writing a +suitable string to usb_gadget//UDC and start the mtp userspace daemon. + +Testing the mtp function + + +On the device: enable the gadget, and start the mtp userspace daemon. +On the host: if configured correctly the media storage device should auto-mount +itself, or use Linux mtp-tools package to browse/transfer the media content +instead. diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index bcf83c0..65d110d 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -199,6 +199,9 @@ config USB_F_HID config USB_F_PRINTER tristate +config USB_F_MTP + tristate + choice tristate "USB Gadget Drivers" default USB_ETH @@ -451,6 +454,16 @@ config USB_CONFIGFS_F_PRINTER For more information, see Documentation/usb/gadget_printer.txt which includes sample code for accessing the device file. +config USB_CONFIGFS_F_MTP + bool "MTP gadget" + depends on USB_CONFIGFS + select USB_F_MTP +
[RFC][PATCH 2/2] usb: gadget: configfs: notify userspace of usb state changes
This is more of an RFC than an actual submission. There are few
scattered #ifdefs..#endifs here and there which still need to be
taken care of before going for actual submission.
Currently there is no way with the upstream ConfigFS gadget to
communicate state changes (connected, disconnected, configured), at
the gadget level. Instead such state changes are handled function by
function independently I presume. This is problematic, because some
coordination between the functions, across the state changes, may be
desired at the userspace level. Thus to address this issue, this
patch send uevents to allow userspace to be notified of these usb
state changes, allowing userspace to respond and configure the
configfs gadget appropriately.
This patch is based on an Android patchset originaly authored by
Badhri Jagan Sridharan to send uevent notifications
to Android userpace for USB state changes. I've folded his patches
together and modified it enough that I don't want him to be blamed for
any mistakes I've made condensing his patches down.
This patch introduces USB_CONFIGFS_UEVENT Kconfig to handle userspace
notifications of usb state changes, and add setup and disconnect
functions to intercept the setup requests from the usb_core. It also
creates a sysfs device class entry and a device attribute (state) to
read and respond to gadget's current state from userspace. As of now
this sysfs device class (/sys/class/android_usb) and gadget device
(/sys/class/android_usb/android0) with state attribute
(/sys/class/android_usb/android0/state) are strictly tied up to
facilitate Android userspace requests. But going forward we may want
to bring all function devices (hid, printer etc) under a unified usb
gadget device class e.g. /sys/class/usb_gadget/g_{func0,func1} etc..
Also I think it make sense to add this state attribute to the configfs
usb gadget itself i.e. have something like /config/usb_gadget/g1/state
to read USB gadget's current state. Since it is going to be consistent
throughout all the functions tied up to that gadget.
Again this is just an initial RFC, thoughts and feedback would be
greatly appreciated.
Cc: Mike Lockwood
Cc: Benoit Goby
Cc: Colin Cross
Cc: Arve Hjønnevåg
Cc: Peter Oh
Cc: Greg Hackmann
Cc: Badhri Jagan Sridharan
Cc: Android Kernel Team
Cc: Greg Kroah-Hartman
Cc: Jonathan Corbet
Cc: Felipe Balbi
Cc: Andrzej Pietrasiewicz
Cc: Laurent Pinchart
Cc: Yegor Yefremov
Cc: Philippe Reynes
Cc: John Stultz
Cc: Sumit Semwal
Signed-off-by: Amit Pundir
---
drivers/usb/gadget/Kconfig| 8 ++
drivers/usb/gadget/configfs.c | 201 +-
2 files changed, 207 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 65d110d..e1d1fc1 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -464,6 +464,14 @@ config USB_CONFIGFS_F_MTP
the file level. Thus exposing the relevant content but hiding
the system/restricted files.
+config USB_CONFIGFS_UEVENT
+ bool "Uevent notification of Gadget state"
+ depends on USB_CONFIGFS
+ help
+ Enable uevent notifications to userspace when the gadget
+ state changes. The gadget can be in any of the following
+ three states: "CONNECTED/DISCONNECTED/CONFIGURED"
+
source "drivers/usb/gadget/legacy/Kconfig"
endchoice
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 289e201..1575343 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -9,6 +9,15 @@
#include "u_f.h"
#include "u_os_desc.h"
+#ifdef CONFIG_USB_CONFIGFS_UEVENT
+#include
+#include
+#include
+
+static struct class *usb_gadget_class;
+static struct device *usb_gadget_device;
+#endif
+
int check_user_usb_string(const char *name,
struct usb_gadget_strings *stringtab_dev)
{
@@ -63,6 +72,12 @@ struct gadget_info {
bool use_os_desc;
char b_vendor_code;
char qw_sign[OS_STRING_QW_SIGN_LEN];
+#ifdef CONFIG_USB_CONFIGFS_UEVENT
+ bool connected;
+ bool sw_connected;
+ struct work_struct work;
+ struct device *dev;
+#endif
};
struct config_usb_cfg {
@@ -1444,13 +1459,143 @@ static void configfs_composite_unbind(struct
usb_gadget *gadget)
set_gadget_data(gadget, NULL);
}
+#ifdef CONFIG_USB_CONFIGFS_UEVENT
+static ssize_t state_show(struct device *pdev, struct device_attribute *attr,
+ char *buf)
+{
+ struct gadget_info *dev = dev_get_drvdata(pdev);
+ struct usb_composite_dev *cdev;
+ char *state = "DISCONNECTED";
+ unsigned long flags;
+
+ if (!dev)
+ goto out;
+
+ cdev = &dev->cdev;
+
+ if (!cdev)
+ goto out;
+
+ spin_lock_irqsave(&cdev->lock, flags);
+ if (cdev->config)
+
[RFC][PATCH 0/2] usb: gadget: add MTP function and Uevent userspace notifications
RFC on Android's ConfigFS based MTP function implementation and usage of Uevents to notify the userspace about the USB state changes. The MTP function is based on years of work originally done in the Android kernel tree by: Mike Lockwood Benoit Goby Colin Cross Arve Hjønnevåg Peter Oh Greg Hackmann Badhri Jagan Sridharan The Uevent notification patch is more of an RFC than an actual submission. It is based on Android patchset originaly authored by Badhri to send uevent notifications to Android userpace for USB state changes. I've folded the series up to make it easier to review, provided a coherent patch description and modified it enough that I don't want them to be blamed for any mistakes I've made condensing their patches down. Thoughts and feedback would be appreciated. Thanks, Amit Pundir Cc: Mike Lockwood Cc: Benoit Goby Cc: Colin Cross Cc: Arve Hjønnevåg Cc: Peter Oh Cc: Greg Hackmann Cc: Badhri Jagan Sridharan Cc: Android Kernel Team Cc: Greg Kroah-Hartman Cc: Jonathan Corbet Cc: Felipe Balbi Cc: Andrzej Pietrasiewicz Cc: Laurent Pinchart Cc: Yegor Yefremov Cc: Philippe Reynes Cc: John Stultz Cc: Sumit Semwal Amit Pundir (2): usb: gadget: configfs: add MTP function usb: gadget: configfs: notify userspace of usb state changes Documentation/ABI/testing/configfs-usb-gadget-mtp |7 + Documentation/usb/gadget-testing.txt | 24 + drivers/usb/gadget/Kconfig| 21 + drivers/usb/gadget/configfs.c | 201 ++- drivers/usb/gadget/function/Makefile |2 + drivers/usb/gadget/function/f_mtp.c | 1365 + include/linux/usb/f_mtp.h | 23 + include/uapi/linux/usb/f_mtp.h| 61 + 8 files changed, 1702 insertions(+), 2 deletions(-) create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-mtp create mode 100644 drivers/usb/gadget/function/f_mtp.c create mode 100644 include/linux/usb/f_mtp.h create mode 100644 include/uapi/linux/usb/f_mtp.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/2] usb: gadget: configfs: add MTP function
On 14 August 2015 at 02:11, Krzysztof Opasiak wrote: > > > On 08/13/2015 09:57 PM, Greg Kroah-Hartman wrote: >> >> On Thu, Aug 13, 2015 at 09:34:46PM +0200, Krzysztof Opasiak wrote: >>> >>> Hello, >>> >>> On 08/13/2015 09:12 PM, Amit Pundir wrote: >>>> >>>> his MTP function is based on years of work originally done in the >>>> Android kernel tree by: >>>> Mike Lockwood >>>> Benoit Goby >>>> Colin Cross >>>> Arve Hjønnevåg >>>> Peter Oh >>>> Greg Hackmann >>>> Badhri Jagan Sridharan >>>> I've folded the series up to make it easier to review, and to provide >>>> a coherent patch description. >>>> >>>> Post Gingerbread (Android v2.3), Android dropped USB Mass Storage >>>> in favor of Media Transfer Protocal (MTP), which is widely used for >>>> transferring media files to digital music players and similar >>>> applications. This USB gadget function implements MTP functionalty. >>>> >>>> Historically this function has been a part of Android composite >>>> gadget driver. Android composite driver was Android's solution >>>> for dynamic gadget function switching prior to the ConfigFS gadget >>>> being merged. There were failed few attempts in past >>>> http://marc.info/?l=linux-usb&m=132451695808552 to upstream Android >>>> composite driver as well. Now this Android MTP gadget function has been >>>> re-implemented so as to be used as a generic ConfigFS function instead. >>>> >>>> Again, many thanks to Mike, Benoit, Colin, Arve, Peter, Greg and Badhri, >>>> as they are the real authors of this work. However, I've folded their >>>> patches together and modified it enough that I don't want them to be >>>> blamed for any mistakes I've made condensing their patches down. >>>> >>>> Cc: Mike Lockwood >>>> Cc: Benoit Goby >>>> Cc: Colin Cross >>>> Cc: Arve Hjønnevåg >>>> Cc: Peter Oh >>>> Cc: Greg Hackmann >>>> Cc: Badhri Jagan Sridharan >>>> Cc: Android Kernel Team >>>> Cc: Greg Kroah-Hartman >>>> Cc: Jonathan Corbet >>>> Cc: Felipe Balbi >>>> Cc: Andrzej Pietrasiewicz >>>> Cc: Laurent Pinchart >>>> Cc: Yegor Yefremov >>>> Cc: Philippe Reynes >>>> Cc: John Stultz >>>> Cc: Sumit Semwal >>>> Signed-off-by: Amit Pundir >>> >>> >>> In my humble opinion adding such function to Linux kernel doesn't make >>> any >>> sense. By design, MTP is a protocol which requires access to userspace >>> features esp. file system. It is very important to run MTP daemon with >>> suitable user and LSM label and many many other issues which should be >>> handled by userspace access policy. >>> >>> Moreover this is not a fully functional USB function but only some >>> interface >>> which can be used by mtp-responder (mtp-daemon - call it as you like) to >>> communicate with host. As we have FunctionFS which allows to implement >>> any >>> USB function in as a userspace service. As MTP nature is more related to >>> userspace I think that porting MTP daemon to use this is a right way to >>> go. >>> This should be much more reasonable than adding new function which also >>> requires daemon for proper working. So why add another interface while we >>> can use a generic one? Fairly valid point. I did see MTP mentioned in FunctionFS context in Documentation/usb/functionfs.txt but I could not find an open userpsace MTP daemon implementation based on F_FS to try. >> >> >> Isn't there already a userspace MTP daemon that uses the existing >> functionfs for usb gadgets? I thought I remember seeing that >> somewhere... >> > > I've found some interesting link[2] which may mean that Sailfish OS guys has > some mtp implementation with functionfs backend: > > <<<<< cite > > - /dev/mtp > mtp functionfs rw,relatime > >>>>>> cite > > Started digging and got it! > > This looks like mtp with ffs backend: > > https://github.com/nemomobile/buteo-mtp Thanks for the pointer. This "buteo-mtp" looks interesting. Regards, Amit Pundir > > Didn't tested, even didn't try to compile, no guarantee;) > > Footnotes: > 1 - > http://reviewjolla.blogspot.com/2014/06/techspecs-android-on-jolla-phone.html > > > Best regards, > > -- > Krzysztof Opasiak > Samsung R&D Institute Poland > Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mmc: block: improve logging of handling emmc timeouts
From: Ken Sumrall
Add some logging to make it clear just how the emmc timeout
was handled.
Cc: Ulf Hansson
Cc: Adrian Hunter
Cc: Shawn Lin
Cc: Jon Hunter
Cc: Grant Grundler
Cc: Luca Porzio
Cc: Android Kernel Team
Cc: Sumit Semwal
Cc: John Stultz
Signed-off-by: Ken Sumrall
[AmitP: cherry-picked this Android patch from aosp common kernel android-4.4]
Signed-off-by: Amit Pundir
---
drivers/mmc/card/block.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 9c69e21..e737c81 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -948,18 +948,25 @@ static int mmc_blk_cmd_error(struct request *req, const
char *name, int error,
req->rq_disk->disk_name, "timed out", name, status);
/* If the status cmd initially failed, retry the r/w cmd */
- if (!status_valid)
+ if (!status_valid) {
+ pr_err("%s: status not valid, retrying timeout\n",
+ req->rq_disk->disk_name);
return ERR_RETRY;
+ }
/*
* If it was a r/w cmd crc error, or illegal command
* (eg, issued in wrong state) then retry - we should
* have corrected the state problem above.
*/
- if (status & (R1_COM_CRC_ERROR | R1_ILLEGAL_COMMAND))
+ if (status & (R1_COM_CRC_ERROR | R1_ILLEGAL_COMMAND)) {
+ pr_err("%s: command error, retrying timeout\n",
+ req->rq_disk->disk_name);
return ERR_RETRY;
+ }
/* Otherwise abort the command */
+ pr_err("%s: not retrying timeout\n", req->rq_disk->disk_name);
return ERR_ABORT;
default:
--
2.7.4
[PATCH v2] mmc: block: improve logging of handling emmc timeouts
From: Ken Sumrall
Add some logging to make it clear just how the emmc timeout
was handled.
Signed-off-by: Ken Sumrall
[AmitP: cherry-picked this Android patch from aosp
common kernel android-4.4]
Signed-off-by: Amit Pundir
---
v1...v2:
Removed CC list from the commit log and skipped one print statement.
drivers/mmc/card/block.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 9c69e21..ddc9620 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -948,16 +948,22 @@ static int mmc_blk_cmd_error(struct request *req, const
char *name, int error,
req->rq_disk->disk_name, "timed out", name, status);
/* If the status cmd initially failed, retry the r/w cmd */
- if (!status_valid)
+ if (!status_valid) {
+ pr_err("%s: status not valid, retrying timeout\n",
+ req->rq_disk->disk_name);
return ERR_RETRY;
+ }
/*
* If it was a r/w cmd crc error, or illegal command
* (eg, issued in wrong state) then retry - we should
* have corrected the state problem above.
*/
- if (status & (R1_COM_CRC_ERROR | R1_ILLEGAL_COMMAND))
+ if (status & (R1_COM_CRC_ERROR | R1_ILLEGAL_COMMAND)) {
+ pr_err("%s: command error, retrying timeout\n",
+ req->rq_disk->disk_name);
return ERR_RETRY;
+ }
/* Otherwise abort the command */
return ERR_ABORT;
--
2.7.4
[RFC][PATCH] usb: gadget: rndis: Free the response queue during REMOTE_NDIS_RESET_MSG
From: xerox_lin When rndis data transfer is in progress, some Windows7 Host PC is not sending the GET_ENCAPSULATED_RESPONSE command for receiving the response for the previous SEND_ENCAPSULATED_COMMAND processed. The rndis function driver appends each response for the SEND_ENCAPSULATED_COMMAND in a queue. As the above process got corrupted, the Host sends a REMOTE_NDIS_RESET_MSG command to do a soft-reset. As the rndis response queue is not freed, the previous response is sent as a part of this REMOTE_NDIS_RESET_MSG's reset response and the Host blocks any more Rndis transfers. Hence free the rndis response queue as a part of this soft-reset so that the current response for REMOTE_NDIS_RESET_MSG is sent properly during the response command. Cc: Felipe Balbi Cc: Greg Kroah-Hartman Cc: Andrzej Pietrasiewicz Cc: Badhri Jagan Sridharan Cc: Android Kernel Team Cc: John Stultz Cc: Sumit Semwal Signed-off-by: Rajkumar Raghupathy Signed-off-by: Xerox Lin [pundir: cherry-picked this patch from AOSP experimental/android-4.4 tree.] Signed-off-by: Amit Pundir --- Cherry-picked this patch from AOSP common/experimental/android-4.4 tree. I could not find upstream submission history for this patch, so my apologies in advance if this has already been NACKed before. drivers/usb/gadget/function/rndis.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/gadget/function/rndis.c b/drivers/usb/gadget/function/rndis.c index 70d3917..27163e8 100644 --- a/drivers/usb/gadget/function/rndis.c +++ b/drivers/usb/gadget/function/rndis.c @@ -681,6 +681,13 @@ static int rndis_reset_response(struct rndis_params *params, rndis_reset_cmplt_type *resp; rndis_resp_t *r; + u32 length; + u8 *xbuf; + + /* drain the response queue */ + while ((xbuf = rndis_get_next_response(configNr, &length))) + rndis_free_response(configNr, xbuf); + r = rndis_add_response(params, sizeof(rndis_reset_cmplt_type)); if (!r) return -ENOMEM; -- 1.9.1
[RFC][PATCH] usb: gadget: prevent change of Host MAC address of 'usb0' interface
From: "taeju.park"
On windows 7 platform, previously allocated ip address is maintained.
However, Host MAC address of 'usb0' interface is changed when the
tethering driver re-enumerated. Thus, the tethering network driver
can't be allocated ip address from dhcp. It causes connection delay
between host and phone for usb tethering.
This patch prevents from changing Host MAC address of 'usb0' interface.
In other words, this patch maintains the Host MAC address allocated when
first tethering driver although the driver is re-enumerated. However,
after reboot, the Host MAC address can be changed.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Mike Looijmans
Cc: Robert Baldyga
Cc: Android Kernel Team
Cc: John Stultz
Cc: Sumit Semwal
Signed-off-by: Badhri Jagan Sridharan
[pundir: cherry-picked this patch from AOSP experimental/android-4.4 tree.]
Signed-off-by: Amit Pundir
---
Cherry-picked this patch from AOSP common/experimental/android-4.4 tree.
I could not find upstream submission history for this patch, so my
apologies in advance if this has already been NACKed before.
drivers/usb/gadget/function/u_ether.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function/u_ether.c
b/drivers/usb/gadget/function/u_ether.c
index 637809e..9a69332 100644
--- a/drivers/usb/gadget/function/u_ether.c
+++ b/drivers/usb/gadget/function/u_ether.c
@@ -698,6 +698,8 @@ static int eth_stop(struct net_device *net)
/*-*/
+static u8 host_ethaddr[ETH_ALEN];
+
static int get_ether_addr(const char *str, u8 *dev_addr)
{
if (str) {
@@ -728,6 +730,17 @@ static int get_ether_addr_str(u8 dev_addr[ETH_ALEN], char
*str, int len)
return 18;
}
+static int get_host_ether_addr(u8 *str, u8 *dev_addr)
+{
+ memcpy(dev_addr, str, ETH_ALEN);
+ if (is_valid_ether_addr(dev_addr))
+ return 0;
+
+ random_ether_addr(dev_addr);
+ memcpy(str, dev_addr, ETH_ALEN);
+ return 1;
+}
+
static const struct net_device_ops eth_netdev_ops = {
.ndo_open = eth_open,
.ndo_stop = eth_stop,
@@ -784,9 +797,12 @@ struct eth_dev *gether_setup_name(struct usb_gadget *g,
if (get_ether_addr(dev_addr, net->dev_addr))
dev_warn(&g->dev,
"using random %s ethernet address\n", "self");
- if (get_ether_addr(host_addr, dev->host_mac))
+
+ if (get_host_ether_addr(host_ethaddr, dev->host_mac))
+ dev_warn(&g->dev, "using random %s ethernet address\n", "host");
+ else
dev_warn(&g->dev,
- "using random %s ethernet address\n", "host");
+ "using previous %s ethernet address\n", "host");
if (ethaddr)
memcpy(ethaddr, dev->host_mac, ETH_ALEN);
--
1.9.1
[RFC][PATCH] usb: gadget: u_ether: Fix data stall issue in RNDIS tethering mode
From: Badhri Jagan Sridharan
For dual speed gadget, with current no. of request(10), there is
possibility of corner case occurrence where all 10 requests are queued
to HW without setting IOC bit, which could lead to data stall in
RNDIS tethering and RNDIS local networking.
With this patch, counter will be incremented before queueing request to
HW and sets IOC bit for every nth request due to which the corner case
of all requests queued to HW without IOC bit set will be avoided.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Mike Looijmans
Cc: Robert Baldyga
Cc: Android Kernel Team
Cc: John Stultz
Cc: Sumit Semwal
Signed-off-by: Vijayavardhan Vennapusa
[pundir: cherry-picked this patch from AOSP experimental/android-4.4 tree.]
Signed-off-by: Amit Pundir
---
Cherry-picked this patch from AOSP common/experimental/android-4.4 tree.
I could not find upstream submission history for this patch, so my
apologies in advance if this has already been NACKed before.
drivers/usb/gadget/function/u_ether.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/function/u_ether.c
b/drivers/usb/gadget/function/u_ether.c
index 9a69332..7f98a2d 100644
--- a/drivers/usb/gadget/function/u_ether.c
+++ b/drivers/usb/gadget/function/u_ether.c
@@ -64,7 +64,7 @@ struct eth_dev {
spinlock_t req_lock; /* guard {rx,tx}_reqs */
struct list_headtx_reqs, rx_reqs;
- atomic_ttx_qlen;
+ unsignedtx_qlen;
struct sk_buff_head rx_frames;
@@ -464,7 +464,6 @@ static void tx_complete(struct usb_ep *ep, struct
usb_request *req)
spin_unlock(&dev->req_lock);
dev_kfree_skb_any(skb);
- atomic_dec(&dev->tx_qlen);
if (netif_carrier_ok(dev->net))
netif_wake_queue(dev->net);
}
@@ -584,12 +583,19 @@ static netdev_tx_t eth_start_xmit(struct sk_buff *skb,
req->length = length;
- /* throttle high/super speed IRQ rate back slightly */
- if (gadget_is_dualspeed(dev->gadget))
- req->no_interrupt = (dev->gadget->speed == USB_SPEED_HIGH ||
-dev->gadget->speed == USB_SPEED_SUPER)
- ? ((atomic_read(&dev->tx_qlen) % dev->qmult) != 0)
- : 0;
+ /* throttle highspeed IRQ rate back slightly */
+ if (gadget_is_dualspeed(dev->gadget) &&
+(dev->gadget->speed == USB_SPEED_HIGH)) {
+ dev->tx_qlen++;
+ if (dev->tx_qlen == qmult) {
+ req->no_interrupt = 0;
+ dev->tx_qlen = 0;
+ } else {
+ req->no_interrupt = 1;
+ }
+ } else {
+ req->no_interrupt = 0;
+ }
retval = usb_ep_queue(in, req, GFP_ATOMIC);
switch (retval) {
@@ -598,7 +604,6 @@ static netdev_tx_t eth_start_xmit(struct sk_buff *skb,
break;
case 0:
net->trans_start = jiffies;
- atomic_inc(&dev->tx_qlen);
}
if (retval) {
@@ -625,7 +630,7 @@ static void eth_start(struct eth_dev *dev, gfp_t gfp_flags)
rx_fill(dev, gfp_flags);
/* and open the tx floodgates */
- atomic_set(&dev->tx_qlen, 0);
+ dev->tx_qlen = 0;
netif_wake_queue(dev->net);
}
--
1.9.1
[RFC][PATCH] usb: gadget: u_ether: Add workqueue as bottom half handler for rx data path
From: Badhri Jagan Sridharan
u_ether driver passes rx data to network layer and resubmits the
request back to usb hardware in interrupt context. Network layer
processes rx data by scheduling tasklet. For high throughput
scenarios on rx data path driver is spending lot of time in interrupt
context due to rx data processing by tasklet and continuous completion
and re-submission of the usb requests which results in watchdog bark.
Hence move the rx data processing and usb request submission to a
workqueue bottom half handler.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Mike Looijmans
Cc: Robert Baldyga
Cc: Android Kernel Team
Cc: John Stultz
Cc: Sumit Semwal
Signed-off-by: Badhri Jagan Sridharan
[pundir: cherry-picked this patch from AOSP experimental/android-4.4 tree.]
Signed-off-by: Amit Pundir
---
Cherry-picked this patch from AOSP common/experimental/android-4.4 tree.
I could not find upstream submission history for this patch, so my
apologies in advance if this has already been NACKed before.
drivers/usb/gadget/function/u_ether.c | 119 +++---
1 file changed, 80 insertions(+), 39 deletions(-)
diff --git a/drivers/usb/gadget/function/u_ether.c
b/drivers/usb/gadget/function/u_ether.c
index 7f98a2d..4235c33 100644
--- a/drivers/usb/gadget/function/u_ether.c
+++ b/drivers/usb/gadget/function/u_ether.c
@@ -53,6 +53,8 @@
* blocks and still have efficient handling. */
#define GETHER_MAX_ETH_FRAME_LEN 15412
+static struct workqueue_struct *uether_wq;
+
struct eth_dev {
/* lock is held while accessing port_usb
*/
@@ -77,6 +79,7 @@ struct eth_dev {
struct sk_buff_head *list);
struct work_struct work;
+ struct work_struct rx_work;
unsigned long todo;
#defineWORK_RX_MEMORY 0
@@ -248,18 +251,16 @@ enomem:
DBG(dev, "rx submit --> %d\n", retval);
if (skb)
dev_kfree_skb_any(skb);
- spin_lock_irqsave(&dev->req_lock, flags);
- list_add(&req->list, &dev->rx_reqs);
- spin_unlock_irqrestore(&dev->req_lock, flags);
}
return retval;
}
static void rx_complete(struct usb_ep *ep, struct usb_request *req)
{
- struct sk_buff *skb = req->context, *skb2;
+ struct sk_buff *skb = req->context;
struct eth_dev *dev = ep->driver_data;
int status = req->status;
+ boolqueue = 0;
switch (status) {
@@ -283,30 +284,8 @@ static void rx_complete(struct usb_ep *ep, struct
usb_request *req)
} else {
skb_queue_tail(&dev->rx_frames, skb);
}
- skb = NULL;
-
- skb2 = skb_dequeue(&dev->rx_frames);
- while (skb2) {
- if (status < 0
- || ETH_HLEN > skb2->len
- || skb2->len >
GETHER_MAX_ETH_FRAME_LEN) {
- dev->net->stats.rx_errors++;
- dev->net->stats.rx_length_errors++;
- DBG(dev, "rx length %d\n", skb2->len);
- dev_kfree_skb_any(skb2);
- goto next_frame;
- }
- skb2->protocol = eth_type_trans(skb2, dev->net);
- dev->net->stats.rx_packets++;
- dev->net->stats.rx_bytes += skb2->len;
-
- /* no buffer copies needed, unless hardware can't
-* use skb buffers.
-*/
- status = netif_rx(skb2);
-next_frame:
- skb2 = skb_dequeue(&dev->rx_frames);
- }
+ if (!status)
+ queue = 1;
break;
/* software-driven interface shutdown */
@@ -329,22 +308,20 @@ quiesce:
/* FALLTHROUGH */
default:
+ queue = 1;
+ dev_kfree_skb_any(skb);
dev->net->stats.rx_errors++;
DBG(dev, "rx status %d\n", status);
break;
}
- if (skb)
- dev_kfree_skb_any(skb);
- if (!netif_running(dev->net)) {
clean:
- spin_lock(&dev->req_lock);
- list_add(&req->list, &dev->rx_reqs);
- spin_unlock(&dev->req_lock);
- req = NULL;
- }
- if (req)
- rx_submit(dev, req, GFP_ATOMIC);
+ spin_lock(&dev->req_lock);
+ list_add(&req->list, &dev->rx_reqs);
+ spin_unlock(&dev->req_lock);
+
+
[RFC][PATCH] usb: phy: Dual role sysfs class definition
From: Badhri Jagan Sridharan This CL adds a new class to monitor and change dual role usb ports from userspace. The usb phy drivers can register to the dual_role_usb class and expose the capabilities of the ports. The phy drivers can decide on whether a specific attribute can be changed from userspace by choosing to implement the appropriate callback. Cc: Felipe Balbi Cc: Greg Kroah-Hartman Cc: Android Kernel Team Cc: John Stultz Cc: Sumit Semwal Signed-off-by: Badhri Jagan Sridharan [pundir: cherry-picked this patch from AOSP experimental/android-4.4 tree.] Signed-off-by: Amit Pundir --- Cherry-picked this patch from AOSP common/experimental/android-4.4 tree. I could not find upstream submission history for this patch, so my apologies in advance if this has already been NACKed before. .../ABI/testing/sysfs-class-dual-role-usb | 71 +++ drivers/usb/phy/Kconfig| 9 + drivers/usb/phy/Makefile | 1 + drivers/usb/phy/class-dual-role.c | 529 + include/linux/usb/class-dual-role.h| 128 + 5 files changed, 738 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-dual-role-usb create mode 100644 drivers/usb/phy/class-dual-role.c create mode 100644 include/linux/usb/class-dual-role.h diff --git a/Documentation/ABI/testing/sysfs-class-dual-role-usb b/Documentation/ABI/testing/sysfs-class-dual-role-usb new file mode 100644 index 000..a900fd7 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-dual-role-usb @@ -0,0 +1,71 @@ +What: /sys/class/dual_role_usb/.../ +Date: June 2015 +Contact: Badhri Jagan Sridharan +Description: + Provide a generic interface to monitor and change + the state of dual role usb ports. The name here + refers to the name mentioned in the + dual_role_phy_desc that is passed while registering + the dual_role_phy_intstance through + devm_dual_role_instance_register. + +What: /sys/class/dual_role_usb/.../supported_modes +Date: June 2015 +Contact:Badhri Jagan Sridharan +Description: + This is a static node, once initialized this + is not expected to change during runtime. "dfp" + refers to "downstream facing port" i.e. port can + only act as host. "ufp" refers to "upstream + facing port" i.e. port can only act as device. + "dfp ufp" refers to "dual role port" i.e. the port + can either be a host port or a device port. + +What: /sys/class/dual_role_usb/.../mode +Date: June 2015 +Contact: Badhri Jagan Sridharan +Description: + The mode node refers to the current mode in which the + port is operating. "dfp" for host ports. "ufp" for device + ports and "none" when cable is not connected. + + On devices where the USB mode is software-controllable, + userspace can change the mode by writing "dfp" or "ufp". + On devices where the USB mode is fixed in hardware, + this attribute is read-only. + +What: /sys/class/dual_role_usb/.../power_role +Date: June 2015 +Contact: Badhri Jagan Sridharan +Description: + The power_role node mentions whether the port + is "sink"ing or "source"ing power. "none" if + they are not connected. + + On devices implementing USB Power Delivery, + userspace can control the power role by writing "sink" or + "source". On devices without USB-PD, this attribute is + read-only. + +What: /sys/class/dual_role_usb/.../data_role +Date: June 2015 +Contact: Badhri Jagan Sridharan +Description: + The data_role node mentions whether the port + is acting as "host" or "device" for USB data connection. + "none" if there is no active data link. + + On devices implementing USB Power Delivery, userspace + can control the data role by writing "host" or "device". + On devices without USB-PD, this attribute is read-only + +What: /sys/class/dual_role_usb/.../powers_vconn +Date: June 2015 +Contact: Badhri Jagan Sridharan +Description: + The powers_vconn node mentions whether the port + is supplying power for VCONN pin. + + On devices with software control of VCONN, + userspace can disable the power supply to VCONN by writing "n", + or enable the power s
Re: [RFC][PATCH] usb: gadget: rndis: Free the response queue during REMOTE_NDIS_RESET_MSG
Please ignore this one. I build tested these patches in series and turned out it can't be build independently because configNr is deprecated. I'll resend this patch. Nevertheless I'd like to get a feedback on the real problem this patch is trying to solve here. Thanks, Amit Pundir On 9 February 2016 at 01:37, Amit Pundir wrote: > From: xerox_lin > > When rndis data transfer is in progress, some Windows7 Host PC is not > sending the GET_ENCAPSULATED_RESPONSE command for receiving the response > for the previous SEND_ENCAPSULATED_COMMAND processed. > > The rndis function driver appends each response for the > SEND_ENCAPSULATED_COMMAND in a queue. As the above process got corrupted, > the Host sends a REMOTE_NDIS_RESET_MSG command to do a soft-reset. > As the rndis response queue is not freed, the previous response is sent > as a part of this REMOTE_NDIS_RESET_MSG's reset response and the Host > blocks any more Rndis transfers. > > Hence free the rndis response queue as a part of this soft-reset so that > the current response for REMOTE_NDIS_RESET_MSG is sent properly during the > response command. > > Cc: Felipe Balbi > Cc: Greg Kroah-Hartman > Cc: Andrzej Pietrasiewicz > Cc: Badhri Jagan Sridharan > Cc: Android Kernel Team > Cc: John Stultz > Cc: Sumit Semwal > Signed-off-by: Rajkumar Raghupathy > Signed-off-by: Xerox Lin > [pundir: cherry-picked this patch from AOSP experimental/android-4.4 tree.] > Signed-off-by: Amit Pundir > --- > Cherry-picked this patch from AOSP common/experimental/android-4.4 tree. > I could not find upstream submission history for this patch, so my > apologies in advance if this has already been NACKed before. > > drivers/usb/gadget/function/rndis.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/usb/gadget/function/rndis.c > b/drivers/usb/gadget/function/rndis.c > index 70d3917..27163e8 100644 > --- a/drivers/usb/gadget/function/rndis.c > +++ b/drivers/usb/gadget/function/rndis.c > @@ -681,6 +681,13 @@ static int rndis_reset_response(struct rndis_params > *params, > rndis_reset_cmplt_type *resp; > rndis_resp_t *r; > > + u32 length; > + u8 *xbuf; > + > + /* drain the response queue */ > + while ((xbuf = rndis_get_next_response(configNr, &length))) > + rndis_free_response(configNr, xbuf); > + > r = rndis_add_response(params, sizeof(rndis_reset_cmplt_type)); > if (!r) > return -ENOMEM; > -- > 1.9.1 >
Re: [RFC][PATCH] usb: gadget: u_ether: Add workqueue as bottom half handler for rx data path
Please ignore this one too. I should have build tested these patches
individually and not in particular series. I'll resend this patch.
Thanks,
Amit Pundir
On 9 February 2016 at 01:41, Amit Pundir wrote:
> From: Badhri Jagan Sridharan
>
> u_ether driver passes rx data to network layer and resubmits the
> request back to usb hardware in interrupt context. Network layer
> processes rx data by scheduling tasklet. For high throughput
> scenarios on rx data path driver is spending lot of time in interrupt
> context due to rx data processing by tasklet and continuous completion
> and re-submission of the usb requests which results in watchdog bark.
> Hence move the rx data processing and usb request submission to a
> workqueue bottom half handler.
>
> Cc: Felipe Balbi
> Cc: Greg Kroah-Hartman
> Cc: Mike Looijmans
> Cc: Robert Baldyga
> Cc: Android Kernel Team
> Cc: John Stultz
> Cc: Sumit Semwal
> Signed-off-by: Badhri Jagan Sridharan
> [pundir: cherry-picked this patch from AOSP experimental/android-4.4 tree.]
> Signed-off-by: Amit Pundir
> ---
> Cherry-picked this patch from AOSP common/experimental/android-4.4 tree.
> I could not find upstream submission history for this patch, so my
> apologies in advance if this has already been NACKed before.
>
> drivers/usb/gadget/function/u_ether.c | 119
> +++---
> 1 file changed, 80 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/u_ether.c
> b/drivers/usb/gadget/function/u_ether.c
> index 7f98a2d..4235c33 100644
> --- a/drivers/usb/gadget/function/u_ether.c
> +++ b/drivers/usb/gadget/function/u_ether.c
> @@ -53,6 +53,8 @@
> * blocks and still have efficient handling. */
> #define GETHER_MAX_ETH_FRAME_LEN 15412
>
> +static struct workqueue_struct *uether_wq;
> +
> struct eth_dev {
> /* lock is held while accessing port_usb
> */
> @@ -77,6 +79,7 @@ struct eth_dev {
> struct sk_buff_head *list);
>
> struct work_struct work;
> + struct work_struct rx_work;
>
> unsigned long todo;
> #defineWORK_RX_MEMORY 0
> @@ -248,18 +251,16 @@ enomem:
> DBG(dev, "rx submit --> %d\n", retval);
> if (skb)
> dev_kfree_skb_any(skb);
> - spin_lock_irqsave(&dev->req_lock, flags);
> - list_add(&req->list, &dev->rx_reqs);
> - spin_unlock_irqrestore(&dev->req_lock, flags);
> }
> return retval;
> }
>
> static void rx_complete(struct usb_ep *ep, struct usb_request *req)
> {
> - struct sk_buff *skb = req->context, *skb2;
> + struct sk_buff *skb = req->context;
> struct eth_dev *dev = ep->driver_data;
> int status = req->status;
> + boolqueue = 0;
>
> switch (status) {
>
> @@ -283,30 +284,8 @@ static void rx_complete(struct usb_ep *ep, struct
> usb_request *req)
> } else {
> skb_queue_tail(&dev->rx_frames, skb);
> }
> - skb = NULL;
> -
> - skb2 = skb_dequeue(&dev->rx_frames);
> - while (skb2) {
> - if (status < 0
> - || ETH_HLEN > skb2->len
> - || skb2->len >
> GETHER_MAX_ETH_FRAME_LEN) {
> - dev->net->stats.rx_errors++;
> - dev->net->stats.rx_length_errors++;
> - DBG(dev, "rx length %d\n", skb2->len);
> - dev_kfree_skb_any(skb2);
> - goto next_frame;
> - }
> - skb2->protocol = eth_type_trans(skb2, dev->net);
> - dev->net->stats.rx_packets++;
> - dev->net->stats.rx_bytes += skb2->len;
> -
> - /* no buffer copies needed, unless hardware can't
> -* use skb buffers.
> -*/
> - status = netif_rx(skb2);
> -next_frame:
> - skb2 = skb_dequeue(&dev->rx_frames);
> - }
> + if (!status)
> + queue = 1;
> break;
>
> /* software-driven interface shutdown */
> @@ -329,22 +308,20 @@ quiesce:
> /* FALLTHROUGH */
>
>
[RFC][PATCH v2] usb: gadget: rndis: Free the response queue during REMOTE_NDIS_RESET_MSG
From: xerox_lin When rndis data transfer is in progress, some Windows7 Host PC is not sending the GET_ENCAPSULATED_RESPONSE command for receiving the response for the previous SEND_ENCAPSULATED_COMMAND processed. The rndis function driver appends each response for the SEND_ENCAPSULATED_COMMAND in a queue. As the above process got corrupted, the Host sends a REMOTE_NDIS_RESET_MSG command to do a soft-reset. As the rndis response queue is not freed, the previous response is sent as a part of this REMOTE_NDIS_RESET_MSG's reset response and the Host blocks any more Rndis transfers. Hence free the rndis response queue as a part of this soft-reset so that the current response for REMOTE_NDIS_RESET_MSG is sent properly during the response command. Cc: Felipe Balbi Cc: Greg Kroah-Hartman Cc: Andrzej Pietrasiewicz Cc: Badhri Jagan Sridharan Cc: Android Kernel Team Cc: John Stultz Cc: Sumit Semwal Signed-off-by: Rajkumar Raghupathy Signed-off-by: Xerox Lin [pundir: * cherry-picked this patch from AOSP experimental/android-4.4 tree. * folded in the AOSP fix to use rndis_params instead of configNr.] Signed-off-by: Amit Pundir --- v2: Use rndis_params instead of configNr in v1. Updated commit log. v1: Cherry-picked this patch from AOSP common/experimental/android-4.4 tree. I could not find upstream submission history for this patch, so my apologies in advance if this has already been NACKed before. drivers/usb/gadget/function/rndis.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/gadget/function/rndis.c b/drivers/usb/gadget/function/rndis.c index 70d3917..27163e8 100644 --- a/drivers/usb/gadget/function/rndis.c +++ b/drivers/usb/gadget/function/rndis.c @@ -681,6 +681,13 @@ static int rndis_reset_response(struct rndis_params *params, rndis_reset_cmplt_type *resp; rndis_resp_t *r; + u32 length; + u8 *xbuf; + + /* drain the response queue */ + while ((xbuf = rndis_get_next_response(params, &length))) + rndis_free_response(params, xbuf); + r = rndis_add_response(params, sizeof(rndis_reset_cmplt_type)); if (!r) return -ENOMEM; -- 1.9.1
[RFC][PATCH v2] usb: gadget: u_ether: Fix data stall issue in RNDIS tethering mode
From: Badhri Jagan Sridharan
For dual speed gadget, with current no. of request(10), there is
possibility of corner case occurrence where all 10 requests are queued
to HW without setting IOC bit, which could lead to data stall in
RNDIS tethering and RNDIS local networking.
With this patch, counter will be incremented before queueing request to
HW and sets IOC bit for every nth request due to which the corner case
of all requests queued to HW without IOC bit set will be avoided.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Mike Looijmans
Cc: Robert Baldyga
Cc: Android Kernel Team
Cc: John Stultz
Cc: Sumit Semwal
Cc: Praneeth Bajjuri
Signed-off-by: Vijayavardhan Vennapusa
[pundir:
* cherry-picked this patch from AOSP experimental/android-4.4 tree.
* folded in an AOSP build fix from Praneeth Bajjuri ]
Signed-off-by: Amit Pundir
---
v2: folded in the build fix for v1 from AOSP. Updated the commit log.
v1: Cherry-picked this patch from AOSP common/experimental/android-4.4 tree.
I could not find upstream submission history for this patch, so my
apologies in advance if this has already been NACKed before.
drivers/usb/gadget/function/u_ether.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/function/u_ether.c
b/drivers/usb/gadget/function/u_ether.c
index 9a69332..7f98a2d 100644
--- a/drivers/usb/gadget/function/u_ether.c
+++ b/drivers/usb/gadget/function/u_ether.c
@@ -64,7 +64,7 @@ struct eth_dev {
spinlock_t req_lock; /* guard {rx,tx}_reqs */
struct list_headtx_reqs, rx_reqs;
- atomic_ttx_qlen;
+ unsignedtx_qlen;
struct sk_buff_head rx_frames;
@@ -464,7 +464,6 @@ static void tx_complete(struct usb_ep *ep, struct
usb_request *req)
spin_unlock(&dev->req_lock);
dev_kfree_skb_any(skb);
- atomic_dec(&dev->tx_qlen);
if (netif_carrier_ok(dev->net))
netif_wake_queue(dev->net);
}
@@ -584,12 +583,19 @@ static netdev_tx_t eth_start_xmit(struct sk_buff *skb,
req->length = length;
- /* throttle high/super speed IRQ rate back slightly */
- if (gadget_is_dualspeed(dev->gadget))
- req->no_interrupt = (dev->gadget->speed == USB_SPEED_HIGH ||
-dev->gadget->speed == USB_SPEED_SUPER)
- ? ((atomic_read(&dev->tx_qlen) % dev->qmult) != 0)
- : 0;
+ /* throttle highspeed IRQ rate back slightly */
+ if (gadget_is_dualspeed(dev->gadget) &&
+(dev->gadget->speed == USB_SPEED_HIGH)) {
+ dev->tx_qlen++;
+ if (dev->tx_qlen == dev->qmult) {
+ req->no_interrupt = 0;
+ dev->tx_qlen = 0;
+ } else {
+ req->no_interrupt = 1;
+ }
+ } else {
+ req->no_interrupt = 0;
+ }
retval = usb_ep_queue(in, req, GFP_ATOMIC);
switch (retval) {
@@ -598,7 +604,6 @@ static netdev_tx_t eth_start_xmit(struct sk_buff *skb,
break;
case 0:
net->trans_start = jiffies;
- atomic_inc(&dev->tx_qlen);
}
if (retval) {
@@ -625,7 +630,7 @@ static void eth_start(struct eth_dev *dev, gfp_t gfp_flags)
rx_fill(dev, gfp_flags);
/* and open the tx floodgates */
- atomic_set(&dev->tx_qlen, 0);
+ dev->tx_qlen = 0;
netif_wake_queue(dev->net);
}
--
1.9.1
[RFC][PATCH v2] usb: gadget: u_ether: Add workqueue as bottom half handler for rx data path
From: Badhri Jagan Sridharan
u_ether driver passes rx data to network layer and resubmits the
request back to usb hardware in interrupt context. Network layer
processes rx data by scheduling tasklet. For high throughput
scenarios on rx data path driver is spending lot of time in interrupt
context due to rx data processing by tasklet and continuous completion
and re-submission of the usb requests which results in watchdog bark.
Hence move the rx data processing and usb request submission to a
workqueue bottom half handler.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Mike Looijmans
Cc: Robert Baldyga
Cc: Android Kernel Team
Cc: John Stultz
Cc: Sumit Semwal
Cc: Praneeth Bajjuri
Signed-off-by: Badhri Jagan Sridharan
[pundir:
* cherry-picked this patch from AOSP experimental/android-4.4 tree.
* folded in an AOSP build fix from Praneeth Bajjuri ]
Signed-off-by: Amit Pundir
---
v2: Folded in the build fix for v1 from AOSP. Updated the commit log.
v1: Cherry-picked this patch from AOSP common/experimental/android-4.4 tree.
I could not find upstream submission history for this patch, so my
apologies in advance if this has already been NACKed before.
drivers/usb/gadget/function/u_ether.c | 119 +++---
1 file changed, 80 insertions(+), 39 deletions(-)
diff --git a/drivers/usb/gadget/function/u_ether.c
b/drivers/usb/gadget/function/u_ether.c
index 7f98a2d..4235c33 100644
--- a/drivers/usb/gadget/function/u_ether.c
+++ b/drivers/usb/gadget/function/u_ether.c
@@ -53,6 +53,8 @@
* blocks and still have efficient handling. */
#define GETHER_MAX_ETH_FRAME_LEN 15412
+static struct workqueue_struct *uether_wq;
+
struct eth_dev {
/* lock is held while accessing port_usb
*/
@@ -77,6 +79,7 @@ struct eth_dev {
struct sk_buff_head *list);
struct work_struct work;
+ struct work_struct rx_work;
unsigned long todo;
#defineWORK_RX_MEMORY 0
@@ -248,18 +251,16 @@ enomem:
DBG(dev, "rx submit --> %d\n", retval);
if (skb)
dev_kfree_skb_any(skb);
- spin_lock_irqsave(&dev->req_lock, flags);
- list_add(&req->list, &dev->rx_reqs);
- spin_unlock_irqrestore(&dev->req_lock, flags);
}
return retval;
}
static void rx_complete(struct usb_ep *ep, struct usb_request *req)
{
- struct sk_buff *skb = req->context, *skb2;
+ struct sk_buff *skb = req->context;
struct eth_dev *dev = ep->driver_data;
int status = req->status;
+ boolqueue = 0;
switch (status) {
@@ -283,30 +284,8 @@ static void rx_complete(struct usb_ep *ep, struct
usb_request *req)
} else {
skb_queue_tail(&dev->rx_frames, skb);
}
- skb = NULL;
-
- skb2 = skb_dequeue(&dev->rx_frames);
- while (skb2) {
- if (status < 0
- || ETH_HLEN > skb2->len
- || skb2->len >
GETHER_MAX_ETH_FRAME_LEN) {
- dev->net->stats.rx_errors++;
- dev->net->stats.rx_length_errors++;
- DBG(dev, "rx length %d\n", skb2->len);
- dev_kfree_skb_any(skb2);
- goto next_frame;
- }
- skb2->protocol = eth_type_trans(skb2, dev->net);
- dev->net->stats.rx_packets++;
- dev->net->stats.rx_bytes += skb2->len;
-
- /* no buffer copies needed, unless hardware can't
-* use skb buffers.
-*/
- status = netif_rx(skb2);
-next_frame:
- skb2 = skb_dequeue(&dev->rx_frames);
- }
+ if (!status)
+ queue = 1;
break;
/* software-driven interface shutdown */
@@ -329,22 +308,20 @@ quiesce:
/* FALLTHROUGH */
default:
+ queue = 1;
+ dev_kfree_skb_any(skb);
dev->net->stats.rx_errors++;
DBG(dev, "rx status %d\n", status);
break;
}
- if (skb)
- dev_kfree_skb_any(skb);
- if (!netif_running(dev->net)) {
clean:
- spin_lock(&dev->req_lock);
- list_add(&req->list, &dev->rx_reqs);
- spin_unlock(&dev->req_lock);
- req = NULL;
- }
- if (req)
- rx_submit(dev, req, GFP_AT
Re: [RFC][PATCH] usb: gadget: u_ether: Add workqueue as bottom half handler for rx data path
On 9 February 2016 at 04:50, Greg Kroah-Hartman wrote: > On Tue, Feb 09, 2016 at 02:07:02AM +0530, Amit Pundir wrote: >> Please ignore this one too. I should have build tested these patches >> individually and not in particular series. I'll resend this patch. > > Send them in a numbered series so we know what order they have to be > applied in. Thanks I'll send them in a numbered series again. Since the patch series didn't have much in common(feature wise), I changed my mind right at the last moment to send them individually but that didn't go well. > > And I always ignore RFC patches, if you can't be confident enough in > submitting it for inclusion, why should we care? :) Yes I got your point. I was not intending to submit it yet, but hoping to get any early feedback or objections from maintainers. > > You have of course tested these, right? I have tested some of it for regressions, though not on the latest kernel, but I will go through and re-test what I can. As I said I was mainly just hoping for early maintainer feedback here. Thank you for the suggestions and feedback Greg. Regards, Amit Pundir > > thanks, > > greg k-h
Regression in v4.0.0-rc1 with Android Binder
Hi,
I ran into series of following binder mmap failures with v4.0.0-rc1:
[ cut here ]
WARNING: CPU: 0 PID: 1971 at mm/vmalloc.c:130
vmap_page_range_noflush+0x119/0x144()
CPU: 0 PID: 1971 Comm: healthd Not tainted 4.0.0-rc1-00399-g7da3fdc-dirty #157
Hardware name: ARM-Versatile Express
[] (unwind_backtrace) from [] (show_stack+0x11/0x14)
[] (show_stack) from [] (dump_stack+0x59/0x7c)
[] (dump_stack) from [] (warn_slowpath_common+0x55/0x84)
[] (warn_slowpath_common) from []
(warn_slowpath_null+0x17/0x1c)
[] (warn_slowpath_null) from []
(vmap_page_range_noflush+0x119/0x144)
[] (vmap_page_range_noflush) from [] (map_vm_area+0x27/0x48)
[] (map_vm_area) from []
(binder_update_page_range+0x12f/0x27c)
[] (binder_update_page_range) from []
(binder_mmap+0xbf/0x1ac)
[] (binder_mmap) from [] (mmap_region+0x2eb/0x4d4)
[] (mmap_region) from [] (do_mmap_pgoff+0x1e7/0x250)
[] (do_mmap_pgoff) from [] (vm_mmap_pgoff+0x45/0x60)
[] (vm_mmap_pgoff) from [] (SyS_mmap_pgoff+0x5d/0x80)
[] (SyS_mmap_pgoff) from [] (ret_fast_syscall+0x1/0x5c)
---[ end trace 48c2c4b9a1349e54 ]---
binder: 1982: binder_alloc_buf failed to map page at f0e0 in kernel
binder: binder_mmap: 1982 b6bde000-b6cdc000 alloc small buf failed -12
Turned out that the following commit tripped off binder:
--8<--
commit 71394fe50146202f2c8d92cf50f5ebc761acf254
Author: Andrey Ryabinin
Date: Fri Feb 13 14:40:03 2015 -0800
mm: vmalloc: add flag preventing guard hole allocation
-->8--
Explicitly disabling the vmalloc no guard (VM_NO_GUARD) flag in binder
worked fine for me. So does a fix like this look reasonable enough to
submit?
--8<--
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -601,6 +601,7 @@ static int binder_update_page_range(struct
binder_proc *proc, int allocate,
goto err_alloc_page_failed;
}
tmp_area.addr = page_addr;
+ tmp_area.flags &= ~VM_NO_GUARD;
tmp_area.size = PAGE_SIZE + PAGE_SIZE /* guard page? */;
ret = map_vm_area(&tmp_area, PAGE_KERNEL, page);
if (ret) {
-->8------
Regards,
Amit Pundir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] android: binder: fix binder mmap failures
On 27 February 2015 at 23:14, Andrey Ryabinin wrote:
> binder_update_page_range() initializes only addr and size
> fields in 'struct vm_struct tmp_area;' and passes it to
> map_vm_area().
>
> Before 71394fe50146 ("mm: vmalloc: add flag preventing guard hole allocation")
> this was because map_vm_area() didn't use any other fields
> in vm_struct except addr and size.
>
> Now get_vm_area_size() (used in map_vm_area()) reads vm_struct's
> flags to determine whether vm area has guard hole or not.
>
> binder_update_page_range() don't initialize flags field, so
> this causes following binder mmap failures:
> ---[ cut here ]
> WARNING: CPU: 0 PID: 1971 at mm/vmalloc.c:130
> vmap_page_range_noflush+0x119/0x144()
> CPU: 0 PID: 1971 Comm: healthd Not tainted 4.0.0-rc1-00399-g7da3fdc-dirty #157
> Hardware name: ARM-Versatile Express
> [] (unwind_backtrace) from [] (show_stack+0x11/0x14)
> [] (show_stack) from [] (dump_stack+0x59/0x7c)
> [] (dump_stack) from [] (warn_slowpath_common+0x55/0x84)
> [] (warn_slowpath_common) from []
> (warn_slowpath_null+0x17/0x1c)
> [] (warn_slowpath_null) from []
> (vmap_page_range_noflush+0x119/0x144)
> [] (vmap_page_range_noflush) from []
> (map_vm_area+0x27/0x48)
> [] (map_vm_area) from []
> (binder_update_page_range+0x12f/0x27c)
> [] (binder_update_page_range) from []
> (binder_mmap+0xbf/0x1ac)
> [] (binder_mmap) from [] (mmap_region+0x2eb/0x4d4)
> [] (mmap_region) from [] (do_mmap_pgoff+0x1e7/0x250)
> [] (do_mmap_pgoff) from [] (vm_mmap_pgoff+0x45/0x60)
> [] (vm_mmap_pgoff) from [] (SyS_mmap_pgoff+0x5d/0x80)
> [] (SyS_mmap_pgoff) from [] (ret_fast_syscall+0x1/0x5c)
> ---[ end trace 48c2c4b9a1349e54 ]---
> binder: 1982: binder_alloc_buf failed to map page at f0e0 in kernel
> binder: binder_mmap: 1982 b6bde000-b6cdc000 alloc small buf failed -12
>
> Use map_kernel_range_noflush() instead of map_vm_area() as this is better
> API for binder's purposes and it allows to get rid of 'vm_struct tmp_area' at
> all.
>
> Fixes: 71394fe50146 ("mm: vmalloc: add flag preventing guard hole allocation")
> Signed-off-by: Andrey Ryabinin
> Reported-by: Amit Pundir
> ---
> Changes since v1:
>- fixed ret check after map_kernel_ranges_noflush().
>
> drivers/android/binder.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index 33b09b6..6607f3c 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -551,7 +551,6 @@ static int binder_update_page_range(struct binder_proc
> *proc, int allocate,
> {
> void *page_addr;
> unsigned long user_page_addr;
> - struct vm_struct tmp_area;
> struct page **page;
> struct mm_struct *mm;
>
> @@ -600,10 +599,11 @@ static int binder_update_page_range(struct binder_proc
> *proc, int allocate,
> proc->pid, page_addr);
> goto err_alloc_page_failed;
> }
> - tmp_area.addr = page_addr;
> - tmp_area.size = PAGE_SIZE + PAGE_SIZE /* guard page? */;
> - ret = map_vm_area(&tmp_area, PAGE_KERNEL, page);
> - if (ret) {
> + ret = map_kernel_range_noflush((unsigned long)page_addr,
> + PAGE_SIZE, PAGE_KERNEL, page);
> + flush_cache_vmap((unsigned long)page_addr,
> + (unsigned long)page_addr + PAGE_SIZE);
> + if (ret != 1) {
> pr_err("%d: binder_alloc_buf failed to map page at %p
> in kernel\n",
>proc->pid, page_addr);
> goto err_map_kernel_failed;
> --
Works for me. Thanks.
Tested-by: Amit Pundir
> 2.3.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH 4/4] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver
On 23 April 2018 at 14:46, Greg KH wrote:
> On Wed, Apr 18, 2018 at 03:35:04PM +0530, Amit Pundir wrote:
>> From: Suren Baghdasaryan
>>
>> Possible buffer overflow when reading next_read_size bytes into
>> tmp buffer after next_read_size was extracted from a previous packet.
>>
>> Signed-off-by: Suren Baghdasaryan
>> Signed-off-by: Amit Pundir
>> ---
>> drivers/nfc/fdp/i2c.c | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
>> index c4da50e07bbc..08a4f82a2965 100644
>> --- a/drivers/nfc/fdp/i2c.c
>> +++ b/drivers/nfc/fdp/i2c.c
>> @@ -176,6 +176,16 @@ static int fdp_nci_i2c_read(struct fdp_i2c_phy *phy,
>> struct sk_buff **skb)
>> /* Packet that contains a length */
>> if (tmp[0] == 0 && tmp[1] == 0) {
>> phy->next_read_size = (tmp[2] << 8) + tmp[3] + 3;
>> + /*
>> + * Ensure next_read_size does not exceed sizeof(tmp)
>> + * for reading that many bytes during next iteration
>> + */
>> + if (phy->next_read_size > FDP_NCI_I2C_MAX_PAYLOAD) {
>> + dev_dbg(&client->dev, "%s: corrupted packet\n",
>> + __func__);
>
> As Andy points out, no need for __func__ in any dev_dbg() call.
Hi, Yes i'm working on v2 of this patch and on the comments I got on
another patch in this series.
Thanks,
Amit Pundir
>
> thanks,
>
> greg k-h
Re: [RESEND][PATCH 2/4] NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler
On 20 April 2018 at 18:09, Andy Shevchenko
wrote:
> On Wed, 2018-04-18 at 15:35 +0530, Amit Pundir wrote:
>
>> if (skb->data[transaction->aid_len + 2] !=
>> - NFC_EVT_TRANSACTION_PARAMS_TAG)
>> + NFC_EVT_TRANSACTION_PARAMS_TAG ||
>> + skb->len < transaction->aid_len + transaction-
>> >params_len + 4) {
>
>> + devm_kfree(dev, transaction);
>
> Oh, no.
>
> This is not memory leak per se, this is bad choice of devm_ API where it
> should use plain kmalloc() / kfree().
>
Hi, If I switch to kmalloc()/kfree() with allocation and may be
pre-usage checks along the way up to nfc_genl_se_transaction() would
that suffice? I believe, I still be needing the additional aid_len and
params_len checks regardless, right?
Regards,
Amit Pundir
>> return -EPROTO;
>> + }
>
> --
> Andy Shevchenko
> Intel Finland Oy
Re: [RESEND][PATCH 2/4] NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler
On 20 April 2018 at 22:15, Mark Greer wrote:
> On Fri, Apr 20, 2018 at 03:39:46PM +0300, Andy Shevchenko wrote:
>> On Wed, 2018-04-18 at 15:35 +0530, Amit Pundir wrote:
>>
>> > if (skb->data[transaction->aid_len + 2] !=
>> > - NFC_EVT_TRANSACTION_PARAMS_TAG)
>> > + NFC_EVT_TRANSACTION_PARAMS_TAG ||
>> > + skb->len < transaction->aid_len + transaction-
>> > >params_len + 4) {
>>
>> > + devm_kfree(dev, transaction);
>>
>> Oh, no.
>>
>> This is not memory leak per se, this is bad choice of devm_ API where it
>> should use plain kmalloc() / kfree().
>
> Also, there is no check to see if the allocation worked at all.
Ack. I'll add that in v2.
Thanks.
Regards,
Amit Pundir
>
> Mark
> --
Re: [PATCH v2 3/3] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver
On 3 May 2018 at 15:50, Andy Shevchenko
wrote:
> On Wed, 2018-05-02 at 23:18 +0530, Amit Pundir wrote:
>> From: Suren Baghdasaryan
>>
>> Possible buffer overflow when reading next_read_size bytes into
>> tmp buffer after next_read_size was extracted from a previous packet.
>>
>> Signed-off-by: Suren Baghdasaryan
>> Signed-off-by: Amit Pundir
>> ---
>> v2:
>> Remove redundant __func__ from dev_dgb().
>>
>> drivers/nfc/fdp/i2c.c | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
>> index c4da50e..b80d1ad 100644
>> --- a/drivers/nfc/fdp/i2c.c
>> +++ b/drivers/nfc/fdp/i2c.c
>> @@ -176,6 +176,15 @@ static int fdp_nci_i2c_read(struct fdp_i2c_phy
>> *phy, struct sk_buff **skb)
>> /* Packet that contains a length */
>> if (tmp[0] == 0 && tmp[1] == 0) {
>> phy->next_read_size = (tmp[2] << 8) + tmp[3]
>> + 3;
>> + /*
>> + * Ensure next_read_size does not exceed
>> sizeof(tmp)
>> + * for reading that many bytes during next
>> iteration
>> + */
>> + if (phy->next_read_size >
>> FDP_NCI_I2C_MAX_PAYLOAD) {
>> + dev_dbg(&client->dev, "corrupted
>> packet\n");
>
>> + phy->next_read_size = 5;
>
> Shouldn't be this magic replaced by
>
> phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
>
> ?
Ack. Fixing it in v3.
Regards,
Amit Pundir
>
>> + goto flush;
>> + }
>> } else {
>> phy->next_read_size =
>> FDP_NCI_I2C_MIN_PAYLOAD;
>>
>
> --
> Andy Shevchenko
> Intel Finland Oy
[PATCH v3 3/4] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver
From: Suren Baghdasaryan
Possible buffer overflow when reading next_read_size bytes into
tmp buffer after next_read_size was extracted from a previous packet.
cc: Stable
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
Reviewed-by: Andy Shevchenko
---
v3:
Reset next_read_size to a more readable macro FDP_NCI_I2C_MIN_PAYLOAD
instead of 5.
v2:
Remove redundant __func__ from dev_dgb().
drivers/nfc/fdp/i2c.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index c4da50e07bbc..2c5ed2224c5e 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -176,6 +176,15 @@ static int fdp_nci_i2c_read(struct fdp_i2c_phy *phy,
struct sk_buff **skb)
/* Packet that contains a length */
if (tmp[0] == 0 && tmp[1] == 0) {
phy->next_read_size = (tmp[2] << 8) + tmp[3] + 3;
+ /*
+* Ensure next_read_size does not exceed sizeof(tmp)
+* for reading that many bytes during next iteration
+*/
+ if (phy->next_read_size > FDP_NCI_I2C_MAX_PAYLOAD) {
+ dev_dbg(&client->dev, "corrupted packet\n");
+ phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
+ goto flush;
+ }
} else {
phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
--
2.7.4
[PATCH v3 1/4] NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ
From: Suren Baghdasaryan
Out of bounds kernel accesses in st21nfca's NFC HCI layer
might happen when handling ATR_REQ events if user-specified
atr_req->length is bigger than the buffer size. In
that case memcpy() inside st21nfca_tm_send_atr_res() will
read extra bytes resulting in OOB read from the kernel heap.
cc: Stable
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
Reviewed-by: Andy Shevchenko
---
v3..v1:
Resend. No changes.
drivers/nfc/st21nfca/dep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/st21nfca/dep.c b/drivers/nfc/st21nfca/dep.c
index fd08be2917e6..3420c5104c94 100644
--- a/drivers/nfc/st21nfca/dep.c
+++ b/drivers/nfc/st21nfca/dep.c
@@ -217,7 +217,8 @@ static int st21nfca_tm_recv_atr_req(struct nfc_hci_dev
*hdev,
atr_req = (struct st21nfca_atr_req *)skb->data;
- if (atr_req->length < sizeof(struct st21nfca_atr_req)) {
+ if (atr_req->length < sizeof(struct st21nfca_atr_req) ||
+ atr_req->length > skb->len) {
r = -EPROTO;
goto exit;
}
--
2.7.4
[PATCH v3 4/4] NFC: fdp: Remove __func__ from dev_dbg()
Remove redundant __func__ parameter from dev_dgb() calls and
delete empty dev_dbg() trace calls, which are redundant if
function tracer is enabled.
Signed-off-by: Amit Pundir
Reviewed-by: Andy Shevchenko
---
v3:
Updated commit message.
v2:
Deleted empty dev_dbg() trace calls, which are redundant if
function tracer is enabled.
drivers/nfc/fdp/fdp.c | 18 +++---
drivers/nfc/fdp/i2c.c | 17 -
2 files changed, 7 insertions(+), 28 deletions(-)
diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
index d5784a47fc13..f64a6fd65c41 100644
--- a/drivers/nfc/fdp/fdp.c
+++ b/drivers/nfc/fdp/fdp.c
@@ -249,8 +249,6 @@ static int fdp_nci_open(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
r = info->phy_ops->enable(info->phy);
return r;
@@ -261,7 +259,6 @@ static int fdp_nci_close(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
return 0;
}
@@ -270,8 +267,6 @@ static int fdp_nci_send(struct nci_dev *ndev, struct
sk_buff *skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
if (atomic_dec_and_test(&info->data_pkt_counter))
info->data_pkt_counter_cb(ndev);
@@ -283,7 +278,6 @@ int fdp_nci_recv_frame(struct nci_dev *ndev, struct sk_buff
*skb)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
return nci_recv_frame(ndev, skb);
}
EXPORT_SYMBOL(fdp_nci_recv_frame);
@@ -498,8 +492,6 @@ static int fdp_nci_setup(struct nci_dev *ndev)
int r;
u8 patched = 0;
- dev_dbg(dev, "%s\n", __func__);
-
r = nci_core_init(ndev);
if (r)
goto error;
@@ -609,7 +601,6 @@ static int fdp_nci_core_reset_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
info->setup_reset_ntf = 1;
wake_up(&info->setup_wq);
@@ -622,7 +613,6 @@ static int fdp_nci_prop_patch_ntf_packet(struct nci_dev
*ndev,
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
info->setup_patch_ntf = 1;
info->setup_patch_status = skb->data[0];
wake_up(&info->setup_wq);
@@ -637,7 +627,7 @@ static int fdp_nci_prop_patch_rsp_packet(struct nci_dev
*ndev,
struct device *dev = &info->phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -650,7 +640,7 @@ static int
fdp_nci_prop_set_production_data_rsp_packet(struct nci_dev *ndev,
struct device *dev = &info->phy->i2c_dev->dev;
u8 status = skb->data[0];
- dev_dbg(dev, "%s: status 0x%x\n", __func__, status);
+ dev_dbg(dev, "status 0x%x\n", status);
nci_req_complete(ndev, status);
return 0;
@@ -695,7 +685,7 @@ static int fdp_nci_core_get_config_rsp_packet(struct
nci_dev *ndev,
dev_dbg(dev, "OTP version %d\n", info->otp_version);
dev_dbg(dev, "RAM version %d\n", info->ram_version);
dev_dbg(dev, "key index %d\n", info->key_index);
- dev_dbg(dev, "%s: status 0x%x\n", __func__, rsp->status);
+ dev_dbg(dev, "status 0x%x\n", rsp->status);
nci_req_complete(ndev, rsp->status);
@@ -798,8 +788,6 @@ void fdp_nci_remove(struct nci_dev *ndev)
struct fdp_nci_info *info = nci_get_drvdata(ndev);
struct device *dev = &info->phy->i2c_dev->dev;
- dev_dbg(dev, "%s\n", __func__);
-
nci_unregister_device(ndev);
nci_free_device(ndev);
}
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index 2c5ed2224c5e..bb14d30c568c 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -57,7 +57,6 @@ static int fdp_nci_i2c_enable(void *phy_id)
{
struct fdp_i2c_phy *phy = phy_id;
- dev_dbg(&phy->i2c_dev->dev, "%s\n", __func__);
fdp_nci_i2c_reset(phy);
return 0;
@@ -67,7 +66,6 @@ static void fdp_nci_i2c_disable(void *phy_id)
{
[PATCH v3 2/4] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Suren Baghdasaryan
When handling SHDLC I-Frame commands "pipe" field used for indexing
into an array should be checked before usage. If left unchecked it
might access memory outside of the array of size NFC_HCI_MAX_PIPES(127).
cc: Stable
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
Reviewed-by: Andy Shevchenko
---
v3..v1:
Resend. No changes.
net/nfc/hci/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/net/nfc/hci/core.c b/net/nfc/hci/core.c
index ac8030c4bcf8..19cb2e473ea6 100644
--- a/net/nfc/hci/core.c
+++ b/net/nfc/hci/core.c
@@ -209,6 +209,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
create_info = (struct hci_create_pipe_resp *)skb->data;
+ if (create_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
/* Save the new created pipe and bind with local gate,
* the description for skb->data[3] is destination gate id
* but since we received this cmd from host controller, we
@@ -232,6 +237,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
delete_info = (struct hci_delete_pipe_noti *)skb->data;
+ if (delete_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
hdev->pipes[delete_info->pipe].gate = NFC_HCI_INVALID_GATE;
hdev->pipes[delete_info->pipe].dest_host = NFC_HCI_INVALID_HOST;
break;
--
2.7.4
[PATCH] Bluetooth: hci_qca: Avoid missing rampatch failure with userspace fw loader
AOSP use userspace firmware loader to load firmwares, which will
return -EAGAIN in case qca/rampatch_00440302.bin is not found.
Since there is no rampatch for dragonboard820c QCA controller
revision, just make it work as is.
CC: Loic Poulain
CC: Nicolas Dechesne
CC: Marcel Holtmann
CC: Johan Hedberg
CC: Stable
Signed-off-by: Amit Pundir
---
drivers/bluetooth/hci_qca.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 05ec530b8a3a..330e9b29e145 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -935,6 +935,12 @@ static int qca_setup(struct hci_uart *hu)
} else if (ret == -ENOENT) {
/* No patch/nvm-config found, run with original fw/config */
ret = 0;
+ } else if (ret == -EAGAIN) {
+ /*
+* Userspace firmware loader will return -EAGAIN in case no
+* patch/nvm-config is found, so run with original fw/config.
+*/
+ ret = 0;
}
/* Setup bdaddr */
--
2.7.4
[RESEND][PATCH 3/4] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Suren Baghdasaryan
When handling SHDLC I-Frame commands "pipe" field used for indexing
into an array should be checked before usage. If left unchecked it
might access memory outside of the array of size NFC_HCI_MAX_PIPES(127).
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
---
net/nfc/hci/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/net/nfc/hci/core.c b/net/nfc/hci/core.c
index ac8030c4bcf8..19cb2e473ea6 100644
--- a/net/nfc/hci/core.c
+++ b/net/nfc/hci/core.c
@@ -209,6 +209,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
create_info = (struct hci_create_pipe_resp *)skb->data;
+ if (create_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
/* Save the new created pipe and bind with local gate,
* the description for skb->data[3] is destination gate id
* but since we received this cmd from host controller, we
@@ -232,6 +237,11 @@ void nfc_hci_cmd_received(struct nfc_hci_dev *hdev, u8
pipe, u8 cmd,
}
delete_info = (struct hci_delete_pipe_noti *)skb->data;
+ if (delete_info->pipe >= NFC_HCI_MAX_PIPES) {
+ status = NFC_HCI_ANY_E_NOK;
+ goto exit;
+ }
+
hdev->pipes[delete_info->pipe].gate = NFC_HCI_INVALID_GATE;
hdev->pipes[delete_info->pipe].dest_host = NFC_HCI_INVALID_HOST;
break;
--
2.7.4
[RESEND][PATCH 0/4] Few NFC fixes from android-4.14 tree
Hi, Resending few NFC fixes I picked up from android-4.14 tree[1] for review and comments. They seem reasonable upstream candidates. My last attempt was not timed properly and it got lost between Christmas-New Year break and then Meltdown-Spectre happened. Also like to point out that I have not feature tested these patches at all. Only made small cosmetic changes to the original patches (removed Android-only tag and internal bug ID) and build tested for arm/arm64 defconfigs, before posting them here for review. Really appreciate any comments or feedback on how to take it forward. Regards, Amit Pundir [1] https://android.googlesource.com/kernel/common/+log/android-4.14 Suren Baghdasaryan (4): NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler NFC: Fix possible memory corruption when handling SHDLC I-Frame commands NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver drivers/nfc/fdp/i2c.c | 10 ++ drivers/nfc/st21nfca/dep.c | 3 ++- drivers/nfc/st21nfca/se.c | 18 ++ net/nfc/hci/core.c | 10 ++ 4 files changed, 36 insertions(+), 5 deletions(-) -- 2.7.4
[RESEND][PATCH 4/4] NFC: fdp: Fix possible buffer overflow in WCS4000 NFC driver
From: Suren Baghdasaryan
Possible buffer overflow when reading next_read_size bytes into
tmp buffer after next_read_size was extracted from a previous packet.
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
---
drivers/nfc/fdp/i2c.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index c4da50e07bbc..08a4f82a2965 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -176,6 +176,16 @@ static int fdp_nci_i2c_read(struct fdp_i2c_phy *phy,
struct sk_buff **skb)
/* Packet that contains a length */
if (tmp[0] == 0 && tmp[1] == 0) {
phy->next_read_size = (tmp[2] << 8) + tmp[3] + 3;
+ /*
+* Ensure next_read_size does not exceed sizeof(tmp)
+* for reading that many bytes during next iteration
+*/
+ if (phy->next_read_size > FDP_NCI_I2C_MAX_PAYLOAD) {
+ dev_dbg(&client->dev, "%s: corrupted packet\n",
+ __func__);
+ phy->next_read_size = 5;
+ goto flush;
+ }
} else {
phy->next_read_size = FDP_NCI_I2C_MIN_PAYLOAD;
--
2.7.4
[RESEND][PATCH 2/4] NFC: st21nfca: Fix memory OOB and leak issues in connectivity events handler
From: Suren Baghdasaryan
Overflow on memcpy is possible in kernel driver for st21nfca's
NFC HCI layer when handling connectivity events if aid_len or
params_len are bigger than the buffer size.
Memory leak is possible when parameter tag is invalid.
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
---
drivers/nfc/st21nfca/se.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index 4bed9e842db3..acdce231e227 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -322,23 +322,33 @@ int st21nfca_connectivity_event_received(struct
nfc_hci_dev *hdev, u8 host,
* AID 81 5 to 16
* PARAMETERS 82 0 to 255
*/
- if (skb->len < NFC_MIN_AID_LENGTH + 2 &&
+ if (skb->len < NFC_MIN_AID_LENGTH + 2 ||
skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
return -EPROTO;
+ /*
+* Buffer should have enough space for at least
+* two tag fields + two length fields + aid_len (skb->data[1])
+*/
+ if (skb->len < skb->data[1] + 4)
+ return -EPROTO;
+
transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
skb->len - 2, GFP_KERNEL);
transaction->aid_len = skb->data[1];
memcpy(transaction->aid, &skb->data[2],
transaction->aid_len);
+ transaction->params_len = skb->data[transaction->aid_len + 3];
- /* Check next byte is PARAMETERS tag (82) */
+ /* Check next byte is PARAMETERS tag (82) and the length field
*/
if (skb->data[transaction->aid_len + 2] !=
- NFC_EVT_TRANSACTION_PARAMS_TAG)
+ NFC_EVT_TRANSACTION_PARAMS_TAG ||
+ skb->len < transaction->aid_len + transaction->params_len +
4) {
+ devm_kfree(dev, transaction);
return -EPROTO;
+ }
- transaction->params_len = skb->data[transaction->aid_len + 3];
memcpy(transaction->params, skb->data +
transaction->aid_len + 4, transaction->params_len);
--
2.7.4
[RESEND][PATCH 1/4] NFC: st21nfca: Fix out of bounds kernel access when handling ATR_REQ
From: Suren Baghdasaryan
Out of bounds kernel accesses in st21nfca's NFC HCI layer
might happen when handling ATR_REQ events if user-specified
atr_req->length is bigger than the buffer size. In
that case memcpy() inside st21nfca_tm_send_atr_res() will
read extra bytes resulting in OOB read from the kernel heap.
Signed-off-by: Suren Baghdasaryan
Signed-off-by: Amit Pundir
---
drivers/nfc/st21nfca/dep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/st21nfca/dep.c b/drivers/nfc/st21nfca/dep.c
index fd08be2917e6..3420c5104c94 100644
--- a/drivers/nfc/st21nfca/dep.c
+++ b/drivers/nfc/st21nfca/dep.c
@@ -217,7 +217,8 @@ static int st21nfca_tm_recv_atr_req(struct nfc_hci_dev
*hdev,
atr_req = (struct st21nfca_atr_req *)skb->data;
- if (atr_req->length < sizeof(struct st21nfca_atr_req)) {
+ if (atr_req->length < sizeof(struct st21nfca_atr_req) ||
+ atr_req->length > skb->len) {
r = -EPROTO;
goto exit;
}
--
2.7.4
[PATCH 1/2] config: android-recommended: disable aio support
From: Daniel Micay The aio interface adds substantial attack surface for a feature that's not being exposed by Android at all. It's unlikely that anyone is using the kernel feature directly either. This feature is rarely used even on servers. The glibc POSIX aio calls really use thread pools. The lack of widespread usage also means this is relatively poorly audited/tested. The kernel's aio rarely provides performance benefits over using a thread pool and is quite incomplete in terms of system call coverage along with having edge cases where blocking can occur. Part of the performance issue is the fact that it only supports direct io, not buffered io. The existing API is considered fundamentally flawed and it's unlikely it will be expanded, but rather replaced: https://marc.info/?l=linux-aio&m=145255815216051&w=2 Since ext4 encryption means no direct io support, kernel aio isn't even going to work properly on Android devices using file-based encryption. Reviewed-at: https://android-review.googlesource.com/#/c/292158/ Signed-off-by: Daniel Micay Signed-off-by: Amit Pundir --- kernel/configs/android-recommended.config | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/configs/android-recommended.config b/kernel/configs/android-recommended.config index 297756b..4719871 100644 --- a/kernel/configs/android-recommended.config +++ b/kernel/configs/android-recommended.config @@ -1,4 +1,5 @@ # KEEP ALPHABETICALLY SORTED +# CONFIG_AIO is not set # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_LEGACY_PTYS is not set -- 2.7.4
[PATCH 2/2] config: android-base: enable hardened usercopy and kernel ASLR
Enable CONFIG_HARDENED_USERCOPY and CONFIG_RANDOMIZE_BASE in Android base config fragment. Reviewed-at: https://android-review.googlesource.com/#/c/283659/ Reviewed-at: https://android-review.googlesource.com/#/c/278133/ Signed-off-by: Amit Pundir --- kernel/configs/android-base.config | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/configs/android-base.config b/kernel/configs/android-base.config index 1a8f34f..26a06e0 100644 --- a/kernel/configs/android-base.config +++ b/kernel/configs/android-base.config @@ -21,6 +21,7 @@ CONFIG_CP15_BARRIER_EMULATION=y CONFIG_DEFAULT_SECURITY_SELINUX=y CONFIG_EMBEDDED=y CONFIG_FB=y +CONFIG_HARDENED_USERCOPY=y CONFIG_HIGH_RES_TIMERS=y CONFIG_INET6_AH=y CONFIG_INET6_ESP=y @@ -129,6 +130,7 @@ CONFIG_PPP_DEFLATE=y CONFIG_PPP_MPPE=y CONFIG_PREEMPT=y CONFIG_QUOTA=y +CONFIG_RANDOMIZE_BASE=y CONFIG_RTC_CLASS=y CONFIG_RT_GROUP_SCHED=y CONFIG_SECCOMP=y -- 2.7.4
Re: [PATCH] config: Add android config fragments
On 8 June 2016 at 22:09, Rob Herring wrote: > Copy the config fragments from the AOSP common kernel tree. It is > becoming possible to run mainline kernels with Android, but the kernel > defconfigs don't work as-is and debugging missing config options is a > pain. Adding the config fragments into the kernel tree, makes > configuring a mainline kernel as simple as: > > make ARCH=arm multi_v7_defconfig android-base.config > android-recommended.config > > Cc: Amit Pundir > Cc: John Stultz > Cc: Dmitry Torokhov > Cc: Rom Lemarchand > Signed-off-by: Rob Herring > --- > kernel/configs/android-base.config| 161 > ++ > kernel/configs/android-recommended.config | 121 ++ > 2 files changed, 282 insertions(+) > create mode 100644 kernel/configs/android-base.config > create mode 100644 kernel/configs/android-recommended.config > > diff --git a/kernel/configs/android-base.config > b/kernel/configs/android-base.config > new file mode 100644 > index 000..44fa01d > --- /dev/null > +++ b/kernel/configs/android-base.config > @@ -0,0 +1,161 @@ > +# KEEP ALPHABETICALLY SORTED > +# CONFIG_DEVKMEM is not set > +# CONFIG_DEVMEM is not set > +# CONFIG_INET_LRO is not set > +# CONFIG_MODULES is not set > +# CONFIG_OABI_COMPAT is not set > +# CONFIG_SYSVIPC is not set > +CONFIG_ANDROID=y > +CONFIG_ANDROID_BINDER_IPC=y > +CONFIG_ANDROID_LOW_MEMORY_KILLER=y > +CONFIG_ARMV8_DEPRECATED=y > +CONFIG_ASHMEM=y > +CONFIG_AUDIT=y > +CONFIG_BLK_DEV_DM=y > +CONFIG_BLK_DEV_INITRD=y > +CONFIG_CGROUPS=y > +CONFIG_CGROUP_CPUACCT=y > +CONFIG_CGROUP_DEBUG=y > +CONFIG_CGROUP_FREEZER=y > +CONFIG_CGROUP_SCHED=y > +CONFIG_CP15_BARRIER_EMULATION=y > +CONFIG_DM_CRYPT=y > +CONFIG_DM_VERITY=y > +CONFIG_EMBEDDED=y > +CONFIG_FB=y > +CONFIG_HIGH_RES_TIMERS=y > +CONFIG_INET6_AH=y > +CONFIG_INET6_ESP=y > +CONFIG_INET6_IPCOMP=y > +CONFIG_INET=y > +CONFIG_INET_ESP=y > +CONFIG_INET_XFRM_MODE_TUNNEL=y > +CONFIG_IP6_NF_FILTER=y > +CONFIG_IP6_NF_IPTABLES=y > +CONFIG_IP6_NF_MANGLE=y > +CONFIG_IP6_NF_RAW=y > +CONFIG_IP6_NF_TARGET_REJECT=y > +CONFIG_IP6_NF_TARGET_REJECT_SKERR=y > +CONFIG_IPV6=y > +CONFIG_IPV6_MIP6=y > +CONFIG_IPV6_MULTIPLE_TABLES=y > +CONFIG_IPV6_OPTIMISTIC_DAD=y > +CONFIG_IPV6_PRIVACY=y > +CONFIG_IPV6_ROUTER_PREF=y > +CONFIG_IPV6_ROUTE_INFO=y > +CONFIG_IP_ADVANCED_ROUTER=y > +CONFIG_IP_MULTIPLE_TABLES=y > +CONFIG_IP_NF_ARPFILTER=y > +CONFIG_IP_NF_ARPTABLES=y > +CONFIG_IP_NF_ARP_MANGLE=y > +CONFIG_IP_NF_FILTER=y > +CONFIG_IP_NF_IPTABLES=y > +CONFIG_IP_NF_MANGLE=y > +CONFIG_IP_NF_MATCH_AH=y > +CONFIG_IP_NF_MATCH_ECN=y > +CONFIG_IP_NF_MATCH_TTL=y > +CONFIG_IP_NF_RAW=y > +CONFIG_IP_NF_SECURITY=y > +CONFIG_IP_NF_TARGET_MASQUERADE=y > +CONFIG_IP_NF_TARGET_NETMAP=y > +CONFIG_IP_NF_TARGET_REDIRECT=y > +CONFIG_IP_NF_TARGET_REJECT=y > +CONFIG_IP_NF_TARGET_REJECT_SKERR=y > +CONFIG_NET=y > +CONFIG_NETDEVICES=y > +CONFIG_NETFILTER=y > +CONFIG_NETFILTER_TPROXY=y > +CONFIG_NETFILTER_XT_MATCH_COMMENT=y > +CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=y > +CONFIG_NETFILTER_XT_MATCH_CONNMARK=y > +CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y > +CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=y > +CONFIG_NETFILTER_XT_MATCH_HELPER=y > +CONFIG_NETFILTER_XT_MATCH_IPRANGE=y > +CONFIG_NETFILTER_XT_MATCH_LENGTH=y > +CONFIG_NETFILTER_XT_MATCH_LIMIT=y > +CONFIG_NETFILTER_XT_MATCH_MAC=y > +CONFIG_NETFILTER_XT_MATCH_MARK=y > +CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y > +CONFIG_NETFILTER_XT_MATCH_POLICY=y > +CONFIG_NETFILTER_XT_MATCH_QTAGUID=y > +CONFIG_NETFILTER_XT_MATCH_QUOTA2=y > +CONFIG_NETFILTER_XT_MATCH_QUOTA2_LOG=y > +CONFIG_NETFILTER_XT_MATCH_QUOTA=y > +CONFIG_NETFILTER_XT_MATCH_SOCKET=y > +CONFIG_NETFILTER_XT_MATCH_STATE=y > +CONFIG_NETFILTER_XT_MATCH_STATISTIC=y > +CONFIG_NETFILTER_XT_MATCH_STRING=y > +CONFIG_NETFILTER_XT_MATCH_TIME=y > +CONFIG_NETFILTER_XT_MATCH_U32=y > +CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y > +CONFIG_NETFILTER_XT_TARGET_CONNMARK=y > +CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y > +CONFIG_NETFILTER_XT_TARGET_IDLETIMER=y > +CONFIG_NETFILTER_XT_TARGET_MARK=y > +CONFIG_NETFILTER_XT_TARGET_NFLOG=y > +CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y > +CONFIG_NETFILTER_XT_TARGET_SECMARK=y > +CONFIG_NETFILTER_XT_TARGET_TCPMSS=y > +CONFIG_NETFILTER_XT_TARGET_TPROXY=y > +CONFIG_NETFILTER_XT_TARGET_TRACE=y > +CONFIG_NET_CLS_ACT=y > +CONFIG_NET_CLS_U32=y > +CONFIG_NET_EMATCH=y > +CONFIG_NET_EMATCH_U32=y > +CONFIG_NET_KEY=y > +CONFIG_NET_SCHED=y > +CONFIG_NET_SCH_HTB=y > +CONFIG_NF_CONNTRACK=y > +CONFIG_NF_CONNTRACK_AMANDA=y > +CONFIG_NF_CONNTRACK_EVENTS=y > +CONFIG_NF_CONNTRACK_FTP=y > +CONFIG_NF_CONNT
Re: [PATCH] config: Add android config fragments
On 23 June 2016 at 08:50, Rob Herring wrote: > On Wed, Jun 22, 2016 at 2:53 AM, Amit Pundir wrote: >> On 8 June 2016 at 22:09, Rob Herring wrote: >>> Copy the config fragments from the AOSP common kernel tree. It is >>> becoming possible to run mainline kernels with Android, but the kernel >>> defconfigs don't work as-is and debugging missing config options is a >>> pain. Adding the config fragments into the kernel tree, makes >>> configuring a mainline kernel as simple as: >>> >>> make ARCH=arm multi_v7_defconfig android-base.config >>> android-recommended.config >>> >>> Cc: Amit Pundir >>> Cc: John Stultz >>> Cc: Dmitry Torokhov >>> Cc: Rom Lemarchand >>> Signed-off-by: Rob Herring >>> --- >>> kernel/configs/android-base.config| 161 >>> ++ >>> kernel/configs/android-recommended.config | 121 ++ > > [...] > >>> +CONFIG_STAGING=y >>> +CONFIG_SWITCH=y >> >> Switch Class support is dropped from kernel/common/android-4.4 sometime back. > > Okay. I'm also removing these options in v2 which don't exist in > upstream. Any comments on them? > > IP6_NF_TARGET_REJECT_SKERR > IP_NF_TARGET_REJECT_SKERR > NETFILTER_XT_MATCH_QTAGUID > NETFILTER_XT_MATCH_QUOTA2 > NETFILTER_XT_MATCH_QUOTA2_LOG > PPPOLAC > PPPOPNS > RESOURCE_COUNTERS > SECURITY_PERF_EVENTS_RESTRICT > USB_CONFIGFS_F_MTP > USB_CONFIGFS_F_PTP > USB_CONFIGFS_F_ACC > USB_CONFIGFS_F_AUDIO_SRC > USB_CONFIGFS_UEVENT > USB_OTG_WAKELOCK > ANDROID_TIMED_GPIO > ARM_KERNMEM_PERMS > INPUT_KEYCHORD > INPUT_KEYRESET > TABLET_USB_WACOM In my opinion we can keep the core configs (usb gadget, netfilter, input key et al.). They will not harm the resulting kernel config anyway. And we can definitely drop following configs from v2: IP6_NF_TARGET_REJECT_SKERR IP_NF_TARGET_REJECT_SKERR RESOURCE_COUNTERS ANDROID_TIMED_GPIO ARM_KERNMEM_PERMS TABLET_USB_WACOM Also please add the following options in v2, which are present in android-4.4 configs but missing from v1. In android-base.config: CONFIG_DM_VERITY_FEC CONFIG_INET_DIAG_DESTROY CONFIG_IP_MULTICAST CONFIG_IP_NF_NAT CONFIG_QUOTA In android-recommended.config: CONFIG_DRAGONRISE_FF CONFIG_TASKSTATS CONFIG_TASK_DELAY_ACCT CONFIG_TASK_IO_ACCOUNTING CONFIG_TASK_XACCT Regards, Amit Pundir > > Rob
[PATCH] usb: gadget: rndis: free response queue during REMOTE_NDIS_RESET_MSG
From: xerox_lin
When rndis data transfer is in progress, some Windows7 Host PC is not
sending the GET_ENCAPSULATED_RESPONSE command for receiving the response
for the previous SEND_ENCAPSULATED_COMMAND processed.
The rndis function driver appends each response for the
SEND_ENCAPSULATED_COMMAND in a queue. As the above process got corrupted,
the Host sends a REMOTE_NDIS_RESET_MSG command to do a soft-reset.
As the rndis response queue is not freed, the previous response is sent
as a part of this REMOTE_NDIS_RESET_MSG's reset response and the Host
block any more Rndis transfers.
Hence free the rndis response queue as a part of this soft-reset so that
the correct response for REMOTE_NDIS_RESET_MSG is sent properly during the
response command.
Signed-off-by: Rajkumar Raghupathy
Signed-off-by: Xerox Lin
[AmitP: Cherry-picked this patch and folded other relevant
fixes from Android common kernel android-4.4]
Signed-off-by: Amit Pundir
---
Cherry picked this usb tethering fix from AOSP kernel/common/android-4.4
tree and to make sure it doesn't get overlooked, submiting it for review
and comment.
drivers/usb/gadget/function/rndis.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/gadget/function/rndis.c
b/drivers/usb/gadget/function/rndis.c
index 943c21a..ab6ac1b 100644
--- a/drivers/usb/gadget/function/rndis.c
+++ b/drivers/usb/gadget/function/rndis.c
@@ -680,6 +680,12 @@ static int rndis_reset_response(struct rndis_params
*params,
{
rndis_reset_cmplt_type *resp;
rndis_resp_t *r;
+ u8 *xbuf;
+ u32 length;
+
+ /* drain the response queue */
+ while ((xbuf = rndis_get_next_response(params, &length)))
+ rndis_free_response(params, xbuf);
r = rndis_add_response(params, sizeof(rndis_reset_cmplt_type));
if (!r)
--
2.7.4
[PATCH v2] usb: gadget: rndis: free response queue during REMOTE_NDIS_RESET_MSG
From: Xerox Lin
When rndis data transfer is in progress, some Windows7 Host PC is not
sending the GET_ENCAPSULATED_RESPONSE command for receiving the response
for the previous SEND_ENCAPSULATED_COMMAND processed.
The rndis function driver appends each response for the
SEND_ENCAPSULATED_COMMAND in a queue. As the above process got corrupted,
the Host sends a REMOTE_NDIS_RESET_MSG command to do a soft-reset.
As the rndis response queue is not freed, the previous response is sent
as a part of this REMOTE_NDIS_RESET_MSG's reset response and the Host
block any more Rndis transfers.
Hence free the rndis response queue as a part of this soft-reset so that
the correct response for REMOTE_NDIS_RESET_MSG is sent properly during the
response command.
Signed-off-by: Rajkumar Raghupathy
Signed-off-by: Xerox Lin
[AmitP: Cherry-picked this patch and folded other relevant
fixes from Android common kernel android-4.4]
Signed-off-by: Amit Pundir
---
v2: Sanitized the name of original author. Dropped his email address from
the list of reviewers, since it is no longer valid.
v1: Cherry picked this usb tethering fix from AOSP kernel/common/android-4.4
tree and to make sure it doesn't get overlooked, submiting it for review
and comment.
drivers/usb/gadget/function/rndis.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/gadget/function/rndis.c
b/drivers/usb/gadget/function/rndis.c
index 943c21a..ab6ac1b 100644
--- a/drivers/usb/gadget/function/rndis.c
+++ b/drivers/usb/gadget/function/rndis.c
@@ -680,6 +680,12 @@ static int rndis_reset_response(struct rndis_params
*params,
{
rndis_reset_cmplt_type *resp;
rndis_resp_t *r;
+ u8 *xbuf;
+ u32 length;
+
+ /* drain the response queue */
+ while ((xbuf = rndis_get_next_response(params, &length)))
+ rndis_free_response(params, xbuf);
r = rndis_add_response(params, sizeof(rndis_reset_cmplt_type));
if (!r)
--
2.7.4
[PATCH] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Add initial dts support for Xiaomi Poco F1 (Beryllium).
This initial support is based on upstream Dragonboard 845c
(sdm845) device. With this dts patch Beryllium boots AOSP up
to ADB shell over USB-C.
Supported functionality includes UFS, USB-C (peripheral),
microSD card and Vol+/Vol-/power keys. Bluetooth should work
too but couldn't be verified from adb command line, it is
verified when enabled from UI with few WIP display patches.
Just like initial db845c support, initializing the SMMU is
clearing the mapping used for the splash screen framebuffer,
which causes the device to hang during boot and recovery
needs a hard power reset. This can be worked around using:
fastboot oem select-display-panel none
To switch ON the display back run:
fastboot oem select-display-panel
But this only works on Beryllium devices running bootloader
version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
Android-9 based release. Newer bootloader version do not
support switching OFF the display panel at all. So we need
a couple of additional smmu patches (under review) from here
to boot to shell:
https://github.com/pundiramit/linux/commits/beryllium-mainline
Signed-off-by: Amit Pundir
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sdm845-beryllium.dts | 320 ++
2 files changed, 321 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 0f2c33d611df..3ef1b48bc0cb 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -21,6 +21,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r1.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-beryllium.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
new file mode 100644
index ..68ccf53d88ca
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-beryllium.dts
@@ -0,0 +1,320 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "sdm845.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+
+/ {
+ model = "Xiaomi Technologies, Inc. Beryllium";
+ compatible = "qcom,sdm845";
+ /* required for bootloader to select correct board */
+ qcom,board-id = <69 0>;
+ qcom,msm-id = <321 0x20001>;
+
+ aliases {
+ hsuart0 = &uart6;
+ };
+
+ dc12v: dc12v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "DC12V";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&vol_up_pin_a>;
+
+ vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <&pm8998_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ vbat: vbat-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT";
+
+ vin-supply = <&dc12v>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vbat_som: vbat-som-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT_SOM";
+
+ vin-supply = <&dc12v>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vdc_3v3: vdc-3v3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VDC_3V3";
+ vin-supply = <&dc12v>;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vdc_5v: vdc-5v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VDC_5V";
+
+ vin-supply = <&dc12v>;
+ regulator-min-microvolt = <50>;
+
Re: [PATCH] ath10k: Introduce a devicetree quirk to skip host cap QMI requests
On Wed, 30 Sep 2020 at 00:38, Rob Herring wrote: > > On Fri, Sep 25, 2020 at 11:59:41PM +0530, Amit Pundir wrote: > > There are firmware versions which do not support host capability > > QMI request. We suspect either the host cap is not implemented or > > there may be firmware specific issues, but apparently there seem > > to be a generation of firmware that has this particular behavior. > > > > For example, firmware build on Xiaomi Poco F1 (sdm845) phone: > > "QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1" > > > > If we do not skip the host cap QMI request on Poco F1, then we > > get a QMI_ERR_MALFORMED_MSG_V01 error message in the > > ath10k_qmi_host_cap_send_sync(). But this error message is not > > fatal to the firmware nor to the ath10k driver and we can still > > bring up the WiFi services successfully if we just ignore it. > > > > Hence introducing this DeviceTree quirk to skip host capability > > QMI request for the firmware versions which do not support this > > feature. > > So if you change the WiFi firmware, you may force a DT change too. Those > are pretty independent things otherwise. This is a valid concern and I'm not sure about the other devices, but on PocoF1 I have tried all the three released firmware version updates: WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1 WLAN.HL.2.0.c3-00445-QCAHLSWMTPLZ-1 WLAN.HL.2.0.c3-00534-QCAHLSWMTPLZ-1 and none of them works without this skip host-cap patch or equivalent hack. PocoF1 is already 2+ years old device and sadly I do not expect any major vendor update coming its way. > > Why can't you just always ignore this error? If you can't deal with this > entirely in the driver, then it should be part of the WiFi firmware so > it's always in sync. I don't know the technical details of the ath10k/qmi driver, but I'm OK if we just ignore the return value of ath10k_qmi_host_cap_send_sync() and move along. Regards, Amit Pundir > > Rob
Re: [PATCH v5] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Hi Konrad,
On Sat, 22 Aug 2020 at 02:51, Konrad Dybcio wrote:
>
> Hi
>
> First of all, sorry if anybody sees this twice. I've been messing with
> Thunderbird lately.
>
>
>
> > dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r3.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c.dtb
> > +dtb-$(CONFIG_ARCH_QCOM) += sdm845-beryllium.dtb
>
> [B]eryllium should come before [C]heza, no? Also, aren't the non-development
> boards supposed to include the vendor name? i.e.
> sdm845-(xiaomi/poco)-beryllium.dtb
Ack. I didn't pay attention to that part. I'll fix that.
>
>
> > + model = "Xiaomi Technologies Inc. Beryllium";
>
> At least with Xperias, we settled on setting the model property to the
> "pretty" name, in this case Poco F1
Ack.
>
>
> > + pm8998-rpmh-regulators {
> > + compatible = "qcom,pm8998-rpmh-regulators";
> > + qcom,pmic-id = "a";
> > +
> > + vreg_l1a_0p875: ldo1 {
>
> I think you forgot to include (regulatorname)-supply properties which should
> cause havoc with all things regulators..
I didn't know that. Thanks for pointing that out. I just copied db845c
dts and started removing the nodes/properties which I didn't seem fit.
There is a very good probability that I goofed up big time.
FWIW in my limited testing so far (Booted AOSP to UI, with working
Touchscreen/BT/WiFi/Audio with out-of-tree drivers [1]), I didn't run
into issues with mainline (v5.9-rc1) or Android GKI (v5.4.58). May be
I just got lucky. I'll check up on the usage of (regulatorname)-supply
properties.
>
>
> > + vreg_l1a_0p875: ldo1 {
> > + regulator-min-microvolt = <88>;
> > + regulator-max-microvolt = <88>;
> 0p88? Unless it's a PMIC limitation.. Please also confirm names for the rest
> of the regulators.
>
> Also why are there so few regulators? And none from pmi8998? Are the rest
> WIP/coming in a followup commit, or are they disabled on this board? AFAICS
> you only include SoC/PMIC DTs which would suggest they should be there.
I intend to add more regulators and feature nodes in follow up commits.
>
>
> > +/* Reserved memory changes from downstream */
>
> Wouldn't it look better if you included that in the main {} node instead of
> reopening it in the middle of the file? I mean, it works, but let's hear what
> others have to say.
Ack. I'll fix that if necessary.
>
>
> > + * It seems that mmc_test reports errors if drive
> > + * strength is not 16 on clk, cmd, and data pins.
>
> You say that, but then you set "drive-strength = <10>;" for cmd and data,
> please confirm it's intentional.
In sync with db845c as well as downstream dts but I'll check on this as well.
>
>
> > +&ufs_mem_hc {
>
> UFS comes before USB alphabetically.
Ack. I'll add them alphabetically if that is the common norm.
Regards,
Amit Pundir
[1] https://github.com/pundiramit/linux/commits/beryllium-mainline
>
>
> > +&ufs_mem_phy
>
> Ditto
>
>
> > +&qup_uart6_default
>
> Ditto
>
>
> Konrad
[PATCH] ath10k: Introduce a devicetree quirk to skip host cap QMI requests
There are firmware versions which do not support host capability
QMI request. We suspect either the host cap is not implemented or
there may be firmware specific issues, but apparently there seem
to be a generation of firmware that has this particular behavior.
For example, firmware build on Xiaomi Poco F1 (sdm845) phone:
"QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1"
If we do not skip the host cap QMI request on Poco F1, then we
get a QMI_ERR_MALFORMED_MSG_V01 error message in the
ath10k_qmi_host_cap_send_sync(). But this error message is not
fatal to the firmware nor to the ath10k driver and we can still
bring up the WiFi services successfully if we just ignore it.
Hence introducing this DeviceTree quirk to skip host capability
QMI request for the firmware versions which do not support this
feature.
Suggested-by: Bjorn Andersson
Signed-off-by: Amit Pundir
---
.../devicetree/bindings/net/wireless/qcom,ath10k.txt| 5 +
drivers/net/wireless/ath/ath10k/qmi.c | 13 ++---
drivers/net/wireless/ath/ath10k/snoc.c | 3 +++
drivers/net/wireless/ath/ath10k/snoc.h | 1 +
4 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
index 65ee68efd574..135c7ecd4487 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -86,6 +86,11 @@ Optional properties:
Value type:
Definition: Quirk specifying that the firmware expects the 8bit version
of the host capability QMI request
+- qcom,snoc-host-cap-skip-quirk:
+ Usage: Optional
+ Value type:
+ Definition: Quirk specifying that the firmware wants to skip the host
+ capability QMI request
- qcom,xo-cal-data: xo cal offset to be configured in xo trim register.
- qcom,msa-fixed-perm: Boolean context flag to disable SCM call for statically
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c
b/drivers/net/wireless/ath/ath10k/qmi.c
index 5468a41e928e..5adff7695e18 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -770,6 +770,7 @@ ath10k_qmi_ind_register_send_sync_msg(struct ath10k_qmi
*qmi)
static void ath10k_qmi_event_server_arrive(struct ath10k_qmi *qmi)
{
struct ath10k *ar = qmi->ar;
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
int ret;
ret = ath10k_qmi_ind_register_send_sync_msg(qmi);
@@ -781,9 +782,15 @@ static void ath10k_qmi_event_server_arrive(struct
ath10k_qmi *qmi)
return;
}
- ret = ath10k_qmi_host_cap_send_sync(qmi);
- if (ret)
- return;
+ /*
+* Skip the host capability request for the firmware versions which
+* do not support this feature.
+*/
+ if (!test_bit(ATH10K_SNOC_FLAG_SKIP_HOST_CAP_QUIRK, &ar_snoc->flags)) {
+ ret = ath10k_qmi_host_cap_send_sync(qmi);
+ if (ret)
+ return;
+ }
ret = ath10k_qmi_msa_mem_info_send_sync_msg(qmi);
if (ret)
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c
b/drivers/net/wireless/ath/ath10k/snoc.c
index 354d49b1cd45..4efbf1339c80 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -1281,6 +1281,9 @@ static void ath10k_snoc_quirks_init(struct ath10k *ar)
if (of_property_read_bool(dev->of_node,
"qcom,snoc-host-cap-8bit-quirk"))
set_bit(ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK, &ar_snoc->flags);
+
+ if (of_property_read_bool(dev->of_node,
"qcom,snoc-host-cap-skip-quirk"))
+ set_bit(ATH10K_SNOC_FLAG_SKIP_HOST_CAP_QUIRK, &ar_snoc->flags);
}
int ath10k_snoc_fw_indication(struct ath10k *ar, u64 type)
diff --git a/drivers/net/wireless/ath/ath10k/snoc.h
b/drivers/net/wireless/ath/ath10k/snoc.h
index a3dd06f6ac62..2a0045f0af7e 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.h
+++ b/drivers/net/wireless/ath/ath10k/snoc.h
@@ -47,6 +47,7 @@ enum ath10k_snoc_flags {
ATH10K_SNOC_FLAG_UNREGISTERING,
ATH10K_SNOC_FLAG_RECOVERY,
ATH10K_SNOC_FLAG_8BIT_HOST_CAP_QUIRK,
+ ATH10K_SNOC_FLAG_SKIP_HOST_CAP_QUIRK,
};
struct clk_bulk_data;
--
2.7.4
Re: [PATCH] ath10k: qmi: Skip host capability request for Xiaomi Poco F1
On Fri, 25 Sep 2020 at 20:57, Bjorn Andersson
wrote:
>
> On Thu 24 Sep 11:31 CDT 2020, Kalle Valo wrote:
>
> > Amit Pundir writes:
> >
> > > Workaround to get WiFi working on Xiaomi Poco F1 (sdm845)
> > > phone. We get a non-fatal QMI_ERR_MALFORMED_MSG_V01 error
> > > message in ath10k_qmi_host_cap_send_sync(), but we can still
> > > bring up WiFi services successfully on AOSP if we ignore it.
> > >
> > > We suspect either the host cap is not implemented or there
> > > may be firmware specific issues. Firmware version is
> > > QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1
> > >
> > > qcom,snoc-host-cap-8bit-quirk didn't help. If I use this
> > > quirk, then the host capability request does get accepted,
> > > but we run into fatal "msa info req rejected" error and
> > > WiFi interface doesn't come up.
> > >
> > > Attempts are being made to debug the failure reasons but no
> > > luck so far. Hence this device specific workaround instead
> > > of checking for QMI_ERR_MALFORMED_MSG_V01 error message.
> > > Tried ath10k/WCN3990/hw1.0/wlanmdsp.mbn from the upstream
> > > linux-firmware project but it didn't help and neither did
> > > building board-2.bin file from stock bdwlan* files.
> > >
> > > This workaround will be removed once we have a viable fix.
> > > Thanks to postmarketOS guys for catching this.
> > >
> > > Signed-off-by: Amit Pundir
> >
> > Bjorn, is this ok to take?
> >
>
> As I wrote in the answer to Amit I think we should introduce a generic
> quirk to skip host_cap instead.
>
> So if you pick this up (which is an ok short term workaround) I think we
> should revert it once we have a generic mechanism.
Hi Bjorn, just sent out a generic skip quirk for review.
Regards,
Amit Pundir
>
> Regards,
> Bjorn
>
> > > --- a/drivers/net/wireless/ath/ath10k/qmi.c
> > > +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> > > @@ -651,7 +651,8 @@ static int ath10k_qmi_host_cap_send_sync(struct
> > > ath10k_qmi *qmi)
> > >
> > > /* older FW didn't support this request, which is not fatal */
> > > if (resp.resp.result != QMI_RESULT_SUCCESS_V01 &&
> > > - resp.resp.error != QMI_ERR_NOT_SUPPORTED_V01) {
> > > + resp.resp.error != QMI_ERR_NOT_SUPPORTED_V01 &&
> > > + !of_machine_is_compatible("xiaomi,beryllium")) { /* Xiaomi Poco
> > > F1 workaround */
> > > ath10k_err(ar, "host capability request rejected: %d\n",
> > > resp.resp.error);
> >
> > ath10k-check complained about a too long line, so in the pending branch
> > I moved the comment before the if statement.
> >
> > --
> > https://patchwork.kernel.org/project/linux-wireless/list/
> >
> > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2 2/3] Input: Add Novatek NT36xxx touchscreen driver
On Sun, 27 Sep 2020 at 18:06, wrote:
>
> From: AngeloGioacchino Del Regno
>
> This is a driver for the Novatek in-cell touch controller and
> supports various chips from the NT36xxx family, currently
> including NT36525, NT36672A, NT36676F, NT36772 and NT36870.
>
> Functionality like wake gestures and firmware flashing is not
> included: I am not aware of any of these DrIC+Touch combo
> chips not including a non-volatile memory and it should be
> highly unlikely to find one, since the touch firmware is
> embedded into the DriverIC one, which is obviously necessary
> to drive the display unit.
>
> However, the necessary address for the firmware update
> procedure was included into the address table in this driver
> so, in the event that someone finds the need to implement it
> for a reason or another, it will be pretty straightforward to.
>
> This driver is lightly based on the downstream implementation [1].
> [1] https://github.com/Rasenkai/caf-tsoft-Novatek-nt36xxx
>
This is so cool!
Xiaomi PocoF1 phone uses same family touchscreen IC and I could
test this series on that phone as well.
However I do have to make a minor change to get it working. The
downstream driver and even the github code you linked above use
GPIO mapped IRQ, and I had to switch to that to get touchscreen
working with your driver
https://github.com/pundiramit/linux/commit/0a73eb656c1e80787dc195641ce7b0076fddb38e.
I wonder if I'm missing any devicetree property other than interrupts?
Regards,
Amit Pundir
> Signed-off-by: AngeloGioacchino Del Regno
> ---
> drivers/input/touchscreen/Kconfig | 12 +
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/nt36xxx.c | 742
> drivers/input/touchscreen/nt36xxx.h | 122 +
> 4 files changed, 877 insertions(+)
> create mode 100644 drivers/input/touchscreen/nt36xxx.c
> create mode 100644 drivers/input/touchscreen/nt36xxx.h
>
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index 35c867b2d9a7..6d118b967021 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -605,6 +605,18 @@ config TOUCHSCREEN_MTOUCH
> To compile this driver as a module, choose M here: the
> module will be called mtouch.
>
> +config TOUCHSCREEN_NT36XXX
> + tristate "Novatek NT36XXX In-Cell I2C touchscreen controller"
> + depends on I2C
> + help
> + Say Y here if you have a Novatek NT36xxx series In-Cell
> + touchscreen connected to your system over I2C.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called nt36xxx.
> +
> config TOUCHSCREEN_IMX6UL_TSC
> tristate "Freescale i.MX6UL touchscreen controller"
> depends on (OF && GPIOLIB) || COMPILE_TEST
> diff --git a/drivers/input/touchscreen/Makefile
> b/drivers/input/touchscreen/Makefile
> index 30d1e1b42492..424a555e03d5 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_TOUCHSCREEN_MIGOR) += migor_ts.o
> obj-$(CONFIG_TOUCHSCREEN_MMS114) += mms114.o
> obj-$(CONFIG_TOUCHSCREEN_MTOUCH) += mtouch.o
> obj-$(CONFIG_TOUCHSCREEN_MK712)+= mk712.o
> +obj-$(CONFIG_TOUCHSCREEN_NT36XXX) += nt36xxx.o
> obj-$(CONFIG_TOUCHSCREEN_HP600)+= hp680_ts_input.o
> obj-$(CONFIG_TOUCHSCREEN_HP7XX)+= jornada720_ts.o
> obj-$(CONFIG_TOUCHSCREEN_IPAQ_MICRO) += ipaq-micro-ts.o
> diff --git a/drivers/input/touchscreen/nt36xxx.c
> b/drivers/input/touchscreen/nt36xxx.c
> new file mode 100644
> index ..57e189938d12
> --- /dev/null
> +++ b/drivers/input/touchscreen/nt36xxx.c
> @@ -0,0 +1,742 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2010 - 2017 Novatek, Inc.
> + * Copyright (C) 2020 AngeloGioacchino Del Regno
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "nt36xxx.h"
> +
> +static const struct nt36xxx_mem_map nt36xxx_memory_maps[] = {
> + [NT36525_IC] = { 0x11a00, 0x1, 0x12000, 0x14000, 0x14002 },
> + [NT36672A_IC] = { 0x21c00, 0x2, 0x23000, 0x24000, 0x24002 },
> + [NT36676F_IC] = { 0x11a00, 0x1, 0x12000, 0x14000, 0x14002 },
> + [NT36772_IC] = { 0x11e00, 0x1, 0x12000, 0x14000, 0x14002 },
> + [NT36870_IC] = { 0x25000, 0x2, 0x23000, 0x24000, 0x24002 },
> +};
> +
> +static const struct nt36xxx_trim_table trim_id_table[] = {
> + {
> +.
Re: [PATCH v2 2/3] Input: Add Novatek NT36xxx touchscreen driver
On Tue, 29 Sep 2020 at 03:21, Dmitry Torokhov wrote: > > On Mon, Sep 28, 2020 at 03:18:18PM +0530, Amit Pundir wrote: > > On Sun, 27 Sep 2020 at 18:06, wrote: > > > > > > From: AngeloGioacchino Del Regno > > > > > > This is a driver for the Novatek in-cell touch controller and > > > supports various chips from the NT36xxx family, currently > > > including NT36525, NT36672A, NT36676F, NT36772 and NT36870. > > > > > > Functionality like wake gestures and firmware flashing is not > > > included: I am not aware of any of these DrIC+Touch combo > > > chips not including a non-volatile memory and it should be > > > highly unlikely to find one, since the touch firmware is > > > embedded into the DriverIC one, which is obviously necessary > > > to drive the display unit. > > > > > > However, the necessary address for the firmware update > > > procedure was included into the address table in this driver > > > so, in the event that someone finds the need to implement it > > > for a reason or another, it will be pretty straightforward to. > > > > > > This driver is lightly based on the downstream implementation [1]. > > > [1] https://github.com/Rasenkai/caf-tsoft-Novatek-nt36xxx > > > > > > > This is so cool! > > > > Xiaomi PocoF1 phone uses same family touchscreen IC and I could > > test this series on that phone as well. > > > > However I do have to make a minor change to get it working. The > > downstream driver and even the github code you linked above use > > GPIO mapped IRQ, and I had to switch to that to get touchscreen > > working with your driver > > https://github.com/pundiramit/linux/commit/0a73eb656c1e80787dc195641ce7b0076fddb38e. > > I wonder if I'm missing any devicetree property other than interrupts? > > Simply specifying GPIO controller/pin as interrupt property should work, > there should be no need to parse custom GPIO property and convert it to > IRQ in the driver. > Indeed. I don't know what was tripping me off yesterday, but I got it working today with interrupt properties. Thank you. Regards, Amit Pundir > Thanks. > > -- > Dmitry
Re: [PATCH] staging: ion: remove from the tree
On Thu, 27 Aug 2020 at 21:34, Greg Kroah-Hartman wrote: > > On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > > The ION android code has long been marked to be removed, now that we > > > dma-buf support merged into the real part of the kernel. > > > > > > It was thought that we could wait to remove the ion kernel at a later > > > time, but as the out-of-tree Android fork of the ion code has diverged > > > quite a bit, and any Android device using the ion interface uses that > > > forked version and not this in-tree version, the in-tree copy of the > > > code is abandonded and not used by anyone. > > > > > > Combine this abandoned codebase with the need to make changes to it in > > > order to keep the kernel building properly, which then causes merge > > > issues when merging those changes into the out-of-tree Android code, and > > > you end up with two different groups of people (the in-kernel-tree > > > developers, and the Android kernel developers) who are both annoyed at > > > the current situation. Because of this problem, just drop the in-kernel > > > copy of the ion code now, as it's not used, and is only causing problems > > > for everyone involved. > > > > > > Cc: "Arve Hjønnevåg" > > > Cc: "Christian König" > > > Cc: Christian Brauner > > > Cc: Christoph Hellwig > > > Cc: Hridya Valsaraju > > > Cc: Joel Fernandes > > > Cc: John Stultz > > > Cc: Laura Abbott > > > Cc: Martijn Coenen > > > Cc: Shuah Khan > > > Cc: Sumit Semwal > > > Cc: Suren Baghdasaryan > > > Cc: Todd Kjos > > > Cc: de...@driverdev.osuosl.org > > > Cc: dri-de...@lists.freedesktop.org > > > Cc: linaro-mm-...@lists.linaro.org > > > Signed-off-by: Greg Kroah-Hartman > > > > We discussed this at the Android MC on Monday and the plan was to > > remove it after the next LTS release. > > I know it was discussed, my point is that it is actually causing > problems now (with developers who want to change the internal kernel api > hitting issues, and newbies trying to clean up code in ways that isn't > exactly optimal wasting maintainer cycles), and that anyone who uses > this code, is not actually using this version of the code. Everyone who > relies on ion right now, is using the version that is in the Android > common kernel tree, which has diverged from this in-kernel way quite a > bit now for the reason that we didn't want to take any of those new > features in the in-kernel version. > > So this is a problem that we have caused by just wanting to wait, no one > is using this code, combined with it causing problems for the upstream > developers. > > There is nothing "magic" about the last kernel of the year that requires > this code to sit here until then. At that point in time, all users > will, again, be using the forked Android kernel version, and if we > delete this now here, that fork can remain just fine, with the added > benifit of it reducing developer workloads here in-kernel. > > So why wait? Hi, I don't know what is the right thing to do here. I just want to highlight that AOSP's audio (codec2) HAL depends on the ION system heap and it will break AOSP for people who boot mainline on their devices, even for just testing purpose like we do in Linaro. Right now we need only 1 (Android specific out-of-tree) patch to boot AOSP with mainline and Sumit is already trying to upstream that vma naming patch. Removal of in-kernel ION, will just add more to that delta. Regards, Amit Pundir > > thanks, > > greg k-h
Re: [PATCH v6] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
On Mon, 31 Aug 2020 at 13:28, Konrad Dybcio wrote: > > > Hi Konrad, > > > > I couldn't find answer to your question around missing > > (regulatorname)-supply properties. Need help in figuring out that > > part. > > When the phone boots up and RPM(H) kicks in, you should see regulators > probing like "s1 supplied by foo". Without the *-supply stuff, you > will likely get "supplied by regulator-dummy". This happens here [1] > and to my knowledge it is the "eletrical wiring" for Linux, as in it > makes Linux aware of which regulators are connected electrically to > the same supply (so that kernel knows when the supply is on and what > voltage it's at). For qcom platforms, this is common per-pmic (afaik, > please check if you are able to!), so you can likely just copy-paste > that part from msm8998-mtp.dtsi, which also uses pm(i)8998. Thank you for the pointer. I dug around the vph_pwr fixed-regulator node used by fellow sdm845 devices. I assume it is safe to copy it from sdm845-mtp but I couldn't verify it in the downstream device-tree, so I'm a bit hesitant. My main concern is that I don't want to burn down my only device :) I did find a few regulator nodes downstream which matches with upstream sdm845-mtp but since I'm not using any of them in my beryllium dts, I'm going to skip them for now. As you pointed out, in case of regulator lookup failure Linux will fall back to dummy regulators, which is working fine for me so far. Also I see that vdd-*-supply properties are optional according to Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt, so I assume it is safe to skip them? Regards, Amit Pundir > > Konrad
Re: [PATCH] wireless: ath10k: Return early in ath10k_qmi_event_server_exit() to avoid hard crash on reboot
On Mon, 8 Jun 2020 at 17:07, Kalle Valo wrote: > > I don't agree with this. If you read through the replies to the bug report, > > it is clear that NS migration uncovered a corner case or even a bug. So we > > should try to fix that indeed. > > I'm with Mani, we should try to fix ath10k instead. Hopefully we can > find a fix soon. Hi Team, Any updates on this? I can reproduce this hard crash on v5.9-rc1 as well. It is not a blocker for us because we switched to a userspace workaround, where we do not wait for modem to shutdown gracefully and SIGKILL it instead, during the shutdown/reboot process. But I'm happy to take a swing at any intermediate/in-progress solution available. Regards, Amit Pundir > > Forcing QCA6390 users to use the userspace qrtr-ns would be bad user > experience, I really would want to avoid that. > > -- > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: your mail
On Thu, 13 Aug 2020 at 12:38, Bjorn Andersson
wrote:
>
> On Thu 06 Aug 15:31 PDT 2020, Konrad Dybcio wrote:
>
> > Subject: Re: [PATCH v4] arm64: dts: qcom: Add support for Xiaomi Poco F1
> > (Beryllium)
> >
> > >// This removed_region is needed to boot the device
> > > // TODO: Find out the user of this reserved memory
> > > removed_region: memory@88f0 {
> >
> > This region seems to belong to the Trust Zone. When Linux tries to access
> > it, TZ bites and shuts the device down.
> >
>
> This is in line with what the documentation indicates and then it would
> be better to just bump &tz_mem to a size of 0x490.
Hi, so just to be sure that I got this right, you want me to extend
&tz_mem to the size of 0x490 from the default size of 0x2D0 by
including this downstream &removed_region (of size 0x1A0) +
previously unreserved downstream memory region (of size 0x20), to
align with the starting address of &qseecom_mem?
I just gave this &tz_mem change a spin and I do not see any obvious
regression in my limited smoke testing (Boots AOSP to UI with
v5.9-rc1. Touch/BT/WiFi works) so far, with 20+ out-of-tree patches.
Regards,
Amit Pundir
>
> Regards,
> Bjorn
[PATCH v6] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Add initial dts support for Xiaomi Poco F1 (Beryllium).
This initial support is based on upstream Dragonboard 845c
(sdm845) device. With this dts, Beryllium boots AOSP up to
ADB shell over USB-C.
Supported functionality includes UFS, USB-C (peripheral),
microSD card and Vol+/Vol-/power keys. Bluetooth should work
too but couldn't be verified from adb command line, it is
verified when enabled from UI with few WIP display patches.
Just like initial db845c support, initializing the SMMU is
clearing the mapping used for the splash screen framebuffer,
which causes the device to hang during boot and recovery
needs a hard power reset. This can be worked around using:
fastboot oem select-display-panel none
To switch ON the display back run:
fastboot oem select-display-panel
But this only works on Beryllium devices running bootloader
version BOOT.XF.2.0-00369-SDM845LZB-1 that shipped with
Android-9 based release. Newer bootloader version do not
support switching OFF the display panel at all.
Signed-off-by: Amit Pundir
---
My WIP tree with a few out-of-tree patches to support
display, touchscreen, wifi, audio etc is here:
https://github.com/pundiramit/linux/commits/beryllium-mainline
v6: Renamed dts file to include vendor (xiaomi) name. Moved
reserved memory changes in the main node. Renamed model to
phone's pretty name. Removed the mmc drive strength comment
to avoid further confusion. Sorted the entries in alphabetical
order, but additional pinctrl entries are still defined at the
end to align with the upstream db845c dts.
v5: Bumped &tz_mem size from 0x2d0 to 0x490 (to include
downstream &removed_region), all the way up to &qseecom_mem.
v4: Added more downstream reserved memory regions. It probably
need more work, but for now I see adsp/cdsp/wlan remoteprocs
powering up properly. Removed the regulator nodes not
required for the device, as suggested by Bjorn. Also added
couple of clocks to protected clocks, which is needed for
display to work.
v3: Added a reserved-memory region from downstream kernel to fix
a boot regression with recent dma-pool changes in v5.8-rc6.
v2: Updated machine compatible string for seemingly inevitable
future quirks.
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 383 +
2 files changed, 384 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index d8f1466e6758..9adc269252d3 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -30,6 +30,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-cheza-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-db845c.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm845-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sdm845-xiaomi-beryllium.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm850-lenovo-yoga-c630.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8250-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
new file mode 100644
index ..cd25d5d8c0c9
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
@@ -0,0 +1,383 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "sdm845.dtsi"
+#include "pm8998.dtsi"
+#include "pmi8998.dtsi"
+
+/*
+ * Delete following upstream (sdm845.dtsi) reserved
+ * memory mappings which are different in this device.
+ */
+/delete-node/ &tz_mem;
+/delete-node/ &adsp_mem;
+/delete-node/ &wlan_msa_mem;
+/delete-node/ &mpss_region;
+/delete-node/ &venus_mem;
+/delete-node/ &cdsp_mem;
+/delete-node/ &mba_region;
+/delete-node/ &slpi_mem;
+/delete-node/ &spss_mem;
+/delete-node/ &rmtfs_mem;
+
+/ {
+ model = "Xiaomi Pocophone F1";
+ compatible = "xiaomi,beryllium", "qcom,sdm845";
+
+ /* required for bootloader to select correct board */
+ qcom,board-id = <69 0>;
+ qcom,msm-id = <321 0x20001>;
+
+ aliases {
+ hsuart0 = &uart6;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&vol_up_pin_a>;
+
+ vol-up {
+ label = "Volume Up";
+ linux,code = ;
+ gpios = <&pm8998_gpio 6 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ /* Reserved memory changes from downstream */
+ reserved-memory {
+ tz_mem: memory@8620 {
+
