Re: [PATCH] soc: imx: Add generic i.MX8 SoC driver
On Sun, 3 Feb 2019 at 11:50, Abel Vesa wrote: > Add generic i.MX8 SoC driver along with the i.MX8MQ SoC specific code. > > Signed-off-by: Abel Vesa Tested-by: Chris Spencer My patch series which adds support for the i.MX8MQ to the CAAM driver [1] needs the SoC driver, so it would be good to get this one in. Thanks, Chris [1] https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg36947.html
Re: [PATCH v2 17/26] userfaultfd: wp: support swap and page migration
On Thu, Feb 21, 2019 at 01:16:19PM -0500, Jerome Glisse wrote:
> On Tue, Feb 12, 2019 at 10:56:23AM +0800, Peter Xu wrote:
> > For either swap and page migration, we all use the bit 2 of the entry to
> > identify whether this entry is uffd write-protected. It plays a similar
> > role as the existing soft dirty bit in swap entries but only for keeping
> > the uffd-wp tracking for a specific PTE/PMD.
> >
> > Something special here is that when we want to recover the uffd-wp bit
> > from a swap/migration entry to the PTE bit we'll also need to take care
> > of the _PAGE_RW bit and make sure it's cleared, otherwise even with the
> > _PAGE_UFFD_WP bit we can't trap it at all.
> >
> > Note that this patch removed two lines from "userfaultfd: wp: hook
> > userfault handler to write protection fault" where we try to remove the
> > VM_FAULT_WRITE from vmf->flags when uffd-wp is set for the VMA. This
> > patch will still keep the write flag there.
>
> That part is confusing, you probably want to remove that code from
> previous patch or at least address my comment in the previous patch
> review.
(please see below...)
>
> >
> > Signed-off-by: Peter Xu
> > ---
> > include/linux/swapops.h | 2 ++
> > mm/huge_memory.c| 3 +++
> > mm/memory.c | 8 ++--
> > mm/migrate.c| 7 +++
> > mm/mprotect.c | 2 ++
> > mm/rmap.c | 6 ++
> > 6 files changed, 26 insertions(+), 2 deletions(-)
> >
>
> [...]
>
> > diff --git a/mm/memory.c b/mm/memory.c
> > index c2035539e9fd..7cee990d67cf 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -736,6 +736,8 @@ copy_one_pte(struct mm_struct *dst_mm, struct mm_struct
> > *src_mm,
> > pte = swp_entry_to_pte(entry);
> > if (pte_swp_soft_dirty(*src_pte))
> > pte = pte_swp_mksoft_dirty(pte);
> > + if (pte_swp_uffd_wp(*src_pte))
> > + pte = pte_swp_mkuffd_wp(pte);
> > set_pte_at(src_mm, addr, src_pte, pte);
> > }
> > } else if (is_device_private_entry(entry)) {
> > @@ -2815,8 +2817,6 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> > inc_mm_counter_fast(vma->vm_mm, MM_ANONPAGES);
> > dec_mm_counter_fast(vma->vm_mm, MM_SWAPENTS);
> > pte = mk_pte(page, vma->vm_page_prot);
> > - if (userfaultfd_wp(vma))
> > - vmf->flags &= ~FAULT_FLAG_WRITE;
>
> So this is the confusing part with the previous patch that introduce
> that code. It feels like you should just remove that code entirely
> in the previous patch.
When I wrote the other part I didn't completely understand those two
lines so I kept them to make sure I won't throw away anthing that can
be actually useful. If you also agree that we can drop these lines
I'll simply do that in the next version (and I'll drop the comments
too in the commit message). Andrea, please correct me if I am wrong
on that...
>
> > if ((vmf->flags & FAULT_FLAG_WRITE) && reuse_swap_page(page, NULL)) {
> > pte = maybe_mkwrite(pte_mkdirty(pte), vma);
> > vmf->flags &= ~FAULT_FLAG_WRITE;
> > @@ -2826,6 +2826,10 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> > flush_icache_page(vma, page);
> > if (pte_swp_soft_dirty(vmf->orig_pte))
> > pte = pte_mksoft_dirty(pte);
> > + if (pte_swp_uffd_wp(vmf->orig_pte)) {
> > + pte = pte_mkuffd_wp(pte);
> > + pte = pte_wrprotect(pte);
> > + }
> > set_pte_at(vma->vm_mm, vmf->address, vmf->pte, pte);
> > arch_do_swap_page(vma->vm_mm, vma, vmf->address, pte, vmf->orig_pte);
> > vmf->orig_pte = pte;
>
> > diff --git a/mm/migrate.c b/mm/migrate.c
> > index d4fd680be3b0..605ccd1f5c64 100644
> > --- a/mm/migrate.c
> > +++ b/mm/migrate.c
> > @@ -242,6 +242,11 @@ static bool remove_migration_pte(struct page *page,
> > struct vm_area_struct *vma,
> > if (is_write_migration_entry(entry))
> > pte = maybe_mkwrite(pte, vma);
> >
> > + if (pte_swp_uffd_wp(*pvmw.pte)) {
> > + pte = pte_mkuffd_wp(pte);
> > + pte = pte_wrprotect(pte);
> > + }
>
> If the page was write protected prior to migration then it should never
> end up as a write migration entry and thus the above should be something
> like:
> if (is_write_migration_entry(entry)) {
> pte = maybe_mkwrite(pte, vma);
> } else if (pte_swp_uffd_wp(*pvmw.pte)) {
> pte = pte_mkuffd_wp(pte);
> }
Yeah I agree I can't think of another case that will violate the rule,
so I'm taking your advise assuming it can be cleaner.
Thanks!
--
Peter Xu
Re: [ANNOUNCE][CFP] Power Management and Scheduling in the Linux Kernel III edition (OSPM-summit 2019)
Hello, A quick one to inform everybody that registrations are now open! Although list of topics looks pretty good already, we are still accepting new ones. So, please don't hesitate to add your. Best, - Juri On 14/01/19 17:19, Juri Lelli wrote: > Power Management and Scheduling in the Linux Kernel (OSPM-summit) III edition > May 20-22, 2019 > Scuola Superiore Sant'Anna > Pisa, Italy > > --- > > .:: FOCUS > > The III edition of the Power Management and Scheduling in the Linux > Kernel (OSPM) summit aims at fostering discussions on power management > and (real-time) scheduling techniques. Summit will be held in Pisa > (Italy) on May 20-22, 2019. > > Although scheduler techniques for reducing energy consumption while > meeting performance and latency requirements are the prime interest of > the summit, we welcome anybody interested in having discussions on the > broader scope of real-time systems, real-time and non-real-time > scheduling, tooling, debugging and tracing. > > Feel free to have a look at what happened previous years: > > I edition - https://lwn.net/Articles/721573/ > II edition - https://lwn.net/Articles/754923/ > > .:: FORMAT > > The summit is organized to cover three days of discussions and talks. > > The list of topics of interest includes (but it is not limited to): > > * Power management techniques > * Real-time and non real-time scheduling techniques > * Energy consumption and CPU capacity aware scheduling > * Real-time virtualization > * Mobile/Server power management real-world use cases (successes and >failures) > * Power management and scheduling tooling (configuration, integration, >testing, etc.) > * Tracing > * Recap/lightning talks > > Presentations can cover recently developed technologies, ongoing work > and new ideas. Please understand that this workshop is not intended for > presenting sales and marketing pitches. > > .:: ATTENDING > > Attending the OSPM-summit is free of charge, but registration to the > event is mandatory. The event can allow a maximum of 50 people (so, be > sure to register early!). Registrations open on February 22nd, 2019. > > To register fill in the registration form available at > https://goo.gl/forms/33rgOC70ypRrrZV33. > > While it is not strictly required to submit a topic/presentation (see > below), registrations with a topic/presentation proposal will take > precedence. > > .:: SUBMIT A TOPIC/PRESENTATION > > To submit a topic/presentation add its details to this list: > https://docs.google.com/spreadsheets/d/1s5JzAlPoISZFwvV6QajE3aPBGVaixdLb5ftamJ4Mn9U/edit?usp=sharing > > (feel free to get inspired by last year list of accepted topics > https://docs.google.com/spreadsheets/d/1ZPfASW6zVOM3xQvOrcaDEf1c-Pxi1XnFukVYHHwGUq4/edit?usp=sharing) > > Or, if you prefer, simply reply (only to me, please :) to this email > specifying: > > - name/surname > - affiliation > - short bio > - email address > - title > - abstract > - 30min or 50min slot > > Deadline for submitting topics/presentations is 8th of February 2019. > Notifications for accepted topics/presentations will be sent out on 22nd > of February 2019. > > .:: VENUE > > The workshop will take place at ReTiS Lab*, Scuola Superiore Sant'Anna, > Pisa, Italy. Pisa is a small town, walking distance from the city center > to the venue is 20 minutes, walking distance from the airport to the > city center is 30 minutes. More details are available from the summit > web page: http://retis.sssup.it/ospm-summit/#site > > * https://goo.gl/maps/2pPXG2v7Lfp > > .:: ORGANIZERS (in alphabetical order) > > Luca Abeni (SSSA) > Patrick Bellasi (Arm) > Tommaso Cucinotta (SSSA) > Dietmar Eggemann (Arm) > Sudeep Holla (Arm) > Juri Lelli (Red Hat) > Lorenzo Pieralisi (Arm) > Morten Rasmussen (Arm) > Claudio Scordino (Evidence SRL)
Re: [PATCH v3] x86/gart/kcore: Exclude GART aperture from kcore
On Wed, Feb 13, 2019 at 4:28 PM Kairui Song wrote:
>
> On machines where the GART aperture is mapped over physical RAM,
> /proc/kcore contains the GART aperture range and reading it may lead
> to kernel panic.
>
> In 'commit 2a3e83c6f96c ("x86/gart: Exclude GART aperture from vmcore")',
> a workaround is applied for vmcore to let /proc/vmcore return zeroes
> when attempting to read the GART region, as vmcore have the same issue,
> and after 'commit 707d4eefbdb3 ("Revert "[PATCH] Insert GART region
> into resource map"")', userspace tools won't be able to detect GART
> region so have to avoid it from being reading in kernel.
>
> This patch applies a similar workaround for kcore. Let /proc/kcore
> return zeroes for GART aperture.
>
> Both vmcore and kcore maintain a memory mapping list, in the vmcore
> workaround we exclude the GART region by registering a hook for checking
> if PFN is valid before reading, because vmcore's memory mapping could
> be generated by userspace which doesn't know about GART. But for kcore
> it will be simpler to just alter the memory area list, kcore's area list
> is always generated by kernel on init.
>
> Kcore's memory area list is generated very late so can't exclude the
> overlapped area when GART is initialized, instead simply introduce a
> new area enum type KCORE_NORAM, register GART aperture as KCORE_NORAM
> and let kcore return zeros for all KCORE_NORAM area. This fixes the
> problem well with minor code changes.
>
> ---
> Update from V2:
> Instead of repeating the same hook infrastructure for kcore, introduce
> a new kcore area type to avoid reading from, and let kcore always bypass
> this kind of area.
>
> Update from V1:
> Fix a complie error when CONFIG_PROC_KCORE is not set
>
> arch/x86/kernel/aperture_64.c | 14 ++
> fs/proc/kcore.c | 13 +
> include/linux/kcore.h | 1 +
> 3 files changed, 28 insertions(+)
>
> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> index 58176b56354e..5fb04bdd3221 100644
> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/aperture_64.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Using 512M as goal, in case kexec will load kernel_big
> @@ -84,6 +85,17 @@ static void exclude_from_vmcore(u64 aper_base, u32
> aper_order)
> }
> #endif
>
> +#ifdef CONFIG_PROC_KCORE
> +static struct kcore_list kcore_gart;
> +
> +static void __init exclude_from_kcore(u64 aper_base, u32 aper_order) {
> + u32 aper_size = (32 * 1024 * 1024) << aper_order;
> + kclist_add(_gart, __va(aper_base), aper_size, KCORE_NORAM);
> +}
> +#else
> +static inline void __init exclude_from_kcore(u64 aper_base, u32 aper_order)
> { }
> +#endif
> +
> /* This code runs before the PCI subsystem is initialized, so just
> access the northbridge directly. */
>
> @@ -475,6 +487,7 @@ int __init gart_iommu_hole_init(void)
> * and fixed up the northbridge
> */
> exclude_from_vmcore(last_aper_base, last_aper_order);
> + exclude_from_kcore(last_aper_base, last_aper_order);
>
> return 1;
> }
> @@ -521,6 +534,7 @@ int __init gart_iommu_hole_init(void)
> * range through vmcore even though it should be part of the dump.
> */
> exclude_from_vmcore(aper_alloc, aper_order);
> + exclude_from_kcore(aper_alloc, aper_order);
>
> /* Fix up the north bridges */
> for (i = 0; i < amd_nb_bus_dev_ranges[i].dev_limit; i++) {
> diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
> index bbcc185062bb..15e0d74d7c56 100644
> --- a/fs/proc/kcore.c
> +++ b/fs/proc/kcore.c
> @@ -75,6 +75,8 @@ static size_t get_kcore_size(int *nphdr, size_t *phdrs_len,
> size_t *notes_len,
> size = 0;
>
> list_for_each_entry(m, _head, list) {
> + if (m->type == KCORE_NORAM)
> + continue;
> try = kc_vaddr_to_offset((size_t)m->addr + m->size);
> if (try > size)
> size = try;
> @@ -256,6 +258,9 @@ static int kcore_update_ram(void)
> list_for_each_entry_safe(pos, tmp, _head, list) {
> if (pos->type == KCORE_RAM || pos->type == KCORE_VMEMMAP)
> list_move(>list, );
> + /* Move NORAM area to head of the new list */
> + if (pos->type == KCORE_NORAM)
> + list_move(>list, );
> }
> list_splice_tail(, _head);
>
> @@ -356,6 +361,8 @@ read_kcore(struct file *file, char __user *buffer, size_t
> buflen, loff_t *fpos)
>
> phdr = [1];
> list_for_each_entry(m, _head, list) {
> + if (m->type == KCORE_NORAM)
> + continue;
> phdr->p_type = PT_LOAD;
> phdr->p_flags = PF_R | PF_W | PF_X;
>
linux-next: Tree for Feb 25
Hi all, Changes since 20190222: The powerpc tree lost its build failure. The sound tree gained a conflict against the arm-soc tree. The akpm-current tree gained a conflict against the powerpc tree. The akpm tree gained a conflict against the powerpc tree. Non-merge commits (relative to Linus' tree): 9861 9975 files changed, 451895 insertions(+), 234453 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 297 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (c3619a482e15 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging fixes/master (ed3ce4cfc919 adfs: mark expected switch fall-throughs) Merging kspp-gustavo/for-next/kspp (6f6c95f09001 ASN.1: mark expected switch fall-through) Merging kbuild-current/fixes (207a369e3c08 sh: fix build error for invisible CONFIG_BUILTIN_DTB_SOURCE) Merging arc-current/for-curr (7b2e932f633b ARCv2: don't assume core 0x54 has dual issue) Merging arm-current/fixes (fc67e6f120a3 ARM: 8835/1: dma-mapping: Clear DMA ops on teardown) Merging arm64-fixes/for-next/fixes (74698f6971f2 arm64: Relax GIC version check during early boot) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (8f5b27347e88 powerpc/powernv/sriov: Register IOMMU groups for VFs) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (c3619a482e15 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging bpf/master (b4b8bb69c104 bpf, doc: add bpf list as secondary entry to maintainers file) Merging ipsec/master (660899ddf06a xfrm: Fix inbound traffic via XFRM interfaces across network namespaces) Merging netfilter/master (1765f5dcd009 sky2: Increase D3 delay again) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (d04ca383860b mt76x0u: fix suspend/resume) Merging mac80211/master (51d0af222f6f mac80211: allocate tailroom for forwarded mesh packets) Merging rdma-fixes/for-rc (f09ef134a7ca iw_cxgb4: cq/qp mask depends on bar2 pages in a host page) Merging sound-current/for-linus (268836649c07 Merge tag 'asoc-fix-v5.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging sound-asoc-fixes/for-linus (0cb26f410319 Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (f17b5f06cb92 Linux 5.0-rc4) Merging regulator-fixes/for-linus (6a1fe3419310 Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (2d068aef6639 Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (f57a98e1b713 PCI: Work around Synopsys duplicate Device ID (HAPS USB3, NXP i.MX)) Merging driver-core.current/driver-core-linus (d13937116f1e Linux 5.0-rc6) Merging tty.current/tty-linus (d13937116f1e Linux 5.0-rc6) Merging usb.current/usb-linus (d13937116f1e Linux 5.0-rc6) Merging usb-gadget-fixes/fixes (a53469a68eb8 usb: phy: am335x: fix race condition in _probe) Merging usb-serial-fixes/usb-linus (8d7fa3d4ea3f USB: serial: ftdi_sio: add ID for Hjelmslund Electronics USB485) Merging
Re: [PATCH v5] PM / sleep: measure the time of filesystem syncing
Hi Harry, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.0-rc4 next-20190222] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Harry-Pan/PM-sleep-measure-the-time-of-filesystem-syncing/20190225-032342 config: powerpc-sbc8548_defconfig (attached as .config) compiler: powerpc-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=8.2.0 make.cross ARCH=powerpc All errors (new ones prefixed by >>): powerpc-linux-gnu-ld: warning: orphan section `.branch_lt' from `arch/powerpc/kernel/head_fsl_booke.o' being placed in section `.branch_lt' powerpc-linux-gnu-ld: kernel/power/main.o: in function `ksys_sync_helper': main.c:(.text+0x6e0): undefined reference to `__moddi3' >> powerpc-linux-gnu-ld: main.c:(.text+0x6fc): undefined reference to `__divdi3' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH v2] net: dsa: fix a leaked reference by adding missing of_node_put
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./net/dsa/port.c:294:1-7: ERROR: missing of_node_put; acquired a node pointer
with refcount incremented on line 284, but without a corresponding object
release within this function.
./net/dsa/dsa2.c:627:3-9: ERROR: missing of_node_put; acquired a node pointer
with refcount incremented on line 618, but without a corresponding object
release within this function.
./net/dsa/dsa2.c:630:3-9: ERROR: missing of_node_put; acquired a node pointer
with refcount incremented on line 618, but without a corresponding object
release within this function.
./net/dsa/dsa2.c:636:3-9: ERROR: missing of_node_put; acquired a node pointer
with refcount incremented on line 618, but without a corresponding object
release within this function.
./net/dsa/dsa2.c:639:1-7: ERROR: missing of_node_put; acquired a node pointer
with refcount incremented on line 618, but without a corresponding object
release within this function.
Signed-off-by: Wen Yang
Reviewed-by: Vivien Didelot
Reviewed-by: "David S. Miller"
Cc: Andrew Lunn
Cc: Vivien Didelot
Cc: Florian Fainelli
Cc: "David S. Miller"
Cc: Vivien Didelot
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
v2->v1: preserve the reverse christmas tree ordering of variables.
net/dsa/dsa2.c | 16 ++--
net/dsa/port.c | 1 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 8c431e0..c00ee464 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -612,8 +612,8 @@ static int dsa_switch_parse_ports_of(struct dsa_switch *ds,
{
struct device_node *ports, *port;
struct dsa_port *dp;
+ int err = 0;
u32 reg;
- int err;
ports = of_get_child_by_name(dn, "ports");
if (!ports) {
@@ -624,19 +624,23 @@ static int dsa_switch_parse_ports_of(struct dsa_switch
*ds,
for_each_available_child_of_node(ports, port) {
err = of_property_read_u32(port, "reg", );
if (err)
- return err;
+ goto out_put_node;
- if (reg >= ds->num_ports)
- return -EINVAL;
+ if (reg >= ds->num_ports) {
+ err = -EINVAL;
+ goto out_put_node;
+ }
dp = >ports[reg];
err = dsa_port_parse_of(dp, port);
if (err)
- return err;
+ goto out_put_node;
}
- return 0;
+out_put_node:
+ of_node_put(ports);
+ return err;
}
static int dsa_switch_parse_member_of(struct dsa_switch *ds,
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 2d7e01b..a6d9a04 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -291,6 +291,7 @@ static struct phy_device *dsa_port_get_phy_device(struct
dsa_port *dp)
return ERR_PTR(-EPROBE_DEFER);
}
+ of_node_put(phy_dn);
return phydev;
}
--
2.9.5
[PATCH] dt-bindings: regulator: tps65218: rectify units of LS3
LS3 has a selectable current limit.
Change units to microamp in the example.
Signed-off-by: Christian Hohnstaedt
---
Documentation/devicetree/bindings/regulator/tps65218.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt
b/Documentation/devicetree/bindings/regulator/tps65218.txt
index b28e9bd..54aded3 100644
--- a/Documentation/devicetree/bindings/regulator/tps65218.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -77,7 +77,7 @@ tps65218: tps65218@24 {
};
ls3: regulator-ls3 {
- regulator-min-microvolt = <10>;
- regulator-max-microvolt = <100>;
+ regulator-min-microamp = <10>;
+ regulator-max-microamp = <100>;
};
};
--
2.7.4
Re: [PATCH v2 14/26] userfaultfd: wp: handle COW properly for uffd-wp
On Fri, Feb 22, 2019 at 10:35:09AM -0500, Jerome Glisse wrote:
> On Fri, Feb 22, 2019 at 04:46:03PM +0800, Peter Xu wrote:
> > On Thu, Feb 21, 2019 at 01:04:24PM -0500, Jerome Glisse wrote:
> > > On Tue, Feb 12, 2019 at 10:56:20AM +0800, Peter Xu wrote:
> > > > This allows uffd-wp to support write-protected pages for COW.
>
> [...]
>
> > > > diff --git a/mm/mprotect.c b/mm/mprotect.c
> > > > index 9d4433044c21..ae93721f3795 100644
> > > > --- a/mm/mprotect.c
> > > > +++ b/mm/mprotect.c
> > > > @@ -77,14 +77,13 @@ static unsigned long change_pte_range(struct
> > > > vm_area_struct *vma, pmd_t *pmd,
> > > > if (pte_present(oldpte)) {
> > > > pte_t ptent;
> > > > bool preserve_write = prot_numa &&
> > > > pte_write(oldpte);
> > > > + struct page *page;
> > > >
> > > > /*
> > > > * Avoid trapping faults against the zero or KSM
> > > > * pages. See similar comment in
> > > > change_huge_pmd.
> > > > */
> > > > if (prot_numa) {
> > > > - struct page *page;
> > > > -
> > > > page = vm_normal_page(vma, addr,
> > > > oldpte);
> > > > if (!page || PageKsm(page))
> > > > continue;
> > > > @@ -114,6 +113,46 @@ static unsigned long change_pte_range(struct
> > > > vm_area_struct *vma, pmd_t *pmd,
> > > > continue;
> > > > }
> > > >
> > > > + /*
> > > > +* Detect whether we'll need to COW before
> > > > +* resolving an uffd-wp fault. Note that this
> > > > +* includes detection of the zero page (where
> > > > +* page==NULL)
> > > > +*/
> > > > + if (uffd_wp_resolve) {
> > > > + /* If the fault is resolved already,
> > > > skip */
> > > > + if (!pte_uffd_wp(*pte))
> > > > + continue;
> > > > + page = vm_normal_page(vma, addr,
> > > > oldpte);
> > > > + if (!page || page_mapcount(page) > 1) {
> > >
> > > This is wrong, if you allow page to be NULL then you gonna segfault
> > > in wp_page_copy() down below. Are you sure you want to test for
> > > special page ? For anonymous memory this should never happens ie
> > > anon page always are regular page. So if you allow userfaulfd to
> > > write protect only anonymous vma then there is no point in testing
> > > here beside maybe a BUG_ON() just in case ...
> >
> > It's majorly for zero pages where page can be NULL. Would this be
> > clearer:
> >
> > if (is_zero_pfn(pte_pfn(old_pte)) || (page && page_mapcount(page)))
> >
> > ?
> >
> > Now we treat zero pages as normal COW pages so we'll do COW here even
> > for zero pages. I think maybe we can do special handling on all over
> > the places for zero pages (e.g., we don't write protect a PTE if we
> > detected that this is the zero PFN) but I'm uncertain on whether
> > that's what we want, so I chose to start with current solution at
> > least to achieve functionality first.
>
> You can keep the vm_normal_page() in that case but split the if
> between page == NULL and page != NULL with mapcount > 1. As other-
> wise you will segfault below.
Could I ask what's the segfault you mentioned? My understanding is
that below code has taken page==NULL into consideration already, e.g.,
we only do get_page() if page!=NULL, and inside wp_page_copy() it has
similar considerations.
>
>
> >
> > >
> > > > + struct vm_fault vmf = {
> > > > + .vma = vma,
> > > > + .address = addr &
> > > > PAGE_MASK,
> > > > + .page = page,
> > > > + .orig_pte = oldpte,
> > > > + .pmd = pmd,
> > > > + /* pte and ptl not
> > > > needed */
> > > > + };
> > > > + vm_fault_t ret;
> > > > +
> > > > + if (page)
> > > > + get_page(page);
> > > > + arch_leave_lazy_mmu_mode();
> > > > + pte_unmap_unlock(pte, ptl);
> > > > + ret = wp_page_copy();
> > > > + /* PTE is changed, or OOM */
> > > > +
Re: [PATCH 06/15] perf script python: add Python3 support to intel-pt-events.py
On 23/02/19 1:06 AM, Tony Jones wrote:
> Support both Python2 and Python3 in the intel-pt-events.py script
>
> There may be differences in the ordering of output lines due to
> differences in dictionary ordering etc. However the format within lines
> should be unchanged.
>
> Fix space/tab inconsistency as python3 enforces consistency.
It would be better for the white space changes to be a separate patch.
But I am not in favour of using spaces instead of tabs because it is the
opposite of what we tend to do with C.
Arnaldo, can you provide a guideline on this?
>
> The use of 'from __future__' implies the minimum supported Python2 version
> is now v2.6
>
> Signed-off-by: Tony Jones
> Signed-off-by: Seeteena Thoufeek
> Cc: Adrian Hunter
> ---
> tools/perf/scripts/python/intel-pt-events.py | 138 ++-
> 1 file changed, 70 insertions(+), 68 deletions(-)
>
> diff --git a/tools/perf/scripts/python/intel-pt-events.py
> b/tools/perf/scripts/python/intel-pt-events.py
> index b19172d673af..aef54566af61 100644
> --- a/tools/perf/scripts/python/intel-pt-events.py
> +++ b/tools/perf/scripts/python/intel-pt-events.py
> @@ -10,79 +10,81 @@
> # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> # more details.
>
> +from __future__ import print_function
> +
> import os
> import sys
> import struct
>
> sys.path.append(os.environ['PERF_EXEC_PATH'] + \
> - '/scripts/python/Perf-Trace-Util/lib/Perf/Trace')
> +'/scripts/python/Perf-Trace-Util/lib/Perf/Trace')
>
> # These perf imports are not used at present
> #from perf_trace_context import *
> #from Core import *
>
> def trace_begin():
> - print "Intel PT Power Events and PTWRITE"
> +print("Intel PT Power Events and PTWRITE")
>
> def trace_end():
> - print "End"
> +print("End")
>
> def trace_unhandled(event_name, context, event_fields_dict):
> - print ' '.join(['%s=%s'%(k,str(v))for k,v in
> sorted(event_fields_dict.items())])
> +print(' '.join(['%s=%s'%(k,str(v))for k,v in
> sorted(event_fields_dict.items())]))
>
> def print_ptwrite(raw_buf):
> - data = struct.unpack_from(" - flags = data[0]
> - payload = data[1]
> - exact_ip = flags & 1
> - print "IP: %u payload: %#x" % (exact_ip, payload),
> +data = struct.unpack_from(" +flags = data[0]
> +payload = data[1]
> +exact_ip = flags & 1
> +print("IP: %u payload: %#x" % (exact_ip, payload), end='')
>
> def print_cbr(raw_buf):
> - data = struct.unpack_from(" - cbr = data[0]
> - f = (data[4] + 500) / 1000
> - p = ((cbr * 1000 / data[2]) + 5) / 10
> - print "%3u freq: %4u MHz (%3u%%)" % (cbr, f, p),
> +data = struct.unpack_from(" +cbr = data[0]
> +f = (data[4] + 500) / 1000
> +p = ((cbr * 1000 / data[2]) + 5) / 10
> +print("%3u freq: %4u MHz (%3u%%)" % (cbr, f, p), end='')
>
> def print_mwait(raw_buf):
> - data = struct.unpack_from(" - payload = data[1]
> - hints = payload & 0xff
> - extensions = (payload >> 32) & 0x3
> - print "hints: %#x extensions: %#x" % (hints, extensions),
> +data = struct.unpack_from(" +payload = data[1]
> +hints = payload & 0xff
> +extensions = (payload >> 32) & 0x3
> +print("hints: %#x extensions: %#x" % (hints, extensions), end='')
>
> def print_pwre(raw_buf):
> - data = struct.unpack_from(" - payload = data[1]
> - hw = (payload >> 7) & 1
> - cstate = (payload >> 12) & 0xf
> - subcstate = (payload >> 8) & 0xf
> - print "hw: %u cstate: %u sub-cstate: %u" % (hw, cstate, subcstate),
> +data = struct.unpack_from(" +payload = data[1]
> +hw = (payload >> 7) & 1
> +cstate = (payload >> 12) & 0xf
> +subcstate = (payload >> 8) & 0xf
> +print("hw: %u cstate: %u sub-cstate: %u" % (hw, cstate, subcstate),
> end='')
>
> def print_exstop(raw_buf):
> - data = struct.unpack_from(" - flags = data[0]
> - exact_ip = flags & 1
> - print "IP: %u" % (exact_ip),
> +data = struct.unpack_from(" +flags = data[0]
> +exact_ip = flags & 1
> +print("IP: %u" % (exact_ip), end='')
>
> def print_pwrx(raw_buf):
> - data = struct.unpack_from(" - payload = data[1]
> - deepest_cstate = payload & 0xf
> - last_cstate = (payload >> 4) & 0xf
> - wake_reason = (payload >> 8) & 0xf
> - print "deepest cstate: %u last cstate: %u wake reason: %#x" %
> (deepest_cstate, last_cstate, wake_reason),
> +data = struct.unpack_from(" +payload = data[1]
> +deepest_cstate = payload & 0xf
> +last_cstate = (payload >> 4) & 0xf
> +wake_reason = (payload >> 8) & 0xf
> +print("deepest cstate: %u last cstate: %u wake reason: %#x" %
> (deepest_cstate, last_cstate, wake_reason), end='')
>
> def print_common_start(comm, sample, name):
> - ts
Re: [PATCH 2/6] mm/memblock: make full utilization of numa info
Hi Pingfan, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.0-rc4] [cannot apply to next-20190222] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Pingfan-Liu/mm-numa-extract-the-code-of-building-node-fall-back-list/20190225-143613 config: i386-tinyconfig (attached as .config) compiler: gcc-8 (Debian 8.2.0-20) 8.2.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): ld: mm/memblock.o: in function `memblock_build_node_order': >> memblock.c:(.init.text+0x310): undefined reference to `build_node_order' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
RE: [PATCH 0/3] soc: fsl: dpio: enable and configure cache stashing
> Subject: Re: [PATCH 0/3] soc: fsl: dpio: enable and configure cache stashing > > From: Ioana Ciornei > Date: Sat, 23 Feb 2019 08:48:42 + > > > The first two patches enable cache stashing and configure the core > > cluster destination per software portal while the third patch is the > > one configuring the amount of stashing on a queue. > > Should I merge this series in via my networking tree? Even though it would be really good to have this on the networking tree as soon as possible, I am afraid that patch 2/3 is not going to apply cleanly because it touches the same areas of code that some other patches on Leo's tree are. Thanks, Ioana C
Re: [PATCH 2/2] staging: erofs: switch to ->iterate_shared()
On 2019/2/25 9:36, Chao Yu wrote:
> On 2019/2/21 10:34, Gao Xiang wrote:
>> After commit 6192269444eb ("introduce a parallel variant of ->iterate()"),
>> readdir can be done without taking exclusive inode lock of course.
>>
>> Signed-off-by: Gao Xiang
>
> Reviewed-by: Chao Yu
Thanks for review :)
>
> Thanks,
>
[PATCH v4 0/5] soc: qcom: Add SoC info driver
This patchset adds SoC info driver which can provide information such as Chip ID, Chip family and serial number about Qualcomm SoCs to user space via sysfs. Furthermore, it allows userspace to get information about custom attributes and various image version information via debugfs. The patchset cleanly applies on top of v5.0-rc6. Changes since v1: - Align ifdefs to left, remove unnecessary debugfs dir creation check and fix function signatures in patch 3 - Fix comment for teh case when serial number is not available in patch 1 Changes since v2: - Reorder patches [patch five -> patch two] Changes since v3: - Add reviewed-bys from Greg - Fix build warning when debugfs is disabled - Remove extra checks for dir creations in patch 5 Vaishali Thakkar (5): base: soc: Add serial_number attribute to soc base: soc: Export soc_device_register/unregister APIs soc: qcom: Add socinfo driver soc: qcom: socinfo: Expose custom attributes soc: qcom: socinfo: Expose image information Documentation/ABI/testing/sysfs-devices-soc | 7 + drivers/base/soc.c | 9 + drivers/soc/qcom/Kconfig| 8 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/smem.c | 8 + drivers/soc/qcom/socinfo.c | 573 include/linux/sys_soc.h | 1 + 7 files changed, 607 insertions(+) create mode 100644 drivers/soc/qcom/socinfo.c -- 2.17.1
[PATCH v4 2/5] base: soc: Export soc_device_register/unregister APIs
From: Vinod Koul
Qcom Socinfo driver can be built as a module, so
export these two APIs.
Signed-off-by: Vinod Koul
Signed-off-by: Vaishali Thakkar
Reviewed-by: Greg Kroah-Hartman
---
Changes since v3:
- Add Greg's reviewed-by
Changes since v2:
- Reorder patches [patch 5->patch 2]
Changes since v1:
- None
---
drivers/base/soc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index b0933b9fe67f..7c0c5ca5953d 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -164,6 +164,7 @@ struct soc_device *soc_device_register(struct
soc_device_attribute *soc_dev_attr
out1:
return ERR_PTR(ret);
}
+EXPORT_SYMBOL_GPL(soc_device_register);
/* Ensure soc_dev->attr is freed prior to calling soc_device_unregister. */
void soc_device_unregister(struct soc_device *soc_dev)
@@ -173,6 +174,7 @@ void soc_device_unregister(struct soc_device *soc_dev)
device_unregister(_dev->dev);
early_soc_dev_attr = NULL;
}
+EXPORT_SYMBOL_GPL(soc_device_unregister);
static int __init soc_bus_register(void)
{
--
2.17.1
[PATCH v2 1/2] arm64: dts: mt8173: correct cpu type of cpu2 and cpu3 to cortex-a72
The cpu type of cpu2 and cpu3 should be cortex-a72, not cortex-a57.
Signed-off-by: Seiya Wang
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 44374c506a1c..99675c51577a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -178,12 +178,12 @@
cpu2: cpu@100 {
device_type = "cpu";
- compatible = "arm,cortex-a57";
+ compatible = "arm,cortex-a72";
reg = <0x100>;
enable-method = "psci";
cpu-idle-states = <_SLEEP_0>;
#cooling-cells = <2>;
- clocks = < CLK_INFRA_CA57SEL>,
+ clocks = < CLK_INFRA_CA72SEL>,
< CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
operating-points-v2 = <_opp>;
@@ -191,12 +191,12 @@
cpu3: cpu@101 {
device_type = "cpu";
- compatible = "arm,cortex-a57";
+ compatible = "arm,cortex-a72";
reg = <0x101>;
enable-method = "psci";
cpu-idle-states = <_SLEEP_0>;
#cooling-cells = <2>;
- clocks = < CLK_INFRA_CA57SEL>,
+ clocks = < CLK_INFRA_CA72SEL>,
< CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
operating-points-v2 = <_opp>;
--
2.14.1
[PATCH v4 5/5] soc: qcom: socinfo: Expose image information
The socinfo driver provides information about version of the various
images loaded in the system. Expose this to user space for debugging
purpose.
Signed-off-by: Vaishali Thakkar
---
Changes since v3:
- Remove extra debugfs directory creation checks
Changes since v2:
- None
Changes since v1:
- None
---
drivers/soc/qcom/socinfo.c | 178 +
1 file changed, 178 insertions(+)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index ccadeba69a81..5d77265054a3 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -31,6 +31,25 @@
#define SMEM_HW_SW_BUILD_ID137
#ifdef CONFIG_DEBUG_FS
+#define SMEM_IMAGE_VERSION_BLOCKS_COUNT32
+#define SMEM_IMAGE_VERSION_SIZE4096
+#define SMEM_IMAGE_VERSION_NAME_SIZE 75
+#define SMEM_IMAGE_VERSION_VARIANT_SIZE20
+#define SMEM_IMAGE_VERSION_OEM_SIZE32
+
+/*
+ * SMEM Image table indices
+ */
+#define SMEM_IMAGE_TABLE_BOOT_INDEX 0
+#define SMEM_IMAGE_TABLE_TZ_INDEX 1
+#define SMEM_IMAGE_TABLE_RPM_INDEX 3
+#define SMEM_IMAGE_TABLE_APPS_INDEX 10
+#define SMEM_IMAGE_TABLE_MPSS_INDEX 11
+#define SMEM_IMAGE_TABLE_ADSP_INDEX 12
+#define SMEM_IMAGE_TABLE_CNSS_INDEX 13
+#define SMEM_IMAGE_TABLE_VIDEO_INDEX14
+#define SMEM_IMAGE_VERSION_TABLE 469
+
/* pmic model info */
static const char *const pmic_model[] = {
[0] = "Unknown PMIC model",
@@ -90,11 +109,21 @@ struct socinfo {
__le32 raw_device_num;
};
+#ifdef CONFIG_DEBUG_FS
+struct smem_image_version {
+ char name[SMEM_IMAGE_VERSION_NAME_SIZE];
+ char variant[SMEM_IMAGE_VERSION_VARIANT_SIZE];
+ char pad;
+ char oem[SMEM_IMAGE_VERSION_OEM_SIZE];
+};
+#endif /* CONFIG_DEBUG_FS */
+
struct qcom_socinfo {
struct soc_device *soc_dev;
struct soc_device_attribute attr;
#ifdef CONFIG_DEBUG_FS
struct dentry *dbg_root;
+ struct dentry *boot, *tz, *rpm, *apps, *mpss, *adsp, *cnss, *video;
#endif /* CONFIG_DEBUG_FS */
struct socinfo *socinfo;
};
@@ -298,8 +327,97 @@ QCOM_OPEN(pmic_model, qcom_show_pmic_model);
QCOM_OPEN(platform_subtype, qcom_show_platform_subtype);
QCOM_OPEN(pmic_die_revision, qcom_show_pmic_die_revision);
+#define IMAGE_SHOW_NAME(attr)\
+static int show_ ##attr## _name(struct seq_file *seq, void *p) \
+{\
+ struct smem_image_version *image_version = seq->private; \
+ seq_puts(seq, image_version->name); \
+ seq_puts(seq, "\n"); \
+ return 0; \
+}\
+static int open_ ##attr## _name(struct inode *inode, struct file *file)
\
+{\
+ return single_open(file, show_ ##attr## _name, inode->i_private); \
+}\
+ \
+static const struct file_operations qcom_ ##attr## _name_ops = { \
+ .open = open_ ##attr## _name, \
+ .read = seq_read, \
+ .llseek = seq_lseek, \
+ .release = single_release,\
+}\
+
+#define DEBUGFS_IMAGE_NAME(fname, attr, index) \
+debugfs_create_file(__stringify(fname), 0400, qcom_socinfo->attr,\
+ _image_version[index], _ ##attr## _name_ops)
+
+#define IMAGE_SHOW_VARIANT(attr)\
+static int show_ ##attr## _variant(struct seq_file *seq, void *p) \
+{ \
+ struct smem_image_version *image_version = seq->private; \
+ seq_puts(seq, image_version->variant); \
+ seq_puts(seq, "\n"); \
+ return 0;\
+} \
+static int open_ ##attr## _variant(struct inode *inode, struct file *file) \
+{\
+ return single_open(file, show_ ##attr## _variant, inode->i_private); \
+} \
+
[PATCH v2 2/2] clk: mediatek: correct cpu clock name for MT8173 SoC
Correct cpu clock name from ca57 to ca72 since MT8173 does use cortex-a72.
Signed-off-by: Seiya Wang
Reviewed-by: Matthias Brugger
Acked-by: Stephen Boyd
---
drivers/clk/mediatek/clk-mt8173.c | 4 ++--
include/dt-bindings/clock/mt8173-clk.h | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
index 96c292c3e440..deedeb3ea33b 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -533,7 +533,7 @@ static const char * const ca53_parents[] __initconst = {
"univpll"
};
-static const char * const ca57_parents[] __initconst = {
+static const char * const ca72_parents[] __initconst = {
"clk26m",
"armca15pll",
"mainpll",
@@ -542,7 +542,7 @@ static const char * const ca57_parents[] __initconst = {
static const struct mtk_composite cpu_muxes[] __initconst = {
MUX(CLK_INFRA_CA53SEL, "infra_ca53_sel", ca53_parents, 0x, 0, 2),
- MUX(CLK_INFRA_CA57SEL, "infra_ca57_sel", ca57_parents, 0x, 2, 2),
+ MUX(CLK_INFRA_CA72SEL, "infra_ca72_sel", ca72_parents, 0x, 2, 2),
};
static const struct mtk_composite top_muxes[] __initconst = {
diff --git a/include/dt-bindings/clock/mt8173-clk.h
b/include/dt-bindings/clock/mt8173-clk.h
index 8aea623dd518..76e4e5b65353 100644
--- a/include/dt-bindings/clock/mt8173-clk.h
+++ b/include/dt-bindings/clock/mt8173-clk.h
@@ -194,7 +194,8 @@
#define CLK_INFRA_PMICWRAP 11
#define CLK_INFRA_CLK_13M 12
#define CLK_INFRA_CA53SEL 13
-#define CLK_INFRA_CA57SEL 14
+#define CLK_INFRA_CA57SEL 14 /* Deprecated. Don't use it. */
+#define CLK_INFRA_CA72SEL 14
#define CLK_INFRA_NR_CLK15
/* PERI_SYS */
--
2.14.1
[PATCH v4 3/5] soc: qcom: Add socinfo driver
From: Imran Khan
The Qualcomm socinfo driver exposes information about the SoC, its
version and its serial number to user space.
Signed-off-by: Imran Khan
[Bjorn: Extract code to platform_driver, split patch in multiple]
Signed-off-by: Bjorn Andersson
[Vaishali: Simplify declarations, introduce qcom_socinfo struc, Fix
memory leak, Remove extra code and Misc code refactoring]
Signed-off-by: Vaishali Thakkar
---
Changes since v3:
- None
Changes since v2:
- Fix typo in the work log under signed off by s
Changes since v1:
- None
---
drivers/soc/qcom/Kconfig | 8 ++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/smem.c| 8 ++
drivers/soc/qcom/socinfo.c | 197 +
4 files changed, 214 insertions(+)
create mode 100644 drivers/soc/qcom/socinfo.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index fcbf8a2e4080..1e31eda07934 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -144,6 +144,14 @@ config QCOM_SMSM
Say yes here to support the Qualcomm Shared Memory State Machine.
The state machine is represented by bits in shared memory.
+config QCOM_SOCINFO
+ tristate "Qualcomm socinfo driver"
+ depends on QCOM_SMEM
+ select SOC_BUS
+ help
+Say yes here to support the Qualcomm socinfo driver, providing
+information about the SoC to user space.
+
config QCOM_WCNSS_CTRL
tristate "Qualcomm WCNSS control driver"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index f25b54cd6cf8..c817da4f4140 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -14,6 +14,7 @@ qcom_rpmh-y += rpmh-rsc.o
qcom_rpmh-y+= rpmh.o
obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
obj-$(CONFIG_QCOM_SMEM) += smem.o
+obj-$(CONFIG_QCOM_SOCINFO) += socinfo.o
obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
obj-$(CONFIG_QCOM_SMP2P) += smp2p.o
obj-$(CONFIG_QCOM_SMSM)+= smsm.o
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index f80d040601fd..efe0b053ef82 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -276,6 +276,7 @@ struct qcom_smem {
struct smem_partition_header *partitions[SMEM_HOST_COUNT];
size_t cacheline[SMEM_HOST_COUNT];
u32 item_count;
+ struct platform_device *socinfo;
unsigned num_regions;
struct smem_region regions[];
@@ -971,11 +972,18 @@ static int qcom_smem_probe(struct platform_device *pdev)
__smem = smem;
+ smem->socinfo = platform_device_register_data(>dev,
"qcom-socinfo",
+ PLATFORM_DEVID_NONE, NULL,
+ 0);
+ if (IS_ERR(smem->socinfo))
+ dev_err(>dev, "failed to register socinfo device\n");
+
return 0;
}
static int qcom_smem_remove(struct platform_device *pdev)
{
+
hwspin_lock_free(__smem->hwlock);
__smem = NULL;
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
new file mode 100644
index ..02078049fac7
--- /dev/null
+++ b/drivers/soc/qcom/socinfo.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2009-2017, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2017-2019, Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * SoC version type with major number in the upper 16 bits and minor
+ * number in the lower 16 bits.
+ */
+#define SOCINFO_MAJOR(ver) (((ver) >> 16) & 0x)
+#define SOCINFO_MINOR(ver) ((ver) & 0x)
+
+#define SMEM_SOCINFO_BUILD_ID_LENGTH 32
+
+/*
+ * SMEM item ids, used to acquire handles to respective
+ * SMEM region.
+ */
+#define SMEM_HW_SW_BUILD_ID137
+
+/* Socinfo SMEM item structure */
+struct socinfo {
+ __le32 fmt;
+ __le32 id;
+ __le32 ver;
+ char build_id[SMEM_SOCINFO_BUILD_ID_LENGTH];
+ /* Version 2 */
+ __le32 raw_id;
+ __le32 raw_ver;
+ /* Version 3 */
+ __le32 hw_plat;
+ /* Version 4 */
+ __le32 plat_ver;
+ /* Version 5 */
+ __le32 accessory_chip;
+ /* Version 6 */
+ __le32 hw_plat_subtype;
+ /* Version 7 */
+ __le32 pmic_model;
+ __le32 pmic_die_rev;
+ /* Version 8 */
+ __le32 pmic_model_1;
+ __le32 pmic_die_rev_1;
+ __le32 pmic_model_2;
+ __le32 pmic_die_rev_2;
+ /* Version 9 */
+ __le32 foundry_id;
+ /* Version 10 */
+ __le32 serial_num;
+ /* Version 11 */
+ __le32 num_pmics;
+ __le32 pmic_array_offset;
+ /* Version 12 */
+ __le32 chip_family;
+ __le32 raw_device_family;
+ __le32 raw_device_num;
+};
+
+struct qcom_socinfo {
+ struct
[PATCH v4 1/5] base: soc: Add serial_number attribute to soc
From: Bjorn Andersson
Add new attribute named "serial_number" as a standard interface for
user space to acquire the serial number of the device.
For ST-Ericsson SoCs this is exposed by the cryptically named "soc_id"
attribute, but this provides a human readable standardized name for this
property.
Signed-off-by: Bjorn Andersson
Signed-off-by: Vaishali Thakkar
Reviewed-by: Greg Kroah-Hartman
---
Changes since v3:
- Add Greg's Reviewed-by
Changes since v2:
- None
Changes since v1:
- Make comment more clear for the case when serial
number is not available
---
Documentation/ABI/testing/sysfs-devices-soc | 7 +++
drivers/base/soc.c | 7 +++
include/linux/sys_soc.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-devices-soc
b/Documentation/ABI/testing/sysfs-devices-soc
index 6d9cc253f2b2..ba3a3fac0ee1 100644
--- a/Documentation/ABI/testing/sysfs-devices-soc
+++ b/Documentation/ABI/testing/sysfs-devices-soc
@@ -26,6 +26,13 @@ Description:
Read-only attribute common to all SoCs. Contains SoC family name
(e.g. DB8500).
+What: /sys/devices/socX/serial_number
+Date: January 2019
+contact: Bjorn Andersson
+Description:
+ Read-only attribute supported by most SoCs. Contains the SoC's
+ serial number, if available.
+
What: /sys/devices/socX/soc_id
Date: January 2012
contact: Lee Jones
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 10b280f30217..b0933b9fe67f 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -33,6 +33,7 @@ static struct bus_type soc_bus_type = {
static DEVICE_ATTR(machine, S_IRUGO, soc_info_get, NULL);
static DEVICE_ATTR(family, S_IRUGO, soc_info_get, NULL);
+static DEVICE_ATTR(serial_number, S_IRUGO, soc_info_get, NULL);
static DEVICE_ATTR(soc_id, S_IRUGO, soc_info_get, NULL);
static DEVICE_ATTR(revision, S_IRUGO, soc_info_get, NULL);
@@ -57,6 +58,9 @@ static umode_t soc_attribute_mode(struct kobject *kobj,
if ((attr == _attr_revision.attr)
&& (soc_dev->attr->revision != NULL))
return attr->mode;
+ if ((attr == _attr_serial_number.attr)
+ && (soc_dev->attr->serial_number != NULL))
+ return attr->mode;
if ((attr == _attr_soc_id.attr)
&& (soc_dev->attr->soc_id != NULL))
return attr->mode;
@@ -77,6 +81,8 @@ static ssize_t soc_info_get(struct device *dev,
return sprintf(buf, "%s\n", soc_dev->attr->family);
if (attr == _attr_revision)
return sprintf(buf, "%s\n", soc_dev->attr->revision);
+ if (attr == _attr_serial_number)
+ return sprintf(buf, "%s\n", soc_dev->attr->serial_number);
if (attr == _attr_soc_id)
return sprintf(buf, "%s\n", soc_dev->attr->soc_id);
@@ -87,6 +93,7 @@ static ssize_t soc_info_get(struct device *dev,
static struct attribute *soc_attr[] = {
_attr_machine.attr,
_attr_family.attr,
+ _attr_serial_number.attr,
_attr_soc_id.attr,
_attr_revision.attr,
NULL,
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index bed223b70217..2a13bc033bd6 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -12,6 +12,7 @@ struct soc_device_attribute {
const char *machine;
const char *family;
const char *revision;
+ const char *serial_number;
const char *soc_id;
const void *data;
};
--
2.17.1
[PATCH v4 4/5] soc: qcom: socinfo: Expose custom attributes
The Qualcomm socinfo provides a number of additional attributes,
add these to the socinfo driver and expose them via debugfs
functionality.
Signed-off-by: Vaishali Thakkar
---
Changes since v3:
- Fix compilation error in function signatures when
debugfs is disabled
Changes since v2:
- None
Changes since v1:
- Remove unnecessary debugfs dir creation check
- Align ifdefs to left
- Fix function signatures for debugfs init/exit
---
drivers/soc/qcom/socinfo.c | 198 +
1 file changed, 198 insertions(+)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index 02078049fac7..ccadeba69a81 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -4,6 +4,7 @@
* Copyright (c) 2017-2019, Linaro Ltd.
*/
+#include
#include
#include
#include
@@ -29,6 +30,28 @@
*/
#define SMEM_HW_SW_BUILD_ID137
+#ifdef CONFIG_DEBUG_FS
+/* pmic model info */
+static const char *const pmic_model[] = {
+ [0] = "Unknown PMIC model",
+ [9] = "PM8994",
+ [11] = "PM8916",
+ [13] = "PM8058",
+ [14] = "PM8028",
+ [15] = "PM8901",
+ [16] = "PM8027",
+ [17] = "ISL9519",
+ [18] = "PM8921",
+ [19] = "PM8018",
+ [20] = "PM8015",
+ [21] = "PM8014",
+ [22] = "PM8821",
+ [23] = "PM8038",
+ [24] = "PM8922",
+ [25] = "PM8917",
+};
+#endif /* CONFIG_DEBUG_FS */
+
/* Socinfo SMEM item structure */
struct socinfo {
__le32 fmt;
@@ -70,6 +93,10 @@ struct socinfo {
struct qcom_socinfo {
struct soc_device *soc_dev;
struct soc_device_attribute attr;
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *dbg_root;
+#endif /* CONFIG_DEBUG_FS */
+ struct socinfo *socinfo;
};
struct soc_of_id {
@@ -133,6 +160,171 @@ static const char *socinfo_machine(struct device *dev,
unsigned int id)
return NULL;
}
+#ifdef CONFIG_DEBUG_FS
+
+#define UINT_SHOW(name, attr) \
+static int qcom_show_##name(struct seq_file *seq, void *p) \
+{ \
+ struct socinfo *socinfo = seq->private; \
+ seq_printf(seq, "%u\n", le32_to_cpu(socinfo->attr));\
+ return 0; \
+} \
+static int qcom_open_##name(struct inode *inode, struct file *file)\
+{ \
+ return single_open(file, qcom_show_##name, inode->i_private); \
+} \
+ \
+static const struct file_operations qcom_ ##name## _ops = {\
+ .open = qcom_open_##name, \
+ .read = seq_read, \
+ .llseek = seq_lseek,\
+ .release = single_release, \
+}
+
+#define DEBUGFS_UINT_ADD(name) \
+ debugfs_create_file(__stringify(name), 0400,\
+ qcom_socinfo->dbg_root, \
+ qcom_socinfo->socinfo, _ ##name## _ops)
+
+#define HEX_SHOW(name, attr) \
+static int qcom_show_##name(struct seq_file *seq, void *p) \
+{ \
+ struct socinfo *socinfo = seq->private; \
+ seq_printf(seq, "0x%x\n", le32_to_cpu(socinfo->attr)); \
+ return 0; \
+} \
+static int qcom_open_##name(struct inode *inode, struct file *file)\
+{ \
+ return single_open(file, qcom_show_##name, inode->i_private); \
+} \
+ \
+static const struct file_operations qcom_ ##name## _ops = {\
+ .open = qcom_open_##name, \
+ .read = seq_read, \
+ .llseek = seq_lseek,\
+ .release = single_release, \
+}
+
+#define DEBUGFS_HEX_ADD(name) \
+ debugfs_create_file(__stringify(name), 0400,\
+
Re: [PATCH v2 10/26] userfaultfd: wp: add UFFDIO_COPY_MODE_WP
On Fri, Feb 22, 2019 at 10:15:47AM -0500, Jerome Glisse wrote:
> On Fri, Feb 22, 2019 at 03:11:06PM +0800, Peter Xu wrote:
> > On Thu, Feb 21, 2019 at 12:29:19PM -0500, Jerome Glisse wrote:
> > > On Tue, Feb 12, 2019 at 10:56:16AM +0800, Peter Xu wrote:
> > > > From: Andrea Arcangeli
> > > >
> > > > This allows UFFDIO_COPY to map pages wrprotected.
> > > >
> > > > Signed-off-by: Andrea Arcangeli
> > > > Signed-off-by: Peter Xu
> > >
> > > Minor nitpick down below, but in any case:
> > >
> > > Reviewed-by: Jérôme Glisse
> > >
> > > > ---
> > > > fs/userfaultfd.c | 5 +++--
> > > > include/linux/userfaultfd_k.h| 2 +-
> > > > include/uapi/linux/userfaultfd.h | 11 +-
> > > > mm/userfaultfd.c | 36 ++--
> > > > 4 files changed, 35 insertions(+), 19 deletions(-)
> > > >
> > >
> > > [...]
> > >
> > > > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> > > > index d59b5a73dfb3..73a208c5c1e7 100644
> > > > --- a/mm/userfaultfd.c
> > > > +++ b/mm/userfaultfd.c
> > > > @@ -25,7 +25,8 @@ static int mcopy_atomic_pte(struct mm_struct *dst_mm,
> > > > struct vm_area_struct *dst_vma,
> > > > unsigned long dst_addr,
> > > > unsigned long src_addr,
> > > > - struct page **pagep)
> > > > + struct page **pagep,
> > > > + bool wp_copy)
> > > > {
> > > > struct mem_cgroup *memcg;
> > > > pte_t _dst_pte, *dst_pte;
> > > > @@ -71,9 +72,9 @@ static int mcopy_atomic_pte(struct mm_struct *dst_mm,
> > > > if (mem_cgroup_try_charge(page, dst_mm, GFP_KERNEL, ,
> > > > false))
> > > > goto out_release;
> > > >
> > > > - _dst_pte = mk_pte(page, dst_vma->vm_page_prot);
> > > > - if (dst_vma->vm_flags & VM_WRITE)
> > > > - _dst_pte = pte_mkwrite(pte_mkdirty(_dst_pte));
> > > > + _dst_pte = pte_mkdirty(mk_pte(page, dst_vma->vm_page_prot));
> > > > + if (dst_vma->vm_flags & VM_WRITE && !wp_copy)
> > > > + _dst_pte = pte_mkwrite(_dst_pte);
> > >
> > > I like parenthesis around around and :) ie:
> > > (dst_vma->vm_flags & VM_WRITE) && !wp_copy
> > >
> > > I feel it is easier to read.
> >
> > Yeah another one. Though this line will be changed in follow up
> > patches, will fix anyways.
> >
> > >
> > > [...]
> > >
> > > > @@ -416,11 +418,13 @@ static __always_inline ssize_t
> > > > mfill_atomic_pte(struct mm_struct *dst_mm,
> > > > if (!(dst_vma->vm_flags & VM_SHARED)) {
> > > > if (!zeropage)
> > > > err = mcopy_atomic_pte(dst_mm, dst_pmd, dst_vma,
> > > > - dst_addr, src_addr,
> > > > page);
> > > > + dst_addr, src_addr, page,
> > > > + wp_copy);
> > > > else
> > > > err = mfill_zeropage_pte(dst_mm, dst_pmd,
> > > > dst_vma, dst_addr);
> > > > } else {
> > > > + VM_WARN_ON(wp_copy); /* WP only available for anon */
> > >
> > > Don't you want to return with error here ?
> >
> > Makes sense to me. Does this looks good to you to be squashed into
> > current patch?
> >
> > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> > index 73a208c5c1e7..f3ea09f412d4 100644
> > --- a/mm/userfaultfd.c
> > +++ b/mm/userfaultfd.c
> > @@ -73,7 +73,7 @@ static int mcopy_atomic_pte(struct mm_struct *dst_mm,
> > goto out_release;
> >
> > _dst_pte = pte_mkdirty(mk_pte(page, dst_vma->vm_page_prot));
> > - if (dst_vma->vm_flags & VM_WRITE && !wp_copy)
> > + if ((dst_vma->vm_flags & VM_WRITE) && !wp_copy)
> > _dst_pte = pte_mkwrite(_dst_pte);
> >
> > dst_pte = pte_offset_map_lock(dst_mm, dst_pmd, dst_addr, );
> > @@ -424,7 +424,10 @@ static __always_inline ssize_t mfill_atomic_pte(struct
> > mm_struct *dst_mm,
> > err = mfill_zeropage_pte(dst_mm, dst_pmd,
> > dst_vma, dst_addr);
> > } else {
> > - VM_WARN_ON(wp_copy); /* WP only available for anon */
> > + if (unlikely(wp_copy))
> > + /* TODO: WP currently only available for anon */
> > + return -EINVAL;
> > +
> > if (!zeropage)
> > err = shmem_mcopy_atomic_pte(dst_mm, dst_pmd,
> > dst_vma, dst_addr,
>
> I would keep a the VM_WARN_ON or maybe a ONCE variant so that we at
> least have a chance to be inform if for some reasons that code path
> is taken. With that my r-b stands.
Yeah *ONCE() is good to me too (both can avoid DOS attack from
userspace) and I don't have
[PATCH v2 0/2] regulator: tps65218: support LS2
Add support for the LS2 regulator in the tps65218 device Christian Hohnstaedt (2): dt-bindings: regulator: Add LS2 load switch documentation regulator: tps65218: Add support for LS2 .../devicetree/bindings/regulator/tps65218.txt | 4 ++-- drivers/regulator/tps65218-regulator.c | 18 +- include/linux/mfd/tps65218.h | 3 ++- 3 files changed, 17 insertions(+), 8 deletions(-) -- 2.7.4
[PATCH v2 2/2] regulator: tps65218: add support for LS2
Re-use the "tps65218_pmic_*_current_limit()" functions of LS3
and calculate the different required bit-shift by counting the
trailing 0s in "struct regulator_desc.csel_mask"
Signed-off-by: Christian Hohnstaedt
---
drivers/regulator/tps65218-regulator.c | 18 +-
include/linux/mfd/tps65218.h | 3 ++-
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/tps65218-regulator.c
b/drivers/regulator/tps65218-regulator.c
index 5dd559e..95708d3 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -205,7 +205,8 @@ static int tps65218_pmic_set_input_current_lim(struct
regulator_dev *dev,
return -EINVAL;
return tps65218_set_bits(tps, dev->desc->csel_reg, dev->desc->csel_mask,
-index << 2, TPS65218_PROTECT_L1);
+index << __builtin_ctz(dev->desc->csel_mask),
+TPS65218_PROTECT_L1);
}
static int tps65218_pmic_set_current_limit(struct regulator_dev *dev,
@@ -224,7 +225,8 @@ static int tps65218_pmic_set_current_limit(struct
regulator_dev *dev,
return -EINVAL;
return tps65218_set_bits(tps, dev->desc->csel_reg, dev->desc->csel_mask,
-index << 2, TPS65218_PROTECT_L1);
+index << __builtin_ctz(dev->desc->csel_mask),
+TPS65218_PROTECT_L1);
}
static int tps65218_pmic_get_current_limit(struct regulator_dev *dev)
@@ -237,12 +239,13 @@ static int tps65218_pmic_get_current_limit(struct
regulator_dev *dev)
if (retval < 0)
return retval;
- index = (index & dev->desc->csel_mask) >> 2;
+ index = (index & dev->desc->csel_mask) >>
+__builtin_ctz(dev->desc->csel_mask);
return ls3_currents[index];
}
-static struct regulator_ops tps65218_ls3_ops = {
+static struct regulator_ops tps65218_ls23_ops = {
.is_enabled = regulator_is_enabled_regmap,
.enable = tps65218_pmic_enable,
.disable= tps65218_pmic_disable,
@@ -304,8 +307,13 @@ static const struct regulator_desc regulators[] = {
TPS65218_ENABLE2_LDO1_EN, 0, 0, ldo1_dcdc3_ranges,
2, 0, 0, TPS65218_REG_SEQ6,
TPS65218_SEQ6_LDO1_SEQ_MASK),
+ TPS65218_REGULATOR("LS2", "regulator-ls2", TPS65218_LS_2,
+ REGULATOR_CURRENT, tps65218_ls23_ops, 0, 0, 0,
+ TPS65218_REG_ENABLE2, TPS65218_ENABLE2_LS2_EN,
+ TPS65218_REG_CONFIG2, TPS65218_CONFIG2_LS2ILIM_MASK,
+ NULL, 0, 0, 0, 0, 0),
TPS65218_REGULATOR("LS3", "regulator-ls3", TPS65218_LS_3,
- REGULATOR_CURRENT, tps65218_ls3_ops, 0, 0, 0,
+ REGULATOR_CURRENT, tps65218_ls23_ops, 0, 0, 0,
TPS65218_REG_ENABLE2, TPS65218_ENABLE2_LS3_EN,
TPS65218_REG_CONFIG2, TPS65218_CONFIG2_LS3ILIM_MASK,
NULL, 0, 0, 0, 0, 0),
diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
index 3cbe103..b0470c3 100644
--- a/include/linux/mfd/tps65218.h
+++ b/include/linux/mfd/tps65218.h
@@ -212,6 +212,7 @@ enum tps65218_regulator_id {
/* LDOs */
TPS65218_LDO_1,
/* LS's */
+ TPS65218_LS_2,
TPS65218_LS_3,
};
@@ -222,7 +223,7 @@ enum tps65218_regulator_id {
/* Number of LDO voltage regulators available */
#define TPS65218_NUM_LDO 1
/* Number of total LS current regulators available */
-#define TPS65218_NUM_LS1
+#define TPS65218_NUM_LS2
/* Number of total regulators available */
#define TPS65218_NUM_REGULATOR (TPS65218_NUM_DCDC + TPS65218_NUM_LDO \
+ TPS65218_NUM_LS)
--
2.7.4
Re: linux-next: manual merge of the akpm-current tree with the powerpc tree
Hi all, On Mon, 25 Feb 2019 17:42:48 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the akpm-current tree got a conflict in: This was actually the akpm tree. -- Cheers, Stephen Rothwell pgpPothP9uC2A.pgp Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with the powerpc tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/kernel/irq.c
between commit:
c8e409a33cf8 ("powerpc/irq: use memblock functions returning virtual address")
and other patches in the powerpc tree
from the powerpc tree and patch:
"powerpc: use memblock functions returning virtual address"
from the akpm-current tree.
This file looks the same after applying either of those patches, so I
just used the powerpc version of the file due to the other changes.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
The akpm patch now looks like this:
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c
b/arch/powerpc/kernel/dt_cpu_ftrs.c
index e49bd5efcfe6..28c076c771de 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -810,7 +810,6 @@ static int __init process_cpufeatures_node(unsigned long
node,
int len;
f = _cpu_features[i];
- memset(f, 0, sizeof(struct dt_cpu_feature));
f->node = node;
@@ -1005,7 +1004,7 @@ static int __init dt_cpu_ftrs_scan_callback(unsigned long
node, const char
/* Count and allocate space for cpu features */
of_scan_flat_dt_subnodes(node, count_cpufeatures_subnodes,
_dt_cpu_features);
- dt_cpu_features = __va(memblock_phys_alloc(sizeof(struct
dt_cpu_feature) * nr_dt_cpu_features, PAGE_SIZE));
+ dt_cpu_features = memblock_alloc(sizeof(struct dt_cpu_feature) *
nr_dt_cpu_features, PAGE_SIZE);
cpufeatures_setup_start(isa);
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 8c890c6557ed..e7382abee868 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -196,7 +196,11 @@ void __init allocate_paca_ptrs(void)
paca_nr_cpu_ids = nr_cpu_ids;
paca_ptrs_size = sizeof(struct paca_struct *) * nr_cpu_ids;
- paca_ptrs = __va(memblock_phys_alloc(paca_ptrs_size, SMP_CACHE_BYTES));
+ paca_ptrs = memblock_alloc_raw(paca_ptrs_size, SMP_CACHE_BYTES);
+ if (!paca_ptrs)
+ panic("Failed to allocate %d bytes for paca pointers\n",
+ paca_ptrs_size);
+
memset(paca_ptrs, 0x88, paca_ptrs_size);
}
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index e97aaf201d67..c0ed4fa0b9d3 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -127,7 +127,10 @@ static void __init move_device_tree(void)
if ((memory_limit && (start + size) > PHYSICAL_START + memory_limit) ||
!memblock_is_memory(start + size - 1) ||
overlaps_crashkernel(start, size) || overlaps_initrd(start, size)) {
- p = __va(memblock_phys_alloc(size, PAGE_SIZE));
+ p = memblock_alloc_raw(size, PAGE_SIZE);
+ if (!p)
+ panic("Failed to allocate %lu bytes to move device
tree\n",
+ size);
memcpy(p, initial_boot_params, size);
initial_boot_params = p;
DBG("Moved device tree to 0x%px\n", p);
--
Cheers,
Stephen Rothwell
pgpCWzKOG0kMl.pgp
Description: OpenPGP digital signature
[PATCH v2 1/2] dt-bindings: regulator: add LS2 load switch documentation
Document device-tree settings of the load-switch LS2
in the tps65218 device.
Signed-off-by: Christian Hohnstaedt
---
Documentation/devicetree/bindings/regulator/tps65218.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt
b/Documentation/devicetree/bindings/regulator/tps65218.txt
index 02f0e9b..b28e9bd 100644
--- a/Documentation/devicetree/bindings/regulator/tps65218.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -71,6 +71,11 @@ tps65218: tps65218@24 {
regulator-always-on;
};
+ ls2: regulator-ls2 {
+ regulator-min-microamp = <10>;
+ regulator-max-microamp = <100>;
+ };
+
ls3: regulator-ls3 {
regulator-min-microvolt = <10>;
regulator-max-microvolt = <100>;
--
2.7.4
Re: [PATCH v2 1/2] dt-bindings: dmaengine: sprd: Change channel id to slave id for DMA cell specifier
On 21-02-19, 13:34, Baolin Wang wrote: > For Spreadtrum DMA engine, all channels are equal, which means slave can > request any channels with setting a unique slave id to trigger this channel. > > Thus we can remove the channel id from device tree to assign the channel > dynamically, moreover we should add the slave id in device tree. Applied, thanks -- ~Vinod
Re: [PATCH net-next] switchdev: Complete removal of switchdev_port_attr_get()
From: Florian Fainelli
Date: Sun, 24 Feb 2019 18:39:02 -0800
> We have no more in tree users of switchdev_port_attr_get() after
> d0e698d57a94 ("Merge branch 'net-Get-rid-of-switchdev_port_attr_get'")
> so completely remove the function signature and body.
>
> Signed-off-by: Florian Fainelli
Applied, thanks.
Re: [PATCH v2.1 04/26] mm: allow VM_FAULT_RETRY for multiple times
On Fri, Feb 22, 2019 at 10:11:58AM -0500, Jerome Glisse wrote:
> On Fri, Feb 22, 2019 at 12:25:44PM +0800, Peter Xu wrote:
> > On Thu, Feb 21, 2019 at 10:53:11AM -0500, Jerome Glisse wrote:
> > > On Thu, Feb 21, 2019 at 04:56:56PM +0800, Peter Xu wrote:
> > > > The idea comes from a discussion between Linus and Andrea [1].
>
> [...]
>
> > > > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> > > > index 248ff0a28ecd..d842c3e02a50 100644
> > > > --- a/arch/x86/mm/fault.c
> > > > +++ b/arch/x86/mm/fault.c
> > > > @@ -1483,9 +1483,7 @@ void do_user_addr_fault(struct pt_regs *regs,
> > > > if (unlikely(fault & VM_FAULT_RETRY)) {
> > > > bool is_user = flags & FAULT_FLAG_USER;
> > > >
> > > > - /* Retry at most once */
> > > > if (flags & FAULT_FLAG_ALLOW_RETRY) {
> > > > - flags &= ~FAULT_FLAG_ALLOW_RETRY;
> > > > flags |= FAULT_FLAG_TRIED;
> > > > if (is_user && signal_pending(tsk))
> > > > return;
> > >
> > > So here you have a change in behavior, it can retry indefinitly for as
> > > long as they are no signal. Don't you want so test for FAULT_FLAG_TRIED ?
> >
> > These first five patches do want to allow the page fault to retry as
> > much as needed. "indefinitely" seems to be a scary word, but IMHO
> > this is fine for page faults since otherwise we'll simply crash the
> > program or even crash the system depending on the fault context, so it
> > seems to be nowhere worse.
> >
> > For userspace programs, if anything really really go wrong (so far I
> > still cannot think a valid scenario in a bug-free system, but just
> > assuming...) and it loops indefinitely, IMHO it'll just hang the buggy
> > process itself rather than coredump, and the admin can simply kill the
> > process to retake the resources since we'll still detect signals.
> >
> > Or did I misunderstood the question?
>
> No i think you are right, it is fine to keep retrying while they are
> no signal maybe just add a comment that says so in so many words :)
> So people do not see that as a potential issue.
Sure thing. I don't know whether commenting this on all the
architectures is good... I'll try to add some comments above
FAULT_FLAG_* deinitions to explain this.
Thanks!
--
Peter Xu
Re: [PATCH v5 1/6] dt-bindings: Add a binding for Mediatek SCP
On Fri, Feb 22, 2019 at 10:43 PM Rob Herring wrote:
>
> On Thu, Feb 21, 2019 at 04:47:24PM +0800, Pi-Hsun Shih wrote:
> > From: Erin Lo
> >
> > Add a DT binding documentation of SCP for the
> > MT8183 SoC from Mediatek.
> >
> > Signed-off-by: Erin Lo
> > ---
> > Changes from v4:
> > - Add detail of more properties.
> > - Document the usage of mtk,rpmsg-name in subnode from the new design.
> >
> > Changes from v3:
> > - No change.
> >
> > Changes from v2:
> > - No change. I realized that for this patch series, there's no need to
> >add anything under the mt8183-scp node (neither the mt8183-rpmsg or
> >the cros-ec-rpmsg) for them to work, since mt8183-rpmsg is added
> >directly as a rproc_subdev by code, and cros-ec-rpmsg is dynamically
> >created by SCP name service.
> >
> > Changes from v1:
> > - No change.
> > ---
> > .../bindings/remoteproc/mtk,scp.txt | 37 +++
> > 1 file changed, 37 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
> > b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
> > new file mode 100644
> > index 00..8cf8b0e0d98a4c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
> > @@ -0,0 +1,37 @@
> > +Mediatek SCP Bindings
> > +
> > +
> > +This binding provides support for ARM Cortex M4 Co-processor found on some
> > +Mediatek SoCs.
> > +
> > +Required properties:
> > +- compatible Should be "mediatek,mt8183-scp"
> > +- regShould contain the address ranges for the two
> > memory
> > + regions, SRAM and CFG.
> > +- reg-names Contains the corresponding names for the two memory
> > + regions. These should be named "sram" & "cfg".
> > +- clocks Clock for co-processor (See:
> > ../clock/clock-bindings.txt)
> > +- clock-namesContains the corresponding name for the
> > clock. This
> > + should be named "main".
> > +
> > +Subnodes
> > +
> > +
> > +When CONFIG_RPMSG_MTK_SCP is enabled, subnodes of the SCP represent rpmsg
>
> Bindings can't depend on kernel config options.
>
What's the recommendation here if the subnode only has effect when the
config is enabled? Should I just skip the sentence "When ... is
enabled"?
> > +devices. The names of the devices are not important. The properties of
> > these
> > +nodes are defined by the individual bindings for the rpmsg devices - but
> > must
> > +contain the following property:
> > +
> > +- mtk,rpmsg-name Contains the name for the rpmsg device. Used to match
> > + the subnode to rpmsg device announced by SCP.
>
> I don't think this belongs in DT, but without some examples I'm not
> really sure.
>
This is similar to the qcom,smd-channels property in
Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt, a example DT
for this:
scp {
compatible = "mediatek,mt8183-scp";
...
cros_ec {
compatible = "google,cros-ec-rpmsg";
mtk,rpmsg-name = "cros-ec-rpmsg";
cros_ec_codec {
compatible = "google,cros-ec-codec";
...
};
};
};
> > +
> > +Example:
> > +
> > + scp: scp@1050 {
> > + compatible = "mediatek,mt8183-scp";
> > + reg = <0 0x1050 0 0x8>,
> > + <0 0x105c 0 0x5000>;
> > + reg-names = "sram", "cfg";
> > + clocks = < CLK_INFRA_SCPSYS>;
> > + clock-names = "main";
> > + };
> > --
> > 2.21.0.rc0.258.g878e2cd30e-goog
> >
linux-next: manual merge of the akpm-current tree with the powerpc tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/kernel/setup_64.c
between commits:
c8e409a33cf8 ("powerpc/irq: use memblock functions returning virtual address")
d608898abc74 ("powerpc: clean stack pointers naming")
from the powerpc tree and commit:
82af77ee7503 ("powerpc: prefer memblock APIs returning virtual address")
from the akpm-current tree.
Commits 82af77ee7503 and c8e409a33cf8 overlap.
I fixed it up (I just used the powerpc tree version of this file) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpoY876kcZke.pgp
Description: OpenPGP digital signature
Clang patches for 4.9
Hi Greg and Sasha,
Attached are three mbox files containing patches that bring the Clang
backports that Nick did in 4.9.139 up to date with what is currently in
4.14 and mainline, as well as fix warnings that are present in the arm64
and x86_64 defconfigs here and in AOSP (cuttlefish_defconfig). All of
these warnings are fixed in 4.14 so there will be no regressions from
upgrading.
They were tested with Arch Linux's GCC 8.2.1 and AOSP's clang-r349610 [1]
and boot tested in QEMU 3.1.0 with our rootfs files [2].
Additionally, for Greg, I have provided a merge resolution for
the Makefile conflict you will get when doing the android-4.9 merge.
You will also get a conflict in arch/arm64/include/asm/arch_gicv3.h,
just check out to MERGE_HEAD as the {read,write}_sysreg_s macros have
the LTO workaround that causes the conflict in the first place. I
tested this resolution by building and booting cuttlefish_defconfig
for arm64 with CONFIG_LTO_CLANG and CONFIG_CFI_CLANG enabled.
[1]:
https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/803bf398de492bb70560a2444d24491bc42b84ec/clang-r349610/
[2]:
https://github.com/ClangBuiltLinux/continuous-integration/tree/8a288264aa71f59a1725d2946b0a40364aafcad7/images
Please let me know if there are any concerns or objections!
Nathan
core-clang-fixes-4.9.mbox
Description: application/mbox
arm64-clang-warning-fixes-4.9.mbox
Description: application/mbox
x86_64-clang-warning-fixes-4.9.mbox
Description: application/mbox
diff --git a/Makefile b/Makefile
index 1b3780acf7c6..e493143bfde1 100644
--- a/Makefile
+++ b/Makefile
@@ -306,11 +306,6 @@ HOSTCXX = g++
HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2
-fomit-frame-pointer -std=gnu89
HOSTCXXFLAGS = -O2
-ifeq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1)
-HOSTCFLAGS += -Wno-unused-value -Wno-unused-parameter \
- -Wno-missing-field-initializers -fno-delete-null-pointer-checks
-endif
-
# Decide whether to build built-in, modular, or both.
# Normally, just do built-in.
@@ -513,40 +508,20 @@ endif
ifeq ($(cc-name),clang)
ifneq ($(CROSS_COMPILE),)
CLANG_TRIPLE ?= $(CROSS_COMPILE)
-CLANG_TARGET := --target=$(notdir $(CLANG_TRIPLE:%-=%))
-ifeq ($(shell $(srctree)/scripts/clang-android.sh $(CC) $(CLANG_TARGET)), y)
+CLANG_FLAGS:= --target=$(notdir $(CLANG_TRIPLE:%-=%))
+ifeq ($(shell $(srctree)/scripts/clang-android.sh $(CC) $(CLANG_FLAGS)), y)
$(error "Clang with Android --target detected. Did you specify CLANG_TRIPLE?")
endif
GCC_TOOLCHAIN_DIR := $(dir $(shell which $(LD)))
-CLANG_PREFIX := --prefix=$(GCC_TOOLCHAIN_DIR)
+CLANG_FLAGS+= --prefix=$(GCC_TOOLCHAIN_DIR)
GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
endif
ifneq ($(GCC_TOOLCHAIN),)
-CLANG_GCC_TC := --gcc-toolchain=$(GCC_TOOLCHAIN)
+CLANG_FLAGS+= --gcc-toolchain=$(GCC_TOOLCHAIN)
endif
-KBUILD_CFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) $(CLANG_PREFIX)
-KBUILD_AFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) $(CLANG_PREFIX)
-KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
-KBUILD_CFLAGS += $(call cc-disable-warning, unused-variable)
-KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier)
-KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
-KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
-KBUILD_CFLAGS += $(call cc-disable-warning, duplicate-decl-specifier)
-# Quiet clang warning: comparison of unsigned expression < 0 is always false
-KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare)
-# CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as the
-# source of a reference will be _MergedGlobals and not on of the whitelisted
names.
-# See modpost pattern 2
-KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,)
-KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior)
-KBUILD_CFLAGS += $(call cc-option, -no-integrated-as)
-KBUILD_AFLAGS += $(call cc-option, -no-integrated-as)
-else
-
-# These warnings generated too much noise in a regular build.
-# Use make W=1 to enable them (see scripts/Makefile.build)
-KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
-KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable)
+CLANG_FLAGS+= -no-integrated-as
+KBUILD_CFLAGS += $(CLANG_FLAGS)
+KBUILD_AFLAGS += $(CLANG_FLAGS)
endif
@@ -806,6 +781,27 @@ ifdef CONFIG_CC_STACKPROTECTOR
endif
KBUILD_CFLAGS += $(stackp-flag)
+ifeq ($(cc-name),clang)
+KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
+KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier)
+KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
+KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
+KBUILD_CFLAGS += $(call cc-disable-warning, duplicate-decl-specifier)
+# Quiet clang warning: comparison of unsigned expression < 0 is always false
+KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare)
+# CLANG uses a _MergedGlobals as optimization, but this
Re: [PATCH v1 2/2] clk: mediatek: correct cpu clock name for MT8173 SoC
On Thu, 2019-02-21 at 14:03 -0800, Stephen Boyd wrote: > Quoting Seiya Wang (2019-02-10 23:15:55) > > Change cpu clock name from ca57 to ca72 since MT8173 does use cortex-a72. > > > > Signed-off-by: Seiya Wang > > --- > > Acked-by: Stephen Boyd > > I'm guessing I can't apply this patch because the define is renamed > which would break older DTs. Another option would be to just add another > define and mark the old define as deprecated and unsupported. Then I > could apply the patch to clk tree. Thank you so much for your advice. We will update the patches and resend soon.
Re: [PATCH] tun: fix blocking read
From: Timur Celik Date: Sat, 23 Feb 2019 12:53:13 +0100 > This patch moves setting of the current state into the loop. Otherwise > the task may end up in a busy wait loop if none of the break conditions > are met. > > Signed-off-by: Timur Celik Applied and queued up for -stable, thanks.
Re: [Patch net-next 00/12] code optimizations & bugfixes for HNS3 driver
From: Huazhong Tan Date: Sat, 23 Feb 2019 17:22:07 +0800 > This patchset includes bugfixes and code optimizations for > the HNS3 ethernet controller driver. Series applied, thanks.
Re: [PATCH 0/3] soc: fsl: dpio: enable and configure cache stashing
From: Ioana Ciornei Date: Sat, 23 Feb 2019 08:48:42 + > The first two patches enable cache stashing and configure the core cluster > destination per software portal while the third patch is the one > configuring the amount of stashing on a queue. Should I merge this series in via my networking tree? Thanks.
[PATCH v1 0/3] perf diff: Add new filter options
This patch series creates following new filter options for perf diff. --time: It supports time percent with multipe time ranges. Time string is 'a%/n,b%/m,...' or 'a%-b%,c%-%d,...'. For example: Select the second 10% time slice to diff: perf diff --time 10%/2 Select from 0% to 10% time slice to diff: perf diff --time 0%-10% Select the first and the second 10% time slices to diff: perf diff --time 10%/1,10%/2 Select from 0% to 10% and 30% to 40% slices to diff: perf diff --time 0%-10%,30%-40% It also supports to analyze samples within given time window as: ,. Times have the format seconds.microseconds. If start is not given (i.e., time string is ',x.y') then analysis starts at the beginning of the file. If stop time is not given (i.e, time string is 'x.y,') then analysis goes to end of file. Time string is 'a1.b1,c1.d1:a2.b2,c2.d2'. Use ':' to separate timestamps for different perf.data files. For example, we get the timestamp information from perf script. perf script -i perf.data.old mgen 13940 [000] 3946.361400: ... perf script -i perf.data mgen 13940 [000] 3971.150589 ... perf diff --time 3946.361400,:3971.150589, It analyzes the perf.data.old from the timestamp 3946.361400 to the end of perf.data.old and analyzes the perf.data from the timestamp 3971.150589 to the end of perf.data. --cpu: Only diff samples for the list of CPUs provided. Multiple CPUs can be provided as a comma-separated list with no space: 0,1. Ranges of CPUs are specified with -: 0-2. Default is to report samples on all CPUs. For example: perf diff --cpu 0,1 It only diff the samples for CPU0 and CPU1. --pid: Only diff samples for given process ID (comma separated list). --tid: Only diff samples for given thread ID (comma separated list). For example, perf diff --tid 13965 It only diff the samples for thread 13965. Jin Yao (3): perf diff: Support --time filter option perf diff: Support --cpu filter option perf diff: Support --pid/--tid filter options tools/perf/Documentation/perf-diff.txt | 52 ++ tools/perf/builtin-diff.c | 174 ++--- 2 files changed, 213 insertions(+), 13 deletions(-) -- 2.7.4
[PATCH v1 3/3] perf diff: Support --pid/--tid filter options
For better filtering support for perf diff, it would be useful to
add --pid and --tid filter options.
For example,
perf diff --tid 13965
It only diff the samples for thread 13965.
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-diff.txt | 6 ++
tools/perf/builtin-diff.c | 4
2 files changed, 10 insertions(+)
diff --git a/tools/perf/Documentation/perf-diff.txt
b/tools/perf/Documentation/perf-diff.txt
index ed13b3f..83c9496 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -164,6 +164,12 @@ OPTIONS
CPUs are specified with -: 0-2. Default is to report samples on all
CPUs.
+--pid=::
+ Only diff samples for given process ID (comma separated list).
+
+--tid=::
+ Only diff samples for given thread ID (comma separated list).
+
COMPARISON
--
The comparison is governed by the baseline file. The baseline perf.data
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 319fbc9..9053eda 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -993,6 +993,10 @@ static const struct option options[] = {
OPT_STRING(0, "time", _str, "str",
"Time span (time percent or absolute timestamp)"),
OPT_STRING(0, "cpu", _list, "cpu", "list of cpus to profile"),
+ OPT_STRING(0, "pid", _conf.pid_list_str, "pid[,pid...]",
+ "only consider symbols in these pids"),
+ OPT_STRING(0, "tid", _conf.tid_list_str, "tid[,tid...]",
+ "only consider symbols in these tids"),
OPT_END()
};
--
2.7.4
[PATCH v1 2/3] perf diff: Support --cpu filter option
For better support for perf diff, it would be useful to add --cpu filter
option.
Multiple CPUs can be provided as a comma-separated list with no space: 0,1.
Ranges of CPUs are specified with -: 0-2. Default is to report samples on
all CPUs.
For example,
perf diff --cpu 0,1
It only diff the samples for CPU0 and CPU1.
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-diff.txt | 5 +
tools/perf/builtin-diff.c | 16
2 files changed, 21 insertions(+)
diff --git a/tools/perf/Documentation/perf-diff.txt
b/tools/perf/Documentation/perf-diff.txt
index 5bfe876..ed13b3f 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -159,6 +159,11 @@ OPTIONS
the end of perf.data.old and analyzes the perf.data from the
timestamp 3971.150589 to the end of perf.data.
+--cpu:: Only diff samples for the list of CPUs provided. Multiple CPUs can
+ be provided as a comma-separated list with no space: 0,1. Ranges of
+ CPUs are specified with -: 0-2. Default is to report samples on all
+ CPUs.
+
COMPARISON
--
The comparison is governed by the baseline file. The baseline perf.data
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index ddc41e7..319fbc9 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -83,6 +83,9 @@ static unsigned int sort_compute = 1;
static s64 compute_wdiff_w1;
static s64 compute_wdiff_w2;
+static const char *cpu_list;
+static DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
+
enum {
COMPUTE_DELTA,
COMPUTE_RATIO,
@@ -354,6 +357,11 @@ static int diff__process_sample_event(struct perf_tool
*tool,
return -1;
}
+ if (cpu_list && !test_bit(sample->cpu, cpu_bitmap)) {
+ ret = 0;
+ goto out_put;
+ }
+
if (!hists__add_entry(hists, , NULL, NULL, NULL, sample, true)) {
pr_warning("problem incrementing symbol period, skipping
event\n");
goto out_put;
@@ -905,6 +913,13 @@ static int __cmd_diff(void)
pdiff.range_num = 1;
}
+ if (cpu_list) {
+ ret = perf_session__cpu_bitmap(d->session, cpu_list,
+ cpu_bitmap);
+ if (ret < 0)
+ goto out_delete;
+ }
+
ret = perf_session__process_events(d->session);
if (ret) {
pr_err("Failed to process %s\n", d->data.file.path);
@@ -977,6 +992,7 @@ static const struct option options[] = {
"How to display percentage of filtered entries",
parse_filter_percentage),
OPT_STRING(0, "time", _str, "str",
"Time span (time percent or absolute timestamp)"),
+ OPT_STRING(0, "cpu", _list, "cpu", "list of cpus to profile"),
OPT_END()
};
--
2.7.4
[PATCH v1 1/3] perf diff: Support --time filter option
For better support for perf diff, it would be useful to add --time filter
option to diff the samples within given time window.
It supports time percent with multipe time ranges. Time string is
'a%/n,b%/m,...' or 'a%-b%,c%-%d,...'.
For example:
Select the second 10% time slice to diff:
perf diff --time 10%/2
Select from 0% to 10% time slice to diff:
perf diff --time 0%-10%
Select the first and the second 10% time slices to diff:
perf diff --time 10%/1,10%/2
Select from 0% to 10% and 30% to 40% slices to diff:
perf diff --time 0%-10%,30%-40%
It also supports to analyze samples within given time window as:
,. Times have the format seconds.microseconds. If start
is not given (i.e., time string is ',x.y') then analysis starts at
the beginning of the file. If stop time is not given (i.e, time
string is 'x.y,') then analysis goes to end of file. Time string is
'a1.b1,c1.d1:a2.b2,c2.d2'. Use ':' to separate timestamps for different
perf.data files.
For example, we get the timestamp information from perf script.
perf script -i perf.data.old
mgen 13940 [000] 3946.361400: ...
perf script -i perf.data
mgen 13940 [000] 3971.150589 ...
perf diff --time 3946.361400,:3971.150589,
It analyzes the perf.data.old from the timestamp 3946.361400 to
the end of perf.data.old and analyzes the perf.data from the
timestamp 3971.150589 to the end of perf.data.
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-diff.txt | 41 +
tools/perf/builtin-diff.c | 154 ++---
2 files changed, 182 insertions(+), 13 deletions(-)
diff --git a/tools/perf/Documentation/perf-diff.txt
b/tools/perf/Documentation/perf-diff.txt
index a79c84a..5bfe876 100644
--- a/tools/perf/Documentation/perf-diff.txt
+++ b/tools/perf/Documentation/perf-diff.txt
@@ -118,6 +118,47 @@ OPTIONS
sum of shown entries will be always 100%. "absolute" means it retains
the original value before and after the filter is applied.
+--time::
+ Analyze samples within given time window. It supports time
+ percent with multipe time ranges. Time string is 'a%/n,b%/m,...'
+ or 'a%-b%,c%-%d,...'.
+
+ For example:
+
+ Select the second 10% time slice to diff:
+ perf diff --time 10%/2
+
+ Select from 0% to 10% time slice to diff:
+ perf diff --time 0%-10%
+
+ Select the first and the second 10% time slices to diff:
+ perf diff --time 10%/1,10%/2
+
+ Select from 0% to 10% and 30% to 40% slices to diff:
+ perf diff --time 0%-10%,30%-40%
+
+ It also supports to analyze samples within given time window:
+ ,. Times have the format seconds.microseconds. If start
+ is not given (i.e., time string is ',x.y') then analysis starts at
+ the beginning of the file. If stop time is not given (i.e, time
+ string is 'x.y,') then analysis goes to end of file. Time string is
+ 'a1.b1,c1.d1:a2.b2,c2.d2'. Use ':' to separate timestamps for different
+ perf.data files.
+
+ For example, we get the timestamp information from perf script.
+
+ perf script -i perf.data.old
+ mgen 13940 [000] 3946.361400: ...
+
+ perf script -i perf.data
+ mgen 13940 [000] 3971.150589 ...
+
+ perf diff --time 3946.361400,:3971.150589,
+
+ It analyzes the perf.data.old from the timestamp 3946.361400 to
+ the end of perf.data.old and analyzes the perf.data from the
+ timestamp 3971.150589 to the end of perf.data.
+
COMPARISON
--
The comparison is governed by the baseline file. The baseline perf.data
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 751e197..ddc41e7 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -19,12 +19,21 @@
#include "util/util.h"
#include "util/data.h"
#include "util/config.h"
+#include "util/time-utils.h"
#include
#include
#include
#include
+struct perf_diff {
+ struct perf_tooltool;
+ const char *time_str;
+ struct perf_time_interval *ptime_range;
+ int range_size;
+ int range_num;
+};
+
/* Diff command specific HPP columns. */
enum {
PERF_HPP_DIFF__BASELINE,
@@ -323,16 +332,22 @@ static int formula_fprintf(struct hist_entry *he, struct
hist_entry *pair,
return -1;
}
-static int diff__process_sample_event(struct perf_tool *tool __maybe_unused,
+static int diff__process_sample_event(struct perf_tool *tool,
union perf_event *event,
struct perf_sample *sample,
struct perf_evsel *evsel,
struct machine *machine)
{
+ struct perf_diff *pdiff = container_of(tool, struct perf_diff, tool);
struct addr_location al;
struct hists *hists = evsel__hists(evsel);
int ret = -1;
+ if
Re: [PATCH 03/11] x86 topology: Add CPUID.1F multi-die/package support
On 2019/2/24 18:04, Brice Goglin wrote:
Le 19/02/2019 à 04:40, Len Brown a écrit :
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index ccd1f2a8e557..4250a87f57db 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -393,6 +393,7 @@ static bool match_smt(struct cpuinfo_x86 *c, struct
cpuinfo_x86 *o)
int cpu1 = c->cpu_index, cpu2 = o->cpu_index;
if (c->phys_proc_id == o->phys_proc_id &&
+ c->cpu_die_id == o->cpu_die_id &&
per_cpu(cpu_llc_id, cpu1) == per_cpu(cpu_llc_id, cpu2)) {
if (c->cpu_core_id == o->cpu_core_id)
return topology_sane(c, o, "smt");
@@ -404,6 +405,7 @@ static bool match_smt(struct cpuinfo_x86 *c, struct
cpuinfo_x86 *o)
}
} else if (c->phys_proc_id == o->phys_proc_id &&
+ c->cpu_die_id == o->cpu_die_id &&
c->cpu_core_id == o->cpu_core_id) {
return topology_sane(c, o, "smt");
}
@@ -461,7 +463,7 @@ static bool match_llc(struct cpuinfo_x86 *c, struct
cpuinfo_x86 *o)
*/
static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
{
- if (c->phys_proc_id == o->phys_proc_id)
+ if (c->cpu_die_id == o->cpu_die_id)
return true;
return false;
}
Hello Len,
I am testing your patches in a VM with CPUID.1f QEMU patches (author Like Xu is
CC'ed),
booted to get 2 packages with 1 NUMA node each and 2 dies each:
-smp cpus=16,threads=2,cores=2,dies=2,sockets=2 -numa node,cpus=0-7,nodeid=0
-numa node,cpus=8-15,nodeid=1
sysfs files expose wrong information:
core_siblings contains threads of the local die AND of die with same number in
other processors,
eg cpu 0-3 and 8-11 instead of 0-3 only.
The issue is that you seem to assume that die ids will always be unique across
multiple packages.
I don't think the intel MCP topolohgy has this global uniqueness
assumption for die_id according to CPUID.1F SDM.
Is this a valid assumption? If so, QEMU patches should be fixed.
If not, I fixed the issue by changing match_die() to check both phys_proc_id
and cpu_die_id:
static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
{
if (c->phys_proc_id == o->phys_proc_id && c->cpu_die_id ==
o->cpu_die_id)
return true;
return false;
}
Thanks
Brice
Re: [PATCH v6 0/7] Support Trusted Foundations firmware on Tegra30
В Mon, 25 Feb 2019 05:02:33 +0100 Michał Mirosław пишет: > On Fri, Feb 22, 2019 at 10:34:19PM +0300, Dmitry Osipenko wrote: > > Hello, > > > > This patchset adds support for the Trusted Foundations firmware on > > NVIDIA Tegra30. Pretty much all of Tegra30 consumer devices have > > that firmware and upstream kernel can't boot on those devices > > without the firmware support. > > Hi Dmitry > > I've applied and tested this patchset on my TF300T. Boots and > suspends/wakes using 'rtcwake -m mem -s 1 -d /dev/rtc1' as the test. > dmesg attached. > > The exact tree used: > git://rere.qmqm.pl/linux tf300t > > Feel free to add my Tested-by and Signed-off-by on the patches where > apropriate, and thanks for your work! Awesome, thank you very much! Robert, could you please confirm that v6 works for you too? I'll probably make a v7 with an extra minor clean up and then will add all the appropriate tags to the patches.
Re: huge fsync latencies for a small file on ext4
On Tue, Feb 19, 2019 at 02:53:02PM +0100, Jan Kara wrote: > Hi! > > On Tue 19-02-19 15:50:23, stumm...@codeaurora.org wrote: > > I am observing huge fsync latencies for a small file under the below test > > scenario - > > > > process A - > > Issue async write of 4GB using dd command (say large_file) on /data mounted > > with ext4: > > dd if=/dev/zero of=/data/testfile bs=1M count=4096 > > > > process B - > > In parallel another process wrote a small 4KB data to another file > > (say, small_file) and has issued fsync on this file. > > > > Problem - > > The fsync() on 4KB file, is taking upto ~30sec (worst case latency). > > This is tested on an eMMC based device. > > > > Observations - > > This happens when the small_file and large_file both are part of the same > > committing transaction or when the small_file is part of the running > > transaction > > while large_file is part of the committing transaction. > > > > During the commit of a transaction which includes large_file, the jbd2 > > thread > > does journal_finish_inode_data_buffers() by calling > > filemap_fdatawait_keep_errors() on the file's inode address space. While > > this is > > happening, if the writeback thread is running in parallel for the > > large_file, then > > filemap_fdatawait_keep_errors() could potentially run in a loop of all the > > pages (upto 4GB of data) and also wait for all the file's data to be written > > to the disk in the current transaction context itself. At the time > > of calling journal_finish_inode_data_buffers(), the file size is of only > > 150MB. > > and by the time filemap_fdatawait_keep_errors() returns, the file size is > > 4GB > > and the page index also points to 4GB file offset in > > __filemap_fdatawait_range(), indicating that is has scanned and waited for > > writeback > > all the pages upto 4GB and not just 150MB. > > Thanks for the detailed analysis! I'm somewhat surprised that the flusher > is able to submit new batch of pages for writeback faster than > __filemap_fdatawait_range() is scanning the radix tree but it is certainly > a possibility. > > > Ideally, I think the jbd2 thread should have waited for only the amount of > > data > > it has submitted as part of the current transaction and not to wait for the > > on-going pages that are getting tagged for writeback in parallel in another > > context. > > So along these lines, I have tried to use the inode's size at the time of > > calling > > journal_finish_inode_data_buffers() as below - > > One has to be really careful when using i_size like this. By the time the > transaction is committing, i_size could have been reduced from the value at > the time page writeback was issued. And that change will be journalled only > in the following transaction. So if the system crashes in the wrong moment, > user could see uninitialized blocks between new_size and old_size after > journal replay. So I don't think your patch is really correct. > Thanks Jan for the clarification on the patch. I agree with your comments. >From that discussion, I think the problem that it is discussing is w.r.t journal thread waiting for on-going active transaction updates to be done and thus causing commit latencies. And I think the proposal is to do not hold any handle while extents are being mapped in ext4_map_blocks() but defer it till IO is completely done. And with the new proposal since the inode will be added to transaction->t_inode_list only after the IO is completed, there will be no longer the need to do journal_finish_inode_data_buffers() in the journal context and thus this problem also will not be observed? Is my understanding correct, please clarify. > Ted has outlined a plan how to get rid of data=ordered limitations [1] and > thus also this problem. It is quite some work but you're certainly welcome > to help out :) > > Honza > > [1] https://www.spinics.net/lists/linux-ext4/msg64175.html > > > > > diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c > > index 2eb55c3..e86cf67 100644 > > --- a/fs/jbd2/commit.c > > +++ b/fs/jbd2/commit.c > > @@ -261,8 +261,8 @@ static int journal_finish_inode_data_buffers(journal_t > > *journal, > > continue; > > jinode->i_flags |= JI_COMMIT_RUNNING; > > spin_unlock(>j_list_lock); > > - err = filemap_fdatawait_keep_errors( > > - jinode->i_vfs_inode->i_mapping); > > + err = > > filemap_fdatawait_range(jinode->i_vfs_inode->i_mapping, > > + 0, > > i_size_read(jinode->i_vfs_inode->i_mapping->host)); > > if (!ret) > > ret = err; > > spin_lock(>j_list_lock); > > > > With this, the fsync latencies for small_file have reduced significantly. > > It took upto max ~5sec (worst case latency). > > > > Although this is seen in a test code, this could potentially impact the
Re: [PATCH v1] usb: chipidea: tegra: Fix missed ci_hdrc_remove_device()
В Mon, 25 Feb 2019 02:27:19 +
Peter Chen пишет:
>
> >
> > Fixes: dfebb5f43a78827a ("usb: chipidea: Add support for
> > Tegra20/30/114/124")
>
> I suppose you need to apply at stable tree too, right?
>
It is enough to have the "Fixes" tag to get patch backported into all
relevant kernel versions.
> > Signed-off-by: Dmitry Osipenko
> > ---
> > drivers/usb/chipidea/ci_hdrc_tegra.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c
> > b/drivers/usb/chipidea/ci_hdrc_tegra.c
> > index 772851bee99b..12025358bb3c 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_tegra.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
> > @@ -130,6 +130,7 @@ static int tegra_udc_remove(struct
> > platform_device *pdev) {
> > struct tegra_udc *udc = platform_get_drvdata(pdev);
> >
> > + ci_hdrc_remove_device(udc->dev);
> > usb_phy_set_suspend(udc->phy, 1);
> > clk_disable_unprepare(udc->clk);
> >
>
> Acked-by: Peter Chen
>
> Hi Greg, would you still accept the bug-fix for this release (v5.0)?
> Or I send you later?
I just want to point out that the bug existed for a very long time and
apparently didn't bother anybody, hence it's not an urgent fix.
Re: [PATCH] time64: Avoid undefined behaviour in timespec64_add()
On Sun, Feb 24, 2019 at 7:13 PM Hongbo Yao wrote:
>
> I ran into this:
>
> =
> UBSAN: Undefined behaviour in ./include/linux/time64.h:70:2
> signed integer overflow:
> 1551059291 + 9223372036854775807 cannot be represented in type 'long
> long int'
> CPU: 5 PID: 20064 Comm: syz-executor.2 Not tainted 4.19.24 #4
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-1ubuntu1 04/01/2014
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0xca/0x13e lib/dump_stack.c:113
> ubsan_epilogue+0xe/0x81 lib/ubsan.c:159
> handle_overflow+0x193/0x1e2 lib/ubsan.c:190
> timespec64_add include/linux/time64.h:70 [inline]
> timekeeping_inject_offset+0x3ed/0x4e0 kernel/time/timekeeping.c:1301
> do_adjtimex+0x1e5/0x6c0 kernel/time/timekeeping.c:2360
> __do_sys_clock_adjtime+0x122/0x200 kernel/time/posix-timers.c:1086
> do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x462eb9
> Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48
> 89
> f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
> f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
> RSP: 002b:7f888aa2dc58 EFLAGS: 0246 ORIG_RAX: 0131
> RAX: ffda RBX: 0073bf00 RCX: 00462eb9
> RDX: RSI: 23c0 RDI:
> RBP: 0002 R08: R09:
> R10: R11: 0246 R12: 7f888aa2e6bc
> R13: 004bcae8 R14: 006f6868 R15:
>
> ==
>
> Since lhs.tv_sec and rhs.tv_sec are both time64_t, this is a signed
> addition which will cause undefined behaviour on overflow.
>
> The easiest way to avoid the overflow is to cast one of the arguments to
> unsigned (so the addition will be done using unsigned arithmetic).
> This patch doesn't change generated code.
>
> Signed-off-by: Hongbo Yao
> ---
> include/linux/time64.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/time64.h b/include/linux/time64.h
> index 05634afba0db..5926bdd4167f 100644
> --- a/include/linux/time64.h
> +++ b/include/linux/time64.h
> @@ -67,7 +67,7 @@ static inline struct timespec64 timespec64_add(struct
> timespec64 lhs,
> struct timespec64 rhs)
> {
> struct timespec64 ts_delta;
> - set_normalized_timespec64(_delta, lhs.tv_sec + rhs.tv_sec,
> + set_normalized_timespec64(_delta, (timeu64_t)lhs.tv_sec +
> rhs.tv_sec,
> lhs.tv_nsec + rhs.tv_nsec);
> return ts_delta;
> }
There is already a timespec64_add_safe() to account for such
overflows. That assumes both the timespec64 values are positive.
But, timekeeping_inject_offset() cannot use that as one of the values
can be negative.
Are you running some kind of a fuzzer that would cause a overflow?
You seem to be adding INT64_MAX here. Maybe the right thing to do is
to add a check at the syscall interface rather than here.
-Deepa
linux-next: build warning after merge of the gpio tree
Hi Linus,
After merging the gpio tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/gpio/gpio-amd-fch.c: In function 'amd_fch_gpio_probe':
drivers/gpio/gpio-amd-fch.c:164:49: warning: passing argument 2 of
'devm_ioremap_resource' discards 'const' qualifier from pointer target type
[-Wdiscarded-qualifiers]
priv->base = devm_ioremap_resource(>dev, _fch_gpio_iores);
^~~
In file included from include/linux/platform_device.h:14,
from drivers/gpio/gpio-amd-fch.c:15:
include/linux/device.h:709:15: note: expected 'struct resource *' but argument
is of type 'const struct resource *'
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
^
Introduced by commit
e09d168f13f0 ("gpio: AMD G-Series PCH gpio driver")
--
Cheers,
Stephen Rothwell
pgp7P076MTKpC.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault
On Sun, Feb 24, 2019 at 6:40 PM Masami Hiramatsu wrote: > > On Sun, 24 Feb 2019 09:26:45 -0800 > Linus Torvalds wrote: > > > On Sun, Feb 24, 2019 at 7:18 AM Masami Hiramatsu > > wrote: > > > > > > On Sat, 23 Feb 2019 20:38:03 -0800 > > > Andy Lutomirski wrote: > > > > > > > > Can we just get rid of this might_sleep()? access_ok() doesn't sleep > > > > as far as I know. > > > > > > Hmm, which might_sleep() would you pointed? What I talked was a > > > WARN_ON_ONCE(!in_task()) in access_ok() on x86 (only!), and in_task() just > > > checks preempt_count. > > > > So the in_task() check does kind of make sense. Using "access_ok()" > > outside of task context is certainly an odd thing, for several > > reasons. The main one being simply that outside of task context, the > > whole "which task" question is open, and you don't know if the task is > > the active one, and so it's not clear if whatever task you interrupt > > might have done "set_fs()" or not. > > Ah I got it. Usual case access_ok() in IRQ handler is strange. > > > > > So PeterZ isn't wrong: > > > > > I guess PeterZ assumed that access_ok() is used only with user space > > > access > > > APIs (e.g. copy_from_user) which can cause page-fault and locks mm (and > > > might > > > sleep :)), but now we are trying to use access_ok() with new functions > > > which > > > disables page-fault and just return -EFAULT. > > > > .. but in this case, if we do it all *within* code that saves and > > restores the user access flag with get_fs/set_fs, access_ok() would be > > ok and it doesn't have the above issue. > > > > So access_ok() in _general_ is absolutely not safe to do from > > interrupts, but within the context of probing user memory from a > > tracing event it just happens to be ok. > > Hmm, but user can specify user-memory access from the tracing event > which is located in interrupt handler. So I understand that it is safe > only if we correctly setup access flag with get_fs/set_fs, is that > correct? > > > It would be lovely to have a special macro for this, and keep the > > warning for the general case, but because this is a "every > > architecture needs to build their own" it's probably too painful. > > Agreed. This should probably go with whatever effort makes nmi_uaccess_ok() available on all architectures. That being said, how about just making copy_from_user_nmi() work on all architectures, even if it just fails unconditionally on some of them?
Re: [PATCH V2 4/5] cpufreq: Register notifiers with the PM QoS framework
On 22-02-19, 11:44, Qais Yousef wrote:
> Hi Verish
>
> On 02/21/19 16:59, Viresh Kumar wrote:
>
> [...]
>
> > @@ -2239,6 +2314,8 @@ static int cpufreq_set_policy(struct cpufreq_policy
> > *policy,
> > struct cpufreq_policy *new_policy)
> > {
> > struct cpufreq_governor *old_gov;
> > + struct device *cpu_dev = get_cpu_device(policy->cpu);
> > + unsigned long min, max;
> > int ret;
> >
> > pr_debug("setting new policy for CPU %u: %u - %u kHz\n",
> > @@ -2253,11 +2330,23 @@ static int cpufreq_set_policy(struct cpufreq_policy
> > *policy,
> > if (new_policy->min > new_policy->max)
> > return -EINVAL;
> >
> > + min = dev_pm_qos_read_value(cpu_dev, DEV_PM_QOS_MIN_FREQUENCY);
> > + max = dev_pm_qos_read_value(cpu_dev, DEV_PM_QOS_MAX_FREQUENCY);
> > +
> > + if (min > new_policy->min)
> > + new_policy->min = min;
> > + if (max < new_policy->max)
> > + new_policy->max = max;
> > +
>
> Assuming for example min and max range from 1-10, and thermal throttles max to
> 5 using pm_qos to deal with temporary thermal pressure. But shortly after
> a driver thinks that max shouldn't be greater than 7 for one reason or
> another.
>
> What will happen after thermal pressure removes its constraint? Will we still
> remember the driver's request and apply it so max is set to 7 instead of 10?
Once everything comes via PM QoS, it will remember all the presently available
requests and choose a target min/max frequency based on that.
But even with this patchset, with half stuff done with PM QoS and half done with
cpufreq notifiers, it should still work that way only.
--
viresh
Re: [PATCH 10/12] cpufreq: ap806: add missing of_node_put after of_device_is_available
On 23-02-19, 14:20, Julia Lawall wrote:
> Add an of_node_put when a tested device node is not available.
>
> The semantic patch that fixes this problem is as follows
> (http://coccinelle.lip6.fr):
>
> //
> @@
> identifier f;
> local idexpression e;
> expression x;
> @@
>
> e = f(...);
> ... when != of_node_put(e)
> when != x = e
> when != e = x
> when any
> if (<+...of_device_is_available(e)...+>) {
> ... when != of_node_put(e)
> (
> return e;
> |
> + of_node_put(e);
> return ...;
> )
> }
> //
>
> Fixes: f525a670533d9 ("cpufreq: ap806: add cpufreq driver for Armada 8K")
> Signed-off-by: Julia Lawall
>
> ---
> drivers/cpufreq/armada-8k-cpufreq.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff -u -p a/drivers/cpufreq/armada-8k-cpufreq.c
> b/drivers/cpufreq/armada-8k-cpufreq.c
> --- a/drivers/cpufreq/armada-8k-cpufreq.c
> +++ b/drivers/cpufreq/armada-8k-cpufreq.c
> @@ -128,8 +128,10 @@ static int __init armada_8k_cpufreq_init
> struct cpumask cpus;
>
> node = of_find_compatible_node(NULL, NULL, "marvell,ap806-cpu-clock");
> - if (!node || !of_device_is_available(node))
> + if (!node || !of_device_is_available(node)) {
> + of_node_put(node);
> return -ENODEV;
> + }
>
> nb_cpus = num_possible_cpus();
> freq_tables = kcalloc(nb_cpus, sizeof(*freq_tables), GFP_KERNEL);
Applied. Thanks.
--
viresh
Re: [PATCH net-next v2 0/7] net: phy: marvell10g: Add 2.5GBaseT support
From: Maxime Chevallier Date: Sat, 23 Feb 2019 00:37:37 +0100 > This series adds the missing bits necessary to fully support 2.5GBaseT > in the Marvell Alaska PHYs. > > The main points for that support are : > > - Making use of the .get_features call, recently introduced by Heiner >and Andrew, that allows having a fully populated list of supported >modes, including 2500BaseT. > > - Configuring the MII to 2500BaseX when establishing a link at 2.5G > > - Adding a small quirk to take into account the fact that some PHYs in >the family won't report the correct supported abilities > > The rest of the series consists of small cosmetic improvements such as > using the correct helper to set a linkmode bit and adding macros for the > PHY ids. > > We also add support for the 88E2110 PHY, which doesn't require the > quirk, and support for 2500BaseT in the PPv2 driver, in order to have a > fully working setup on the MacchiatoBin board. > > Changes since V1 : Fixed formatting issue in patch 01, rebased. Series applied, thank you.
Re: [PATCH] block: fix inconsistent page index
On Thu, Feb 21, 2019 at 11:27 AM Francesco Ruggeri wrote: > > __find_get_block_slow() and grow_buffers() use different methods to compute > a page index for a given block: __find_get_block_slow() computes it from > bd_inode->i_blkbits, while grow_buffers() computes it from the block size > argument. > The two can get out of sync, for example if bd_inode->i_blkbits is modified > while a isofs_fill_super() (in mount) is between sb_min_blocksize() and > sb_read/__bread_gfp/__getblk_gfp/__getblk_slow. > The script below can reproduce such a scenario, resulting in an infinite > loop in __getblk_slow(), as grow_buffers() allocates a page but > __find_get_block() keeps looking for a different one. > This patch changes __find_get_block_slow() to also use the block size. > It implicitly relies on size being a power of 2 in the 256..PAGE_SIZE > range. > Any comments? Thanks, Francesco Ruggeri
[PATCH v2 1/1] lib/string: Add strscpy_pad() function
We have a function to copy strings safely and we have a function to copy
strings and zero the tail of the destination (if source string is
shorter than destination buffer) but we do not have a function to do
both at once. This means developers must write this themselves if they
desire this functionality. This is a chore, and also leaves us open to
off by one errors unnecessarily.
Add a function that calls strscpy() then memset()s the tail to zero if
the source string is shorter than the destination buffer.
Add test module for the new code.
Signed-off-by: Tobin C. Harding
---
include/linux/string.h | 4 +
lib/Kconfig.debug | 3 +
lib/Makefile | 1 +
lib/string.c | 47 +--
lib/test_strscpy.c | 175 +
5 files changed, 223 insertions(+), 7 deletions(-)
create mode 100644 lib/test_strscpy.c
diff --git a/include/linux/string.h b/include/linux/string.h
index 7927b875f80c..bfe95bf5d07e 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -31,6 +31,10 @@ size_t strlcpy(char *, const char *, size_t);
#ifndef __HAVE_ARCH_STRSCPY
ssize_t strscpy(char *, const char *, size_t);
#endif
+
+/* Wraps calls to strscpy()/memset(), no arch specific code required */
+ssize_t strscpy_pad(char *dest, const char *src, size_t count);
+
#ifndef __HAVE_ARCH_STRCAT
extern char * strcat(char *, const char *);
#endif
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index d4df5b24d75e..fb629a0c6272 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1805,6 +1805,9 @@ config TEST_HEXDUMP
config TEST_STRING_HELPERS
tristate "Test functions located in the string_helpers module at
runtime"
+config TEST_STRSCPY
+ tristate "Test strscpy*() family of functions at runtime"
+
config TEST_KSTRTOX
tristate "Test kstrto*() family of functions at runtime"
diff --git a/lib/Makefile b/lib/Makefile
index e1b59da71418..59519926cbc6 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -42,6 +42,7 @@ obj-y += bcd.o div64.o sort.o parser.o debug_locks.o
random32.o \
obj-$(CONFIG_STRING_SELFTEST) += test_string.o
obj-y += string_helpers.o
obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
+obj-$(CONFIG_TEST_STRSCPY) += test_strscpy.o
obj-y += hexdump.o
obj-$(CONFIG_TEST_HEXDUMP) += test_hexdump.o
obj-y += kstrtox.o
diff --git a/lib/string.c b/lib/string.c
index 38e4ca08e757..209444cb36d6 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -159,11 +159,9 @@ EXPORT_SYMBOL(strlcpy);
* @src: Where to copy the string from
* @count: Size of destination buffer
*
- * Copy the string, or as much of it as fits, into the dest buffer.
- * The routine returns the number of characters copied (not including
- * the trailing NUL) or -E2BIG if the destination buffer wasn't big enough.
- * The behavior is undefined if the string buffers overlap.
- * The destination buffer is always NUL terminated, unless it's zero-sized.
+ * Copy the string, or as much of it as fits, into the dest buffer. The
+ * behavior is undefined if the string buffers overlap. The destination
+ * buffer is always NUL terminated, unless it's zero-sized.
*
* Preferred to strlcpy() since the API doesn't require reading memory
* from the src string beyond the specified "count" bytes, and since
@@ -173,8 +171,10 @@ EXPORT_SYMBOL(strlcpy);
*
* Preferred to strncpy() since it always returns a valid string, and
* doesn't unnecessarily force the tail of the destination buffer to be
- * zeroed. If the zeroing is desired, it's likely cleaner to use strscpy()
- * with an overflow test, then just memset() the tail of the dest buffer.
+ * zeroed. If zeroing is desired please use strscpy_pad().
+ *
+ * Return: The number of characters copied (not including the trailing
+ * %NUL) or -E2BIG if the destination buffer wasn't big enough.
*/
ssize_t strscpy(char *dest, const char *src, size_t count)
{
@@ -237,6 +237,39 @@ ssize_t strscpy(char *dest, const char *src, size_t count)
EXPORT_SYMBOL(strscpy);
#endif
+/**
+ * strscpy_pad() - Copy a C-string into a sized buffer
+ * @dest: Where to copy the string to
+ * @src: Where to copy the string from
+ * @count: Size of destination buffer
+ *
+ * Copy the string, or as much of it as fits, into the dest buffer. The
+ * behavior is undefined if the string buffers overlap. The destination
+ * buffer is always NUL terminated, unless it's zero-sized.
+ *
+ * If the source string is shorter than the destination buffer, zeros
+ * the tail of the destination buffer.
+ *
+ * For full explanation of why you may want to consider using the
+ * 'strscpy' functions please see the function docstring for strscpy().
+ *
+ * Return: The number of characters copied (not including the trailing
+ * %NUL) or -E2BIG if the destination buffer wasn't big enough.
+ */
+ssize_t strscpy_pad(char *dest, const char *src, size_t count)
+{
+ ssize_t written;
+
+ written = strscpy(dest, src,
[PATCH v2 0/1] lib/string: Add strscpy_pad() function
Hi, This patch set was formerly Subject: [PATCH 0/6] lib: Add safe string funtions[sic] And FTR can be seen here: https://lkml.org/lkml/2019/2/18/1428 The v1 patch set has been reduced to a single patch by dropping the strscpy_from_user() stuff and by rolling all the docs changes into the main patch as suggested. This patch adds the function strscpy_pad() named after consensus was reached on the v1 email thread (linked to above). Thanks to Kees for the extreme test case coverage. test_basic() is probably redundant but is left in for the benefit of any poor sucker who has to debug a regression using test_fully(). The test module is _not_ tied into kselftest. As discussed on v1, there are some issues with tools/testing/selftest/lib/ at the moment. I intend on working on those issues as suggested but it does not seem totally relevant to this patch so instead of slowing this one down with my poor knowledge of how kselftest works it seems better to do this separately. thanks for looking at this, Tobin. Tobin C. Harding (1): lib/string: Add strscpy_pad() function include/linux/string.h | 4 + lib/Kconfig.debug | 3 + lib/Makefile | 1 + lib/string.c | 47 +-- lib/test_strscpy.c | 175 + 5 files changed, 223 insertions(+), 7 deletions(-) create mode 100644 lib/test_strscpy.c -- 2.20.1
Re: [PATCH RFC] mm/vmscan: try to protect active working set of cgroup from reclaim.
On Fri, Feb 22, 2019 at 08:58:25PM +0300, Andrey Ryabinin wrote: > In a presence of more than 1 memory cgroup in the system our reclaim > logic is just suck. When we hit memory limit (global or a limit on > cgroup with subgroups) we reclaim some memory from all cgroups. > This is sucks because, the cgroup that allocates more often always wins. > E.g. job that allocates a lot of clean rarely used page cache will push > out of memory other jobs with active relatively small all in memory > working set. > > To prevent such situations we have memcg controls like low/max, etc which > are supposed to protect jobs or limit them so they to not hurt others. > But memory cgroups are very hard to configure right because it requires > precise knowledge of the workload which may vary during the execution. > E.g. setting memory limit means that job won't be able to use all memory > in the system for page cache even if the rest the system is idle. > Basically our current scheme requires to configure every single cgroup > in the system. > > I think we can do better. The idea proposed by this patch is to reclaim > only inactive pages and only from cgroups that have big > (!inactive_is_low()) inactive list. And go back to shrinking active lists > only if all inactive lists are low. Hi Andrey! It's definitely an interesting idea! However, let me bring some concerns: 1) What's considered active and inactive depends on memory pressure inside a cgroup. Actually active pages in one cgroup (e.g. just deleted) can be colder than inactive pages in an other (e.g. a memory-hungry cgroup with a tight memory.max). Also a workload inside a cgroup can to some extend control what's going to the active LRU. So it opens a way to get more memory unfairly by artificially promoting more pages to the active LRU. So a cgroup can get an unfair advantage over other cgroups. Generally speaking, now we have a way to measure the memory pressure inside a cgroup. So, in theory, it should be possible to balance scanning effort based on memory pressure. Thanks!
Re: [PATCH v6 0/7] Support Trusted Foundations firmware on Tegra30
On Fri, Feb 22, 2019 at 10:34:19PM +0300, Dmitry Osipenko wrote: > Hello, > > This patchset adds support for the Trusted Foundations firmware on > NVIDIA Tegra30. Pretty much all of Tegra30 consumer devices have that > firmware and upstream kernel can't boot on those devices without the > firmware support. Hi Dmitry I've applied and tested this patchset on my TF300T. Boots and suspends/wakes using 'rtcwake -m mem -s 1 -d /dev/rtc1' as the test. dmesg attached. The exact tree used: git://rere.qmqm.pl/linux tf300t Feel free to add my Tested-by and Signed-off-by on the patches where apropriate, and thanks for your work! Best Regards, Michał Mirosław [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 5.0.0-rc8mq-00034-g83dcf8d77845 (mirq@qmqm) (gcc version 8.2.0 (Debian 8.2.0-20)) #16 SMP Mon Feb 25 04:45:43 CET 2019 [0.00] CPU: ARMv7 Processor [412fc099] revision 9 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: Asus Transformer Pad TF300T [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 32 MiB at 0xbbc0 [0.00] before early_ioremap_reset() [0.00] after early_ioremap_reset() [0.00] debug_ll_io_init() start [0.00] debug_ll_io_init() done [0.00] On node 0 totalpages: 261632 [0.00] Normal zone: 2300 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 261632 pages, LIFO batch:63 [0.00] after paging_init() [0.00] TF: version 2.8, protocol 6.0 [0.00] random: get_random_bytes called from start_kernel+0x90/0x478 with crng_init=0 [0.00] percpu: Embedded 17 pages/cpu @(ptrval) s37544 r8192 d23896 u69632 [0.00] pcpu-alloc: s37544 r8192 d23896 u69632 alloc=17*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 259332 [0.00] Kernel command line: clk_ignore_unused=1 console=tty0 console=ttyGS0 tegra_wdt.heartbeat=30 androidboot.serialno=015d15b4da27f206 no_console_suspend=1 gpt zswap.enabled=1 [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 973756K/1046528K available (6144K kernel code, 536K rwdata, 2156K rodata, 1024K init, 9165K bss, 40004K reserved, 32768K cma-reserved) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf000 - 0xff80 ( 248 MB) [0.00] lowmem : 0xb000 - 0xefe0 (1022 MB) [0.00] modules : 0xaf00 - 0xb000 ( 16 MB) [0.00] .text : 0x(ptrval) - 0x(ptrval) (7136 kB) [0.00] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) [0.00] .data : 0x(ptrval) - 0x(ptrval) ( 537 kB) [0.00].bss : 0x(ptrval) - 0x(ptrval) (9166 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] ftrace: allocating 21925 entries in 43 pages [0.00] rcu: Hierarchical RCU implementation. [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] /interrupt-controller@60004000: 160 interrupts forwarded to /interrupt-controller@50041000 [0.00] L2C: DT/platform modifies aux control register: 0x2c08 -> 0x3c480001 [0.00] L2C-310 erratum 769419 enabled [0.00] L2C-310 enabling early BRESP for Cortex-A9 [0.00] L2C-310: enabling full line of zeros but not enabled in Cortex-A9 [0.00] L2C-310 ID prefetch enabled, offset 1 lines [0.00] L2C-310 dynamic clock gating enabled, standby mode enabled [0.00] L2C-310 cache controller enabled, 8 ways, 1024 kB [0.00] L2C-310: CACHE_ID 0x41c7, AUX_CTRL 0x7e080001 [0.08] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns [0.28] clocksource: timer_us: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.58] Switching to timer-based delay loop, resolution 1000ns [0.000659] Console: colour dummy device 80x30 [0.002601] printk: console [tty0] enabled [0.002634] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.002686] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.002718] ... MAX_LOCK_DEPTH: 48 [0.002750] ... MAX_LOCKDEP_KEYS:8191 [0.002783] ... CLASSHASH_SIZE: 4096 [0.002815] ... MAX_LOCKDEP_ENTRIES: 32768 [0.002847] ... MAX_LOCKDEP_CHAINS: 65536 [0.002880] ... CHAINHASH_SIZE: 32768 [0.002912] memory used by lock dependency
Re: [v6 PATCH 6/6] RISC-V: Assign hwcap as per comman capabilities.
On Sat, Feb 23, 2019 at 1:11 AM Atish Patra wrote:
>
> Currently, we set hwcap based on first valid hart from DT. This may not
> be correct always as that hart might not be current booting cpu or may
> have a different capability.
>
> Set hwcap as the capabilities supported by all possible harts with "okay"
> status.
>
> Signed-off-by: Atish Patra
> ---
> arch/riscv/kernel/cpufeature.c | 41 ++---
> 1 file changed, 22 insertions(+), 19 deletions(-)
>
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index e7a4701f..bc29b010 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> unsigned long elf_hwcap __read_mostly;
> #ifdef CONFIG_FPU
> @@ -42,28 +43,30 @@ void riscv_fill_hwcap(void)
>
> elf_hwcap = 0;
>
> - /*
> -* We don't support running Linux on hertergenous ISA systems. For
> -* now, we just check the ISA of the first "okay" processor.
> -*/
> for_each_of_cpu_node(node) {
> - if (riscv_of_processor_hartid(node) >= 0)
> - break;
> - }
> - if (!node) {
> - pr_warn("Unable to find \"cpu\" devicetree entry\n");
> - return;
> - }
> + unsigned long this_hwcap = 0;
>
> - if (of_property_read_string(node, "riscv,isa", )) {
> - pr_warn("Unable to find \"riscv,isa\" devicetree entry\n");
> - of_node_put(node);
> - return;
> - }
> - of_node_put(node);
> + if (riscv_of_processor_hartid(node) < 0)
> + continue;
>
> - for (i = 0; i < strlen(isa); ++i)
> - elf_hwcap |= isa2hwcap[(unsigned char)(isa[i])];
> + if (of_property_read_string(node, "riscv,isa", )) {
> + pr_warn("Unable to find \"riscv,isa\" devicetree
> entry\n");
> + continue;
> + }
> +
> + for (i = 0; i < strlen(isa); ++i)
> + this_hwcap |= isa2hwcap[(unsigned char)(isa[i])];
> +
> + /*
> +* All "okay" hart should have same isa. Set HWCAP based on
> +* common capabilities of every "okay" hart, in case they
> don't
> +* have.
> +*/
> + if (elf_hwcap)
> + elf_hwcap &= this_hwcap;
> + else
> + elf_hwcap = this_hwcap;
> + }
>
> /* We don't support systems with F but without D, so mask those out
> * here. */
> --
> 2.7.4
>
Looks good to me.
Reviewed-by: Anup Patel
Regards,
Anup
[PATCH v2 2/9] power: supply: axp20x_usb_power: Fix typo in VBUS current limit macros
The VBUS current limit value macros have VBUS typed as VBUC, while
the bitmask macro is named correctly. Fix it.
Fixes: 69fb4dcada77 ("power: Add an axp20x-usb-power driver")
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index f52fe77edb6f..cd9b90d79839 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -36,10 +36,10 @@
#define AXP20X_VBUS_VHOLD_MASK GENMASK(5, 3)
#define AXP20X_VBUS_VHOLD_OFFSET 3
#define AXP20X_VBUS_CLIMIT_MASK3
-#define AXP20X_VBUC_CLIMIT_900mA 0
-#define AXP20X_VBUC_CLIMIT_500mA 1
-#define AXP20X_VBUC_CLIMIT_100mA 2
-#define AXP20X_VBUC_CLIMIT_NONE3
+#define AXP20X_VBUS_CLIMIT_900mA 0
+#define AXP20X_VBUS_CLIMIT_500mA 1
+#define AXP20X_VBUS_CLIMIT_100mA 2
+#define AXP20X_VBUS_CLIMIT_NONE3
#define AXP20X_ADC_EN1_VBUS_CURR BIT(2)
#define AXP20X_ADC_EN1_VBUS_VOLT BIT(3)
@@ -107,19 +107,19 @@ static int axp20x_usb_power_get_property(struct
power_supply *psy,
return ret;
switch (v & AXP20X_VBUS_CLIMIT_MASK) {
- case AXP20X_VBUC_CLIMIT_100mA:
+ case AXP20X_VBUS_CLIMIT_100mA:
if (power->axp20x_id == AXP221_ID)
val->intval = -1; /* No 100mA limit */
else
val->intval = 10;
break;
- case AXP20X_VBUC_CLIMIT_500mA:
+ case AXP20X_VBUS_CLIMIT_500mA:
val->intval = 50;
break;
- case AXP20X_VBUC_CLIMIT_900mA:
+ case AXP20X_VBUS_CLIMIT_900mA:
val->intval = 90;
break;
- case AXP20X_VBUC_CLIMIT_NONE:
+ case AXP20X_VBUS_CLIMIT_NONE:
val->intval = -1;
break;
}
--
2.20.1
[PATCH v2 4/9] power: supply: axp20x_usb_power: use polling to detect vbus status change
On AXP221 and later AXP PMICs that have the N_VBUSEN pin, when this pin
is high, either due to the PMIC driving it high or as an input, the VBUS
detection related interrupt mechanisms are disabled.
Previously this was worked around in the phy-sun4i-usb driver, which
needed to sense VBUS changes and report them to the musb driver in a
timely matter. However this workaround was only for the A31 and A33 type
USB PHYs. To support newer platforms we would have to enable it for
almost all the post-A31 SoCs.
However, since this is actually the result of the PMIC's behavior, the
workaround would be better if done in the PMIC driver, in this case the
VBUS power supply driver.
Add the same workqueue-based polling to the VBUS power supply driver.
The polling interval is chosen to be the debounce interval from the USB
PHY driver, as this short interval is needed in some cases, but the
power supply driver would not know when.
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 53 +
1 file changed, 53 insertions(+)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index e2f353906bb1..ac061bcdc056 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define DRVNAME "axp20x-usb-power-supply"
@@ -46,6 +47,12 @@
#define AXP20X_VBUS_MON_VBUS_VALID BIT(3)
+/*
+ * Note do not raise the debounce time, we must report Vusb high within
+ * 100ms otherwise we get Vbus errors in musb.
+ */
+#define DEBOUNCE_TIME msecs_to_jiffies(50)
+
struct axp20x_usb_power {
struct device_node *np;
struct regmap *regmap;
@@ -53,6 +60,8 @@ struct axp20x_usb_power {
enum axp20x_variants axp20x_id;
struct iio_channel *vbus_v;
struct iio_channel *vbus_i;
+ struct delayed_work vbus_detect;
+ unsigned int old_status;
};
static irqreturn_t axp20x_usb_power_irq(int irq, void *devid)
@@ -64,6 +73,35 @@ static irqreturn_t axp20x_usb_power_irq(int irq, void *devid)
return IRQ_HANDLED;
}
+static void axp20x_usb_power_poll_vbus(struct work_struct *work)
+{
+ struct axp20x_usb_power *power =
+ container_of(work, struct axp20x_usb_power, vbus_detect.work);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, );
+ if (ret)
+ goto out;
+
+ val &= (AXP20X_PWR_STATUS_VBUS_PRESENT | AXP20X_PWR_STATUS_VBUS_USED);
+ if (val != power->old_status)
+ power_supply_changed(power->supply);
+
+ power->old_status = val;
+
+out:
+ mod_delayed_work(system_wq, >vbus_detect, DEBOUNCE_TIME);
+}
+
+static bool axp20x_usb_vbus_needs_polling(struct axp20x_usb_power *power)
+{
+ if (power->axp20x_id >= AXP221_ID)
+ return true;
+
+ return false;
+}
+
static int axp20x_usb_power_get_property(struct power_supply *psy,
enum power_supply_property psp, union power_supply_propval *val)
{
@@ -362,6 +400,7 @@ static int axp20x_usb_power_probe(struct platform_device
*pdev)
if (!power)
return -ENOMEM;
+ platform_set_drvdata(pdev, power);
power->axp20x_id = (enum axp20x_variants)of_device_get_match_data(
>dev);
@@ -420,6 +459,19 @@ static int axp20x_usb_power_probe(struct platform_device
*pdev)
irq_names[i], ret);
}
+ INIT_DELAYED_WORK(>vbus_detect, axp20x_usb_power_poll_vbus);
+ if (axp20x_usb_vbus_needs_polling(power))
+ queue_delayed_work(system_wq, >vbus_detect, 0);
+
+ return 0;
+}
+
+static int axp20x_usb_power_remove(struct platform_device *pdev)
+{
+ struct axp20x_usb_power *power = platform_get_drvdata(pdev);
+
+ cancel_delayed_work_sync(>vbus_detect);
+
return 0;
}
@@ -439,6 +491,7 @@ MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
static struct platform_driver axp20x_usb_power_driver = {
.probe = axp20x_usb_power_probe,
+ .remove = axp20x_usb_power_remove,
.driver = {
.name = DRVNAME,
.of_match_table = axp20x_usb_power_match,
--
2.20.1
[PATCH v2 6/9] power: supply: axp20x_usb_power: add support for AXP813
From: Quentin Schulz
This adds support for AXP813 PMIC. It is almost the same as AXP22X but
has a different current limit.
Signed-off-by: Quentin Schulz
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 66 -
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index 90d06027bf98..d39c450b14c6 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -42,6 +42,11 @@
#define AXP20X_VBUS_CLIMIT_100mA 2
#define AXP20X_VBUS_CLIMIT_NONE3
+#define AXP813_VBUS_CLIMIT_900mA 0
+#define AXP813_VBUS_CLIMIT_1500mA 1
+#define AXP813_VBUS_CLIMIT_2000mA 2
+#define AXP813_VBUS_CLIMIT_2500mA 3
+
#define AXP20X_ADC_EN1_VBUS_CURR BIT(2)
#define AXP20X_ADC_EN1_VBUS_VOLT BIT(3)
@@ -131,6 +136,31 @@ static int axp20x_get_current_max(struct axp20x_usb_power
*power, int *val)
return 0;
}
+static int axp813_get_current_max(struct axp20x_usb_power *power, int *val)
+{
+ unsigned int v;
+ int ret = regmap_read(power->regmap, AXP20X_VBUS_IPSOUT_MGMT, );
+
+ if (ret)
+ return ret;
+
+ switch (v & AXP20X_VBUS_CLIMIT_MASK) {
+ case AXP813_VBUS_CLIMIT_900mA:
+ *val = 90;
+ break;
+ case AXP813_VBUS_CLIMIT_1500mA:
+ *val = 150;
+ break;
+ case AXP813_VBUS_CLIMIT_2000mA:
+ *val = 200;
+ break;
+ case AXP813_VBUS_CLIMIT_2500mA:
+ *val = 250;
+ break;
+ }
+ return 0;
+}
+
static int axp20x_usb_power_get_property(struct power_supply *psy,
enum power_supply_property psp, union power_supply_propval *val)
{
@@ -169,6 +199,8 @@ static int axp20x_usb_power_get_property(struct
power_supply *psy,
val->intval = ret * 1700; /* 1 step = 1.7 mV */
return 0;
case POWER_SUPPLY_PROP_CURRENT_MAX:
+ if (power->axp20x_id == AXP813_ID)
+ return axp813_get_current_max(power, >intval);
return axp20x_get_current_max(power, >intval);
case POWER_SUPPLY_PROP_CURRENT_NOW:
if (IS_ENABLED(CONFIG_AXP20X_ADC)) {
@@ -260,6 +292,31 @@ static int axp20x_usb_power_set_voltage_min(struct
axp20x_usb_power *power,
return -EINVAL;
}
+static int axp813_usb_power_set_current_max(struct axp20x_usb_power *power,
+ int intval)
+{
+ int val;
+
+ switch (intval) {
+ case 90:
+ return regmap_update_bits(power->regmap,
+ AXP20X_VBUS_IPSOUT_MGMT,
+ AXP20X_VBUS_CLIMIT_MASK,
+ AXP813_VBUS_CLIMIT_900mA);
+ case 150:
+ case 200:
+ case 250:
+ val = (intval - 100) / 50;
+ return regmap_update_bits(power->regmap,
+ AXP20X_VBUS_IPSOUT_MGMT,
+ AXP20X_VBUS_CLIMIT_MASK, val);
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
static int axp20x_usb_power_set_current_max(struct axp20x_usb_power *power,
int intval)
{
@@ -299,6 +356,9 @@ static int axp20x_usb_power_set_property(struct
power_supply *psy,
return axp20x_usb_power_set_voltage_min(power, val->intval);
case POWER_SUPPLY_PROP_CURRENT_MAX:
+ if (power->axp20x_id == AXP813_ID)
+ return axp813_usb_power_set_current_max(power,
+ val->intval);
return axp20x_usb_power_set_current_max(power, val->intval);
default:
@@ -434,7 +494,8 @@ static int axp20x_usb_power_probe(struct platform_device
*pdev)
usb_power_desc = _usb_power_desc;
irq_names = axp20x_irq_names;
} else if (power->axp20x_id == AXP221_ID ||
- power->axp20x_id == AXP223_ID) {
+ power->axp20x_id == AXP223_ID ||
+ power->axp20x_id == AXP813_ID) {
usb_power_desc = _usb_power_desc;
irq_names = axp22x_irq_names;
} else {
@@ -493,6 +554,9 @@ static const struct of_device_id axp20x_usb_power_match[] =
{
}, {
.compatible = "x-powers,axp223-usb-power-supply",
.data = (void *)AXP223_ID,
+ }, {
+ .compatible = "x-powers,axp813-usb-power-supply",
+ .data = (void *)AXP813_ID,
}, { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
--
2.20.1
[PATCH v2 7/9] mfd: axp20x: add USB power supply mfd cell to AXP813
From: Quentin Schulz
The AXP813 has a VBUS power input. Now that the axp20x_usb_power driver
supports this variant, we can add an mfd cell for it to use it.
Signed-off-by: Quentin Schulz
[w...@csie.org: add commit message]
Acked-for-MFD-by: Lee Jones
Signed-off-by: Chen-Yu Tsai
---
Changes since v1:
- Made axp803_usb_power_supply_resources[] constant
- Added Lee's acked-by
---
drivers/mfd/axp20x.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 3c97f2c0fdfe..902f9f27e748 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -198,6 +198,12 @@ static const struct resource
axp22x_usb_power_supply_resources[] = {
DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_VBUS_REMOVAL, "VBUS_REMOVAL"),
};
+/* AXP803 and AXP813/AXP818 share the same interrupts */
+static const struct resource axp803_usb_power_supply_resources[] = {
+ DEFINE_RES_IRQ_NAMED(AXP803_IRQ_VBUS_PLUGIN, "VBUS_PLUGIN"),
+ DEFINE_RES_IRQ_NAMED(AXP803_IRQ_VBUS_REMOVAL, "VBUS_REMOVAL"),
+};
+
static const struct resource axp22x_pek_resources[] = {
DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_PEK_RIS_EDGE, "PEK_DBR"),
DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_PEK_FAL_EDGE, "PEK_DBF"),
@@ -793,6 +799,11 @@ static const struct mfd_cell axp813_cells[] = {
.of_compatible = "x-powers,axp813-ac-power-supply",
.num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
.resources = axp20x_ac_power_supply_resources,
+ }, {
+ .name = "axp20x-usb-power-supply",
+ .num_resources = ARRAY_SIZE(axp803_usb_power_supply_resources),
+ .resources = axp803_usb_power_supply_resources,
+ .of_compatible = "x-powers,axp813-usb-power-supply",
},
};
--
2.20.1
[PATCH v2 1/9] dt-bindings: power: supply: axp20x_usb_power: add axp813 compatible
This adds the "x-powers,axp813-usb-power-supply" to the list of compatibles for AXP20X VBUS power supply driver. Signed-off-by: Chen-Yu Tsai --- .../devicetree/bindings/power/supply/axp20x_usb_power.txt| 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt index ba8d35f66cbe..b2d4968fde7d 100644 --- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt +++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt @@ -4,6 +4,7 @@ Required Properties: -compatible: One of: "x-powers,axp202-usb-power-supply" "x-powers,axp221-usb-power-supply" "x-powers,axp223-usb-power-supply" +"x-powers,axp813-usb-power-supply" The AXP223 PMIC shares most of its behaviour with the AXP221 but has slight variations such as the former being able to set the VBUS power supply max -- 2.20.1
[PATCH v2 8/9] ARM: dtsi: axp81x: add USB power supply node
From: Quentin Schulz
The AXP813/818 has a VBUS power input. Add a device node for it, now
that we support it.
Signed-off-by: Quentin Schulz
[w...@csie.org: Add commit message]
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/axp81x.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/axp81x.dtsi
index bd83962d3627..1dfeeceabf4c 100644
--- a/arch/arm/boot/dts/axp81x.dtsi
+++ b/arch/arm/boot/dts/axp81x.dtsi
@@ -171,4 +171,8 @@
status = "disabled";
};
};
+
+ usb_power_supply: usb-power-supply {
+ compatible = "x-powers,axp813-usb-power-supply";
+ };
};
--
2.20.1
[PATCH v2 0/9] ARM: sun8i: a83t: Enable USB OTG
Hi everyone, This is v2 of my A83T USB power supply / OTG series. Changes since v1: - Added Lee's ack for mfd patch - Make axp803_usb_power_supply_resources[] const This series has since been tested. Both host mode and gadget mode work well. However this SoC seems to have a glitch in hardware. After host mode is used by plugging in a host mode cable, the hardware will not revert back to gadget mode if a standard USB cable is plugged in. Host mode continues to work however. This will likely have to be addressed with some workaround in either the musb driver or our USB PHY driver. The patches have no cross-tree dependencies, so each part can go through their respective trees (power-supply / mfd / arm-soc). I also have some follow-up patches to enable the USB power supply on AXP803 / A64. It's the boiler-plate mfd cell and device node addition. Original cover letter follows: This series enables USB OTG on the A83T boards. The AXP813/AXP818 PMICs used with the A83T have the same behavior as the AXP221 and AXP223, where if the N_VBUSEN pin is driven high, the VBUS sensing interrupts stop working. In the past Hans made a polling workaround in the USB PHY driver. In this series polling is added to the power supply driver. The power supply driver work was started by Quentin, and shared with me when I expressed interest in getting USB OTG to work some time ago. Neither of us got around to finishing it, until now that is. Patch 1 adds a new compatible string for the AXP813 VBUS power supply part. Patch 2 is a bit of cleanup work for the driver. Patch 3 allows disabling VBUS input current limiting on the AXP20x / AXP22x PMICs. While not strictly related to this series, I found it easier to just send everything together. This patch depends on the previous one. Patch 4 adds the VBUS status polling feature. This is enabled on AXP221 and all later PMICs. Patch 5 factors out code to read out the configured input current limit for the AXP20x and AXP22x PMICs. As the AXP813 uses different values, factoring out the code based on model will make the main function more readable. Patch 6 adds support for the AXP813 VBUS power supply. checkpatch.pl reports a few warnings for this patch: WARNING: Possible switch case/default not preceded by break or fallthrough comment #100: FILE: drivers/power/supply/axp20x_usb_power.c:306: + case 150: WARNING: Possible switch case/default not preceded by break or fallthrough comment #101: FILE: drivers/power/supply/axp20x_usb_power.c:307: + case 200: WARNING: Possible switch case/default not preceded by break or fallthrough comment #102: FILE: drivers/power/supply/axp20x_usb_power.c:308: + case 250: However they seem to be a false positive. The preceding line of the reported lines is a return statement, which is definitely not a fallthrough. Patch 7 adds an mfd cell for the newly supported VBUS power supply. Patch 8 adds a device node for the VBUS power supply to the common axp81x dtsi file. Patch 9 enables USB OTG on the Cubietruck Plus and Bananapi M3. Please have a look, and also test it on boards you have, and don't limit it to just the A83T ones. As mentioned above, the polling feature affects all boards that have an AXP221 or newer PMIC. I haven't removed the polling workaround from the USB PHY driver yet. That would be the next step after this series is merged, and preferrably a release has passed. Regards ChenYu Chen-Yu Tsai (5): dt-bindings: power: supply: axp20x_usb_power: add axp813 compatible power: supply: axp20x_usb_power: Fix typo in VBUS current limit macros power: supply: axp20x_usb_power: allow disabling input current limiting power: supply: axp20x_usb_power: use polling to detect vbus status change ARM: dts: sun8i: a83t: Enable USB OTG controller on some boards Quentin Schulz (4): power: supply: axp20x_usb_power: add function to get max current power: supply: axp20x_usb_power: add support for AXP813 mfd: axp20x: add USB power supply mfd cell to AXP813 ARM: dtsi: axp81x: add USB power supply node .../power/supply/axp20x_usb_power.txt | 1 + arch/arm/boot/dts/axp81x.dtsi | 4 + arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 12 ++ .../boot/dts/sun8i-a83t-cubietruck-plus.dts | 12 ++ drivers/mfd/axp20x.c | 11 ++ drivers/power/supply/axp20x_usb_power.c | 184 +++--- 6 files changed, 197 insertions(+), 27 deletions(-) -- 2.20.1
[PATCH v2 5/9] power: supply: axp20x_usb_power: add function to get max current
From: Quentin Schulz
To prepare for a new PMIC, factor out the code responsible of returning
the maximum current to axp20x_get_current_max.
Signed-off-by: Quentin Schulz
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 52 ++---
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index ac061bcdc056..90d06027bf98 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -102,6 +102,35 @@ static bool axp20x_usb_vbus_needs_polling(struct
axp20x_usb_power *power)
return false;
}
+static int axp20x_get_current_max(struct axp20x_usb_power *power, int *val)
+{
+ unsigned int v;
+ int ret = regmap_read(power->regmap, AXP20X_VBUS_IPSOUT_MGMT, );
+
+ if (ret)
+ return ret;
+
+ switch (v & AXP20X_VBUS_CLIMIT_MASK) {
+ case AXP20X_VBUS_CLIMIT_100mA:
+ if (power->axp20x_id == AXP221_ID)
+ *val = -1; /* No 100mA limit */
+ else
+ *val = 10;
+ break;
+ case AXP20X_VBUS_CLIMIT_500mA:
+ *val = 50;
+ break;
+ case AXP20X_VBUS_CLIMIT_900mA:
+ *val = 90;
+ break;
+ case AXP20X_VBUS_CLIMIT_NONE:
+ *val = -1;
+ break;
+ }
+
+ return 0;
+}
+
static int axp20x_usb_power_get_property(struct power_supply *psy,
enum power_supply_property psp, union power_supply_propval *val)
{
@@ -140,28 +169,7 @@ static int axp20x_usb_power_get_property(struct
power_supply *psy,
val->intval = ret * 1700; /* 1 step = 1.7 mV */
return 0;
case POWER_SUPPLY_PROP_CURRENT_MAX:
- ret = regmap_read(power->regmap, AXP20X_VBUS_IPSOUT_MGMT, );
- if (ret)
- return ret;
-
- switch (v & AXP20X_VBUS_CLIMIT_MASK) {
- case AXP20X_VBUS_CLIMIT_100mA:
- if (power->axp20x_id == AXP221_ID)
- val->intval = -1; /* No 100mA limit */
- else
- val->intval = 10;
- break;
- case AXP20X_VBUS_CLIMIT_500mA:
- val->intval = 50;
- break;
- case AXP20X_VBUS_CLIMIT_900mA:
- val->intval = 90;
- break;
- case AXP20X_VBUS_CLIMIT_NONE:
- val->intval = -1;
- break;
- }
- return 0;
+ return axp20x_get_current_max(power, >intval);
case POWER_SUPPLY_PROP_CURRENT_NOW:
if (IS_ENABLED(CONFIG_AXP20X_ADC)) {
ret = iio_read_channel_processed(power->vbus_i,
--
2.20.1
[PATCH v2 9/9] ARM: dts: sun8i: a83t: Enable USB OTG controller on some boards
The Bananapi M3 and Cubietruck Plus both have USB OTG ports wired to the
SoC and PMIC in the same way, with the N_VBUSEN pin on the PMIC
controlling VBUS output, the PMIC's VBUS input for sensing VBUS, and
PH11 on the SoC for sensing the ID pin.
Enable OTG on both boards.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 12
arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 12
2 files changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 838be7b3715f..9d34eabba121 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -389,7 +389,19 @@
};
};
+_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+_power_supply {
+ status = "okay";
+};
+
{
+ usb0_id_det-gpios = < 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
+ usb0_vbus_power-supply = <_power_supply>;
+ usb0_vbus-supply = <_drivevbus>;
usb1_vbus-supply = <_usb1_vbus>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
index fcbec3d7ccd7..ea299d3d84d0 100644
--- a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
@@ -420,7 +420,19 @@
};
};
+_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+_power_supply {
+ status = "okay";
+};
+
{
+ usb0_id_det-gpios = < 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
+ usb0_vbus_power-supply = <_power_supply>;
+ usb0_vbus-supply = <_drivevbus>;
usb1_vbus-supply = <_usb1_vbus>;
usb2_vbus-supply = <_usb2_vbus>;
status = "okay";
--
2.20.1
[PATCH v2 3/9] power: supply: axp20x_usb_power: allow disabling input current limiting
The AXP PMICs allow the user to disable current limiting on the VBUS input. While read-out of this setting was already supported by the driver, it did not allow the user to configure the PMIC to disable current limiting. Add support for this. Signed-off-by: Chen-Yu Tsai --- drivers/power/supply/axp20x_usb_power.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c index cd9b90d79839..e2f353906bb1 100644 --- a/drivers/power/supply/axp20x_usb_power.c +++ b/drivers/power/supply/axp20x_usb_power.c @@ -230,6 +230,11 @@ static int axp20x_usb_power_set_current_max(struct axp20x_usb_power *power, return regmap_update_bits(power->regmap, AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_CLIMIT_MASK, val); + case -1: + return regmap_update_bits(power->regmap, + AXP20X_VBUS_IPSOUT_MGMT, + AXP20X_VBUS_CLIMIT_MASK, + AXP20X_VBUS_CLIMIT_NONE); default: return -EINVAL; } -- 2.20.1
Re: [PATCH] sched/debug: Show intergroup and hierarchy sum wait time of a task group
PING
禹舟键 于2019年2月19日周二 上午10:15写道：
>
> PING
>
> 禹舟键 于2019年2月12日周二 上午11:14写道：
> >
> > Hi, Peter
> > I think hierarchy wait time for task groups is worth accounting
> > despite with a little extra overhead. Because we can evaluate task
> > groups' condition with a more direct metric. We cannot get the real
> > situation just with some general metrics, like idle or loadavg, since
> > their value is decreased with the elapse of time. So, I think general
> > metrics cannot satisify the request for task groups.
> >
> > Thanks
> > Yuzhoujian
> >
> >
> > Peter Zijlstra 于2019年2月7日周四 上午1:19写道：
> > >
> > > On Wed, Jan 23, 2019 at 05:46:56PM +0800, ufo19890...@gmail.com wrote:
> > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > > index e2ff4b6..35e89ca 100644
> > > > --- a/kernel/sched/fair.c
> > > > +++ b/kernel/sched/fair.c
> > > > @@ -858,6 +858,19 @@ static void update_curr_fair(struct rq *rq)
> > > > }
> > > >
> > > > static inline void
> > > > +update_hierarchy_wait_sum(struct sched_entity *se,
> > > > + u64 delta_wait)
> > > > +{
> > > > + for_each_sched_entity(se) {
> > > > + struct cfs_rq *cfs_rq = cfs_rq_of(se);
> > > > +
> > > > + if (cfs_rq->tg != _task_group)
> > > > + __schedstat_add(cfs_rq->hierarchy_wait_sum,
> > > > + delta_wait);
> > > > + }
> > > > +}
> > > > +
> > > > +static inline void
> > > > update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se)
> > > > {
> > > > struct task_struct *p;
> > > > @@ -880,6 +893,7 @@ static void update_curr_fair(struct rq *rq)
> > > > return;
> > > > }
> > > > trace_sched_stat_wait(p, delta);
> > > > + update_hierarchy_wait_sum(se, delta);
> > > > }
> > > >
> > > > __schedstat_set(se->statistics.wait_max,
> > >
> > > The problem I have with this is that it will make schedstats even more
> > > expensive :/
Re: [PATCH v4] mm/hugetlb: Fix unsigned overflow in __nr_hugepages_store_common()
On Sun, 24 Feb 2019, Mike Kravetz wrote: > > User can change a node specific hugetlb count. i.e. > > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages > > the calculated value of count is a total number of huge pages. It could > > be overflow when a user entering a crazy high value. If so, the total > > number of huge pages could be a small value which is not user expect. > > We can simply fix it by setting count to ULONG_MAX, then it goes on. This > > may be more in line with user's intention of allocating as many huge pages > > as possible. > > > > Signed-off-by: Jing Xiangfeng > > Thank you. > > Acked-by: Mike Kravetz > > > --- > > mm/hugetlb.c | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > index afef616..6688894 100644 > > --- a/mm/hugetlb.c > > +++ b/mm/hugetlb.c > > @@ -2423,7 +2423,14 @@ static ssize_t __nr_hugepages_store_common(bool > > obey_mempolicy, > > * per node hstate attribute: adjust count to global, > > * but restrict alloc/free to the specified node. > > */ > > + unsigned long old_count = count; > > count += h->nr_huge_pages - h->nr_huge_pages_node[nid]; > > + /* > > +* If user specified count causes overflow, set to > > +* largest possible value. > > +*/ > > + if (count < old_count) > > + count = ULONG_MAX; > > init_nodemask_of_node(nodes_allowed, nid); > > } else > > nodes_allowed = _states[N_MEMORY]; > > Looks like this fixes the overflow issue, but isn't there already a possible underflow since we don't hold hugetlb_lock? Even if count == 0, what prevents h->nr_huge_pages_node[nid] being greater than h->nr_huge_pages here? I think the per hstate values need to be read with READ_ONCE() and stored on the stack to do any sane bounds checking.
[PATCH] time64: Avoid undefined behaviour in timespec64_add()
I ran into this:
=
UBSAN: Undefined behaviour in ./include/linux/time64.h:70:2
signed integer overflow:
1551059291 + 9223372036854775807 cannot be represented in type 'long
long int'
CPU: 5 PID: 20064 Comm: syz-executor.2 Not tainted 4.19.24 #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
ubsan_epilogue+0xe/0x81 lib/ubsan.c:159
handle_overflow+0x193/0x1e2 lib/ubsan.c:190
timespec64_add include/linux/time64.h:70 [inline]
timekeeping_inject_offset+0x3ed/0x4e0 kernel/time/timekeeping.c:1301
do_adjtimex+0x1e5/0x6c0 kernel/time/timekeeping.c:2360
__do_sys_clock_adjtime+0x122/0x200 kernel/time/posix-timers.c:1086
do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462eb9
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89
f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:7f888aa2dc58 EFLAGS: 0246 ORIG_RAX: 0131
RAX: ffda RBX: 0073bf00 RCX: 00462eb9
RDX: RSI: 23c0 RDI:
RBP: 0002 R08: R09:
R10: R11: 0246 R12: 7f888aa2e6bc
R13: 004bcae8 R14: 006f6868 R15:
==
Since lhs.tv_sec and rhs.tv_sec are both time64_t, this is a signed
addition which will cause undefined behaviour on overflow.
The easiest way to avoid the overflow is to cast one of the arguments to
unsigned (so the addition will be done using unsigned arithmetic).
This patch doesn't change generated code.
Signed-off-by: Hongbo Yao
---
include/linux/time64.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/time64.h b/include/linux/time64.h
index 05634afba0db..5926bdd4167f 100644
--- a/include/linux/time64.h
+++ b/include/linux/time64.h
@@ -67,7 +67,7 @@ static inline struct timespec64 timespec64_add(struct
timespec64 lhs,
struct timespec64 rhs)
{
struct timespec64 ts_delta;
- set_normalized_timespec64(_delta, lhs.tv_sec + rhs.tv_sec,
+ set_normalized_timespec64(_delta, (timeu64_t)lhs.tv_sec + rhs.tv_sec,
lhs.tv_nsec + rhs.tv_nsec);
return ts_delta;
}
--
2.20.1
[PATCH] arm64: dts: ls1088a: add one more thermal zone node
Ls1088a has 2 thermal sensors. This patch adds the second node
to dts to enable it.
Signed-off-by: Yuantian Tang
---
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 43 +--
1 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 661137f..9f52bc9 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -129,19 +129,19 @@
};
thermal-zones {
- cpu_thermal: cpu-thermal {
+ ccu {
polling-delay-passive = <1000>;
polling-delay = <5000>;
thermal-sensors = < 0>;
trips {
- cpu_alert: cpu-alert {
+ ccu_alert: ccu-alert {
temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
- cpu_crit: cpu-crit {
+ ccu_crit: ccu-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -150,7 +150,42 @@
cooling-maps {
map0 {
- trip = <_alert>;
+ trip = <_alert>;
+ cooling-device =
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
+ < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ plt {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+ thermal-sensors = < 1>;
+
+ trips {
+ plt_alert: plt-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ plt_crit: plt-crit {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <_alert>;
cooling-device =
< THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
< THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>,
--
1.7.1
[PATCH 1/1] iommu/vt-d: Check identity map for hot-added devices
The Intel IOMMU driver will put devices into a static identity
mapped domain during boot if the kernel parameter "iommu=pt" is
used. That means the IOMMU hardware will translate a DMA address
into the same memory address.
Unfortunately, hot-added devices are not subject to this. That
results in some devices not working properly after hot added. A
quick way to reproduce this issue is to boot a system with
iommu=pt
and, remove then readd the pci device with
echo 1 > /sys/bus/pci/devices/[pci_source_id]/remove
echo 1 > /sys/bus/pci/rescan
You will find the identity mapped domain was replaced with a
normal domain.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Fenghua Yu
Cc: sta...@vger.kernel.org
Reported-by: Jis Ben
Signed-off-by: Lu Baolu
Tested-by: James Dong
---
drivers/iommu/intel-iommu.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index af23cfc2a05e..4f77657a9c25 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4564,16 +4564,19 @@ static int device_notifier(struct notifier_block *nb,
if (iommu_dummy(dev))
return 0;
- if (action != BUS_NOTIFY_REMOVED_DEVICE)
- return 0;
-
- domain = find_domain(dev);
- if (!domain)
- return 0;
+ if (action == BUS_NOTIFY_REMOVED_DEVICE) {
+ domain = find_domain(dev);
+ if (!domain)
+ return 0;
- dmar_remove_one_dev_info(dev);
- if (!domain_type_is_vm_or_si(domain) && list_empty(>devices))
- domain_exit(domain);
+ dmar_remove_one_dev_info(dev);
+ if (!domain_type_is_vm_or_si(domain) &&
+ list_empty(>devices))
+ domain_exit(domain);
+ } else if (action == BUS_NOTIFY_ADD_DEVICE) {
+ if (iommu_should_identity_map(dev, 1))
+ domain_add_dev_info(si_domain, dev);
+ }
return 0;
}
--
2.17.1
Re: [PATCH v2] perf record: Add support for limit perf output file size
Hi Arnaldo,
On 02/22/2019 10:53 PM, Arnaldo Carvalho de Melo wrote:
> Em Fri, Feb 22, 2019 at 03:19:04PM +0800, Jiwei Sun escreveu:
>> The patch adds a new option to limit the output file size, then based
>> on it, we can create a wrapper of the perf command that uses the option
>> to avoid exhausting the disk space by the unconscious user.
>>
>> Signed-off-by: Jiwei Sun
>> ---
>> v2 changes:
>
> Please do a v3 adding this new option to
> tools/perf/Documentation/perf-record.txt
>
> Please also rename it to --max-size-output, because then we coudl use:
>
> perf record --max-size-output
>
> or:
>
> perf record --max-size
>
> or even:
>
> perf record --max saving typing :-)
>
> Also please show it in use, i.e. the output of it working.
Thanks for your advice, I will modify the patch and send a v3.
Thanks,
Regards,
Jiwei
>
>
> - Arnaldo
>
>> - make patch based on latest Arnaldo's perf/core,
>> - display warning message when reached the limit.
>> ---
>> tools/perf/builtin-record.c | 42 +
>> 1 file changed, 42 insertions(+)
>>
>> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
>> index 6c3719ac901d..dc3648c0816d 100644
>> --- a/tools/perf/builtin-record.c
>> +++ b/tools/perf/builtin-record.c
>> @@ -83,6 +83,7 @@ struct record {
>> struct switch_outputswitch_output;
>> unsigned long long samples;
>> cpu_set_t affinity_mask;
>> +unsigned long output_max_size;/* = 0: unlimited */
>> };
>>
>> static volatile int auxtrace_record__snapshot_started;
>> @@ -112,6 +113,12 @@ static bool switch_output_time(struct record *rec)
>> trigger_is_ready(_output_trigger);
>> }
>>
>> +static bool record__output_max_size_exceeded(struct record *rec)
>> +{
>> +return (rec->output_max_size &&
>> + rec->bytes_written >= rec->output_max_size);
>> +}
>> +
>> static int record__write(struct record *rec, struct perf_mmap *map
>> __maybe_unused,
>> void *bf, size_t size)
>> {
>> @@ -124,6 +131,12 @@ static int record__write(struct record *rec, struct
>> perf_mmap *map __maybe_unuse
>>
>> rec->bytes_written += size;
>>
>> +if (record__output_max_size_exceeded(rec)) {
>> +pr_warning("WARNING: The perf data has already reached "
>> + "the limit, stop recording!\n");
>> +raise(SIGTERM);
>> +}
>> +
>> if (switch_output_size(rec))
>> trigger_hit(_output_trigger);
>>
>> @@ -1671,6 +1684,33 @@ static int record__parse_affinity(const struct option
>> *opt, const char *str, int
>> return 0;
>> }
>>
>> +static int parse_output_max_size(const struct option *opt,
>> + const char *str, int unset)
>> +{
>> +unsigned long *s = (unsigned long *)opt->value;
>> +static struct parse_tag tags_size[] = {
>> +{ .tag = 'B', .mult = 1 },
>> +{ .tag = 'K', .mult = 1 << 10 },
>> +{ .tag = 'M', .mult = 1 << 20 },
>> +{ .tag = 'G', .mult = 1 << 30 },
>> +{ .tag = 0 },
>> +};
>> +unsigned long val;
>> +
>> +if (unset) {
>> +*s = 0;
>> +return 0;
>> +}
>> +
>> +val = parse_tag_value(str, tags_size);
>> +if (val != (unsigned long) -1) {
>> +*s = val;
>> +return 0;
>> +}
>> +
>> +return -1;
>> +}
>> +
>> static int record__parse_mmap_pages(const struct option *opt,
>> const char *str,
>> int unset __maybe_unused)
>> @@ -1982,6 +2022,8 @@ static struct option __record_options[] = {
>> OPT_CALLBACK(0, "affinity", , "node|cpu",
>> "Set affinity mask of trace reading thread to NUMA node
>> cpu mask or cpu of processed mmap buffer",
>> record__parse_affinity),
>> +OPT_CALLBACK(0, "output-max-size", _max_size,
>> + "size", "Output file maximum size", parse_output_max_size),
>> OPT_END()
>> };
>>
>> --
>> 2.20.1
>
Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault
On Sun, 24 Feb 2019 09:26:45 -0800
Linus Torvalds wrote:
> On Sun, Feb 24, 2019 at 7:18 AM Masami Hiramatsu wrote:
> >
> > On Sat, 23 Feb 2019 20:38:03 -0800
> > Andy Lutomirski wrote:
> > >
> > > Can we just get rid of this might_sleep()? access_ok() doesn't sleep
> > > as far as I know.
> >
> > Hmm, which might_sleep() would you pointed? What I talked was a
> > WARN_ON_ONCE(!in_task()) in access_ok() on x86 (only!), and in_task() just
> > checks preempt_count.
>
> So the in_task() check does kind of make sense. Using "access_ok()"
> outside of task context is certainly an odd thing, for several
> reasons. The main one being simply that outside of task context, the
> whole "which task" question is open, and you don't know if the task is
> the active one, and so it's not clear if whatever task you interrupt
> might have done "set_fs()" or not.
Ah I got it. Usual case access_ok() in IRQ handler is strange.
>
> So PeterZ isn't wrong:
>
> > I guess PeterZ assumed that access_ok() is used only with user space access
> > APIs (e.g. copy_from_user) which can cause page-fault and locks mm (and
> > might
> > sleep :)), but now we are trying to use access_ok() with new functions which
> > disables page-fault and just return -EFAULT.
>
> .. but in this case, if we do it all *within* code that saves and
> restores the user access flag with get_fs/set_fs, access_ok() would be
> ok and it doesn't have the above issue.
>
> So access_ok() in _general_ is absolutely not safe to do from
> interrupts, but within the context of probing user memory from a
> tracing event it just happens to be ok.
Hmm, but user can specify user-memory access from the tracing event
which is located in interrupt handler. So I understand that it is safe
only if we correctly setup access flag with get_fs/set_fs, is that
correct?
> It would be lovely to have a special macro for this, and keep the
> warning for the general case, but because this is a "every
> architecture needs to build their own" it's probably too painful.
Agreed.
>
> PeterZ, do you remember the particular use case that triggered that
> commit 7c4788950ba5 ("x86/uaccess, sched/preempt: Verify access_ok()
> context")?
>
> Linus
Thank you,
--
Masami Hiramatsu
[PATCH net-next] switchdev: Complete removal of switchdev_port_attr_get()
We have no more in tree users of switchdev_port_attr_get() after
d0e698d57a94 ("Merge branch 'net-Get-rid-of-switchdev_port_attr_get'")
so completely remove the function signature and body.
Signed-off-by: Florian Fainelli
---
include/net/switchdev.h | 4
net/switchdev/switchdev.c | 42 ---
2 files changed, 46 deletions(-)
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index 45310ddf2d7e..be4b13e8 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -115,13 +115,9 @@ typedef int switchdev_obj_dump_cb_t(struct switchdev_obj
*obj);
/**
* struct switchdev_ops - switchdev operations
*
- * @switchdev_port_attr_get: Get a port attribute (see switchdev_attr).
- *
* @switchdev_port_attr_set: Set a port attribute (see switchdev_attr).
*/
struct switchdev_ops {
- int (*switchdev_port_attr_get)(struct net_device *dev,
- struct switchdev_attr *attr);
int (*switchdev_port_attr_set)(struct net_device *dev,
const struct switchdev_attr *attr,
struct switchdev_trans *trans);
diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
index 7e1357db33d7..362413c9b389 100644
--- a/net/switchdev/switchdev.c
+++ b/net/switchdev/switchdev.c
@@ -174,48 +174,6 @@ static int switchdev_deferred_enqueue(struct net_device
*dev,
return 0;
}
-/**
- * switchdev_port_attr_get - Get port attribute
- *
- * @dev: port device
- * @attr: attribute to get
- */
-int switchdev_port_attr_get(struct net_device *dev, struct switchdev_attr
*attr)
-{
- const struct switchdev_ops *ops = dev->switchdev_ops;
- struct net_device *lower_dev;
- struct list_head *iter;
- struct switchdev_attr first = {
- .id = SWITCHDEV_ATTR_ID_UNDEFINED
- };
- int err = -EOPNOTSUPP;
-
- if (ops && ops->switchdev_port_attr_get)
- return ops->switchdev_port_attr_get(dev, attr);
-
- if (attr->flags & SWITCHDEV_F_NO_RECURSE)
- return err;
-
- /* Switch device port(s) may be stacked under
-* bond/team/vlan dev, so recurse down to get attr on
-* each port. Return -ENODATA if attr values don't
-* compare across ports.
-*/
-
- netdev_for_each_lower_dev(dev, lower_dev, iter) {
- err = switchdev_port_attr_get(lower_dev, attr);
- if (err)
- break;
- if (first.id == SWITCHDEV_ATTR_ID_UNDEFINED)
- first = *attr;
- else if (memcmp(, attr, sizeof(*attr)))
- return -ENODATA;
- }
-
- return err;
-}
-EXPORT_SYMBOL_GPL(switchdev_port_attr_get);
-
static int __switchdev_port_attr_set(struct net_device *dev,
const struct switchdev_attr *attr,
struct switchdev_trans *trans)
--
2.19.1
Re: [PATCH 1/3] net: ethernet: add support for PCS and 2.5G speed
Le 2/22/19 à 12:12 PM, Parshuram Thombare a écrit :
> This patch add support for PCS (for SGMII interface) and 2.5Gbps MAC
> in Cadence ethernet controller driver.
At a high level you don't seem to be making use of PHYLINK so which
2.5Gbps interfaces do you actually support?
>
> Signed-off-by: Parshuram Thombare
> ---
[snip]
> @@ -361,26 +361,50 @@ static int macb_mdio_write(struct mii_bus *bus, int
> mii_id, int regnum,
> * macb_set_tx_clk() - Set a clock to a new frequency
> * @clk Pointer to the clock to change
> * @rate New frequency in Hz
> + * @interafcePhy interface
Typo: @interface and this is an unrelated change.
> * @dev Pointer to the struct net_device
> */
> -static void macb_set_tx_clk(struct clk *clk, int speed, struct net_device
> *dev)
> +static void macb_set_tx_clk(struct clk *clk, int speed,
> + phy_interface_t interface, struct net_device *dev)
> {
> long ferr, rate, rate_rounded;
>
> if (!clk)
> return;
>
> - switch (speed) {
> - case SPEED_10:
> + if (interface == PHY_INTERFACE_MODE_GMII ||
> + interface == PHY_INTERFACE_MODE_MII) {
> + switch (speed) {
> + case SPEED_10:> rate = 250;
You need to add one tab to align rate and break.
> break;
> - case SPEED_100:
> + case SPEED_100:
> rate = 2500;
> break;
> - case SPEED_1000:
> + case SPEED_1000:
> rate = 12500;
> break;
> - default:
> + default:
> + return;
> + }
> + } else if (interface == PHY_INTERFACE_MODE_SGMII) {
> + switch (speed) {
> + case SPEED_10:
> + rate = 125;
> + break;
> + case SPEED_100:
> + rate = 1250;
> + break;
> + case SPEED_1000:
> + rate = 12500;
> + break;
> + case SPEED_2500:
> + rate = 31250;
> + break;
> + default:
> + return;
The indentation is broken here and you can greatly simplify this with a
simple function that returns speed * 1250 and does an initial check for
unsupported speeds.
> + }
> + } else {
> return;
> }
>
> @@ -410,30 +434,49 @@ static void macb_handle_link_change(struct net_device
> *dev)
>
> spin_lock_irqsave(>lock, flags);
>
> - if (phydev->link) {
> - if ((bp->speed != phydev->speed) ||
> - (bp->duplex != phydev->duplex)) {
> - u32 reg;
> -
> - reg = macb_readl(bp, NCFGR);
> - reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
> - if (macb_is_gem(bp))
> - reg &= ~GEM_BIT(GBE);
> + if (phydev->link && (bp->speed != phydev->speed ||
> + bp->duplex != phydev->duplex)) {
> + u32 reg;
>
> - if (phydev->duplex)
> - reg |= MACB_BIT(FD);
> + reg = macb_readl(bp, NCFGR);
> + reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
> + if (macb_is_gem(bp))
> + reg &= ~GEM_BIT(GBE);
> + if (phydev->duplex)
> + reg |= MACB_BIT(FD);
> + macb_or_gem_writel(bp, NCFGR, reg);
> +
> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII &&
> + (phydev->speed == SPEED_1000 ||
> + phydev->speed == SPEED_2500)) {
> + if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED) {
> + reg = gem_readl(bp, NCR) &
> + ~GEM_BIT(TWO_PT_FIVE_GIG);
> + gem_writel(bp, NCR, reg);
> + }
If you are making correct use of the capabilities then there is no point
in re-checking them here. If you allowed the MAC to advertise 2.5Gbps
then it is de-facto SGMII capable.
> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
> + gem_readl(bp, NCFGR));
> + if (bp->caps & MACB_CAPS_TWO_PT_FIVE_GIG_SPEED &&
> + phydev->speed == SPEED_2500)
> + gem_writel(bp, NCR, gem_readl(bp, NCR) |
> + GEM_BIT(TWO_PT_FIVE_GIG));
> + } else if (phydev->speed == SPEED_1000) {
> + gem_writel(bp, NCFGR, GEM_BIT(GBE) |
> + gem_readl(bp, NCFGR));
> + } else {
> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) {
> + reg = gem_readl(bp, NCFGR);
> + reg &= ~(GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL));
> +
RE: [PATCH v1] usb: chipidea: tegra: Fix missed ci_hdrc_remove_device()
>
> Fixes: dfebb5f43a78827a ("usb: chipidea: Add support for Tegra20/30/114/124")
I suppose you need to apply at stable tree too, right?
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/usb/chipidea/ci_hdrc_tegra.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c
> b/drivers/usb/chipidea/ci_hdrc_tegra.c
> index 772851bee99b..12025358bb3c 100644
> --- a/drivers/usb/chipidea/ci_hdrc_tegra.c
> +++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
> @@ -130,6 +130,7 @@ static int tegra_udc_remove(struct platform_device *pdev)
> {
> struct tegra_udc *udc = platform_get_drvdata(pdev);
>
> + ci_hdrc_remove_device(udc->dev);
> usb_phy_set_suspend(udc->phy, 1);
> clk_disable_unprepare(udc->clk);
>
Acked-by: Peter Chen
Hi Greg, would you still accept the bug-fix for this release (v5.0)? Or I send
you later?
Peter
Re: [PATCH v2] PCI: pciehp: Report degraded links via link bandwidth notification
On Fri, Dec 07, 2018 at 12:20:00PM -0600, Alexandru Gagniuc wrote:
> A warning is generated when a PCIe device is probed with a degraded
> link, but there was no similar mechanism to warn when the link becomes
> degraded after probing. The Link Bandwidth Notification provides this
> mechanism.
>
> Use the link bandwidth notification interrupt to detect bandwidth
> changes, and rescan the bandwidth, looking for the weakest point. This
> is the same logic used in probe().
This is unrelated to pciehp, so the subject prefix should be changed
to "PCI/portdrv".
> Q: Why is this unconditionally compiled in?
> A: The symmetrical check in pci probe() is also always compiled in.
Hm, it looks like the convention is to provide a separate Kconfig entry
for each port service.
> Q: Why call module_init() instead of adding a call in pcie_init_services() ?
> A: A call in pcie_init_services() also requires a prototype in portdrv.h, a
> non-static implementation in bw_notification.c. Using module_init() is
> functionally equivalent, and takes less code.
Commit c29de84149ab ("PCI: portdrv: Initialize service drivers directly")
moved away from module_init() on purpose, apparently to fix a race
condition.
> Q: Why print only on degraded links and not when a link is back to full speed?
> For symmetry with PCI probe(). Although I see a benefit in conveying that a
> link is back to full speed, I expect this to be extremely rare. Secondary bus
> reset is usually needed to retrain at full bandwidth.
What if the link is retrained at the same speed/width? Intuitively
I'd compare the speed in the Link Status Register to what is cached
in the cur_bus_speed member of struct pci_bus and print a message
only if the speed has changed. (Don't we need to cache the width as
well?)
> +static irqreturn_t pcie_bw_notification_irq(int irq, void *context)
> +{
> + struct pcie_device *srv = context;
> + struct pci_dev *port = srv->port;
> + struct pci_dev *dev;
> + u16 link_status, events;
> + int ret;
> +
> + ret = pcie_capability_read_word(port, PCI_EXP_LNKSTA, _status);
> + events = link_status & PCI_EXP_LNKSTA_LBMS;
> +
> + if (!events || ret != PCIBIOS_SUCCESSFUL)
> + return IRQ_NONE;
> +
> + /* Print status from upstream link partner, not this downstream port. */
> + list_for_each_entry(dev, >subordinate->devices, bus_list)
> + __pcie_print_link_status(dev, false);
> +
> + pcie_capability_write_word(port, PCI_EXP_LNKSTA, events);
> + return IRQ_HANDLED;
> +}
You need to hold pci_bus_sem for the list iteration to protect against
simultaneous removal of child devices.
This may sleep, so request the IRQ with request_threaded_irq(), pass NULL
for the "handler" argument and pcie_bw_notification_irq for the "thread_fn"
argument.
You may want to call pcie_update_link_speed() to update the now stale
speed cached in the pci_bus struct.
> + ret = devm_request_irq(>device, srv->irq, pcie_bw_notification_irq,
> +IRQF_SHARED, "PCIe BW notif", srv);
The plan is to move away from port services as devices in the future,
so device-managed allocations should be avoided.
Apart from that, with a device-managed IRQ, if this service driver is
unbound, its IRQ handler may still be invoked if some other port service
signals an interrupt (because the IRQ is shared). Which seems wrong.
> + .port_type = PCI_EXP_TYPE_DOWNSTREAM,
According to PCIe r4.0, sec 7.8.6, Link Bandwidth Notification Capability
is also required for root ports, so I think you need to match for
PCIE_ANY_PORT and amend pcie_link_bandwidth_notification_supported()
to check that you're dealing with a root or downstream port.
> + .service= PCIE_PORT_SERVICE_BwNOTIF,
All caps please.
> @@ -136,9 +136,12 @@ static int pcie_port_enable_irq_vec(struct pci_dev *dev,
> int *irqs, int mask)
> }
>
> /* PME and hotplug share an MSI/MSI-X vector */
> - if (mask & (PCIE_PORT_SERVICE_PME | PCIE_PORT_SERVICE_HP)) {
> - irqs[PCIE_PORT_SERVICE_PME_SHIFT] = pci_irq_vector(dev, pme);
> - irqs[PCIE_PORT_SERVICE_HP_SHIFT] = pci_irq_vector(dev, pme);
> + if (mask & (PCIE_PORT_SERVICE_PME | PCIE_PORT_SERVICE_HP |
> + PCIE_PORT_SERVICE_BwNOTIF)) {
> + pcie_irq = pci_irq_vector(dev, pme);
> + irqs[PCIE_PORT_SERVICE_PME_SHIFT] = pcie_irq;
> + irqs[PCIE_PORT_SERVICE_HP_SHIFT] = pcie_irq;
> + irqs[PCIE_PORT_SERVICE_BWNOTIF_SHIFT] = pcie_irq;
Please amend the code comment with something like
- /* PME and hotplug share an MSI/MSI-X vector */
+ /* PME, hotplug and bandwidth notification share an MSI/MSI-X vector */
> @@ -250,6 +253,9 @@ static int get_port_device_capability(struct pci_dev *dev)
> pci_aer_available() && services & PCIE_PORT_SERVICE_AER)
> services |= PCIE_PORT_SERVICE_DPC;
>
> + if (pci_pcie_type(dev) ==
RE: [PATCH RESEND V2 1/4] dt-bindings: fsl: scu: add watchdog binding
Hi, Guenter
Best Regards!
Anson Huang
> -Original Message-
> From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter
> Roeck
> Sent: 2019年2月24日 11:20
> To: Anson Huang ; Rob Herring
> Cc: mark.rutl...@arm.com; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> catalin.mari...@arm.com; will.dea...@arm.com; w...@linux-watchdog.org;
> Aisheng Dong ; ulf.hans...@linaro.org; Daniel
> Baluta ; Andy Gross ;
> horms+rene...@verge.net.au; he...@sntech.de; a...@arndb.de;
> bjorn.anders...@linaro.org; ja...@amarulasolutions.com;
> enric.balle...@collabora.com; marc.w.gonza...@free.fr; o...@lixom.net;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-watch...@vger.kernel.org; dl-linux-imx
>
> Subject: Re: [PATCH RESEND V2 1/4] dt-bindings: fsl: scu: add watchdog
> binding
>
> On 2/23/19 7:04 PM, Anson Huang wrote:
> > Hi, Guenter/Rob
> >
> > Best Regards!
> > Anson Huang
> >
> >> -Original Message-
> >> From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter
> >> Roeck
> >> Sent: 2019年2月24日 1:08
> >> To: Rob Herring ; Anson Huang
>
> >> Cc: mark.rutl...@arm.com; shawn...@kernel.org;
> >> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> >> catalin.mari...@arm.com; will.dea...@arm.com; wim@linux-
> watchdog.org;
> >> Aisheng Dong ; ulf.hans...@linaro.org; Daniel
> >> Baluta ; Andy Gross ;
> >> horms+rene...@verge.net.au; he...@sntech.de; a...@arndb.de;
> >> bjorn.anders...@linaro.org; ja...@amarulasolutions.com;
> >> enric.balle...@collabora.com; marc.w.gonza...@free.fr;
> >> o...@lixom.net; devicet...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; linux-arm- ker...@lists.infradead.org;
> >> linux-watch...@vger.kernel.org; dl-linux-imx
> >> Subject: Re: [PATCH RESEND V2 1/4] dt-bindings: fsl: scu: add
> >> watchdog binding
> >>
> >> On 2/22/19 11:52 AM, Rob Herring wrote:
> >>> On Mon, Feb 18, 2019 at 06:53:48AM +, Anson Huang wrote:
> Add i.MX8QXP system controller watchdog binding.
>
> Signed-off-by: Anson Huang
> ---
> Changes since V1:
> - update dts node name to "watchdog";
> ---
> Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 10
> >> ++
> 1 file changed, 10 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> index 4b79751..f388ec6 100644
> --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> @@ -136,6 +136,12 @@ Required properties:
> resource id for thermal driver to get
> temperature
> >> via
> SCU IPC.
>
> +Watchdog bindings based on SCU Message Protocol
> +
> +
> +Required properties:
> +- compatible: should be "fsl,imx8qxp-sc-wdt";
> +
> Example (imx8qxp):
> -
> lsio_mu1: mailbox@5d1c {
> @@ -188,6 +194,10 @@ firmware {
> tsens-num = <1>;
> #thermal-sensor-cells = <1>;
> };
> +
> +watchdog: watchdog {
> +compatible = "fsl,imx8qxp-sc-wdt";
> >>>
> >>> As-is, there's no reason for this to be in DT. The parent node's
> >>> driver can instantiate the wdog.
> >>>
> >>
> >> As the driver is currently written, you are correct, since it doesn't
> >> accept watchdog timeout configuration through devicetree.
> >>
> >> Question is if that is intended. Is it ?
> >
> > I am a little confused, do you mean we no need to have "watchdog" node
> in side "scu"
> > node? Or we need to modify the watchdog node's compatible string to "
> > fsl,imx-sc-wdt" to make it more generic for other platforms? If yes, I can
> resend the patch series to modify it.
> >
>
> I think Rob suggested that the SCU parent driver should instantiate the
> watchdog without explicit watchdog node. That would be possible, but it
> currently uses
> devm_of_platform_populate() to do the instantiation, and changing that
> would be a mess. Besides, it does sem to me that your suggested node would
> describe the hardware, so I am not sure I understand the reasoning.
>
> For my part I referred to
> watchdog_init_timeout(imx_sc_wdd, DEFAULT_TIMEOUT,
> >dev); in the driver, which guarantees that the timeout property will not be
> used to set the timeout. A more common implementation would have been
>
> imx_sc_wdd->timeout = DEFAULT_TIMEOUT;
> ret = watchdog_init_timeout(imx_sc_wdd, timeout, >dev);
>
> where 'timeout' is the module parameter. Which is actually not used in your
> driver.
> Hmm ... I wasn't careful enough with my
RE: [PATCH RESEND V2 2/4] watchdog: imx_sc: Add i.MX system controller watchdog support
Hi, Guenter Best Regards! Anson Huang > -Original Message- > From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter > Roeck > Sent: 2019年2月24日 11:29 > To: Anson Huang ; robh...@kernel.org; > mark.rutl...@arm.com; shawn...@kernel.org; s.ha...@pengutronix.de; > ker...@pengutronix.de; feste...@gmail.com; catalin.mari...@arm.com; > will.dea...@arm.com; w...@linux-watchdog.org; Aisheng Dong > ; ulf.hans...@linaro.org; Daniel Baluta > ; Andy Gross ; > horms+rene...@verge.net.au; he...@sntech.de; a...@arndb.de; > bjorn.anders...@linaro.org; ja...@amarulasolutions.com; > enric.balle...@collabora.com; marc.w.gonza...@free.fr; o...@lixom.net; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-watch...@vger.kernel.org > Cc: dl-linux-imx > Subject: Re: [PATCH RESEND V2 2/4] watchdog: imx_sc: Add i.MX system > controller watchdog support > > On 2/17/19 10:53 PM, Anson Huang wrote: > > i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller > > inside, the system controller is in charge of controlling power, clock > > and watchdog etc.. > > > > This patch adds i.MX system controller watchdog driver support, > > watchdog operation needs to be done in secure EL3 mode via > > ARM-Trusted-Firmware, using SMC call, CPU will trap into > > ARM-Trusted-Firmware and then it will request system controller to do > > watchdog operation via IPC. > > > > Signed-off-by: Anson Huang > > Sorry, but I have to take back my Reviewed-by: Comments below. > Sorry, I completely missed that earlier. > > > --- > > Changes since V1: > > - use watchdog_active() instead of comparing watchdog status > > directly; > > - use devm_kzalloc instead of using static variable; > > - remove unnecessary wdog set driver data in .probe; > > - use watchdog_stop_on_unregister() instead of .remove callback; > > - use watchdog_stop_on_reboot() instead of .shutdown callback; > > - use SIMPLE_DEV_PM_OPS() to simply the PM code. > > --- > > drivers/watchdog/Kconfig | 13 +++ > > drivers/watchdog/Makefile | 1 + > > drivers/watchdog/imx_sc_wdt.c | 185 > ++ > > 3 files changed, 199 insertions(+) > > create mode 100644 drivers/watchdog/imx_sc_wdt.c > > > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index > > 65c3c42..5c5b8ba 100644 > > --- a/drivers/watchdog/Kconfig > > +++ b/drivers/watchdog/Kconfig > > @@ -625,6 +625,19 @@ config IMX2_WDT > > To compile this driver as a module, choose M here: the > > module will be called imx2_wdt. > > > > +config IMX_SC_WDT > > + tristate "IMX SC Watchdog" > > + depends on ARCH_MXC || COMPILE_TEST > > + select WATCHDOG_CORE > > + help > > + This is the driver for the system controller watchdog > > + on the NXP i.MX SoCs with system controller inside. > > + If you have one of these processors and wish to have > > + watchdog support enabled, say Y, otherwise say N. > > + > > + To compile this driver as a module, choose M here: the > > + module will be called imx_sc_wdt. > > + > > config UX500_WATCHDOG > > tristate "ST-Ericsson Ux500 watchdog" > > depends on MFD_DB8500_PRCMU > > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile > > index 4e78a8c..0c9da63 100644 > > --- a/drivers/watchdog/Makefile > > +++ b/drivers/watchdog/Makefile > > @@ -68,6 +68,7 @@ obj-$(CONFIG_NUC900_WATCHDOG) += > nuc900_wdt.o > > obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o > > obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o > > obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o > > +obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o > > obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o > > obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o > > obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o diff --git > > a/drivers/watchdog/imx_sc_wdt.c b/drivers/watchdog/imx_sc_wdt.c new > > file mode 100644 index 000..a234a0c > > --- /dev/null > > +++ b/drivers/watchdog/imx_sc_wdt.c > > @@ -0,0 +1,185 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* > > + * Copyright 2018-2019 NXP. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define DEFAULT_TIMEOUT 60 > > +/* > > + * Software timer tick implemented in scfw side, support 10ms to > > +0x ms > > + * in theory, but for normal case, 1s~128s is enough, you can change > > +this max > > + * value in case it's not enough. > > + */ > > +#define MAX_TIMEOUT 128 > > + > > +#define IMX_SIP_TIMER 0xC202 > > +#define IMX_SIP_TIMER_START_WDOG 0x01 > > +#define IMX_SIP_TIMER_STOP_WDOG0x02 > > +#define IMX_SIP_TIMER_SET_WDOG_ACT 0x03 > > +#define IMX_SIP_TIMER_PING_WDOG0x04 > > +#define IMX_SIP_TIMER_SET_TIMEOUT_WDOG 0x05 > > +#define IMX_SIP_TIMER_GET_WDOG_STAT0x06
Re: [PATCH] mfd: sc27xx: Use SoC compatible string for PMIC devices
Hi Lee,
On Wed, 13 Feb 2019 at 20:57, Baolin Wang wrote:
>
> We should use SoC compatible string in stead of wildcard string for
> PMIC child devices.
>
> Signed-off-by: Baolin Wang
> ---
Could you apply this patch if you have no other issues? Thanks.
> drivers/mfd/sprd-sc27xx-spi.c | 42
> -
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mfd/sprd-sc27xx-spi.c b/drivers/mfd/sprd-sc27xx-spi.c
> index 69df277..43ac716 100644
> --- a/drivers/mfd/sprd-sc27xx-spi.c
> +++ b/drivers/mfd/sprd-sc27xx-spi.c
> @@ -53,67 +53,67 @@ struct sprd_pmic_data {
> static const struct mfd_cell sprd_pmic_devs[] = {
> {
> .name = "sc27xx-wdt",
> - .of_compatible = "sprd,sc27xx-wdt",
> + .of_compatible = "sprd,sc2731-wdt",
> }, {
> .name = "sc27xx-rtc",
> - .of_compatible = "sprd,sc27xx-rtc",
> + .of_compatible = "sprd,sc2731-rtc",
> }, {
> .name = "sc27xx-charger",
> - .of_compatible = "sprd,sc27xx-charger",
> + .of_compatible = "sprd,sc2731-charger",
> }, {
> .name = "sc27xx-chg-timer",
> - .of_compatible = "sprd,sc27xx-chg-timer",
> + .of_compatible = "sprd,sc2731-chg-timer",
> }, {
> .name = "sc27xx-fast-chg",
> - .of_compatible = "sprd,sc27xx-fast-chg",
> + .of_compatible = "sprd,sc2731-fast-chg",
> }, {
> .name = "sc27xx-chg-wdt",
> - .of_compatible = "sprd,sc27xx-chg-wdt",
> + .of_compatible = "sprd,sc2731-chg-wdt",
> }, {
> .name = "sc27xx-typec",
> - .of_compatible = "sprd,sc27xx-typec",
> + .of_compatible = "sprd,sc2731-typec",
> }, {
> .name = "sc27xx-flash",
> - .of_compatible = "sprd,sc27xx-flash",
> + .of_compatible = "sprd,sc2731-flash",
> }, {
> .name = "sc27xx-eic",
> - .of_compatible = "sprd,sc27xx-eic",
> + .of_compatible = "sprd,sc2731-eic",
> }, {
> .name = "sc27xx-efuse",
> - .of_compatible = "sprd,sc27xx-efuse",
> + .of_compatible = "sprd,sc2731-efuse",
> }, {
> .name = "sc27xx-thermal",
> - .of_compatible = "sprd,sc27xx-thermal",
> + .of_compatible = "sprd,sc2731-thermal",
> }, {
> .name = "sc27xx-adc",
> - .of_compatible = "sprd,sc27xx-adc",
> + .of_compatible = "sprd,sc2731-adc",
> }, {
> .name = "sc27xx-audio-codec",
> - .of_compatible = "sprd,sc27xx-audio-codec",
> + .of_compatible = "sprd,sc2731-audio-codec",
> }, {
> .name = "sc27xx-regulator",
> - .of_compatible = "sprd,sc27xx-regulator",
> + .of_compatible = "sprd,sc2731-regulator",
> }, {
> .name = "sc27xx-vibrator",
> - .of_compatible = "sprd,sc27xx-vibrator",
> + .of_compatible = "sprd,sc2731-vibrator",
> }, {
> .name = "sc27xx-keypad-led",
> - .of_compatible = "sprd,sc27xx-keypad-led",
> + .of_compatible = "sprd,sc2731-keypad-led",
> }, {
> .name = "sc27xx-bltc",
> - .of_compatible = "sprd,sc27xx-bltc",
> + .of_compatible = "sprd,sc2731-bltc",
> }, {
> .name = "sc27xx-fgu",
> - .of_compatible = "sprd,sc27xx-fgu",
> + .of_compatible = "sprd,sc2731-fgu",
> }, {
> .name = "sc27xx-7sreset",
> - .of_compatible = "sprd,sc27xx-7sreset",
> + .of_compatible = "sprd,sc2731-7sreset",
> }, {
> .name = "sc27xx-poweroff",
> - .of_compatible = "sprd,sc27xx-poweroff",
> + .of_compatible = "sprd,sc2731-poweroff",
> }, {
> .name = "sc27xx-syscon",
> - .of_compatible = "sprd,sc27xx-syscon",
> + .of_compatible = "sprd,sc2731-syscon",
> },
> };
>
> --
> 1.7.9.5
>
--
Baolin Wang
Best Regards
[PATCH V3 4/4] arm64: dts: freescale: imx8qxp: add watchdog support
Add i.MX8QXP system controller watchdog support.
Signed-off-by: Anson Huang
---
Changes since V2:
- add fallback compatilbe "fsl,imx-sc-wdt" for other i.MX platforms
with system
controller watchdog available;
- this patch depends on my thermal patch series:
https://patchwork.kernel.org/patch/10827673/
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 85c90e0..514432c7 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -123,6 +123,10 @@
#thermal-sensor-cells = <0>;
imx,sensor-resource-id = ;
};
+
+ watchdog: watchdog {
+ compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
+ };
};
timer {
--
2.7.4
[PATCH V3 2/4] watchdog: imx_sc: Add i.MX system controller watchdog support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and watchdog etc..
This patch adds i.MX system controller watchdog driver support,
watchdog operation needs to be done in secure EL3 mode via
ARM-Trusted-Firmware, using SMC call, CPU will trap into
ARM-Trusted-Firmware and then it will request system controller
to do watchdog operation via IPC.
Signed-off-by: Anson Huang
---
Changes since V2:
- improve watchdog_init_timeout() operation and error check, setting it
via module parameter "timeout", if it is invalid, roll back to use
defaul
timeout value DEFAULT_TIMEOUT;
- change compatible string to "fsl,imx-sc-wdt" to make driver more
generic
for all i.MX platforms with system controller watchdog inside.
---
drivers/watchdog/Kconfig | 13 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/imx_sc_wdt.c | 183 ++
3 files changed, 197 insertions(+)
create mode 100644 drivers/watchdog/imx_sc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 65c3c42..5c5b8ba 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -625,6 +625,19 @@ config IMX2_WDT
To compile this driver as a module, choose M here: the
module will be called imx2_wdt.
+config IMX_SC_WDT
+ tristate "IMX SC Watchdog"
+ depends on ARCH_MXC || COMPILE_TEST
+ select WATCHDOG_CORE
+ help
+ This is the driver for the system controller watchdog
+ on the NXP i.MX SoCs with system controller inside.
+ If you have one of these processors and wish to have
+ watchdog support enabled, say Y, otherwise say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx_sc_wdt.
+
config UX500_WATCHDOG
tristate "ST-Ericsson Ux500 watchdog"
depends on MFD_DB8500_PRCMU
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 4e78a8c..0c9da63 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
+obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o
obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
diff --git a/drivers/watchdog/imx_sc_wdt.c b/drivers/watchdog/imx_sc_wdt.c
new file mode 100644
index 000..7b22575
--- /dev/null
+++ b/drivers/watchdog/imx_sc_wdt.c
@@ -0,0 +1,183 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018-2019 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEFAULT_TIMEOUT 60
+/*
+ * Software timer tick implemented in scfw side, support 10ms to 0x ms
+ * in theory, but for normal case, 1s~128s is enough, you can change this max
+ * value in case it's not enough.
+ */
+#define MAX_TIMEOUT 128
+
+#define IMX_SIP_TIMER 0xC202
+#define IMX_SIP_TIMER_START_WDOG 0x01
+#define IMX_SIP_TIMER_STOP_WDOG0x02
+#define IMX_SIP_TIMER_SET_WDOG_ACT 0x03
+#define IMX_SIP_TIMER_PING_WDOG0x04
+#define IMX_SIP_TIMER_SET_TIMEOUT_WDOG 0x05
+#define IMX_SIP_TIMER_GET_WDOG_STAT0x06
+#define IMX_SIP_TIMER_SET_PRETIME_WDOG 0x07
+
+#define SC_TIMER_WDOG_ACTION_PARTITION 0
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, );
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+static unsigned int timeout = DEFAULT_TIMEOUT;
+module_param(timeout, uint, );
+MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds (default="
+__MODULE_STRING(DEFAULT_TIMEOUT) ")");
+
+static int imx_sc_wdt_ping(struct watchdog_device *wdog)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_PING_WDOG,
+ 0, 0, 0, 0, 0, 0, );
+
+ return res.a0;
+}
+
+static int imx_sc_wdt_start(struct watchdog_device *wdog)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_START_WDOG,
+ 0, 0, 0, 0, 0, 0, );
+ if (res.a0)
+ return res.a0;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_SET_WDOG_ACT,
+ SC_TIMER_WDOG_ACTION_PARTITION,
+ 0, 0, 0, 0, 0, );
+ return res.a0;
+}
+
+static int imx_sc_wdt_stop(struct watchdog_device *wdog)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_STOP_WDOG,
+ 0, 0, 0, 0, 0, 0, );
+
+ return res.a0;
+}
+
+static int imx_sc_wdt_set_timeout(struct
[PATCH V3 3/4] arm64: defconfig: add support for i.MX system controller watchdog
Enable CONFIG_IMX_SC_WDT as module to support i.MX system controller watchdog. Signed-off-by: Anson Huang --- No changes since V2. --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 52d503e..c3d4607 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -428,6 +428,7 @@ CONFIG_WATCHDOG=y CONFIG_ARM_SP805_WATCHDOG=y CONFIG_S3C2410_WATCHDOG=y CONFIG_IMX2_WDT=y +CONFIG_IMX_SC_WDT=m CONFIG_MESON_GXBB_WATCHDOG=m CONFIG_MESON_WATCHDOG=m CONFIG_RENESAS_WDT=y -- 2.7.4
[PATCH V3 0/4] Add i.MX8QXP system controller watchdog support
i.MX8QXP is an ARMv8 Cortex-A35 SoC with a Cortex-M4 system controller inside, the system controller manages overall power, clock, secure RTC and watchdog etc., so Linux kernel running on A35 needs to communicate with system controller for watchdog operation, this system controller watchdog will call SMC to trap to EL3 secure world ARM-Trusted-Firmware and then it will request system controller to do the watchdog operation via IPC. This V3 patch series addresses all the comments from V2, and change log is inside each patch of this V3 series. Below are the patch dependency: The dt-binding and imx8qxp.dtsi patch are based on my thermal patch series as below: https://patchwork.kernel.org/patch/10827673/ Anson Huang (4): dt-bindings: fsl: scu: add watchdog binding watchdog: imx_sc: Add i.MX system controller watchdog support arm64: defconfig: add support for i.MX system controller watchdog arm64: dts: freescale: imx8qxp: add watchdog support .../devicetree/bindings/arm/freescale/fsl,scu.txt | 12 ++ arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 4 + arch/arm64/configs/defconfig | 1 + drivers/watchdog/Kconfig | 13 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/imx_sc_wdt.c | 183 + 6 files changed, 214 insertions(+) create mode 100644 drivers/watchdog/imx_sc_wdt.c -- 2.7.4
[PATCH V3 1/4] dt-bindings: fsl: scu: add watchdog binding
Add i.MX8QXP system controller watchdog binding.
Signed-off-by: Anson Huang
---
Changes since V2:
- add fallback compatible "fsl,imx-sc-wdt" to cover other i.MX
platforms with system controller
watchdog available.
- this patch depends on my thermal patch series:
https://patchwork.kernel.org/patch/10827673/
---
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 2e310ac..4f9a3f4 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -137,6 +137,14 @@ Required properties:
an array of integers to specify each thermal
zone's sensor
resource ID.
+Watchdog bindings based on SCU Message Protocol
+
+
+Required properties:
+- compatible: Should be :
+ "fsl,imx8qxp-sc-wdt"
+ followed by "fsl,imx-sc-wdt";
+
Example (imx8qxp):
-
lsio_mu1: mailbox@5d1c {
@@ -189,6 +197,10 @@ firmware {
#thermal-sensor-cells = <0>;
imx,sensor-resource-id = ;
};
+
+ watchdog: watchdog {
+ compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
+ };
};
};
--
2.7.4
[PATCH V6 4/8] drm/mediatek: fix the rate and divder of hdmi phy for MT2701
From: chunhui dai
Due to a clerical error,there is one zero less for 1280.
Fix it for 12800.
Fixes: 0fc721b2968e ("drm/mediatek: add hdmi driver for MT2701 and MT7623")
Reviewed-by: CK Hu
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 43bc058d5528..88dd9e812ca0 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -114,8 +114,8 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
if (rate <= 6400)
pos_div = 3;
- else if (rate <= 1280)
- pos_div = 1;
+ else if (rate <= 12800)
+ pos_div = 2;
else
pos_div = 1;
--
2.14.1
[PATCH v6 1/8] drm/mediatek: recalculate hdmi phy clock of MT2701 by querying hardware
From: chunhui dai
Recalculate the rate of this clock, by querying hardware.
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 7 ++
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 3 +--
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 35 ++
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 8 ++
4 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 4ef9c57ffd44..13c5e65b9ead 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -29,12 +29,9 @@ long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned
long rate,
return rate;
}
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate)
+u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
{
- struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
- return hdmi_phy->pll_rate;
+ return readl(hdmi_phy->regs + offset);
}
void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index f39b1fc66612..fdad8b17a915 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -41,6 +41,7 @@ struct mtk_hdmi_phy {
unsigned int ibias_up;
};
+u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset);
void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 bits);
void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
@@ -50,8 +51,6 @@ void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate);
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate);
extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index fcc42dc6ea7f..b25c9dfc432a 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -153,6 +153,41 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
RG_HDMITX_DRV_IBIAS_MASK);
return 0;
}
+static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+ unsigned long out_rate, val;
+
+ val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
+ & RG_HTPLL_PREDIV_MASK) >> RG_HTPLL_PREDIV;
+ switch (val) {
+ case 0x00:
+ out_rate = parent_rate;
+ break;
+ case 0x01:
+ out_rate = parent_rate / 2;
+ break;
+ default:
+ out_rate = parent_rate / 4;
+ break;
+ }
+
+ val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
+ & RG_HTPLL_FBKDIV_MASK) >> RG_HTPLL_FBKDIV;
+ out_rate *= (val + 1) * 2;
+ val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2)
+ & RG_HDMITX_TX_POSDIV_MASK);
+
+ out_rate >>= (val >> RG_HDMITX_TX_POSDIV);
+
+ if (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2) & RG_HDMITX_EN_TX_POSDIV)
+ out_rate = out_rate / 5;
+
+ hdmi_phy->pll_rate = out_rate;
+
+ return hdmi_phy->pll_rate;
+}
static const struct clk_ops mtk_hdmi_phy_pll_ops = {
.prepare = mtk_hdmi_pll_prepare,
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index ed5916b27658..cb23c1e4692a 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -285,6 +285,14 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
return 0;
}
+static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+ return hdmi_phy->pll_rate;
+}
+
static const struct clk_ops mtk_hdmi_phy_pll_ops = {
.prepare = mtk_hdmi_pll_prepare,
.unprepare = mtk_hdmi_pll_unprepare,
--
2.14.1
[PATCH V6 8/8] drm/mediatek: fix the rate of parent for hdmi phy in MT2701
From: chunhui dai
We should not change the rate of parent for hdmi phy when
doing round_rate for this clock. The parent clock of hdmi
phy must be the same as it. We change it when doing set_rate
only.
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 14 --
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 3 ---
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 11 +++
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 14 ++
4 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 370309d684ec..ca8bc1489f37 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -15,20 +15,6 @@ static const struct phy_ops mtk_hdmi_phy_dev_ops = {
.owner = THIS_MODULE,
};
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate)
-{
- struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
- hdmi_phy->pll_rate = rate;
- if (rate <= 7425)
- *parent_rate = rate;
- else
- *parent_rate = rate / 2;
-
- return rate;
-}
-
u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
{
return readl(hdmi_phy->regs + offset);
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index 446e2acd1926..c6061ad15ff0 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -50,9 +50,6 @@ void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 val, u32 mask);
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate);
-
extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 88dd9e812ca0..33893a180c2e 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -152,6 +152,17 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
RG_HDMITX_DRV_IBIAS_MASK);
return 0;
}
+
+static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+ hdmi_phy->pll_rate = rate;
+
+ return rate;
+}
+
static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 63dde42521b8..3a339f516613 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -285,6 +285,20 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
return 0;
}
+static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+ hdmi_phy->pll_rate = rate;
+ if (rate <= 7425)
+ *parent_rate = rate;
+ else
+ *parent_rate = rate / 2;
+
+ return rate;
+}
+
static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
--
2.14.1
[PATCH V6 2/8] drm/mediatek: move the setting of fixed divider
From: chunhui dai move the setting of fixed divider from enable/disable to the function of setting rate. the patch is for hdmi pll divider, the divder should be configured before clock calculation to ensure the clock is right. Signed-off-by: chunhui dai Signed-off-by: wangyan wang --- drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c index b25c9dfc432a..b26fb7dbdb28 100644 --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c @@ -79,7 +79,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw) mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK); usleep_range(80, 100); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN); - mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK); @@ -94,7 +93,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw) mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK); - mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN); usleep_range(80, 100); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK); @@ -123,6 +121,7 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate, mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_PREDIV_MASK); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_POSDIV_MASK); + mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV); mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IC), RG_HTPLL_IC_MASK); mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IR), @@ -209,7 +208,6 @@ static void mtk_hdmi_phy_enable_tmds(struct mtk_hdmi_phy *hdmi_phy) mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK); usleep_range(80, 100); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN); - mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK); mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK); @@ -221,7 +219,6 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy *hdmi_phy) mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK); - mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN); usleep_range(80, 100); mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK); -- 2.14.1
[PATCH V6 7/8] drm/mediatek: using new factor for tvdpll in MT2701
From: chunhui dai
The factor depends on the divider of DPI in MT2701, therefore,
we should fix this factor to the right and new one.
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 69c6e42dad6b..4a2f4a650494 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -662,13 +662,11 @@ static unsigned int mt8173_calculate_factor(int clock)
static unsigned int mt2701_calculate_factor(int clock)
{
if (clock <= 64000)
- return 16;
- else if (clock <= 128000)
- return 8;
- else if (clock <= 256000)
return 4;
- else
+ else if (clock <= 128000)
return 2;
+ else
+ return 1;
}
static const struct mtk_dpi_conf mt8173_conf = {
--
2.14.1
[PATCH V6 6/8] clk: mediatek: using CLK_MUX_ROUND_CLOSEST for the clock of dpi1_sel
From: chunhui dai
The MUX clock of dpi1_sel should select the closet clock for itself.
We could add this flag to enable this function of MUX in CCF.
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/clk/mediatek/clk-mt2701.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt2701.c
b/drivers/clk/mediatek/clk-mt2701.c
index ab6ab07f53e6..905a2316f6a7 100644
--- a/drivers/clk/mediatek/clk-mt2701.c
+++ b/drivers/clk/mediatek/clk-mt2701.c
@@ -535,8 +535,8 @@ static const struct mtk_composite top_muxes[] = {
0x0080, 8, 2, 15),
MUX_GATE(CLK_TOP_DPI0_SEL, "dpi0_sel", dpi0_parents,
0x0080, 16, 3, 23),
- MUX_GATE(CLK_TOP_DPI1_SEL, "dpi1_sel", dpi1_parents,
- 0x0080, 24, 2, 31),
+ MUX_GATE_FLAGS_2(CLK_TOP_DPI1_SEL, "dpi1_sel", dpi1_parents,
+ 0x0080, 24, 2, 31, 0, CLK_MUX_ROUND_CLOSEST),
MUX_GATE(CLK_TOP_TVE_SEL, "tve_sel", tve_parents,
0x0090, 0, 3, 7),
--
2.14.1
[PATCH V6 0/8] make mt7623 clock of hdmi stable
From: Wangyan Wang V6 adopt maintainer's suggestion. Here is the change list between V5 & V6 1. change "unsigned char mux_flags;" to "u8 mux_flags;" to match with the struct in " clk: mediatek: add MUX_GATE_FLAGS_2". chunhui dai (8): drm/mediatek: recalculate hdmi phy clock of MT2701 by querying hardware drm/mediatek: move the setting of fixed divider drm/mediatek: using different flags of clk for HDMI phy drm/mediatek: fix the rate and divder of hdmi phy for MT2701 clk: mediatek: add MUX_GATE_FLAGS_2 clk: mediatek: using CLK_MUX_ROUND_CLOSEST for the clock of dpi1_sel drm/mediatek: using new factor for tvdpll in MT2701 drm/mediatek: fix the rate of parent for hdmi phy in MT2701 drivers/clk/mediatek/clk-mt2701.c | 4 +- drivers/clk/mediatek/clk-mtk.c | 2 +- drivers/clk/mediatek/clk-mtk.h | 20 ++--- drivers/gpu/drm/mediatek/mtk_dpi.c | 8 ++-- drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 34 drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 7 +--- drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 56 +++--- drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 23 +++ 8 files changed, 102 insertions(+), 52 deletions(-) -- 2.14.1
[PATCH V6 5/8] clk: mediatek: add MUX_GATE_FLAGS_2
From: chunhui dai
Add MUX_GATE_FLAGS_2 for the clock which needs to set two falgs.
Such as some mux need to set the flags of "CLK_MUX_ROUND_CLOSEST".
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/clk/mediatek/clk-mtk.c | 2 +-
drivers/clk/mediatek/clk-mtk.h | 20 ++--
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 9c0ae4278a94..2ed996404804 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -167,7 +167,7 @@ struct clk *mtk_clk_register_composite(const struct
mtk_composite *mc,
mux->mask = BIT(mc->mux_width) - 1;
mux->shift = mc->mux_shift;
mux->lock = lock;
-
+ mux->flags = mc->mux_flags;
mux_hw = >hw;
mux_ops = _mux_ops;
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index f83c2bbb677e..4b88d196d52f 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -81,15 +81,13 @@ struct mtk_composite {
signed char divider_shift;
signed char divider_width;
+ u8 mux_flags;
+
signed char num_parents;
};
-/*
- * In case the rate change propagation to parent clocks is undesirable,
- * this macro allows to specify the clock flags manually.
- */
-#define MUX_GATE_FLAGS(_id, _name, _parents, _reg, _shift, _width, \
- _gate, _flags) {\
+#define MUX_GATE_FLAGS_2(_id, _name, _parents, _reg, _shift, \
+ _width, _gate, _flags, _muxflags) { \
.id = _id, \
.name = _name, \
.mux_reg = _reg,\
@@ -101,8 +99,18 @@ struct mtk_composite {
.parent_names = _parents, \
.num_parents = ARRAY_SIZE(_parents),\
.flags = _flags,\
+ .mux_flags = _muxflags, \
}
+/*
+ * In case the rate change propagation to parent clocks is undesirable,
+ * this macro allows to specify the clock flags manually.
+ */
+#define MUX_GATE_FLAGS(_id, _name, _parents, _reg, _shift, _width, \
+ _gate, _flags) \
+ MUX_GATE_FLAGS_2(_id, _name, _parents, _reg,\
+ _shift, _width, _gate, _flags, 0)
+
/*
* Unless necessary, all MUX_GATE clocks propagate rate changes to their
* parent clock by default.
--
2.14.1
[PATCH V6 3/8] drm/mediatek: using different flags of clk for HDMI phy
From: chunhui dai
The parent rate of hdmi phy had set by DPI driver.
We should not set or change the parent rate of MT2701 hdmi phy,
as a result we should remove the flags of "CLK_SET_RATE_PARENT"
from the clock of MT2701 hdmi phy.
Signed-off-by: chunhui dai
Signed-off-by: wangyan wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 13 +
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 1 +
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 1 +
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 1 +
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 13c5e65b9ead..370309d684ec 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -107,13 +107,11 @@ mtk_hdmi_phy_dev_get_ops(const struct mtk_hdmi_phy
*hdmi_phy)
return NULL;
}
-static void mtk_hdmi_phy_clk_get_ops(struct mtk_hdmi_phy *hdmi_phy,
-const struct clk_ops **ops)
+static void mtk_hdmi_phy_clk_get_data(struct mtk_hdmi_phy *hdmi_phy,
+struct clk_init_data *clk_init)
{
- if (hdmi_phy && hdmi_phy->conf && hdmi_phy->conf->hdmi_phy_clk_ops)
- *ops = hdmi_phy->conf->hdmi_phy_clk_ops;
- else
- dev_err(hdmi_phy->dev, "Failed to get clk ops of phy\n");
+ clk_init->flags = hdmi_phy->conf->flags;
+ clk_init->ops = hdmi_phy->conf->hdmi_phy_clk_ops;
}
static int mtk_hdmi_phy_probe(struct platform_device *pdev)
@@ -126,7 +124,6 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
struct clk_init_data clk_init = {
.num_parents = 1,
.parent_names = (const char * const *)_clk_name,
- .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
};
struct phy *phy;
@@ -164,7 +161,7 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
hdmi_phy->dev = dev;
hdmi_phy->conf =
(struct mtk_hdmi_phy_conf *)of_device_get_match_data(dev);
- mtk_hdmi_phy_clk_get_ops(hdmi_phy, _init.ops);
+ mtk_hdmi_phy_clk_get_data(hdmi_phy, _init);
hdmi_phy->pll_hw.init = _init;
hdmi_phy->pll = devm_clk_register(dev, _phy->pll_hw);
if (IS_ERR(hdmi_phy->pll)) {
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index fdad8b17a915..446e2acd1926 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -21,6 +21,7 @@ struct mtk_hdmi_phy;
struct mtk_hdmi_phy_conf {
bool tz_disabled;
+ unsigned long flags;
const struct clk_ops *hdmi_phy_clk_ops;
void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index b26fb7dbdb28..43bc058d5528 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -234,6 +234,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
.tz_disabled = true,
+ .flags = CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index cb23c1e4692a..63dde42521b8 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -317,6 +317,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
}
struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf = {
+ .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
--
2.14.1
Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr
On 02/24/19 at 09:25pm, Pingfan Liu wrote: > On Fri, Feb 22, 2019 at 9:00 PM Borislav Petkov wrote: > > > > On Fri, Feb 22, 2019 at 09:42:41AM +0100, Joerg Roedel wrote: > > > The current default of 256MB was found by experiments on a bigger > > > number of machines, to create a reasonable default that is at least > > > likely to be sufficient of an average machine. > > > > Exactly, and this is what makes sense. > > > > The code should try the requested reservation and if it fails, it should > > try high allocation with default swiotlb size because we need to reserve > > *some* range. > > > > If that reservation succeeds, we should say something along the lines of > > > > "... requested range failed, reserved range instead." > > > Maybe I misunderstood you, but does "requested range failed" mean that > user specify the range? If yes, then it should be the duty of user as > you said later, not the duty of kernel" If you go with the changes in your current patch it is needed to say something like: "crashkernel: can not find free memory under 4G, reserve XM@.. instead" Also need to print the reserved low memory area in case ,high being used. But for 896M -> 4G, the 896M faulure is not necessary to show in dmesg, it is some in kernel logic. Thanks Dave
[PATCH net-next] mlxsw: spectrum: remove set but not used variable 'autoneg_status'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function
'mlxsw_sp_port_get_link_ksettings':
drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3062:5: warning:
variable 'autoneg_status' set but not used [-Wunused-but-set-variable]
It's not used since commit 475b33cb66c9 ("mlxsw: spectrum: Remove unsupported
eth_proto_lp_advertise field in PTYS")
Signed-off-by: YueHaibing
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 40177b9834c4..b00f6f74f91a 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -3059,7 +3059,6 @@ static int mlxsw_sp_port_get_link_ksettings(struct
net_device *dev,
const struct mlxsw_sp_port_type_speed_ops *ops;
char ptys_pl[MLXSW_REG_PTYS_LEN];
u8 connector_type;
- u8 autoneg_status;
bool autoneg;
int err;
@@ -3079,8 +3078,6 @@ static int mlxsw_sp_port_get_link_ksettings(struct
net_device *dev,
mlxsw_sp_port_get_link_advertise(mlxsw_sp, eth_proto_admin, autoneg,
cmd);
- autoneg_status = mlxsw_reg_ptys_an_status_get(ptys_pl);
-
cmd->base.autoneg = autoneg ? AUTONEG_ENABLE : AUTONEG_DISABLE;
connector_type = mlxsw_reg_ptys_connector_type_get(ptys_pl);
cmd->base.port = mlxsw_sp_port_connector_port(connector_type);
Re: [PATCH] arm64: dts: renesas: r8a77965: add SSIU support for sound
Hi Jiada
Thank you for your patch
> From: Jiada Wang
>
> rsnd driver supports SSIU now, let's use it.
> Then, BUSIF DMA settings on rcar_sound,ssi (= rxu, txu) are
> no longer needed.
> Applies commit 8d14bfa074db ("arm64: dts: renesas: r8a7796: add SSIU
> support for sound") for r8a77965.
>
> Signed-off-by: Jiada Wang
> Signed-off-by: Timo Wischer
> ---
I think ARM maintainer doesn't want duplicate/copied patches.
So, we want/need to merge into this patch, too
10bd03fa896ee5e25fa3548a3d1112b9beb76943
("arm64: dts: renesas: r8a7796: remove BUSIF0 settings from
rcar_sound,ssi")
And I guess this patch is related, so, we need to merge it too ?
arm64: dts: renesas: r8a7796: use extended audio dmac register
linux-next: manual merge of the sound tree with the arm-soc tree
Hi Takashi,
Today's linux-next merge of the sound tree got conflicts in:
arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
between commits:
5eef17ee764d ("arm64: tegra: p2972: Sort nodes properly")
be4f0dd347ad ("arm64: tegra: p2597: Sort nodes by unit-address")
from the arm-soc tree and commit:
11ce4308307c ("arm64: tegra: custom name for hda sound card")
from the sound tree.
I fixed it up (see below - in tegra194-p2972-.dts. the line added
just needed to be moved up a few lines) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
index 34a7044927fd,39c616737232..
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
diff --cc arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
index 8780b5b3d2b9,6096dfb7e17a..
--- a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
@@@ -1317,15 -1303,6 +1317,16 @@@
clock-frequency = <10>;
};
+ sata@7002 {
+ status = "okay";
+ phys = <&{/padctl@7009f000/pads/sata/lanes/sata-0}>;
+ };
+
+ hda@7003 {
++ nvidia,model = "jetson-tx1-hda";
+ status = "okay";
+ };
+
usb@7009 {
phys = <&{/padctl@7009f000/pads/usb2/lanes/usb2-0}>,
<&{/padctl@7009f000/pads/usb2/lanes/usb2-1}>,
pgpxbxuUaueoU.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/2] staging: erofs: switch to ->iterate_shared()
On 2019/2/21 10:34, Gao Xiang wrote:
> After commit 6192269444eb ("introduce a parallel variant of ->iterate()"),
> readdir can be done without taking exclusive inode lock of course.
>
> Signed-off-by: Gao Xiang
Reviewed-by: Chao Yu
Thanks,
