Re: [PATCH] ext4: flag as supporting buffered async reads
On 8/24/20 4:56 AM, Jens Axboe wrote: > On 8/22/20 9:48 AM, Jens Axboe wrote: >> On 8/22/20 8:33 AM, Theodore Y. Ts'o wrote: >>> On Fri, Aug 21, 2020 at 03:26:35PM -0600, Jens Axboe wrote: >>> Resending this one, as I've been carrying it privately since May. The >>> necessary bits are now upstream (and XFS/btrfs equiv changes as well), >>> please consider this one for 5.9. Thanks! >> >> The necessary commit only hit upstream as of 5.9-rc1, unless I'm >> missing something? It's on my queue to send to Linus once I get my >> (late) ext4 primary pull request for 5.9. > > Right, it went in at the start of the merge window for 5.9. Thanks Ted! Didn't see it in the queue that just sent in, is it still queued up? >>> >>> It wasn't in the queue which I queued up because that was based on >>> 5.8-rc4. Linus was a bit grumpy (fairly so) because it was late, and >>> that's totally on me. >>> >>> He has said that he's going to start ignoring pull requests that >>> aren't fixes only if this becomes a pattern, so while I can send him >>> another pull request which will just have that one change, there are >>> no guarantees he's going to take it at this late date. >>> >>> Sorry, when you sent me the commit saying that the changes that were >>> needed were already upstream on August 3rd, I thought that meant that >>> they were aready in Linus's tree. I should have checked and noticed >>> that that in fact "ext4: flag as supporting buffered async reads" >>> wasn't compiling against Linus's upstream tree, so I didn't realize >>> this needed to be handled as a special case during the merge window. >> >> Well to be honest, this kind of sucks. I've been posting it since May, >> and the ideal approach would have been to just ack it and I could have >> carried it in my tree. That's what we did for btrfs and XFS, both of >> which have it. >> >> The required patches *were* upstreamed on August 3rd, which is why I >> mentioned that. But yes, not in 5.8 or earlier, of course. >> >> So I suggest that you either include it for the next pull request for >> Linus, or that I put it in with your ack. Either is fine with me. I'd >> consider this a "dropping the ball" kind of thing, it's not like the >> patch hasn't been in linux-next or hasn't been ready for months. This >> isn't some "oh I wrote this feature after the merge window" event. It'd >> be a real shame to ship 5.9 and ext4 not have support for the more >> efficient async buffered reads, imho, especially since the two other >> major local file systems already have it. >> >> Let me know what you think. > > Ted, can you make a call on this, please? It's now post -rc2. Let's > get this settled and included, one way or another. Daily ping on this one... -- Jens Axboe
Re: [PATCH 3/5] ARM: dts: aspeed: yamp: Set 32MB FMC flash layout
On Mon, Aug 24, 2020 at 02:19:46PM -0700, rentao.b...@gmail.com wrote: > From: Tao Ren > > Set 32MB FMC flash layout in Yamp device tree explicitly because flash > layout settings were removed from "ast2500-facebook-netbmc-common.dtsi". > > Signed-off-by: Tao Ren > --- > arch/arm/boot/dts/aspeed-bmc-facebook-yamp.dts | 17 + > 1 file changed, 17 insertions(+) > Reviewed-by: Patrick Williams -- Patrick Williams signature.asc Description: PGP signature
Re: [PATCH 2/5] ARM: dts: aspeed: cmm: Set 32MB FMC flash layout
On Mon, Aug 24, 2020 at 02:19:45PM -0700, rentao.b...@gmail.com wrote: > From: Tao Ren > > Set 32MB FMC flash layout in CMM device tree explicitly because the flash > layout settings were removed from "ast2500-facebook-netbmc-common.dtsi". > > Signed-off-by: Tao Ren > --- > arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts | 17 + > 1 file changed, 17 insertions(+) > Reviewed-by: Patrick Williams -- Patrick Williams signature.asc Description: PGP signature
Re: [PATCH 1/5] ARM: dts: aspeed: Remove flash layout from Facebook AST2500 Common dtsi
On Mon, Aug 24, 2020 at 02:19:44PM -0700, rentao.b...@gmail.com wrote: > From: Tao Ren > > Remove FMC flash layout from ast2500-facebook-netbmc-common.dtsi because > flash size and layout varies across different Facebook AST2500 OpenBMC > platforms. > > Signed-off-by: Tao Ren > --- > .../boot/dts/ast2500-facebook-netbmc-common.dtsi| 13 - > 1 file changed, 13 deletions(-) > Reviewed-by: Patrick Williams -- Patrick Williams signature.asc Description: PGP signature
Re: [PATCH v8 2/8] powerpc/vdso: Remove __kernel_datapage_offset and simplify __get_datapage()
Le 04/08/2020 à 13:17, Christophe Leroy a écrit :
On 07/16/2020 02:59 AM, Michael Ellerman wrote:
Christophe Leroy writes:
The VDSO datapage and the text pages are always located immediately
next to each other, so it can be hardcoded without an indirection
through __kernel_datapage_offset
In order to ease things, move the data page in front like other
arches, that way there is no need to know the size of the library
to locate the data page.
[...]
I merged this but then realised it breaks the display of the vdso in
/proc/self/maps.
ie. the vdso vma gets no name:
# cat /proc/self/maps
[...]
And it's also going to break the logic in arch_unmap() to detect if
we're unmapping (part of) the VDSO. And it will break arch_remap() too.
And the logic to recognise the signal trampoline in
arch/powerpc/perf/callchain_*.c as well.
I don't think it breaks that one, because ->vdsobase is still the start
of text.
So I'm going to rebase and drop this for now.
Basically we have a bunch of places that assume that vdso_base is == the
start of the VDSO vma, and also that the code starts there. So that will
need some work to tease out all those assumptions and make them work
with this change.
Ok, one day I need to look at it in more details and see how other
architectures handle it etc ...
I just sent out a series which switches powerpc to the new
_install_special_mapping() API, the one powerpc uses being deprecated
since commit a62c34bd2a8a ("x86, mm: Improve _install_special_mapping
and fix x86 vdso naming")
arch_remap() gets replaced by vdso_remap()
For arch_unmap(), I'm wondering how/what other architectures do, because
powerpc seems to be the only one to erase the vdso context pointer when
unmapping the vdso. So far I updated it to take into account the pages
switch.
Everything else is not impacted because our vdso_base is still the base
of the text and that's what those things (signal trampoline, callchain,
...) expect.
Maybe we should change it to 'void *vdso' in the same way as other
architectures, as it is not anymore the exact vdso_base but the start of
VDSO text.
Note that the series applies on top of the generic C VDSO implementation
series. However all but the last commit cleanly apply without that
series. As that last commit is just an afterwork cleanup, it can come in
a second step.
Christophe
Re: x86/kprobes: kretprobe fails to triggered if kprobe at function entry is not optimized (trigger by int3 breakpoint)
On Tue, Aug 25, 2020 at 10:59:54PM +0900, Masami Hiramatsu wrote:
> On Tue, 25 Aug 2020 15:30:05 +0200
> pet...@infradead.org wrote:
>
> > On Tue, Aug 25, 2020 at 10:15:55PM +0900, Masami Hiramatsu wrote:
> >
> > > > damn... one last problem is dangling instances.. so close.
> > > > We can apparently unregister a kretprobe while there's still active
> > > > kretprobe_instance's out referencing it.
> > >
> > > Yeah, kretprobe already provided the per-instance data (as far as
> > > I know, only systemtap depends on it). We need to provide it for
> > > such users.
> > > But if we only have one lock, we can avoid checking NMI because
> > > we can check the recursion with trylock. It is needed only if the
> > > kretprobe uses per-instance data. Or we can just pass a dummy
> > > instance on the stack.
> >
> > I think it is true in general, you can unregister a rp while tasks are
> > preempted.
>
> Would you mean the kretprobe handler (or trampoline handler) will be
> preempted? All kprobes (including kretprobe) handler is running in
> non-preemptive state, so it shouldn't happen...
I was thinking about something like:
for_each_process_thread(p, t) {
if (!t->kretprobe_instances.first)
continue;
again:
if (try_invoke_on_locked_down_task(t, unhook_rp_inst, tp))
continue;
smp_function_call(...);
if (!done)
goto again;
}
So then for each task that has a kretprobe stack, we iterate the stack
and set ri->rp = NULL, remotely when the task isn't running, locally if
the task is running.
I just need to change the semantics of try_invoke_on_locked_down_task()
a bit -- they're a tad weird atm.
> > Anyway,. I think I have a solution, just need to talk to paulmck for a
> > bit.
>
> Ah, you mentioned that the removing the kfree() from the trampline
> handler? I think we can make an rcu callback which will kfree() the
> given instances. (If it works in NMI)
Yes, calling kfree() from the trampoline seems dodgy at best. When
!ri->rp rcu_free() is a good option.
[gustavoars-linux:for-linus/kspp] BUILD SUCCESS 308f765116e9176bf508c10b72ca80ad594e3119
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git for-linus/kspp branch HEAD: 308f765116e9176bf508c10b72ca80ad594e3119 lib: Revert use of fallthrough pseudo-keyword elapsed time: 722m configs tested: 105 configs skipped: 4 The following configs have been built successfully. More configs may be tested in the coming days. arm64 defconfig arm64allyesconfig arm allyesconfig arm allmodconfig arm defconfig arm colibri_pxa300_defconfig mipsworkpad_defconfig mips loongson1c_defconfig h8300alldefconfig xtensageneric_kc705_defconfig powerpc ppc64e_defconfig armxcep_defconfig mips pistachio_defconfig mipsvocore2_defconfig armzeus_defconfig arm zx_defconfig arc alldefconfig arm badge4_defconfig h8300 edosk2674_defconfig mipsar7_defconfig c6xevmc6472_defconfig c6xevmc6474_defconfig sh sdk7780_defconfig sh r7785rp_defconfig arm rpc_defconfig h8300h8300h-sim_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig cskydefconfig alpha defconfig alphaallyesconfig nios2allyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig sparc defconfig i386 allyesconfig sparcallyesconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a003-20200825 x86_64 randconfig-a002-20200825 x86_64 randconfig-a001-20200825 x86_64 randconfig-a005-20200825 x86_64 randconfig-a006-20200825 x86_64 randconfig-a004-20200825 i386 randconfig-a002-20200825 i386 randconfig-a004-20200825 i386 randconfig-a005-20200825 i386 randconfig-a003-20200825 i386 randconfig-a006-20200825 i386 randconfig-a001-20200825 i386 randconfig-a002-20200824 i386 randconfig-a004-20200824 i386 randconfig-a005-20200824 i386 randconfig-a003-20200824 i386 randconfig-a006-20200824 i386 randconfig-a001-20200824 x86_64 randconfig-a016-20200824 x86_64 randconfig-a015-20200824 x86_64 randconfig-a012-20200824 x86_64 randconfig-a014-20200824 x86_64 randconfig-a011-20200824 x86_64 randconfig-a013-20200824 i386 randconfig-a013-20200825 i386 randconfig-a012-20200825 i386 randconfig-a011-20200825 i386 randconfig-a016-20200825 i386 randconfig-a015-20200825 i386 randconfig-a014-20200825 i386 randconfig-a013-20200824 i386 randconfig-a012-20200824 i386 randconfig-a011-20200824 i386 randconfig-a016-20200824 i386 randconfig-a015-20200824 i386 randconfig-a014-20200824 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64
Re: [PATCH v2 11/17] clk: imx: Add blk_ctrl combo driver
On 20-08-25 14:07:29, Philipp Zabel wrote:
> On Tue, 2020-08-25 at 14:24 +0300, Abel Vesa wrote:
> [...]
> > > > +static int imx_blk_ctrl_reset_set(struct reset_controller_dev *rcdev,
> > > > + unsigned long id, bool assert)
> > > > +{
> > > > + struct imx_blk_ctrl_drvdata *drvdata = container_of(rcdev,
> > > > + struct imx_blk_ctrl_drvdata, rcdev);
> > > > + unsigned int offset = drvdata->rst_hws[id].offset;
> > > > + unsigned int shift = drvdata->rst_hws[id].shift;
> > > > + unsigned int mask = drvdata->rst_hws[id].mask;
> > > > + void __iomem *reg_addr = drvdata->base + offset;
> > > > + unsigned long flags;
> > > > + unsigned int asserted_before = 0, asserted_after = 0;
> > > > + u32 reg;
> > > > + int i;
> > > > +
> > > > + spin_lock_irqsave(&drvdata->lock, flags);
> > > > +
> > > > + for (i = 0; i < drvdata->rcdev.nr_resets; i++)
> > > > + if (drvdata->rst_hws[i].asserted)
> > > > + asserted_before++;
> > > > +
> > > > + if (asserted_before == 0 && assert)
> > > > + pm_runtime_get(rcdev->dev);
> > >
> > > Shouldn't that be pm_runtime_get_sync() ?
> > >
> > > I would do that unconditionally before locking drvdata->lock and then
> > > drop unnecessary refcounts afterwards.
> > >
> >
> > I thought we already discussed this on the last's version thread.
>
> This is about something different. pm_runtime_get() just queues the
> device to be enabled at a later point, but I presume you want to have it
> enabled before writing to its registers. (The question here is can you
> write to the registers, and have the device update its internal state,
> while the power domain is disabled?)
> Either way, if you want the reset to be asserted after the function
> returns (as is required by the reset API), as I understand it, you have
> to make sure that the power domain is activated before the function
> returns.
> Therefore pm_runtime_get_sync() is required instead of pm_runtime_get(),
> and that must be called outside of the spin locked section. My
> suggestion would be:
>
> if (assert)
> pm_runtime_get_sync();
> spin_lock_irqsave();
> /* ... */
> spin_unlock_irqrestore();
> if (assert && asserted_before)
> pm_runtime_put();
>
You're right this makes more sense.
> unless the following might be an issue:
>
> > > > +
> > > > + if (assert) {
> > > > + reg = readl(reg_addr);
> > > > + writel(reg & ~(mask << shift), reg_addr);
> > > > + drvdata->rst_hws[id].asserted = true;
> > > > + } else {
> > > > + reg = readl(reg_addr);
> > > > + writel(reg | (mask << shift), reg_addr);
>
> Could this cause problems if the power domain is already disabled? If
> so, it would be best to either temporarily enable power, or to skip the
> register writes if asserted_before == 0 && !assert.
I'll go with the latter one since it leaves the PD off.
>
> > > > + drvdata->rst_hws[id].asserted = false;
> > > > + }
> > > > +
> > > > + for (i = 0; i < drvdata->rcdev.nr_resets; i++)
> > > > + if (drvdata->rst_hws[i].asserted)
> > > > + asserted_after++;
> > > > +
> > > > + if (asserted_before == 1 && asserted_after == 0)
> > > > + pm_runtime_put(rcdev->dev);
> > > > +
> > > > + spin_unlock_irqrestore(&drvdata->lock, flags);
> > > > +
> > > > + return 0;
> > > > +}
>
> regards
> Philipp
Re: x86/kprobes: kretprobe fails to triggered if kprobe at function entry is not optimized (trigger by int3 breakpoint)
On Tue, Aug 25, 2020 at 03:30:05PM +0200, pet...@infradead.org wrote: > On Tue, Aug 25, 2020 at 10:15:55PM +0900, Masami Hiramatsu wrote: > > OK, this looks good to me too. > > I'll make a series to rewrite kretprobe based on this patch, OK? > > Please, I'll send the fix along when I have it. One approach that I think might work nicely is trying to pull trampoline_handler() into core code (with a few arch helpers). Then we can replace that loop once, instead of having to go fix each architectures one by one. They're all basically the same loop after all.
Re: [PATCH bpf-next v9 5/7] bpf: Implement bpf_local_storage for inodes
On 8/25/20 2:52 AM, Martin KaFai Lau wrote:
> On Sun, Aug 23, 2020 at 06:56:10PM +0200, KP Singh wrote:
>> From: KP Singh
>>
>> Similar to bpf_local_storage for sockets, add local storage for inodes.
>> The life-cycle of storage is managed with the life-cycle of the inode.
>> i.e. the storage is destroyed along with the owning inode.
>>
>> The BPF LSM allocates an __rcu pointer to the bpf_local_storage in the
>> security blob which are now stackable and can co-exist with other LSMs.
>>
> [ ... ]
>
>> diff --git a/kernel/bpf/bpf_inode_storage.c b/kernel/bpf/bpf_inode_storage.c
>> new file mode 100644
>> index ..b0b283c224c1
>> --- /dev/null
>> +++ b/kernel/bpf/bpf_inode_storage.c
[...]
>> +
>> +DEFINE_BPF_STORAGE_CACHE(inode_cache);
>> +
>> +static struct bpf_local_storage __rcu **
>> +inode_storage_ptr(void *owner)
>> +{
>> +struct inode *inode = owner;
>> +struct bpf_storage_blob *bsb;
>> +
>> +bsb = bpf_inode(inode);
>> +if (!bsb)
>> +return NULL;
> just noticed this one. NULL could be returned here. When will it happen?
This can happen if CONFIG_BPF_LSM is enabled but "bpf" is not in the list of
active LSMs.
>
>> +return &bsb->storage;
>> +}
>> +
>> +static struct bpf_local_storage_data *inode_storage_lookup(struct inode
>> *inode,
>> + struct bpf_map *map,
>> + bool cacheit_lockit)
>> +{
[...]
> path first before calling the bpf_local_storage_update() since
> this case is specific to inode local storage.
>
> Same for the other bpf_local_storage_update() cases.
If you're okay with this I can send a new series with the following updates.
diff --git a/kernel/bpf/bpf_inode_storage.c b/kernel/bpf/bpf_inode_storage.c
index b0b283c224c1..74546cee814d 100644
--- a/kernel/bpf/bpf_inode_storage.c
+++ b/kernel/bpf/bpf_inode_storage.c
@@ -125,7 +125,7 @@ static int bpf_fd_inode_storage_update_elem(struct bpf_map
*map, void *key,
fd = *(int *)key;
f = fget_raw(fd);
- if (!f)
+ if (!f || !inode_storage_ptr(f->f_inode))
return -EBADF;
sdata = bpf_local_storage_update(f->f_inode,
@@ -171,6 +171,14 @@ BPF_CALL_4(bpf_inode_storage_get, struct bpf_map *, map,
struct inode *, inode,
if (flags & ~(BPF_LOCAL_STORAGE_GET_F_CREATE))
return (unsigned long)NULL;
+ /* explicitly check that the inode_storage_ptr is not
+* NULL as inode_storage_lookup returns NULL in this case and
+* and bpf_local_storage_update expects the owner to have a
+* valid storage pointer.
+*/
+ if (!inode_storage_ptr(inode))
+ return (unsigned long)NULL;
+
sdata = inode_storage_lookup(inode, map, true);
if (sdata)
return (unsigned long)sdata->data;
>
>> + (struct bpf_local_storage_map *)map,
>> + value, map_flags);
>> +fput(f);
>> +return PTR_ERR_OR_ZERO(sdata);
>> +}
>> +
>
[...]
>> +return (unsigned long)NULL;
>> +}
>> +
>
>> diff --git a/security/bpf/hooks.c b/security/bpf/hooks.c
>> index 32d32d485451..35f9b19259e5 100644
>> --- a/security/bpf/hooks.c
>> +++ b/security/bpf/hooks.c
>> @@ -3,6 +3,7 @@
>> /*
>> * Copyright (C) 2020 Google LLC.
>> */
>> +#include
> Is it needed?
No. Removed. Thanks!
>
>> #include
>> #include
>>
>> @@ -11,6 +12,7 @@ static struct security_hook_list bpf_lsm_hooks[]
>> __lsm_ro_after_init = {
>> LSM_HOOK_INIT(NAME, bpf_lsm_##NAME),
[...]
>> +.blobs = &bpf_lsm_blob_sizes
>> };
Configuring Fortigate 60D Firewall SSL VPN with FortiToken 2FA (Advanced Configuration)
Subject: Configuring Fortigate 60D Firewall SSL VPN with FortiToken 2FA (Advanced Configuration) Author: Mr. Turritopsis Dohrnii Teo En Ming Country: Singapore Date: 25 August 2020 Tuesday Singapore Time Type of Publication: PDF Manual Document Version: 20200825.01 INTRODUCTION Fortigate firewall appliances are based on Linux Kernel and open source software. In this PDF manual, I will show you how to: 1. Install Windows Server 2019 Standard as a virtual machine in Linux KVM/QEMU Hypervisor 2. Install Active Directory Domain Services role/feature 3. Promote Windows Server 2019 Standard to Domain Controller 4. Create organizational units in Active Directory Users and Computers 5. Create Active Directory user 6. Create security group for SSL VPN users 7. Assign Active Directory user to the SSL VPN Users security group 8. Add LDAP server (Microsoft Active Directory/LDAP integration) in Fortigate 60D firewall 9. Add user group from LDAP server in Fortigate 60D firewall (remember to add members of the group as well) 10. Add LDAP user in Fortigate 60D firewall 11. Configure SSL VPN tunnel in Fortigate 60D firewall 12. Configure two firewall security policies to allow VPN users to access the (a) internal network and the (b) internet 13. Assign FortiToken to LDAP user in Fortigate 60D firewall and turn on 2nd Factor Authentication (2FA) 14. Create VPN tunnel in FortiClient VPN on your Android phone and connect to Fortigate 60D SSL VPN tunnel successfully 15. FortiClient VPN will now ask you for the token code Redundant Google Drive download links for my PDF manual === [1] https://drive.google.com/file/d/1uhRWr8OXerCN30OeWhgFP8rG_4NlkHsa/view?usp=sharing [2] https://drive.google.com/file/d/1mJ5m7zlPFLXuXfKgfLcq_nAGP1jC2QlC/view?usp=sharing [3] https://drive.google.com/file/d/1ZU7aphOXIG3q8-1g6GSRXX2hXgG7AibU/view?usp=sharing [4] https://drive.google.com/file/d/1IKVeGJZ5HPR6hAsRwxTHfABBLjKz9uyl/view?usp=sharing [5] https://drive.google.com/file/d/1nwC7VlA3p0U2apmsOlH6mADrX84wxTNM/view?usp=sharing [6] https://drive.google.com/file/d/1mXT3TdX8dtCDA1YeoX7oRxk3mSgcoN6P/view?usp=sharing -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan (5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020): [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
Schönen Tag
Schönen Tag, Ich bin Ahmed Muzashah, Account Manager einer Investmentbank hier in Burkina Faso. In meinem Unternehmen wird seit langem ein Kontoprojekt von einem Kunden unserer Bank eröffnet. Ich habe die Möglichkeit, den verbleibenden Fonds (15,8 Millionen US-Dollar) zu übertragen. Fünfzehn Millionen Achthunderttausend US-Dollar. Ich möchte diese Mittel investieren und diese Vereinbarung bei unserer Bank einreichen. Diese wird im Rahmen einer legitimen Vereinbarung ausgeführt, die uns vor Gesetzesverstößen schützt. Wir teilen den Fonds zu 40% für Sie, zu 50% für mich und zu 10%, um eine Basis für arme Kinder in Ihrem Land zu schaffen. Wenn Sie wirklich an meinem Vorschlag interessiert sind, erhalten Sie weitere Informationen zur Überweisung. Dein, Mr Ahmed Muzashah,
[PATCH 1/3] software node: Power management operations for software nodes
Adding separate PM operations vector for the software nodes.
The software node specific PM operations make it possible to
handle most PM related quirks separately in their own
functions instead of conditionally in the device driver's
generic PM functions (and in some cases all over the
driver). The software node specific PM operations will also
reduce the need to pass platform data in some cases, for
example from a core MFD driver to the child device drivers,
as from now on the core MFD driver will be able to implement
the PM quirks directly for the child devices without the
need to touch the drivers of those child devices.
If a software node includes the PM operations, those PM
operations are always executed separately on top of the
other PM operations of the device, so the software node will
never replace any of the "normal" PM operations of the
device (including the PM domain's operations, class's or
bus's PM operations, the device drivers own operations, or
any other).
Signed-off-by: Heikki Krogerus
---
drivers/base/power/common.c | 8 +-
drivers/base/swnode.c | 524 +++-
include/linux/property.h| 10 +
3 files changed, 532 insertions(+), 10 deletions(-)
diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c
index bbddb267c2e69..b64cd4690ac63 100644
--- a/drivers/base/power/common.c
+++ b/drivers/base/power/common.c
@@ -109,8 +109,14 @@ int dev_pm_domain_attach(struct device *dev, bool power_on)
ret = acpi_dev_pm_attach(dev, power_on);
if (!ret)
ret = genpd_dev_pm_attach(dev);
+ if (ret < 0)
+ return ret;
- return ret < 0 ? ret : 0;
+ ret = software_node_dev_pm_attach(dev, power_on);
+ if (ret)
+ dev_pm_domain_detach(dev, power_on);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(dev_pm_domain_attach);
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 010828fc785bc..9a13a61a2f0bb 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -8,6 +8,8 @@
#include
#include
+#include
+#include
#include
#include
@@ -48,6 +50,19 @@ EXPORT_SYMBOL_GPL(is_software_node);
struct swnode, fwnode) : NULL; \
})
+static inline struct swnode *dev_to_swnode(struct device *dev)
+{
+ struct fwnode_handle *fwnode = dev_fwnode(dev);
+
+ if (!fwnode)
+ return NULL;
+
+ if (!is_software_node(fwnode))
+ fwnode = fwnode->secondary;
+
+ return to_swnode(fwnode);
+}
+
static struct swnode *
software_node_to_swnode(const struct software_node *node)
{
@@ -344,6 +359,504 @@ void property_entries_free(const struct property_entry
*properties)
}
EXPORT_SYMBOL_GPL(property_entries_free);
+/* --
*/
+/* Power management operations */
+
+#ifdef CONFIG_PM
+struct swnode_pm_domain {
+ struct dev_pm_domain pm_domain;
+ struct dev_pm_domain *primary;
+};
+
+#define to_swnode_pm_domain(d) \
+ container_of(d, struct swnode_pm_domain, pm_domain)
+
+static int software_node_runtime_suspend(struct device *dev)
+{
+ struct swnode_pm_domain *domain = to_swnode_pm_domain(dev->pm_domain);
+ struct swnode *swnode = dev_to_swnode(dev);
+ int ret;
+
+ if (domain->primary && domain->primary->ops.runtime_suspend)
+ ret = domain->primary->ops.runtime_suspend(dev);
+ else
+ ret = pm_generic_runtime_suspend(dev);
+
+ if (ret || !swnode->node->pm->runtime_suspend)
+ return ret;
+
+ return swnode->node->pm->runtime_suspend(dev);
+}
+
+static int software_node_runtime_resume(struct device *dev)
+{
+ struct swnode_pm_domain *domain = to_swnode_pm_domain(dev->pm_domain);
+ struct swnode *swnode = dev_to_swnode(dev);
+ int ret;
+
+ if (swnode->node->pm->runtime_resume) {
+ ret = swnode->node->pm->runtime_resume(dev);
+ if (ret)
+ return ret;
+ }
+
+ if (domain->primary && domain->primary->ops.runtime_resume)
+ ret = domain->primary->ops.runtime_resume(dev);
+ else
+ ret = pm_generic_runtime_resume(dev);
+
+ return ret;
+}
+
+static int software_node_runtime_idle(struct device *dev)
+{
+ struct swnode_pm_domain *domain = to_swnode_pm_domain(dev->pm_domain);
+ struct swnode *swnode = dev_to_swnode(dev);
+ int ret = 0;
+
+ if (domain->primary && domain->primary->ops.runtime_idle)
+ ret = domain->primary->ops.runtime_idle(dev);
+
+ if (ret || !swnode->node->pm->runtime_idle)
+ return ret;
+
+ return swnode->node->pm->runtime_idle(dev);
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int software_node_prepare(struct device *dev)
+{
+ struct swnode_pm_domain *domain = to_swnode_pm_domain(dev->pm_domain);
+ struct s
[PATCH 0/3] PM operations for software nodes
Hi guys, Unfortunately the last patch depends on this: https://lore.kernel.org/linux-usb/20200821131101.81915-1-heikki.kroge...@linux.intel.com/ Would it be easiest that Felipe took care of these (assuming they are acceptable)? thanks, Heikki Krogerus (3): software node: Power management operations for software nodes software node: Introduce device_add_software_node() usb: dwc3: pci: Register a software node for the dwc3 platform device drivers/base/power/common.c | 8 +- drivers/base/swnode.c | 569 +++- drivers/usb/dwc3/dwc3-pci.c | 175 ++- include/linux/property.h| 13 + 4 files changed, 666 insertions(+), 99 deletions(-) -- 2.28.0
[PATCH 3/3] usb: dwc3: pci: Register a software node for the dwc3 platform device
By registering the software node directly instead of just
the properties in it, the driver can take advantage of also
the other features the software nodes have.
Initially using the nodes for isolating the Intel Broxton
specific power management quirk by handling it in Broxton's
very own power management operations (which are supplied as
part of the software node) instead of the drivers generic
ones.
Signed-off-by: Heikki Krogerus
---
drivers/usb/dwc3/dwc3-pci.c | 175 ++--
1 file changed, 86 insertions(+), 89 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 242b6210380a4..43cc0f602820d 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -54,17 +54,12 @@
* struct dwc3_pci - Driver private structure
* @dwc3: child dwc3 platform_device
* @pci: our link to PCI bus
- * @guid: _DSM GUID
- * @has_dsm_for_pm: true for devices which need to run _DSM on runtime PM
* @wakeup_work: work for asynchronous resume
*/
struct dwc3_pci {
struct platform_device *dwc3;
struct pci_dev *pci;
- guid_t guid;
-
- unsigned int has_dsm_for_pm:1;
struct work_struct wakeup_work;
};
@@ -108,6 +103,50 @@ static int dwc3_byt_enable_ulpi_refclock(struct pci_dev
*pci)
return 0;
}
+#ifdef CONFIG_PM
+static int dwc3_pci_intel_pm_dsm(struct device *dev, int param)
+{
+ union acpi_object *obj;
+ union acpi_object tmp;
+ union acpi_object argv4 = ACPI_INIT_DSM_ARGV4(1, &tmp);
+ guid_t guid;
+ int ret;
+
+ ret = guid_parse(PCI_INTEL_BXT_DSM_GUID, &guid);
+ if (ret)
+ return ret;
+
+ tmp.type = ACPI_TYPE_INTEGER;
+ tmp.integer.value = param;
+
+ obj = acpi_evaluate_dsm(ACPI_HANDLE(dev), &guid,
+ 1, PCI_INTEL_BXT_FUNC_PMU_PWR, &argv4);
+ if (!obj) {
+ dev_err(dev, "failed to evaluate _DSM\n");
+ return -EIO;
+ }
+
+ ACPI_FREE(obj);
+
+ return 0;
+}
+
+static int dwc3_pci_intel_suspend(struct device *dev)
+{
+ return dwc3_pci_intel_pm_dsm(dev->parent, PCI_INTEL_BXT_STATE_D3);
+}
+
+static int dwc3_pci_intel_resume(struct device *dev)
+{
+ return dwc3_pci_intel_pm_dsm(dev->parent, PCI_INTEL_BXT_STATE_D0);
+}
+#endif /* CONFIG_PM */
+
+static const struct dev_pm_ops dwc3_pci_intel_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(dwc3_pci_intel_suspend, dwc3_pci_intel_resume)
+ SET_RUNTIME_PM_OPS(dwc3_pci_intel_suspend, dwc3_pci_intel_resume, NULL)
+};
+
static const struct property_entry dwc3_pci_intel_properties[] = {
PROPERTY_ENTRY_STRING("dr_mode", "peripheral"),
PROPERTY_ENTRY_BOOL("linux,sysdev_is_parent"),
@@ -141,18 +180,28 @@ static const struct property_entry
dwc3_pci_amd_properties[] = {
{}
};
+static const struct software_node dwc3_pci_intel_swnode = {
+ .properties = dwc3_pci_intel_properties,
+};
+
+static const struct software_node dwc3_pci_intel_pm_swnode = {
+ .properties = dwc3_pci_intel_properties,
+ .pm = &dwc3_pci_intel_pm_ops,
+};
+
+static const struct software_node dwc3_pci_intel_mrfld_swnode = {
+ .properties = dwc3_pci_mrfld_properties,
+};
+
+static const struct software_node dwc3_pci_amd_swnode = {
+ .properties = dwc3_pci_amd_properties,
+};
+
static int dwc3_pci_quirks(struct dwc3_pci *dwc)
{
struct pci_dev *pdev = dwc->pci;
if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
- if (pdev->device == PCI_DEVICE_ID_INTEL_BXT ||
- pdev->device == PCI_DEVICE_ID_INTEL_BXT_M ||
- pdev->device == PCI_DEVICE_ID_INTEL_EHLLP) {
- guid_parse(PCI_INTEL_BXT_DSM_GUID, &dwc->guid);
- dwc->has_dsm_for_pm = true;
- }
-
if (pdev->device == PCI_DEVICE_ID_INTEL_BYT) {
struct gpio_desc *gpio;
int ret;
@@ -221,7 +270,6 @@ static void dwc3_pci_resume_work(struct work_struct *work)
static int dwc3_pci_probe(struct pci_dev *pci, const struct pci_device_id *id)
{
- struct property_entry *p = (struct property_entry *)id->driver_data;
struct dwc3_pci *dwc;
struct resource res[2];
int ret;
@@ -264,7 +312,7 @@ static int dwc3_pci_probe(struct pci_dev *pci, const struct
pci_device_id *id)
dwc->dwc3->dev.parent = dev;
ACPI_COMPANION_SET(&dwc->dwc3->dev, ACPI_COMPANION(dev));
- ret = platform_device_add_properties(dwc->dwc3, p);
+ ret = device_add_software_node(&dwc->dwc3->dev, (void
*)id->driver_data);
if (ret < 0)
goto err;
@@ -287,6 +335,7 @@ static int dwc3_pci_probe(struct pci_dev *pci, const struct
pci_device_id *id)
return 0;
err:
+ device_remove_software_node(&dwc->dwc3->dev);
platform_device_put(dwc->dwc3);
Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches
On Tue, Aug 25, 2020 at 5:30 AM Masahiro Yamada wrote: > > On Tue, Aug 25, 2020 at 4:10 PM Nick Desaulniers > wrote: > > > > Masahiro, are you implying that we shouldn't take the > > -fno-builtin-stpcpy patch, because Clang is inconsistent? (That can be > > fixed.) Even though -fno-builtin-stpcpy works here as intended? > > https://lore.kernel.org/lkml/20200817220212.338670-2-ndesaulni...@google.com/ > > > > Otherwise we need to provide an implementation of this symbol in the kernel. > > https://lore.kernel.org/lkml/20200815020946.1538085-1-ndesaulni...@google.com/ > > > > Please, pick your poison. > > > > I am not a compiler expert. > > Nor am I sure if I am the right person who makes this decision. > But, if so, I would choose the latter. > (implement stpcpy() in the kernel) > > I was addressed last night, so > I should write up my thoughts. > > I do not think -fno-builtin-stpcpy is a > general solution. > > -fno-builtin-stpcpy will work for now > because only Clang implements the transformation > from 'sprintf(dest, "%s", str)' into > 'stpcpy(dest, str) - dest'. > > If GCC implements it some day, > we would run into a problem because > in GCC, it is not -fno-builtin-stpcpy, but > -fno-builtin-sprintf that disables that optimization. > > In this regard, 'KBUILD_CFLAGS += -fno-builtin-sprintf' > would be more future-proof, but it is potentially > an overkill. > We want to disable optimization from sprintf() to stpcpy(), > but we may still benefit from the optimization from > sprintf() into something else. > > > Linus is uncomfortable with this kind of compiler magic. > If we take compiler's freedom away, > -ffreestanding is a big hammer to solve this problem. > > If we welcome the compiler's optimization, > we should implement stpcpy(), bcmp(), and whatever > until we solve all link errors. Speculating that -ffreestanding is untenable, submitted v3: https://lore.kernel.org/lkml/20200825135838.2938771-1-ndesaulni...@google.com/T/#u -- Thanks, ~Nick Desaulniers
Re: x86/kprobes: kretprobe fails to triggered if kprobe at function entry is not optimized (trigger by int3 breakpoint)
On Tue, 25 Aug 2020 15:30:05 +0200 pet...@infradead.org wrote: > On Tue, Aug 25, 2020 at 10:15:55PM +0900, Masami Hiramatsu wrote: > > > > damn... one last problem is dangling instances.. so close. > > > We can apparently unregister a kretprobe while there's still active > > > kretprobe_instance's out referencing it. > > > > Yeah, kretprobe already provided the per-instance data (as far as > > I know, only systemtap depends on it). We need to provide it for > > such users. > > But if we only have one lock, we can avoid checking NMI because > > we can check the recursion with trylock. It is needed only if the > > kretprobe uses per-instance data. Or we can just pass a dummy > > instance on the stack. > > I think it is true in general, you can unregister a rp while tasks are > preempted. Would you mean the kretprobe handler (or trampoline handler) will be preempted? All kprobes (including kretprobe) handler is running in non-preemptive state, so it shouldn't happen... > > Anyway,. I think I have a solution, just need to talk to paulmck for a > bit. Ah, you mentioned that the removing the kfree() from the trampline handler? I think we can make an rcu callback which will kfree() the given instances. (If it works in NMI) > > > > Ignoring that issue for the moment, the below seems to actually work. > > > > OK, this looks good to me too. > > I'll make a series to rewrite kretprobe based on this patch, OK? > > Please, I'll send the fix along when I have it. OK, I'm planning to (1) add a generic trampoline code (2) cleanup per-arch trampoline to use generic one, (3) rewrite the generic trampoline to use lockless code. Then it will not break anything. Thank you, -- Masami Hiramatsu
drivers/iommu/sun50i-iommu.c:890:14: warning: variable 'iova' set but not used
Hi Maxime,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 6a9dc5fd6170d0a41c8a14eb19e63d94bea5705a
commit: 4100b8c229b328358cc4a82f5042dbf22f1c1ccb iommu: Add Allwinner H6 IOMMU
driver
date: 3 months ago
config: i386-randconfig-r015-20200825 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
git checkout 4100b8c229b328358cc4a82f5042dbf22f1c1ccb
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/iommu/sun50i-iommu.c: In function 'sun50i_dte_get_page_table':
drivers/iommu/sun50i-iommu.c:486:16: warning: unused variable 'flags'
[-Wunused-variable]
486 | unsigned long flags;
|^
drivers/iommu/sun50i-iommu.c: In function 'sun50i_iommu_unmap':
drivers/iommu/sun50i-iommu.c:561:13: warning: variable 'pte_dma' set but not
used [-Wunused-but-set-variable]
561 | dma_addr_t pte_dma;
| ^~~
drivers/iommu/sun50i-iommu.c:559:23: warning: unused variable 'iommu'
[-Wunused-variable]
559 | struct sun50i_iommu *iommu = sun50i_domain->iommu;
| ^
drivers/iommu/sun50i-iommu.c: In function 'sun50i_iommu_probe_device':
drivers/iommu/sun50i-iommu.c:749:22: warning: unused variable 'group'
[-Wunused-variable]
749 | struct iommu_group *group;
| ^
drivers/iommu/sun50i-iommu.c: In function 'sun50i_iommu_irq':
>> drivers/iommu/sun50i-iommu.c:890:14: warning: variable 'iova' set but not
>> used [-Wunused-but-set-variable]
890 | phys_addr_t iova;
| ^~~~
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4100b8c229b328358cc4a82f5042dbf22f1c1ccb
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 4100b8c229b328358cc4a82f5042dbf22f1c1ccb
vim +/iova +890 drivers/iommu/sun50i-iommu.c
886
887 static irqreturn_t sun50i_iommu_irq(int irq, void *dev_id)
888 {
889 struct sun50i_iommu *iommu = dev_id;
> 890 phys_addr_t iova;
891 u32 status;
892
893 spin_lock(&iommu->iommu_lock);
894
895 status = iommu_read(iommu, IOMMU_INT_STA_REG);
896 if (!(status & IOMMU_INT_MASK)) {
897 spin_unlock(&iommu->iommu_lock);
898 return IRQ_NONE;
899 }
900
901 if (status & IOMMU_INT_INVALID_L2PG)
902 iova = sun50i_iommu_handle_pt_irq(iommu,
903
IOMMU_INT_ERR_ADDR_L2_REG,
904IOMMU_L2PG_INT_REG);
905 else if (status & IOMMU_INT_INVALID_L1PG)
906 iova = sun50i_iommu_handle_pt_irq(iommu,
907
IOMMU_INT_ERR_ADDR_L1_REG,
908IOMMU_L1PG_INT_REG);
909 else
910 iova = sun50i_iommu_handle_perm_irq(iommu);
911
912 iommu_write(iommu, IOMMU_INT_CLR_REG, status);
913
914 iommu_write(iommu, IOMMU_RESET_REG, ~status);
915 iommu_write(iommu, IOMMU_RESET_REG, status);
916
917 spin_unlock(&iommu->iommu_lock);
918
919 return IRQ_HANDLED;
920 }
921
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH v3] lib/string.c: implement stpcpy
LLVM implemented a recent "libcall optimization" that lowers calls to
`sprintf(dest, "%s", str)` where the return value is used to
`stpcpy(dest, str) - dest`. This generally avoids the machinery involved
in parsing format strings. `stpcpy` is just like `strcpy` except it
returns the pointer to the new tail of `dest`. This optimization was
introduced into clang-12.
Implement this so that we don't observe linkage failures due to missing
symbol definitions for `stpcpy`.
Similar to last year's fire drill with:
commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")
The kernel is somewhere between a "freestanding" environment (no full libc)
and "hosted" environment (many symbols from libc exist with the same
type, function signature, and semantics).
As H. Peter Anvin notes, there's not really a great way to inform the
compiler that you're targeting a freestanding environment but would like
to opt-in to some libcall optimizations (see pr/47280 below), rather than
opt-out.
Arvind notes, -fno-builtin-* behaves slightly differently between GCC
and Clang, and Clang is missing many __builtin_* definitions, which I
consider a bug in Clang and am working on fixing.
Masahiro summarizes the subtle distinction between compilers justly:
To prevent transformation from foo() into bar(), there are two ways in
Clang to do that; -fno-builtin-foo, and -fno-builtin-bar. There is
only one in GCC; -fno-buitin-foo.
(Any difference in that behavior in Clang is likely a bug from a missing
__builtin_* definition.)
Masahiro also notes:
We want to disable optimization from foo() to bar(),
but we may still benefit from the optimization from
foo() into something else. If GCC implements the same transform, we
would run into a problem because it is not -fno-builtin-bar, but
-fno-builtin-foo that disables that optimization.
In this regard, -fno-builtin-foo would be more future-proof than
-fno-built-bar, but -fno-builtin-foo is still potentially overkill. We
may want to prevent calls from foo() being optimized into calls to
bar(), but we still may want other optimization on calls to foo().
It seems that compilers today don't quite provide the fine grain control
over which libcall optimizations pseudo-freestanding environments would
prefer.
Finally, Kees notes that this interface is unsafe, so we should not
encourage its use. As such, I've removed the declaration from any
header, but it still needs to be exported to avoid linkage errors in
modules.
Cc: sta...@vger.kernel.org
Link: https://bugs.llvm.org/show_bug.cgi?id=47162
Link: https://bugs.llvm.org/show_bug.cgi?id=47280
Link: https://github.com/ClangBuiltLinux/linux/issues/1126
Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html
Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html
Link: https://reviews.llvm.org/D85963
Suggested-by: Andy Lavr
Suggested-by: Arvind Sankar
Suggested-by: Joe Perches
Suggested-by: Masahiro Yamada
Suggested-by: Rasmus Villemoes
Reported-by: Sami Tolvanen
Signed-off-by: Nick Desaulniers
---
Changes V3:
* Drop Sami's Tested by tag; newer patch.
* Add EXPORT_SYMBOL as per Andy.
* Rewrite commit message, rewrote part of what Masahiro said to be
generic in terms of foo() and bar().
* Prefer %NUL-terminated to NULL terminated. NUL is the ASCII character
'\0', as per Arvind and Rasmus.
Changes V2:
* Added Sami's Tested by; though the patch changed implementation, the
missing symbol at link time was the problem Sami was observing.
* Fix __restrict -> __restrict__ typo as per Joe.
* Drop note about restrict from commit message as per Arvind.
* Fix NULL -> NUL as per Arvind; NUL is ASCII '\0'. TIL
* Fix off by one error as per Arvind; I had another off by one error in
my test program that was masking this.
lib/string.c | 24
1 file changed, 24 insertions(+)
diff --git a/lib/string.c b/lib/string.c
index 6012c385fb31..6bd0cf0fb009 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -272,6 +272,30 @@ ssize_t strscpy_pad(char *dest, const char *src, size_t
count)
}
EXPORT_SYMBOL(strscpy_pad);
+/**
+ * stpcpy - copy a string from src to dest returning a pointer to the new end
+ * of dest, including src's %NUL-terminator. May overrun dest.
+ * @dest: pointer to end of string being copied into. Must be large enough
+ *to receive copy.
+ * @src: pointer to the beginning of string being copied from. Must not overlap
+ * dest.
+ *
+ * stpcpy differs from strcpy in a key way: the return value is the new
+ * %NUL-terminated character. (for strcpy, the return value is a pointer to
+ * src. This interface is considered unsafe as it doesn't perform bounds
+ * checking of the inputs. As such it's not recommended for usage. Instead,
+ * its definition is provided in case the compiler lowers other libcalls to
+ * stpcpy.
+ */
+char *stpcpy(char *__restrict__ dest, const char *__restrict__ src);
+char *stpcpy(char *__restrict__ dest, const char *__rest
[PATCH 2/3] software node: Introduce device_add_software_node()
This helper will register a software node and then assign
it to device at the same time. The function will also make
sure that the device can't have more than one software node.
Signed-off-by: Heikki Krogerus
---
drivers/base/swnode.c| 45
include/linux/property.h | 3 +++
2 files changed, 48 insertions(+)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 9a13a61a2f0bb..ec14f02565a65 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -1356,6 +1356,51 @@ void fwnode_remove_software_node(struct fwnode_handle
*fwnode)
}
EXPORT_SYMBOL_GPL(fwnode_remove_software_node);
+/**
+ * device_add_software_node - Assign software node to a device
+ * @dev: The device the software node is meant for.
+ * @swnode: The software node.
+ *
+ * This function will register @swnode and make it the secondary firmware node
+ * pointer of @dev. If @dev has no primary node, then @swnode will become the
primary
+ * node.
+ */
+int device_add_software_node(struct device *dev, const struct software_node
*swnode)
+{
+ int ret;
+
+ /* Only one software node per device. */
+ if (dev_to_swnode(dev))
+ return -EBUSY;
+
+ ret = software_node_register(swnode);
+ if (ret)
+ return ret;
+
+ set_secondary_fwnode(dev, software_node_fwnode(swnode));
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(device_add_software_node);
+
+/**
+ * device_remove_software_node - Remove device's software node
+ * @dev: The device with the software node.
+ *
+ * This function will unregister the software node of @dev.
+ */
+void device_remove_software_node(struct device *dev)
+{
+ struct swnode *swnode;
+
+ swnode = dev_to_swnode(dev);
+ if (!swnode)
+ return;
+
+ kobject_put(&swnode->kobj);
+}
+EXPORT_SYMBOL_GPL(device_remove_software_node);
+
int software_node_notify(struct device *dev, unsigned long action)
{
struct swnode *swnode;
diff --git a/include/linux/property.h b/include/linux/property.h
index 4a2e0edb78275..5f84286183f9a 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -468,4 +468,7 @@ fwnode_create_software_node(const struct property_entry
*properties,
const struct fwnode_handle *parent);
void fwnode_remove_software_node(struct fwnode_handle *fwnode);
+int device_add_software_node(struct device *dev, const struct software_node
*swnode);
+void device_remove_software_node(struct device *dev);
+
#endif /* _LINUX_PROPERTY_H_ */
--
2.28.0
[PATCH v3] lib/string.c: implement stpcpy
LLVM implemented a recent "libcall optimization" that lowers calls to
`sprintf(dest, "%s", str)` where the return value is used to
`stpcpy(dest, str) - dest`. This generally avoids the machinery involved
in parsing format strings. `stpcpy` is just like `strcpy` except it
returns the pointer to the new tail of `dest`. This optimization was
introduced into clang-12.
Implement this so that we don't observe linkage failures due to missing
symbol definitions for `stpcpy`.
Similar to last year's fire drill with:
commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")
The kernel is somewhere between a "freestanding" environment (no full libc)
and "hosted" environment (many symbols from libc exist with the same
type, function signature, and semantics).
As H. Peter Anvin notes, there's not really a great way to inform the
compiler that you're targeting a freestanding environment but would like
to opt-in to some libcall optimizations (see pr/47280 below), rather than
opt-out.
Arvind notes, -fno-builtin-* behaves slightly differently between GCC
and Clang, and Clang is missing many __builtin_* definitions, which I
consider a bug in Clang and am working on fixing.
Masahiro summarizes the subtle distinction between compilers justly:
To prevent transformation from foo() into bar(), there are two ways in
Clang to do that; -fno-builtin-foo, and -fno-builtin-bar. There is
only one in GCC; -fno-buitin-foo.
(Any difference in that behavior in Clang is likely a bug from a missing
__builtin_* definition.)
Masahiro also notes:
We want to disable optimization from foo() to bar(),
but we may still benefit from the optimization from
foo() into something else. If GCC implements the same transform, we
would run into a problem because it is not -fno-builtin-bar, but
-fno-builtin-foo that disables that optimization.
In this regard, -fno-builtin-foo would be more future-proof than
-fno-built-bar, but -fno-builtin-foo is still potentially overkill. We
may want to prevent calls from foo() being optimized into calls to
bar(), but we still may want other optimization on calls to foo().
It seems that compilers today don't quite provide the fine grain control
over which libcall optimizations pseudo-freestanding environments would
prefer.
Finally, Kees notes that this interface is unsafe, so we should not
encourage its use. As such, I've removed the declaration from any
header, but it still needs to be exported to avoid linkage errors in
modules.
Cc: sta...@vger.kernel.org
Link: https://bugs.llvm.org/show_bug.cgi?id=47162
Link: https://bugs.llvm.org/show_bug.cgi?id=47280
Link: https://github.com/ClangBuiltLinux/linux/issues/1126
Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html
Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html
Link: https://reviews.llvm.org/D85963
Suggested-by: Andy Lavr
Suggested-by: Arvind Sankar
Suggested-by: Joe Perches
Suggested-by: Masahiro Yamada
Suggested-by: Rasmus Villemoes
Reported-by: Sami Tolvanen
Signed-off-by: Nick Desaulniers
---
Changes V3:
* Drop Sami's Tested by tag; newer patch.
* Add EXPORT_SYMBOL as per Andy.
* Rewrite commit message, rewrote part of what Masahiro said to be
generic in terms of foo() and bar().
* Prefer %NUL-terminated to NULL terminated. NUL is the ASCII character
'\0', as per Arvind and Rasmus.
Changes V2:
* Added Sami's Tested by; though the patch changed implementation, the
missing symbol at link time was the problem Sami was observing.
* Fix __restrict -> __restrict__ typo as per Joe.
* Drop note about restrict from commit message as per Arvind.
* Fix NULL -> NUL as per Arvind; NUL is ASCII '\0'. TIL
* Fix off by one error as per Arvind; I had another off by one error in
my test program that was masking this.
lib/string.c | 24
1 file changed, 24 insertions(+)
diff --git a/lib/string.c b/lib/string.c
index 6012c385fb31..6bd0cf0fb009 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -272,6 +272,30 @@ ssize_t strscpy_pad(char *dest, const char *src, size_t
count)
}
EXPORT_SYMBOL(strscpy_pad);
+/**
+ * stpcpy - copy a string from src to dest returning a pointer to the new end
+ * of dest, including src's %NUL-terminator. May overrun dest.
+ * @dest: pointer to end of string being copied into. Must be large enough
+ *to receive copy.
+ * @src: pointer to the beginning of string being copied from. Must not overlap
+ * dest.
+ *
+ * stpcpy differs from strcpy in a key way: the return value is the new
+ * %NUL-terminated character. (for strcpy, the return value is a pointer to
+ * src. This interface is considered unsafe as it doesn't perform bounds
+ * checking of the inputs. As such it's not recommended for usage. Instead,
+ * its definition is provided in case the compiler lowers other libcalls to
+ * stpcpy.
+ */
+char *stpcpy(char *__restrict__ dest, const char *__restrict__ src);
+char *stpcpy(char *__restrict__ dest, const char *__rest
Re: [PATCH] power: supply: Add dependency to lego-ev3-battery Kconfig options
Hi, On Mon, Aug 17, 2020 at 01:25:45PM -0500, David Lechner wrote: > Acked-by: David Lechner Thanks, queued. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH] sched/numa: use runnable_avg to classify node
On Tue, Aug 25, 2020 at 02:18:18PM +0200, Vincent Guittot wrote: > Use runnable_avg to classify numa node state similarly to what is done for > normal load balancer. This helps to ensure that numa and normal balancers > use the same view of the state of the system. > > - large arm64system: 2 nodes / 224 CPUs > hackbench -l (256000/#grp) -g #grp > > grptip/sched/core +patchset improvement > 1 14,008(+/- 4,99 %) 13,800(+/- 3.88 %) 1,48 % > 4 4,340(+/- 5.35 %) 4.283(+/- 4.85 %) 1,33 % > 16 3,357(+/- 0.55 %) 3.359(+/- 0.54 %)-0,06 % > 32 3,050(+/- 0.94 %) 3.039(+/- 1,06 %) 0,38 % > 64 2.968(+/- 1,85 %) 3.006(+/- 2.92 %)-1.27 % > 128 3,290(+/-12.61 %) 3,108(+/- 5.97 %) 5.51 % > 256 3.235(+/- 3.95 %) 3,188(+/- 2.83 %) 1.45 % > Intuitively the patch makes sense but I'm not a fan of using hackbench for evaluating NUMA balancing. The tasks are too short-lived and it's not sensitive enough to data placement because of the small footprint and because hackbench tends to saturate a machine. As predicting NUMA balancing behaviour in your head can be difficult, I've queued up a battery of tests on a few different NUMA machines and will see what falls out. It'll take a few days as some of the tests are long-lived. Baseline will be 5.9-rc2 as I haven't looked at the topology rework in tip/sched/core and this patch should not be related to it. -- Mel Gorman SUSE Labs
[PATCH v1 2/9] powerpc/vdso: Remove get_page() in vdso_pagelist initialization
Partly copied from commit 16fb1a9bec61 ("arm64: vdso: clean up
vdso_pagelist initialization").
No need to get_page() the vdso text/data - these are part of the
kernel image.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/vdso.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 88a4a02ed4c4..3bc4d5b1980b 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -757,11 +757,9 @@ static int __init vdso_init(void)
if (!vdso32_pagelist)
goto alloc_failed;
- for (i = 0; i < vdso32_pages; i++) {
- struct page *pg = virt_to_page(vdso32_kbase + i*PAGE_SIZE);
- get_page(pg);
- vdso32_pagelist[i] = pg;
- }
+ for (i = 0; i < vdso32_pages; i++)
+ vdso32_pagelist[i] = virt_to_page(vdso32_kbase + i * PAGE_SIZE);
+
vdso32_pagelist[i++] = virt_to_page(vdso_data);
vdso32_pagelist[i] = NULL;
#endif
@@ -772,17 +770,13 @@ static int __init vdso_init(void)
if (!vdso64_pagelist)
goto alloc_failed;
- for (i = 0; i < vdso64_pages; i++) {
- struct page *pg = virt_to_page(vdso64_kbase + i*PAGE_SIZE);
- get_page(pg);
- vdso64_pagelist[i] = pg;
- }
+ for (i = 0; i < vdso64_pages; i++)
+ vdso64_pagelist[i] = virt_to_page(vdso64_kbase + i * PAGE_SIZE);
+
vdso64_pagelist[i++] = virt_to_page(vdso_data);
vdso64_pagelist[i] = NULL;
#endif /* CONFIG_PPC64 */
- get_page(virt_to_page(vdso_data));
-
smp_wmb();
vdso_ready = 1;
--
2.25.0
[PATCH v1 4/9] powerpc/vdso: Remove unnecessary ifdefs in vdso_pagelist initialization
No need of all those #ifdefs around the pagelist initialisation,
use IS_ENABLED(), GCC will kick out unused static variables.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/vdso.c | 57 +++---
1 file changed, 22 insertions(+), 35 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index daef14a284a3..bbb69832fd46 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -51,15 +51,13 @@ static struct page **vdso32_pagelist;
unsigned long vdso32_sigtramp;
unsigned long vdso32_rt_sigtramp;
-#ifdef CONFIG_VDSO32
extern char vdso32_start, vdso32_end;
-#endif
-#ifdef CONFIG_PPC64
extern char vdso64_start, vdso64_end;
static void *vdso64_kbase = &vdso64_start;
static unsigned int vdso64_pages;
static struct page **vdso64_pagelist;
+#ifdef CONFIG_PPC64
unsigned long vdso64_rt_sigtramp;
#endif /* CONFIG_PPC64 */
@@ -134,7 +132,6 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
int uses_interp)
if (!vdso_ready)
return 0;
-#ifdef CONFIG_PPC64
if (is_32bit_task()) {
vdso_pagelist = vdso32_pagelist;
vdso_pages = vdso32_pages;
@@ -149,11 +146,6 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
int uses_interp)
*/
vdso_base = 0;
}
-#else
- vdso_pagelist = vdso32_pagelist;
- vdso_pages = vdso32_pages;
- vdso_base = VDSO32_MBASE;
-#endif
current->mm->context.vdso_base = 0;
@@ -718,16 +710,14 @@ static int __init vdso_init(void)
vdso_data->icache_block_size = ppc64_caches.l1i.block_size;
vdso_data->dcache_log_block_size = ppc64_caches.l1d.log_block_size;
vdso_data->icache_log_block_size = ppc64_caches.l1i.log_block_size;
+#endif /* CONFIG_PPC64 */
/*
* Calculate the size of the 64 bits vDSO
*/
vdso64_pages = (&vdso64_end - &vdso64_start) >> PAGE_SHIFT;
DBG("vdso64_kbase: %p, 0x%x pages\n", vdso64_kbase, vdso64_pages);
-#endif /* CONFIG_PPC64 */
-
-#ifdef CONFIG_VDSO32
vdso32_kbase = &vdso32_start;
/*
@@ -735,8 +725,6 @@ static int __init vdso_init(void)
*/
vdso32_pages = (&vdso32_end - &vdso32_start) >> PAGE_SHIFT;
DBG("vdso32_kbase: %p, 0x%x pages\n", vdso32_kbase, vdso32_pages);
-#endif
-
/*
* Setup the syscall map in the vDOS
@@ -750,30 +738,30 @@ static int __init vdso_init(void)
if (vdso_setup())
goto setup_failed;
-#ifdef CONFIG_VDSO32
- /* Make sure pages are in the correct state */
- vdso32_pagelist = kcalloc(vdso32_pages + 1, sizeof(struct page *),
- GFP_KERNEL);
- if (!vdso32_pagelist)
- goto alloc_failed;
+ if (IS_ENABLED(CONFIG_VDSO32)) {
+ /* Make sure pages are in the correct state */
+ vdso32_pagelist = kcalloc(vdso32_pages + 1, sizeof(struct page
*),
+ GFP_KERNEL);
+ if (!vdso32_pagelist)
+ goto alloc_failed;
- for (i = 0; i < vdso32_pages; i++)
- vdso32_pagelist[i] = virt_to_page(vdso32_kbase + i * PAGE_SIZE);
+ for (i = 0; i < vdso32_pages; i++)
+ vdso32_pagelist[i] = virt_to_page(vdso32_kbase + i *
PAGE_SIZE);
- vdso32_pagelist[i] = virt_to_page(vdso_data);
-#endif
+ vdso32_pagelist[i] = virt_to_page(vdso_data);
+ }
-#ifdef CONFIG_PPC64
- vdso64_pagelist = kcalloc(vdso64_pages + 1, sizeof(struct page *),
- GFP_KERNEL);
- if (!vdso64_pagelist)
- goto alloc_failed;
+ if (IS_ENABLED(CONFIG_PPC64)) {
+ vdso64_pagelist = kcalloc(vdso64_pages + 1, sizeof(struct page
*),
+ GFP_KERNEL);
+ if (!vdso64_pagelist)
+ goto alloc_failed;
- for (i = 0; i < vdso64_pages; i++)
- vdso64_pagelist[i] = virt_to_page(vdso64_kbase + i * PAGE_SIZE);
+ for (i = 0; i < vdso64_pages; i++)
+ vdso64_pagelist[i] = virt_to_page(vdso64_kbase + i *
PAGE_SIZE);
- vdso64_pagelist[i] = virt_to_page(vdso_data);
-#endif /* CONFIG_PPC64 */
+ vdso64_pagelist[i] = virt_to_page(vdso_data);
+ }
smp_wmb();
vdso_ready = 1;
@@ -784,9 +772,8 @@ static int __init vdso_init(void)
pr_err("vDSO setup failure, not enabled !\n");
alloc_failed:
vdso32_pages = 0;
-#ifdef CONFIG_PPC64
vdso64_pages = 0;
-#endif
+
return 0;
}
arch_initcall(vdso_init);
--
2.25.0
[PATCH v1 9/9] powerpc/vdso: Remove unused \tmp param in __get_datapage()
The \tmp param is not used anymore, remove it. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/vdso/gettimeofday.h | 4 ++-- arch/powerpc/include/asm/vdso_datapage.h | 2 +- arch/powerpc/kernel/vdso32/cacheflush.S | 2 +- arch/powerpc/kernel/vdso32/datapage.S| 4 ++-- arch/powerpc/kernel/vdso64/cacheflush.S | 2 +- arch/powerpc/kernel/vdso64/datapage.S| 4 ++-- 6 files changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h b/arch/powerpc/include/asm/vdso/gettimeofday.h index 59a609a48b63..8602f1243e8d 100644 --- a/arch/powerpc/include/asm/vdso/gettimeofday.h +++ b/arch/powerpc/include/asm/vdso/gettimeofday.h @@ -22,7 +22,7 @@ #ifdef CONFIG_PPC64 PPC_STL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1) #endif - get_datapager5, r0 + get_datapager5 addir5, r5, VDSO_DATA_OFFSET bl \funct PPC_LL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1) @@ -51,7 +51,7 @@ #ifdef CONFIG_PPC64 PPC_STL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1) #endif - get_datapager4, r0 + get_datapager4 addir4, r4, VDSO_DATA_OFFSET bl \funct PPC_LL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1) diff --git a/arch/powerpc/include/asm/vdso_datapage.h b/arch/powerpc/include/asm/vdso_datapage.h index 2bc415f7714c..71f44598f392 100644 --- a/arch/powerpc/include/asm/vdso_datapage.h +++ b/arch/powerpc/include/asm/vdso_datapage.h @@ -102,7 +102,7 @@ extern struct vdso_arch_data *vdso_data; #else /* __ASSEMBLY__ */ -.macro get_datapage ptr, tmp +.macro get_datapage ptr bcl 20, 31, .+4 999: mflr\ptr diff --git a/arch/powerpc/kernel/vdso32/cacheflush.S b/arch/powerpc/kernel/vdso32/cacheflush.S index 3440ddf21c8b..017843bf5382 100644 --- a/arch/powerpc/kernel/vdso32/cacheflush.S +++ b/arch/powerpc/kernel/vdso32/cacheflush.S @@ -27,7 +27,7 @@ V_FUNCTION_BEGIN(__kernel_sync_dicache) #ifdef CONFIG_PPC64 mflrr12 .cfi_register lr,r12 - get_datapager10, r0 + get_datapager10 mtlrr12 #endif diff --git a/arch/powerpc/kernel/vdso32/datapage.S b/arch/powerpc/kernel/vdso32/datapage.S index 5513a4f8253e..0513a2eabec8 100644 --- a/arch/powerpc/kernel/vdso32/datapage.S +++ b/arch/powerpc/kernel/vdso32/datapage.S @@ -28,7 +28,7 @@ V_FUNCTION_BEGIN(__kernel_get_syscall_map) mflrr12 .cfi_register lr,r12 mr. r4,r3 - get_datapager3, r0 + get_datapager3 mtlrr12 addir3,r3,CFG_SYSCALL_MAP32 beqlr @@ -49,7 +49,7 @@ V_FUNCTION_BEGIN(__kernel_get_tbfreq) .cfi_startproc mflrr12 .cfi_register lr,r12 - get_datapager3, r0 + get_datapager3 lwz r4,(CFG_TB_TICKS_PER_SEC + 4)(r3) lwz r3,CFG_TB_TICKS_PER_SEC(r3) mtlrr12 diff --git a/arch/powerpc/kernel/vdso64/cacheflush.S b/arch/powerpc/kernel/vdso64/cacheflush.S index cab14324242b..61985de5758f 100644 --- a/arch/powerpc/kernel/vdso64/cacheflush.S +++ b/arch/powerpc/kernel/vdso64/cacheflush.S @@ -25,7 +25,7 @@ V_FUNCTION_BEGIN(__kernel_sync_dicache) .cfi_startproc mflrr12 .cfi_register lr,r12 - get_datapager10, r0 + get_datapager10 mtlrr12 lwz r7,CFG_DCACHE_BLOCKSZ(r10) diff --git a/arch/powerpc/kernel/vdso64/datapage.S b/arch/powerpc/kernel/vdso64/datapage.S index 03bb72c440dc..00760dc69d68 100644 --- a/arch/powerpc/kernel/vdso64/datapage.S +++ b/arch/powerpc/kernel/vdso64/datapage.S @@ -28,7 +28,7 @@ V_FUNCTION_BEGIN(__kernel_get_syscall_map) mflrr12 .cfi_register lr,r12 mr r4,r3 - get_datapager3, r0 + get_datapager3 mtlrr12 addir3,r3,CFG_SYSCALL_MAP64 cmpldi cr0,r4,0 @@ -50,7 +50,7 @@ V_FUNCTION_BEGIN(__kernel_get_tbfreq) .cfi_startproc mflrr12 .cfi_register lr,r12 - get_datapager3, r0 + get_datapager3 ld r3,CFG_TB_TICKS_PER_SEC(r3) mtlrr12 crclr cr0*4+so -- 2.25.0
[PATCH v1 5/9] powerpc/vdso: move to _install_special_mapping() and remove arch_vma_name()
>From commit 2fea7f6c98f5 ("arm64: vdso: move to
_install_special_mapping and remove arch_vma_name").
Use the new _install_special_mapping() API added by
commit a62c34bd2a8a ("x86, mm: Improve _install_special_mapping
and fix x86 vdso naming") which obsolete install_special_mapping().
And remove arch_vma_name() as the name is handled by the new API.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/vdso.c | 59 +++---
1 file changed, 30 insertions(+), 29 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index bbb69832fd46..4ccfc0dc96b5 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -47,7 +47,6 @@
static unsigned int vdso32_pages;
static void *vdso32_kbase;
-static struct page **vdso32_pagelist;
unsigned long vdso32_sigtramp;
unsigned long vdso32_rt_sigtramp;
@@ -56,7 +55,6 @@ extern char vdso32_start, vdso32_end;
extern char vdso64_start, vdso64_end;
static void *vdso64_kbase = &vdso64_start;
static unsigned int vdso64_pages;
-static struct page **vdso64_pagelist;
#ifdef CONFIG_PPC64
unsigned long vdso64_rt_sigtramp;
#endif /* CONFIG_PPC64 */
@@ -117,6 +115,14 @@ struct lib64_elfinfo
};
+static struct vm_special_mapping vdso32_spec __ro_after_init = {
+ .name = "[vdso]",
+};
+
+static struct vm_special_mapping vdso64_spec __ro_after_init = {
+ .name = "[vdso]",
+};
+
/*
* This is called from binfmt_elf, we create the special vma for the
* vDSO and insert it into the mm struct tree
@@ -124,7 +130,8 @@ struct lib64_elfinfo
int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
{
struct mm_struct *mm = current->mm;
- struct page **vdso_pagelist;
+ struct vm_special_mapping *vdso_spec;
+ struct vm_area_struct *vma;
unsigned long vdso_pages;
unsigned long vdso_base;
int rc;
@@ -133,11 +140,11 @@ int arch_setup_additional_pages(struct linux_binprm
*bprm, int uses_interp)
return 0;
if (is_32bit_task()) {
- vdso_pagelist = vdso32_pagelist;
+ vdso_spec = &vdso32_spec;
vdso_pages = vdso32_pages;
vdso_base = VDSO32_MBASE;
} else {
- vdso_pagelist = vdso64_pagelist;
+ vdso_spec = &vdso64_spec;
vdso_pages = vdso64_pages;
/*
* On 64bit we don't have a preferred map address. This
@@ -194,12 +201,12 @@ int arch_setup_additional_pages(struct linux_binprm
*bprm, int uses_interp)
* It's fine to use that for setting breakpoints in the vDSO code
* pages though.
*/
- rc = install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
-VM_READ|VM_EXEC|
-VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
-vdso_pagelist);
- if (rc) {
+ vma = _install_special_mapping(mm, vdso_base, vdso_pages << PAGE_SHIFT,
+ VM_READ | VM_EXEC | VM_MAYREAD |
+ VM_MAYWRITE | VM_MAYEXEC, vdso_spec);
+ if (IS_ERR(vma)) {
current->mm->context.vdso_base = 0;
+ rc = PTR_ERR(vma);
goto fail_mmapsem;
}
@@ -211,15 +218,6 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
int uses_interp)
return rc;
}
-const char *arch_vma_name(struct vm_area_struct *vma)
-{
- if (vma->vm_mm && vma->vm_start == vma->vm_mm->context.vdso_base)
- return "[vdso]";
- return NULL;
-}
-
-
-
#ifdef CONFIG_VDSO32
static void * __init find_section32(Elf32_Ehdr *ehdr, const char *secname,
unsigned long *size)
@@ -685,6 +683,7 @@ early_initcall(vdso_getcpu_init);
static int __init vdso_init(void)
{
int i;
+ struct page **pagelist;
#ifdef CONFIG_PPC64
/*
@@ -740,27 +739,29 @@ static int __init vdso_init(void)
if (IS_ENABLED(CONFIG_VDSO32)) {
/* Make sure pages are in the correct state */
- vdso32_pagelist = kcalloc(vdso32_pages + 1, sizeof(struct page
*),
- GFP_KERNEL);
- if (!vdso32_pagelist)
+ pagelist = kcalloc(vdso32_pages + 1, sizeof(struct page *),
GFP_KERNEL);
+ if (!pagelist)
goto alloc_failed;
for (i = 0; i < vdso32_pages; i++)
- vdso32_pagelist[i] = virt_to_page(vdso32_kbase + i *
PAGE_SIZE);
+ pagelist[i] = virt_to_page(vdso32_kbase + i *
PAGE_SIZE);
+
+ pagelist[i++] = virt_to_page(vdso_data);
- vdso32_pagelist[i] = virt_to_page(vdso_data);
+ vdso32_spec.pages = pagelist;
}
if (IS_ENABLED(CONFIG_PPC64)) {
- vdso64_pagelist = kcalloc(v
[PATCH v1 1/9] powerpc/vdso: Remove BUG_ON() in vdso_init()
If we are not able to allocate memory for the pagelists, bail out.
There is no reason to crash the machine, just have vdso init fail.
Signed-off-by: Christophe Leroy
---
This series is based on top of the series switching to C VDSO implementation,
but in fact only the last patch depends on that series and is not vital as
it is just afterwork cleanup.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/vdso.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 23208a051af5..88a4a02ed4c4 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -747,20 +747,16 @@ static int __init vdso_init(void)
* Initialize the vDSO images in memory, that is do necessary
* fixups of vDSO symbols, locate trampolines, etc...
*/
- if (vdso_setup()) {
- printk(KERN_ERR "vDSO setup failure, not enabled !\n");
- vdso32_pages = 0;
-#ifdef CONFIG_PPC64
- vdso64_pages = 0;
-#endif
- return 0;
- }
+ if (vdso_setup())
+ goto setup_failed;
#ifdef CONFIG_VDSO32
/* Make sure pages are in the correct state */
vdso32_pagelist = kcalloc(vdso32_pages + 2, sizeof(struct page *),
GFP_KERNEL);
- BUG_ON(vdso32_pagelist == NULL);
+ if (!vdso32_pagelist)
+ goto alloc_failed;
+
for (i = 0; i < vdso32_pages; i++) {
struct page *pg = virt_to_page(vdso32_kbase + i*PAGE_SIZE);
get_page(pg);
@@ -773,7 +769,9 @@ static int __init vdso_init(void)
#ifdef CONFIG_PPC64
vdso64_pagelist = kcalloc(vdso64_pages + 2, sizeof(struct page *),
GFP_KERNEL);
- BUG_ON(vdso64_pagelist == NULL);
+ if (!vdso64_pagelist)
+ goto alloc_failed;
+
for (i = 0; i < vdso64_pages; i++) {
struct page *pg = virt_to_page(vdso64_kbase + i*PAGE_SIZE);
get_page(pg);
@@ -789,5 +787,14 @@ static int __init vdso_init(void)
vdso_ready = 1;
return 0;
+
+setup_failed:
+ pr_err("vDSO setup failure, not enabled !\n");
+alloc_failed:
+ vdso32_pages = 0;
+#ifdef CONFIG_PPC64
+ vdso64_pages = 0;
+#endif
+ return 0;
}
arch_initcall(vdso_init);
--
2.25.0
[PATCH v1 3/9] powerpc/vdso: Remove NULL termination element in vdso_pagelist
No need of a NULL last element in pagelists, install_special_mapping() knows how long the list is. Remove that element. Signed-off-by: Christophe Leroy --- arch/powerpc/kernel/vdso.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c index 3bc4d5b1980b..daef14a284a3 100644 --- a/arch/powerpc/kernel/vdso.c +++ b/arch/powerpc/kernel/vdso.c @@ -752,7 +752,7 @@ static int __init vdso_init(void) #ifdef CONFIG_VDSO32 /* Make sure pages are in the correct state */ - vdso32_pagelist = kcalloc(vdso32_pages + 2, sizeof(struct page *), + vdso32_pagelist = kcalloc(vdso32_pages + 1, sizeof(struct page *), GFP_KERNEL); if (!vdso32_pagelist) goto alloc_failed; @@ -760,12 +760,11 @@ static int __init vdso_init(void) for (i = 0; i < vdso32_pages; i++) vdso32_pagelist[i] = virt_to_page(vdso32_kbase + i * PAGE_SIZE); - vdso32_pagelist[i++] = virt_to_page(vdso_data); - vdso32_pagelist[i] = NULL; + vdso32_pagelist[i] = virt_to_page(vdso_data); #endif #ifdef CONFIG_PPC64 - vdso64_pagelist = kcalloc(vdso64_pages + 2, sizeof(struct page *), + vdso64_pagelist = kcalloc(vdso64_pages + 1, sizeof(struct page *), GFP_KERNEL); if (!vdso64_pagelist) goto alloc_failed; @@ -773,8 +772,7 @@ static int __init vdso_init(void) for (i = 0; i < vdso64_pages; i++) vdso64_pagelist[i] = virt_to_page(vdso64_kbase + i * PAGE_SIZE); - vdso64_pagelist[i++] = virt_to_page(vdso_data); - vdso64_pagelist[i] = NULL; + vdso64_pagelist[i] = virt_to_page(vdso_data); #endif /* CONFIG_PPC64 */ smp_wmb(); -- 2.25.0
[PATCH v1 7/9] powerpc/vdso: Move vdso datapage up front
Move the vdso datapage in front of the VDSO area,
before vdso test.
This will allow to remove the __kernel_datapage_offset symbol
and simplify __get_datapage() in the following patch.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/mmu_context.h | 4 +++-
arch/powerpc/kernel/vdso.c | 22 ++
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu_context.h
b/arch/powerpc/include/asm/mmu_context.h
index 7f3658a97384..be18ad12bb54 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -262,7 +262,9 @@ extern void arch_exit_mmap(struct mm_struct *mm);
static inline void arch_unmap(struct mm_struct *mm,
unsigned long start, unsigned long end)
{
- if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
+ unsigned long vdso_base = mm->context.vdso_base - PAGE_SIZE;
+
+ if (start <= vdso_base && vdso_base < end)
mm->context.vdso_base = 0;
}
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index b9270923452e..1d72c4b7672f 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -124,7 +124,7 @@ static int vdso_mremap(unsigned long vdso_pages,
if (new_size != vdso_size)
return -EINVAL;
- current->mm->context.vdso_base = (unsigned long)new_vma->vm_start;
+ current->mm->context.vdso_base = (unsigned long)new_vma->vm_start +
PAGE_SIZE;
return 0;
}
@@ -217,7 +217,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
int uses_interp)
* install_special_mapping or the perf counter mmap tracking code
* will fail to recognise it as a vDSO (since arch_vma_name fails).
*/
- current->mm->context.vdso_base = vdso_base;
+ current->mm->context.vdso_base = vdso_base + PAGE_SIZE;
/*
* our vma flags don't have VM_WRITE so by default, the process isn't
@@ -516,8 +516,7 @@ static __init int vdso_fixup_datapage(struct lib32_elfinfo
*v32,
return -1;
}
*((int *)(vdso64_kbase + sym64->st_value - VDSO64_LBASE)) =
- (vdso64_pages << PAGE_SHIFT) -
- (sym64->st_value - VDSO64_LBASE);
+ (sym64->st_value - VDSO64_LBASE) - PAGE_SIZE;
#endif /* CONFIG_PPC64 */
#ifdef CONFIG_VDSO32
@@ -528,8 +527,7 @@ static __init int vdso_fixup_datapage(struct lib32_elfinfo
*v32,
return -1;
}
*((int *)(vdso32_kbase + (sym32->st_value - VDSO32_LBASE))) =
- (vdso32_pages << PAGE_SHIFT) -
- (sym32->st_value - VDSO32_LBASE);
+ (sym32->st_value - VDSO32_LBASE) - PAGE_SIZE;
#endif
return 0;
@@ -771,10 +769,10 @@ static int __init vdso_init(void)
if (!pagelist)
goto alloc_failed;
- for (i = 0; i < vdso32_pages; i++)
- pagelist[i] = virt_to_page(vdso32_kbase + i *
PAGE_SIZE);
+ pagelist[0] = virt_to_page(vdso_data);
- pagelist[i++] = virt_to_page(vdso_data);
+ for (i = 0; i < vdso32_pages; i++)
+ pagelist[i + 1] = virt_to_page(vdso32_kbase + i *
PAGE_SIZE);
vdso32_spec.pages = pagelist;
}
@@ -784,10 +782,10 @@ static int __init vdso_init(void)
if (!pagelist)
goto alloc_failed;
- for (i = 0; i < vdso64_pages; i++)
- pagelist[i] = virt_to_page(vdso64_kbase + i *
PAGE_SIZE);
+ pagelist[0] = virt_to_page(vdso_data);
- pagelist[i++] = virt_to_page(vdso_data);
+ for (i = 0; i < vdso64_pages; i++)
+ pagelist[i + 1] = virt_to_page(vdso64_kbase + i *
PAGE_SIZE);
vdso64_spec.pages = pagelist;
}
--
2.25.0
[PATCH v1 6/9] powerpc/vdso: Provide vdso_remap()
Provide vdso_remap() through _install_special_mapping() and
drop arch_remap().
This adds a test of the size and returns -EINVAL if the size
is not correct.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/mm-arch-hooks.h | 25 -
arch/powerpc/kernel/vdso.c | 28
2 files changed, 28 insertions(+), 25 deletions(-)
delete mode 100644 arch/powerpc/include/asm/mm-arch-hooks.h
diff --git a/arch/powerpc/include/asm/mm-arch-hooks.h
b/arch/powerpc/include/asm/mm-arch-hooks.h
deleted file mode 100644
index dce274be824a..
--- a/arch/powerpc/include/asm/mm-arch-hooks.h
+++ /dev/null
@@ -1,25 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Architecture specific mm hooks
- *
- * Copyright (C) 2015, IBM Corporation
- * Author: Laurent Dufour
- */
-
-#ifndef _ASM_POWERPC_MM_ARCH_HOOKS_H
-#define _ASM_POWERPC_MM_ARCH_HOOKS_H
-
-static inline void arch_remap(struct mm_struct *mm,
- unsigned long old_start, unsigned long old_end,
- unsigned long new_start, unsigned long new_end)
-{
- /*
-* mremap() doesn't allow moving multiple vmas so we can limit the
-* check to old_start == vdso_base.
-*/
- if (old_start == mm->context.vdso_base)
- mm->context.vdso_base = new_start;
-}
-#define arch_remap arch_remap
-
-#endif /* _ASM_POWERPC_MM_ARCH_HOOKS_H */
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 4ccfc0dc96b5..b9270923452e 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -114,13 +114,41 @@ struct lib64_elfinfo
unsigned long text;
};
+static int vdso_mremap(unsigned long vdso_pages,
+ const struct vm_special_mapping *sm,
+ struct vm_area_struct *new_vma)
+{
+ unsigned long new_size = new_vma->vm_end - new_vma->vm_start;
+ unsigned long vdso_size = (vdso_pages + 1) << PAGE_SHIFT;
+
+ if (new_size != vdso_size)
+ return -EINVAL;
+
+ current->mm->context.vdso_base = (unsigned long)new_vma->vm_start;
+
+ return 0;
+}
+
+static int vdso32_mremap(const struct vm_special_mapping *sm,
+struct vm_area_struct *new_vma)
+{
+ return vdso_mremap(vdso32_pages, sm, new_vma);
+}
+
+static int vdso64_mremap(const struct vm_special_mapping *sm,
+struct vm_area_struct *new_vma)
+{
+ return vdso_mremap(vdso64_pages, sm, new_vma);
+}
static struct vm_special_mapping vdso32_spec __ro_after_init = {
.name = "[vdso]",
+ .mremap = vdso32_mremap,
};
static struct vm_special_mapping vdso64_spec __ro_after_init = {
.name = "[vdso]",
+ .mremap = vdso64_mremap,
};
/*
--
2.25.0
[PATCH v1 8/9] powerpc/vdso: Remove __kernel_datapage_offset and simplify __get_datapage()
The VDSO datapage and the text pages are always located immediately
next to each other, so it can be hardcoded without an indirection
through __kernel_datapage_offset
Before:
clock-getres-realtime-coarse:vdso: 714 nsec/call
clock-gettime-realtime-coarse:vdso: 792 nsec/call
clock-gettime-realtime:vdso: 1243 nsec/call
After:
clock-getres-realtime-coarse:vdso: 699 nsec/call
clock-gettime-realtime-coarse:vdso: 784 nsec/call
clock-gettime-realtime:vdso: 1231 nsec/call
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/vdso_datapage.h | 8 +++--
arch/powerpc/kernel/vdso.c | 37
arch/powerpc/kernel/vdso32/datapage.S| 3 --
arch/powerpc/kernel/vdso32/vdso32.lds.S | 7 ++---
arch/powerpc/kernel/vdso64/datapage.S| 3 --
arch/powerpc/kernel/vdso64/vdso64.lds.S | 7 ++---
6 files changed, 9 insertions(+), 56 deletions(-)
diff --git a/arch/powerpc/include/asm/vdso_datapage.h
b/arch/powerpc/include/asm/vdso_datapage.h
index c4d320504d26..2bc415f7714c 100644
--- a/arch/powerpc/include/asm/vdso_datapage.h
+++ b/arch/powerpc/include/asm/vdso_datapage.h
@@ -104,10 +104,12 @@ extern struct vdso_arch_data *vdso_data;
.macro get_datapage ptr, tmp
bcl 20, 31, .+4
+999:
mflr\ptr
- addi\ptr, \ptr, (__kernel_datapage_offset - (.-4))@l
- lwz \tmp, 0(\ptr)
- add \ptr, \tmp, \ptr
+#if CONFIG_PPC_PAGE_SHIFT > 14
+ addis \ptr, \ptr, (_vdso_datapage - 999b)@ha
+#endif
+ addi\ptr, \ptr, (_vdso_datapage - 999b)@l
.endm
#endif /* __ASSEMBLY__ */
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 1d72c4b7672f..e2568d9ecdff 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -500,40 +500,6 @@ static __init void vdso_setup_trampolines(struct
lib32_elfinfo *v32,
vdso32_rt_sigtramp = find_function32(v32, "__kernel_sigtramp_rt32");
}
-static __init int vdso_fixup_datapage(struct lib32_elfinfo *v32,
- struct lib64_elfinfo *v64)
-{
-#ifdef CONFIG_VDSO32
- Elf32_Sym *sym32;
-#endif
-#ifdef CONFIG_PPC64
- Elf64_Sym *sym64;
-
- sym64 = find_symbol64(v64, "__kernel_datapage_offset");
- if (sym64 == NULL) {
- printk(KERN_ERR "vDSO64: Can't find symbol "
- "__kernel_datapage_offset !\n");
- return -1;
- }
- *((int *)(vdso64_kbase + sym64->st_value - VDSO64_LBASE)) =
- (sym64->st_value - VDSO64_LBASE) - PAGE_SIZE;
-#endif /* CONFIG_PPC64 */
-
-#ifdef CONFIG_VDSO32
- sym32 = find_symbol32(v32, "__kernel_datapage_offset");
- if (sym32 == NULL) {
- printk(KERN_ERR "vDSO32: Can't find symbol "
- "__kernel_datapage_offset !\n");
- return -1;
- }
- *((int *)(vdso32_kbase + (sym32->st_value - VDSO32_LBASE))) =
- (sym32->st_value - VDSO32_LBASE) - PAGE_SIZE;
-#endif
-
- return 0;
-}
-
-
static __init int vdso_fixup_features(struct lib32_elfinfo *v32,
struct lib64_elfinfo *v64)
{
@@ -634,9 +600,6 @@ static __init int vdso_setup(void)
if (vdso_do_find_sections(&v32, &v64))
return -1;
- if (vdso_fixup_datapage(&v32, &v64))
- return -1;
-
if (vdso_fixup_features(&v32, &v64))
return -1;
diff --git a/arch/powerpc/kernel/vdso32/datapage.S
b/arch/powerpc/kernel/vdso32/datapage.S
index 217bb630f8f9..5513a4f8253e 100644
--- a/arch/powerpc/kernel/vdso32/datapage.S
+++ b/arch/powerpc/kernel/vdso32/datapage.S
@@ -13,9 +13,6 @@
#include
.text
- .global __kernel_datapage_offset;
-__kernel_datapage_offset:
- .long 0
/*
* void *__kernel_get_syscall_map(unsigned int *syscall_count) ;
diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S
b/arch/powerpc/kernel/vdso32/vdso32.lds.S
index 582c5b046cc9..25be27b47a9f 100644
--- a/arch/powerpc/kernel/vdso32/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S
@@ -4,6 +4,7 @@
* library
*/
#include
+#include
#ifdef __LITTLE_ENDIAN__
OUTPUT_FORMAT("elf32-powerpcle", "elf32-powerpcle", "elf32-powerpcle")
@@ -15,6 +16,7 @@ ENTRY(_start)
SECTIONS
{
+ PROVIDE(_vdso_datapage = . - PAGE_SIZE);
. = VDSO32_LBASE + SIZEOF_HEADERS;
.hash : { *(.hash) } :text
@@ -139,11 +141,6 @@ VERSION
{
VDSO_VERSION_STRING {
global:
- /*
-* Has to be there for the kernel to find
-*/
- __kernel_datapage_offset;
-
__kernel_get_syscall_map;
#ifndef CONFIG_PPC_BOOK3S_601
__kernel_gettimeofday;
diff --git a/arch/powerpc/kernel/vdso64/datapage.S
b/arch/powerpc/kernel/vdso64/datapage.S
index 067247d3efb9..03bb72c440dc 100644
--- a/arch/powerpc/kernel/vdso64/datapage.S
+++ b/arch/powerpc/ke
Re: [PATCH 0/2][next] update gdb scripts for lockless printk ringbuffer
On 25.08.20 14:35, Petr Mladek wrote: > On Mon 2020-08-24 10:20:53, Kieran Bingham wrote: >> Hi Petr, >> >> On 21/08/2020 09:55, Jan Kiszka wrote: >>> On 21.08.20 10:08, Petr Mladek wrote: On Fri 2020-08-14 23:31:23, John Ogness wrote: > Hi, > > When we brought in the new lockless printk ringbuffer, we overlooked the > gdb > scripts. Here are a set of patches to implement gdb support for the new > ringbuffer. > > John Ogness (2): > scripts/gdb: add utils.read_ulong() > scripts/gdb: update for lockless printk ringbuffer I am not fluent in the gdb macros and python so I did not try any deep review. But both patches work for me: Tested-by: Petr Mladek I am going to give it few more days before pushing just in case there is another feedback. >> >> Before 'pushing' ? >> >> What context do you mean here? These patches go through AKPM don't they? >> Did I miss some update to procedures? > > Both patches should go into mainline together with the lockless printk > ring buffer. It is already in linux-next via printk/linux.git, > branch printk-rework. > > The plan is to get it into mainline when pr_cont() handling is solved. > It is more complicated than we hoped for, see > https://lore.kernel.org/r/20200824103538.31446-1-john.ogn...@linutronix.de > It is still not clear whether it will be ready for 5.10. > > Andrew, would you mind when I take the three gdb/lockless-printk > related changes via printk tree to avoid synchronization problems? >From my POV, that would be best in this case - but actually also in other cases where developers happen to notice the dependency between their refactorings and gdb scripts. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH v2 0/3] Some clean-ups for bio merge
Hi, On Tue, Aug 18, 2020 at 01:45:27PM +0800, Baolin Wang wrote: > Hi, > > There are some duplicated code when trying to merge bio from pluged list > and software queue, thus this patch set did some clean-ups when merging > a bio. Any comments are welcome. Thanks. > > Changes from v1: > - Drop patch 2 and patch 5 in v1 patch set. > - Add reviewed-by tag from Christoph. > - Move blk_mq_bio_list_merge() into blk-merge.c and rename it. > - Some coding style improvements. Any comments for this patch set? Thanks. > > Baolin Wang (3): > block: Move bio merge related functions into blk-merge.c > block: Add a new helper to attempt to merge a bio > block: Remove blk_mq_attempt_merge() function > > block/blk-core.c | 156 -- > block/blk-merge.c | 202 > + > block/blk-mq-sched.c | 94 +-- > block/blk.h| 23 -- > block/kyber-iosched.c | 2 +- > include/linux/blk-mq.h | 2 - > 6 files changed, 239 insertions(+), 240 deletions(-) > > -- > 1.8.3.1
Re: [PATCH v5 00/16] Allwinner A100 Initial support
On Tue, 25 Aug 2020, Maxime Ripard wrote: > On Mon, Aug 24, 2020 at 09:03:27AM +0100, Lee Jones wrote: > > On Mon, 24 Aug 2020, Frank Lee wrote: > > > > > ping.. > > > > "Please don't send content free pings and please allow a reasonable > > time for review. People get busy, go on holiday, attend conferences > > and so on so unless there is some reason for urgency (like critical > > bug fixes) please allow at least a couple of weeks for review. If > > there have been review comments then people may be waiting for those > > to be addressed. Sending content free pings just adds to the mail > > volume (if they are seen at all) and if something has gone wrong > > you'll have to resend the patches anyway so [RESEND]ing with any > > comments addressed is generally a much better approach." > > This is true to some extent, but pinging after a month doesn't seem > unreasonable either. Pinging is mostly a fruitless exercise. After a month, many Maintainers would have purged any un-serviced mails anyway. If a patch-set is left hanging, still requiring attention before the next version, submitting a [RESEND] is generally a better option. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v5 00/16] Allwinner A100 Initial support
On Tue, Aug 25, 2020 at 10:55:32AM +0200, Maxime Ripard wrote: > On Mon, Aug 24, 2020 at 09:03:27AM +0100, Lee Jones wrote: > > On Mon, 24 Aug 2020, Frank Lee wrote: > > > > > ping.. > > > > "Please don't send content free pings and please allow a reasonable > > time for review. People get busy, go on holiday, attend conferences > > and so on so unless there is some reason for urgency (like critical > > bug fixes) please allow at least a couple of weeks for review. If > > there have been review comments then people may be waiting for those > > to be addressed. Sending content free pings just adds to the mail > > volume (if they are seen at all) and if something has gone wrong > > you'll have to resend the patches anyway so [RESEND]ing with any > > comments addressed is generally a much better approach." > > This is true to some extent, but pinging after a month doesn't seem > unreasonable either. Especially if resending would mean up to 16 patches sent again. signature.asc Description: PGP signature
[PATCH] clk: renesas: cpg-mssr: Add clk entry for VSPR
Add clock entry 130 for VSPR module, so that this module can be used
on R8A7742 (RZ/G1H) SoC.
Note: The entry for VSPR clock was accidentally dropped from RZ/G manual
when all the information related to RT were removed.
Signed-off-by: Lad Prabhakar
Reviewed-by: Biju Das
---
Similar details can be seen in commit 79ea9934b8df ("ARM: shmobile:
r8a7790: Rename VSP1_(SY|RT) clocks to VSP1_(S|R)") for R-Car H2
---
drivers/clk/renesas/r8a7742-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r8a7742-cpg-mssr.c
b/drivers/clk/renesas/r8a7742-cpg-mssr.c
index e919828668a4..28b24c4e9d7d 100644
--- a/drivers/clk/renesas/r8a7742-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7742-cpg-mssr.c
@@ -97,6 +97,7 @@ static const struct mssr_mod_clk r8a7742_mod_clks[]
__initconst = {
DEF_MOD("tmu0", 125, R8A7742_CLK_CP),
DEF_MOD("vsp1du1", 127, R8A7742_CLK_ZS),
DEF_MOD("vsp1du0", 128, R8A7742_CLK_ZS),
+ DEF_MOD("vspr", 130, R8A7742_CLK_ZS),
DEF_MOD("vsp1-sy", 131, R8A7742_CLK_ZS),
DEF_MOD("scifa2",202, R8A7742_CLK_MP),
DEF_MOD("scifa1",203, R8A7742_CLK_MP),
--
2.17.1
Re: [PATCH] ARM: dts: sun4i: Enable HDMI support on the Mele A1000
On Fri, Aug 21, 2020 at 01:18:33PM -0400, Stefan Monnier wrote: > Enable the display pipeline and HDMI output. > > Signed-off-by: Stefan Monnier Applied, thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH 0/2] ARM: dts: sun8i: r40: Enable mali400 GPU
On Mon, Aug 24, 2020 at 05:04:32PM +0200, Jernej Skrabec wrote: > Following two patches enable Mali400 GPU on Allwinner R40 SoC. At this > point I didn't add table for frequency switching because it would > require far more testing and defaults work stable and reasonably well. > > Please take a look. Applied both, thanks Maxime signature.asc Description: PGP signature
[PATCH mmc-next v3 2/2] mmc: allow setting slot index via device tree alias
As with GPIO, UART and others, allow specifying the device index via the
aliases node in the device tree.
On embedded devices, there is often a combination of removable (e.g.
SD card) and non-removable MMC devices (e.g. eMMC).
Therefore the index might change depending on
* host of removable device
* removable card present or not
This makes it difficult to hardcode the root device, if it is on the
non-removable device. E.g. if SD card is present eMMC will be mmcblk1,
if SD card is not present at boot, eMMC will be mmcblk0.
Alternative solutions like PARTUUIDs do not cover the case where multiple
mmcblk devices contain the same image. This is a common issue on devices
that can boot both from eMMC (for regular boot) and SD cards (as a
temporary boot medium for development). When a firmware image is
installed to eMMC after a test boot via SD card, there will be no
reliable way to refer to a specific device using (PART)UUIDs oder
LABELs.
The demand for this feature has led to multiple attempts to implement
it, dating back at least to 2012 (see
https://www.spinics.net/lists/linux-mmc/msg26586.html for a previous
discussion from 2014).
All indices defined in the aliases node will be reserved for use by the
respective MMC device, moving the indices of devices that don't have an
alias up into the non-reserved range. If the aliases node is not found,
the driver will act as before.
This is a rebased and slightly cleaned up version of
https://www.spinics.net/lists/linux-mmc/msg26588.html .
Based-on-patch-by: Sascha Hauer
Link: https://lkml.org/lkml/2020/8/5/194
Signed-off-by: Matthias Schiffer
---
v3:
- remove unneeded mmcblock changes
- remove most helper functions to simplify code
- extended commit message
v2:
- fix missing symbols for modular mmcblock
drivers/mmc/core/host.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index c8fae6611b73..96b2ca1f1b06 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -376,6 +376,20 @@ int mmc_of_parse_voltage(struct device_node *np, u32 *mask)
}
EXPORT_SYMBOL(mmc_of_parse_voltage);
+/**
+ * mmc_first_nonreserved_index() - get the first index that is not reserved
+ */
+static int mmc_first_nonreserved_index(void)
+{
+ int max;
+
+ max = of_alias_get_highest_id("mmc");
+ if (max < 0)
+ return 0;
+
+ return max + 1;
+}
+
/**
* mmc_alloc_host - initialise the per-host structure.
* @extra: sizeof private data structure
@@ -387,6 +401,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct device
*dev)
{
int err;
struct mmc_host *host;
+ int alias_id, min_idx, max_idx;
host = kzalloc(sizeof(struct mmc_host) + extra, GFP_KERNEL);
if (!host)
@@ -395,7 +410,16 @@ struct mmc_host *mmc_alloc_host(int extra, struct device
*dev)
/* scanning will be enabled when we're ready */
host->rescan_disable = 1;
- err = ida_simple_get(&mmc_host_ida, 0, 0, GFP_KERNEL);
+ alias_id = of_alias_get_id(dev->of_node, "mmc");
+ if (alias_id >= 0) {
+ min_idx = alias_id;
+ max_idx = alias_id + 1;
+ } else {
+ min_idx = mmc_first_nonreserved_index();
+ max_idx = 0;
+ }
+
+ err = ida_simple_get(&mmc_host_ida, min_idx, max_idx, GFP_KERNEL);
if (err < 0) {
kfree(host);
return NULL;
--
2.17.1
Re: [PATCH v5 05/16] pinctrl: sunxi: add support for the Allwinner A100 pin controller
On Fri, Jul 24, 2020 at 03:05:49PM +0800, Frank Lee wrote: > From: Yangtao Li > > This commit introduces support for the pin controller on A100. > > Signed-off-by: Yangtao Li Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH] arm64: dts: allwinner: h5: remove Mali GPU PMU module
On Sat, Aug 22, 2020 at 02:27:55PM +0800, Qiang Yu wrote:
> H5's Mali GPU PMU is not present or working corretly although
> H5 datasheet record its interrupt vector.
>
> Adding this module will miss lead lima driver try to shutdown
> it and get waiting timeout. This problem is not exposed before
> lima runtime PM supoprt is added.
>
> Fixes: bb39ed07e55b ("arm64: dts: allwinner: h5: Add device node for Mali-450
> GPU")
> Signed-off-by: Qiang Yu
Fixed the typo (s/supoprt/support) and applied, thanks!
Maxime
signature.asc
Description: PGP signature
[PATCH mmc-next v3 1/2] dt-bindings: mmc: add alias example
As for I2C and SPI, it now is possible to reserve a fixed index for
mmc/mmcblk devices.
Signed-off-by: Matthias Schiffer
---
v3: new patch
Documentation/devicetree/bindings/mmc/mmc-controller.yaml | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
index b96da0c7f819..22ed4a36c65d 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
@@ -367,6 +367,14 @@ examples:
};
- |
+/*
+ * Optionally define an alias to reserve a fixed index for the
+ * mmc and mmcblk devices
+ */
+aliases {
+mmc0 = &mmc3;
+};
+
mmc3: mmc@1c12000 {
#address-cells = <1>;
#size-cells = <0>;
--
2.17.1
Re: [PATCH v2 13/14] [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
Hi Clement, On Mon, Aug 03, 2020 at 09:54:05AM +0200, Clément Péron wrote: > Hi Maxime and All, > > On Sat, 4 Jul 2020 at 16:56, Clément Péron wrote: > > > > Hi Maxime, > > > > On Sat, 4 Jul 2020 at 14:13, Maxime Ripard wrote: > > > > > > Hi, > > > > > > On Sat, Jul 04, 2020 at 12:25:34PM +0200, Clément Péron wrote: > > > > Add an Operating Performance Points table for the GPU to > > > > enable Dynamic Voltage & Frequency Scaling on the H6. > > > > > > > > The voltage range is set with minival voltage set to the target > > > > and the maximal voltage set to 1.2V. This allow DVFS framework to > > > > work properly on board with fixed regulator. > > > > > > > > Signed-off-by: Clément Péron > > > > > > That patch seems reasonable, why shouldn't we merge it? > > > > I didn't test it a lot and last time I did, some frequencies looked > > unstable. > > https://lore.kernel.org/patchwork/cover/1239739/ > > > > This series adds regulator support to Panfrost devfreq, I will send a > > new one if DVFS on the H6 GPU is stable. > > > > I got this running glmark2 last time > > # glmark2-es2-drm > > === > > glmark2 2017.07 > > === > > OpenGL Information > > GL_VENDOR: Panfrost > > GL_RENDERER: Mali T720 (Panfrost) > > GL_VERSION:OpenGL ES 2.0 Mesa 20.0.5 > > === > > > > [ 93.550063] panfrost 180.gpu: GPU Fault 0x0088 (UNKNOWN) at > > 0x80117100 > > [ 94.045401] panfrost 180.gpu: gpu sched timeout, js=0, > > config=0x3700, status=0x8, head=0x21d6c00, tail=0x21d6c00, > > sched_job=e3c2132f > > > > [ 328.871070] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > > 0x > > [ 328.871070] Reason: TODO > > [ 328.871070] raw fault status: 0xAA0003C2 > > [ 328.871070] decoded fault status: SLAVE FAULT > > [ 328.871070] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > > [ 328.871070] access type 0x3: WRITE > > [ 328.871070] source id 0xAA00 > > [ 329.373327] panfrost 180.gpu: gpu sched timeout, js=1, > > config=0x3700, status=0x8, head=0xa1a4900, tail=0xa1a4900, > > sched_job=7ac31097 > > [ 329.386527] panfrost 180.gpu: js fault, js=0, > > status=DATA_INVALID_FAULT, head=0xa1a4c00, tail=0xa1a4c00 > > [ 329.396293] panfrost 180.gpu: gpu sched timeout, js=0, > > config=0x3700, status=0x58, head=0xa1a4c00, tail=0xa1a4c00, > > sched_job=04c90381 > > [ 329.411521] panfrost 180.gpu: Unhandled Page fault in AS0 at VA > > 0x > > [ 329.411521] Reason: TODO > > [ 329.411521] raw fault status: 0xAA0003C2 > > [ 329.411521] decoded fault status: SLAVE FAULT > > [ 329.411521] exception type 0xC2: TRANSLATION_FAULT_LEVEL2 > > [ 329.411521] access type 0x3: WRITE > > [ 329.411521] source id 0xAA00 > > Just to keep a track of this issue. > > Piotr Oniszczuk give more test and seems to be software related: > https://www.spinics.net/lists/dri-devel/msg264279.html > > Ondrej gave a great explanation about a possible origin of this issue: > https://freenode.irclog.whitequark.org/linux-sunxi/2020-07-11 > > 20:12 looks like gpu pll on H6 is NKMP clock, and those are > implemented in such a way in mainline that they are prone to > overshooting the frequency during output divider reduction > 20:13 so disabling P divider may help > 20:13 or fixing the dividers > 20:14 and just allowing N to change > 20:22 hmm, I haven't looked at this for quite some time, but H6 > BSP way of setting PLL factors actually makes the most sense out of > everything I've seen/tested so far > 20:23 it waits for lock not after setting NK factors, but after > reducing the M factor (pre-divider) > 20:24 I might as well re-run my CPU PLL tester with this > algorithm, to see if it fixes the lockups > 20:26 it makes sense to wait for PLL to stabilize "after" > changing all the factors that actually affect the VCO, and not just > some of them > 20:27 warpme_: ^ > 20:28 it may be the same thing that plagues the CPU PLL rate > changes at runtime I guess it's one of the bugs we never heard of... It would be a good idea to test it on another platform (like Rockchip?) to rule out any driver issue? What do you think? Maxime signature.asc Description: PGP signature
Re: [PATCH 0/7] Allwinner A64 digital audio codec fixes
Hi Mark, On Tue, Aug 18, 2020 at 05:54:50PM +0100, Mark Brown wrote: > On Sat, 25 Jul 2020 20:25:50 -0500, Samuel Holland wrote: > > This series fixes a couple of issues with the digital audio codec in the > > Allwinner A64 SoC: > > 1) Left/right channels were swapped when playing/recording audio > > 2) DAPM topology was wrong, breaking some kcontrols > > > > This is the minimum set of changes necessary to fix these issues in a > > backward-compatible way. For that reason, some DAPM widgets still have > > incorrect or confusing names; those and other issues will be fixed in > > later patch sets. > > > > [...] > > Applied to > >https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next > > Thanks! > > [1/7] ASoC: dt-bindings: Add a new compatible for the A64 codec > commit: cef305d4eb0733f25215793ed30b056a7db9bb62 > [2/7] ASoC: sun8i-codec: Fix DAPM to match the hardware topology > commit: 90cac932976e93b17203b4216ba83bdcd68e0ed0 > [3/7] ASoC: sun8i-codec: Add missing mixer routes > commit: e47d2dcd88fc3e6837f8aa0060ce820ec9001e26 > [4/7] ASoC: sun8i-codec: Add a quirk for LRCK inversion > commit: 7518805fb636308909a6a7953e9fdb194abb15f8 > [5/7] ARM: dts: sun8i: a33: Update codec widget names > (no commit info) > [6/7] arm64: dts: allwinner: a64: Update codec widget names > (no commit info) > [7/7] arm64: dts: allwinner: a64: Update the audio codec compatible > (no commit info) Ideally we should get the DT patches through arm-soc, can you drop the patches 5 to 7? Thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH] arm64: dts: allwinner: replace numerical constant with CCU_CLKX
On Mon, Aug 03, 2020 at 05:30:22PM +0300, Alexander Kochetkov wrote: > From: Alexander Kochetkov > > Signed-off-by: Alexander Kochetkov Applied, thanks Maxime signature.asc Description: PGP signature
Re: [PATCH 0/7] Support of MIPI CSI-2 for A83T and OV8865 camera
Hi, On Fri, Aug 21, 2020 at 04:59:28PM +0200, Kévin L'hôpital wrote: > > Kévin L'hôpital (7): > media: sun6i-csi: Fix the bpp for 10-bit bayer formats > dt-bindings: media: i2c: Add documentation for ov8865 > media: i2c: Add support for the OV8865 image sensor > media: sunxi: sun6i-csi: Move the sun6i_csi_dev structure to the > common header > media: sunxi: sun6i-csi: Add support of MIPI CSI-2 for A83T > ARM: dts: sun8i: a83t: Add support for the MIPI CSI-2 in CSI node > [NOT FOR MERGE] ARM: dts: sun8i: a83t: bananapi-m3: Enable OV8865 > camera You should have a cover letter here to provide some context. There's a bunch of things that would need to be explained and / or argued for here, in particular: - Why did you need to plumb it into sun6i-csi? - You're naming the CSI part as the A83t CSI, while MIPI-CSI has been supported since the A31(?), is there a reason for that? - This is not documented anywhere, what did you base this work on? Also, I think that documenting the general challenges you faced (which were likely because of the first bullet point above) and how you solved them here would be great to start a discussion if needed. Finally, iirc, Hans requires a v4l2-compliance run for any new driver, which isn't strictly the case for this driver, but isn't really *not* the case either. Maxime signature.asc Description: PGP signature
Re: [PATCH 1/7] media: sun6i-csi: Fix the bpp for 10-bit bayer formats
On Fri, Aug 21, 2020 at 04:59:29PM +0200, Kévin L'hôpital wrote: > 10-bit bayer formats are aligned to 16 bits in memory, so this is what > needs to be used as bpp for calculating the size of the buffers to > allocate. > > Signed-off-by: Kévin L'hôpital Generally speaking, you should also explain why it's not an issue for the callers. Depending on what that function is supposed to be doing (returning the padded bits or the padded bits per pixel), your patch could be either right or wrong. Since all the callers are using it to generate the number of bytes per line, your patch is indeed correct. But it should be mentionned in the commit log. Maxime signature.asc Description: PGP signature
Re: arm: dts: allwinner: a20: Add Drejo DS167 initial support
Hi,
On Sun, Aug 02, 2020 at 11:29:24PM +0300, stul...@gmail.com wrote:
> From: Sertac TULLUK
>
> Drejo DS167 is an Allwinner A20 based IoT device, which support
>
> - Allwinner A20 Cortex-A7
> - Mali-400MP2 GPU
> - AXP209 PMIC
> - 1GB DDR3 RAM
> - 8GB eMMC
> - 10/100M Ethernet
> - SATA
> - HDMI
> - 10.1inch and 7.0inch LVDS LCD and Touch screens
> - CSI: OV5640 sensor
> - USB OTG
> - 2x USB2.0
> - builtin KNX Transceiver
> - 3x Dry Contact Input
> - 3x Relay output
> - IR
> - UART3
> - SPI1
> - RTC Battery
> - 8x GPIO
> - Analogue + Digital Microphone
> - PAM8620 speaker Amplifier
> - 12V DC power supply
> - 3.7V Battery Operable
>
> Signed-off-by: Sertac TULLUK
> ---
> arch/arm/boot/dts/Makefile| 2 +
> .../boot/dts/sun7i-a20-drejo-ds167-emmc.dts | 69
> arch/arm/boot/dts/sun7i-a20-drejo-ds167.dts | 361 ++
> 3 files changed, 432 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun7i-a20-drejo-ds167-emmc.dts
> create mode 100644 arch/arm/boot/dts/sun7i-a20-drejo-ds167.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 3823090d0..574305522 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1115,6 +1115,8 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> sun7i-a20-olinuxino-lime2-emmc.dtb \
> sun7i-a20-olinuxino-micro.dtb \
> sun7i-a20-olinuxino-micro-emmc.dtb \
> + sun7i-a20-drejo-ds167.dtb \
> + sun7i-a20-drejo-ds167-emmc.dtb \
Why do you need an emmc variant here?
> sun7i-a20-orangepi.dtb \
> sun7i-a20-orangepi-mini.dtb \
> sun7i-a20-pcduino3.dtb \
> diff --git a/arch/arm/boot/dts/sun7i-a20-drejo-ds167-emmc.dts
> b/arch/arm/boot/dts/sun7i-a20-drejo-ds167-emmc.dts
> new file mode 100644
> index 0..b6147eb01
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-drejo-ds167-emmc.dts
> @@ -0,0 +1,69 @@
> +/*
> + * Copyright 2020 Sertac TULLUK
> + *
> + * Sertac TULLUK
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
You should use an SPDX tag here instead
> +#include "sun7i-a20-drejo-ds167.dts"
> +
> +/ {
> + model = "drejo DS167-eMMC";
What is the casing of the vendor name? You use an uppercase in the
commit title, but a lowercase letter here
> + compatible = "drejo,sun7i-a20-drejo-ds167-emmc", "allwinner,sun7i-a20";
The vendor prefix must be documented in vendor-prefixes.yaml, and
similarly the board compatible must be documented in arm/sunxi.yaml.
I'm not really sure why you'd need a compatible so complicated. If the
DS167 ships only with an A20, then you can simply use drejo,ds167-emmc.
Also, adding the base board compatible would make sense here.
> +
> + mmc2_pwrseq: pwrseq {
> + compatible = "mmc-pwrseq-emmc";
> + reset-gpios = <&pio 2 24 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> +&mmc2 {
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <4>;
> + non-removable;
> + mmc-pwrseq = <&mmc2_pwrseq>;
> + status = "okay";
> +
Re: [PATCH] arm64: dts: allwinner: Mark timer as stopped in suspend
Hi! On Sat, Aug 08, 2020 at 09:18:22PM -0500, Samuel Holland wrote: > When possible, system firmware on 64-bit Allwinner platforms disables > OSC24M during system suspend. Since this oscillator is the clock source > for the ARM architectural timer, this causes the timer to stop counting. > Therefore, the ARM architectural timer must not be marked as NONSTOP on > these platforms, or the time will be wrong after system resume. > > Adding the arm,no-tick-in-suspend property forces the kernel to ignore > the ARM architectural timer when calculating sleeptime; it falls back to > reading the RTC. Note that this only affects deep suspend, not s2idle. > > Signed-off-by: Samuel Holland Applied, thanks! I assume it affects all the SoCs with a Cortex-A7 as well? Maxime signature.asc Description: PGP signature
Re: [PATCH] drm/sun4i: Constify static structs
Hi, On Tue, Aug 04, 2020 at 11:53:37PM +0200, Rikard Falkeborn wrote: > A number of static variables are not modified and can be made const to > allow the compiler to put them in read-only memory. > > Signed-off-by: Rikard Falkeborn Applied, thanks! Maxime signature.asc Description: PGP signature
[git pull] m68knommu changes for v5.9-rc3
Hi Linus, Please pull the m68knommu changes for v5.9-rc3. Only a single fix for the binfmt_flat loader (reverting a recent change). Regards Greg The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd: Linux 5.9-rc2 (2020-08-23 14:08:43 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git tags/m68knommu-for-v5.9-rc3 for you to fetch changes up to 2217b982624680d19a80ebb4600d05c8586c4f96: binfmt_flat: revert "binfmt_flat: don't offset the data start" (2020-08-24 08:49:13 +1000) m68knommu: fixes for 5.9-rc3 Fixes include: . revert binfmt_flat data offset removal Max Filippov (1): binfmt_flat: revert "binfmt_flat: don't offset the data start" fs/binfmt_flat.c | 20 1 file changed, 12 insertions(+), 8 deletions(-)
RE: [RFC PATCH 1/5] printk: implement pr_cont_t
From: Petr Mladek > Sent: 25 August 2020 14:11 > > On Thu 2020-08-20 12:33:23, David Laight wrote: > > From: Petr Mladek > > > Sent: 20 August 2020 11:16 > > ... > > > Now that I think about it. This is the biggest problem with any temporary > > > buffer > > > for pr_cont() lines. I am more and more convinced that we should just > > > _keep the current behavior_. It is not ideal. But sometimes mixed > > > messages are always better than lost ones. > > > > Maybe a marker to say 'more expected' might be useful. > > OTOH lack of a trailing '\n' probably signifies that a > > pr_cont() is likely to be next. > > The problem is the "probably". Lack of trailing '\n' might also mean > that the author did not care. Note that newline is not strictly > required at the moment. The next message is concatenated only when > pr_cont() is used from the same process. Thinks (smoke comes out of ears...): If the 'trace entry' contained the pid and whether it was a pr_cont then the trace reader could merge continuation lines even if there was a small number of interleaved other traces. So anything reading continuously might break a continuation (as might happen if there is a trace from an ISR). But the output from dmesg and /var/log/messages will almost always be correct. This moves all the complexity away from the trace writing code. > I would personally hate printk when I debugged some hard-to-reproduce > bug, finally succeeded, and some message was missing just because > of a missing newline. My annoyance is that I want printk() to come out on the console (like it used to 30 years ago). I don't want the console output to be from a syslogd process. On SYSV killing syslogd (mostly) did the trick. x86 is annoying because you need to have setup a serial console (or have a high speed camera pointing at the vga monitor). > > Unexpected pr_cont() could be output with a leading "... " > > to help indicate the message is a continuation. > > Interesting idea. It might help to catch broken code. Well, I am still > not sure that people would appreciate this printk() behavior. I was thinking of just catching the case where pr_cont() data can't be appended to the earlier line. For direct tty output this would happen if an intervening printk() had to add an extra '\n' to terminate the partial line. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH v5 15/16] dt-bindings: arm: sunxi: Add Allwinner A100 Perf1 Board bindings
On Fri, Jul 24, 2020 at 03:20:12PM +0800, Frank Lee wrote: > From: Yangtao Li > > Document board compatible names for Allwinner A100 Perf1 Board. > > Signed-off-by: Yangtao Li > Reviewed-by: Rob Herring Applied, thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH v5 07/16] dt-bindings: thermal: sun8i: Add binding for A100's THS controller
On Fri, Jul 24, 2020 at 03:10:57PM +0800, Frank Lee wrote: > From: Yangtao Li > > Add a binding for A100's ths controller. > > Signed-off-by: Yangtao Li > Reviewed-by: Rob Herring Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH v5 11/16] dt-bindings: irq: sun7i-nmi: fix dt-binding for a80 nmi
On Fri, Jul 24, 2020 at 03:14:48PM +0800, Frank Lee wrote: > From: Yangtao Li > > There is no one use "allwinner,sun9i-a80-sc-nmi". The A80 uses > "allwinner,sun9i-a80-nmi". > > Let's fix it. > > Signed-off-by: Yangtao Li > Acked-by: Rob Herring Applied, thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH] drm/sun4i: add missing put_device() call in sun8i_r40_tcon_tv_set_mux()
Hi,
On Tue, Aug 25, 2020 at 07:44:03PM +0800, Yu Kuai wrote:
> If sun8i_r40_tcon_tv_set_mux() succeed, at_dma_xlate() doesn't have a
> corresponding put_device(). Thus add put_device() to fix the exception
> handling for this function implementation.
>
> Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON")
> Signed-off-by: Yu Kuai
That doesn't sound right, we're not using at_dma_xlate at all in that
driver?
Maxime
Re: [PATCH v5 14/16] arm64: allwinner: A100: add the basical Allwinner A100 DTSI file
On Fri, Jul 24, 2020 at 03:18:24PM +0800, Frank Lee wrote: > From: Yangtao Li > > Allwinner A100 is a new SoC with Cortex-A53 cores, this commit adds > the basical DTSI file of it, including the clock, i2c, pins, sid, ths, > nmi, and UART support. > > Signed-off-by: Yangtao Li Applied, thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH v5 16/16] arm64: allwinner: A100: add support for Allwinner Perf1 board
On Fri, Jul 24, 2020 at 03:21:05PM +0800, Frank Lee wrote: > From: Yangtao Li > > A100 perf1 is an Allwinner A100-based SBC, with the following features: > > - 1GiB DDR3 DRAM > - AXP803 PMIC > - 2 USB 2.0 ports > - MicroSD slot and on-board eMMC module > - on-board Nand flash > - ··· > > Adds initial support for it, including UART and PMU. > > Signed-off-by: Yangtao Li Applied thanks! Maxime signature.asc Description: PGP signature
net/netfilter/nft_set_rbtree.c:85:4: warning: Address of local auto-variable assigned to a function parameter.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 6a9dc5fd6170d0a41c8a14eb19e63d94bea5705a
commit: e32a4dc6512ce3c1a1920531246e7037896e510a netfilter: nf_tables: make
sets built-in
date: 5 months ago
compiler: arc-elf-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
cppcheck warnings: (new ones prefixed by >>)
>> net/netfilter/nft_set_rbtree.c:85:4: warning: Address of local auto-variable
>> assigned to a function parameter. [autoVariables]
*ext = &rbe->ext;
^
net/netfilter/nft_set_rbtree.c:93:3: warning: Address of local auto-variable
assigned to a function parameter. [autoVariables]
*ext = &interval->ext;
^
net/netfilter/nft_set_rbtree.c:233:5: warning: Address of local
auto-variable assigned to a function parameter. [autoVariables]
*ext = &rbe->ext;
^
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e32a4dc6512ce3c1a1920531246e7037896e510a
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e32a4dc6512ce3c1a1920531246e7037896e510a
vim +85 net/netfilter/nft_set_rbtree.c
e701001e7cbe88 net/netfilter/nft_rbtree.c Pablo Neira Ayuso 2016-04-12 41
9b7e26aee7cf27 net/netfilter/nft_set_rbtree.c Florian Westphal 2017-07-28 42
static bool __nft_rbtree_lookup(const struct net *net, const struct nft_set
*set,
9b7e26aee7cf27 net/netfilter/nft_set_rbtree.c Florian Westphal 2017-07-28 43
const u32 *key, const struct nft_set_ext **ext,
9b7e26aee7cf27 net/netfilter/nft_set_rbtree.c Florian Westphal 2017-07-28 44
unsigned int seq)
20a69341f2d00c net/netfilter/nft_rbtree.c Patrick McHardy 2013-10-11 45
{
03e5fd0e9bcc1f net/netfilter/nft_set_rbtree.c Liping Zhang 2017-03-12 46
struct nft_rbtree *priv = nft_set_priv(set);
20a69341f2d00c net/netfilter/nft_rbtree.c Patrick McHardy 2013-10-11 47
const struct nft_rbtree_elem *rbe, *interval = NULL;
42a55769132fdf net/netfilter/nft_rbtree.c Pablo Neira Ayuso 2016-07-08 48
u8 genmask = nft_genmask_cur(net);
16c45eda96038a net/netfilter/nft_rbtree.c Patrick McHardy 2015-03-21 49
const struct rb_node *parent;
e701001e7cbe88 net/netfilter/nft_rbtree.c Pablo Neira Ayuso 2016-04-12 50
const void *this;
20a69341f2d00c net/netfilter/nft_rbtree.c Patrick McHardy 2013-10-11 51
int d;
20a69341f2d00c net/netfilter/nft_rbtree.c Patrick McHardy 2013-10-11 52
9b7e26aee7cf27 net/netfilter/nft_set_rbtree.c Florian Westphal 2017-07-28 53
parent = rcu_dereference_raw(priv->root.rb_node);
20a69341f2d00c net/netfilter/nft_rbtree.c Patrick McHardy 2013-10-11 54
while (parent != NULL) {
9b7e26aee7cf27 net/netfilter/nft_set_rbtree.c Florian Westphal 2017-07-28 55
if (read_seqcount_retry(&priv->count, seq))
9b7e26aee7cf27 net/netfilter/nft_set_rbtree.c Florian Westphal 2017-07-28 56
return false;
9b7e26aee7cf27 net/netfilter/nft_set_rbtree.c Florian Westphal 2017-07-28 57
20a69341f2d00c net/netfilter/nft_rbtree.c Patrick McHardy 2013-10-11 58
rbe = rb_entry(parent, struct nft_rbtree_elem, node);
20a69341f2d00c net/netfilter/nft_rbtree.c Patrick McHardy 2013-10-11 59
e701001e7cbe88 net/netfilter/nft_rbtree.c Pablo Neira Ayuso 2016-04-12 60
this = nft_set_ext_key(&rbe->ext);
e701001e7cbe88 net/netfilter/nft_rbtree.c Pablo Neira Ayuso 2016-04-12 61
d = memcmp(this, key, set->klen);
20a69341f2d00c net/netfilter/nft_rbtree.c Patrick McHardy 2013-10-11 62
if (d < 0) {
9b7e26aee7cf27 net/netfilter/nft_set_rbtree.c Florian Westphal 2017-07-28 63
parent = rcu_dereference_raw(parent->rb_left);
f9121355eb6f9b net/netfilter/nft_set_rbtree.c Pablo Neira Ayuso 2017-03-01 64
if (interval &&
f9121355eb6f9b net/netfilter/nft_set_rbtree.c Pablo Neira Ayuso 2017-03-01 65
nft_rbtree_equal(set, this, interval) &&
82e20b44477ffe net/netfilter/nft_set_rbtree.c Taehee Yoo2018-06-07 66
nft_rbtree_interval_end(rbe) &&
f9121355eb6f9b net/netfilter/nft_set_rbtree.c Pablo Neira Ayuso 2017-03-01 67
!nft_rbtree_interval_end(interval))
e701001e7cbe88 net/netfilter/nft_rbtree.c Pablo Neira Ayuso 2016-04-12 68
continue;
20a69341f2d00c net/netfilter/nft_rbtree.c Patrick McHardy 2013-10-11 69
interval = rbe;
20a69341f2d00c net/netfilter/nft_rbtree.c Patrick McHardy 2013-10-11 70
} else if (d > 0)
9b7e26aee7cf27 net/netfilter/nft_set_rbtree.c Flori
Re: [PATCH v5 01/16] dt-bindings: clk: sunxi-ccu: add compatible string for A100 CCU and R-CCU
On Fri, Jul 24, 2020 at 02:56:08PM +0800, Frank Lee wrote: > From: Yangtao Li > > This patch adds binding to a100's ccu clock and r-ccu clock. > > Signed-off-by: Yangtao Li > Reviewed-by: Rob Herring Applied, thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH v5 02/16] clk: sunxi-ng: add support for the Allwinner A100 CCU
On Fri, Jul 24, 2020 at 02:58:43PM +0800, Frank Lee wrote: > From: Yangtao Li > > Add support for a100 in the sunxi-ng CCU framework. > > Signed-off-by: Yangtao Li Applied, thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH v5 00/16] Allwinner A100 Initial support
On Mon, Aug 24, 2020 at 09:03:27AM +0100, Lee Jones wrote: > On Mon, 24 Aug 2020, Frank Lee wrote: > > > ping.. > > "Please don't send content free pings and please allow a reasonable > time for review. People get busy, go on holiday, attend conferences > and so on so unless there is some reason for urgency (like critical > bug fixes) please allow at least a couple of weeks for review. If > there have been review comments then people may be waiting for those > to be addressed. Sending content free pings just adds to the mail > volume (if they are seen at all) and if something has gone wrong > you'll have to resend the patches anyway so [RESEND]ing with any > comments addressed is generally a much better approach." This is true to some extent, but pinging after a month doesn't seem unreasonable either. Maxime signature.asc Description: PGP signature
Re: [PATCH v5 08/16] thermal: sun8i: add TEMP_CALIB_MASK for calibration data in sun50i_h6_ths_calibrate
On Fri, Jul 24, 2020 at 03:11:42PM +0800, Frank Lee wrote: > From: Yangtao Li > > For sun50i_h6_ths_calibrate(), the data read from nvmem needs a round of > calculation. On the other hand, the newer SOC may store other data in > the space other than 12bit sensor data. Add mask operation to read data > to avoid conversion error. > > Signed-off-by: Yangtao Li Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature
Re: [PATCH v5 12/16] dt-bindings: irq: sun7i-nmi: Add binding for A100's NMI controller
On Fri, Jul 24, 2020 at 03:15:53PM +0800, Frank Lee wrote: > From: Yangtao Li > > Add a binding for A100's nmi controller. > > Signed-off-by: Yangtao Li > Acked-by: Rob Herring Applied, thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH v5 03/16] dt-bindings: pinctrl: sunxi: Get rid of continual nesting
On Fri, Jul 24, 2020 at 03:00:31PM +0800, Frank Lee wrote: > From: Yangtao Li > > Rather than a continual nesting of 'else' clauses, just make > each 'if' a new entry under 'allOf' and get rid of the else. > > Signed-off-by: Yangtao Li > Reviewed-by: Rob Herring Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH v5 04/16] dt-bindings: pinctrl: sunxi: Add A100 pinctrl bindings
On Fri, Jul 24, 2020 at 03:02:42PM +0800, Frank Lee wrote: > From: Yangtao Li > > Add device tree binding Documentation details for A100 pinctrl driver, > which has a r pin controller and a pin controller with more irq lines. > > Signed-off-by: Yangtao Li > Reviewed-by: Rob Herring Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH v5 09/16] thermal: sun8i: Add A100's THS controller support
On Fri, Jul 24, 2020 at 03:11:43PM +0800, Frank Lee wrote: > From: Yangtao Li > > This patch add thermal sensor controller support for A100, > which is similar to the previous ones. > > Signed-off-by: Yangtao Li Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH 2/7] dt-bindings: media: i2c: Add documentation for ov8865
Hi, On Fri, Aug 21, 2020 at 04:59:30PM +0200, Kévin L'hôpital wrote: > Add a documentation for the sensor ov8865 from Omnivision. > > Signed-off-by: Kévin L'hôpital In order to ease the submission of both drivers, you should probably split this series into two, one with the MIPI-CSI driver, and one with the ov8865 driver. > --- > .../devicetree/bindings/media/i2c/ov8865.txt | 51 +++ > 1 file changed, 51 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/i2c/ov8865.txt > > diff --git a/Documentation/devicetree/bindings/media/i2c/ov8865.txt > b/Documentation/devicetree/bindings/media/i2c/ov8865.txt > new file mode 100644 > index ..ac5a662288de > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/i2c/ov8865.txt > @@ -0,0 +1,51 @@ > +* Omnivision OV8865 MIPI CSI-2 > + > +Required Properties: > +- compatible: should be "ovti,ov8865" > +- clocks: reference to the xclk input clock. > +- clock-names: should be "xclk". > +- DOVDD-supply: Digital I/O voltage supply, 2.8 volts > +- AVDD-supply: Analog voltage supply, 2.8 volts > +- AFVDD-supply: Analog voltage supply, 2.8 volts > +- DVDD-supply: Digital core voltage supply, 1.2 volts > +- reset-gpios: reference to the GPIO connected to the reset pin. > +This is an active low signal to the OV8865. > +- powerdown-gpios: reference to the GPIO connected to the powerdown pin. > +This is an active low signal to the OV8865. > +- rotation: as defined in > + Documentation/devicetree/bindings/media/video-interfaces.txt, > + valid values are 0 (sensor mounted upright) and 180 (sensor > + mounted upside down). > +- remote-endpoint: a phandle to the bus receiver's endpoint node. > +- clock-lanes: should be set to <0> (clock lane on hardware lane 0). > +- data-lanes: should be set to <4> (four CSI-2 lanes supported). > + > +The device node must contain one 'port' child node for its digital output > video > +port, in accordance with the video interface bindings defined in > +Documentation/devicetree/bindings/media/video-interfaces.txt. Free form DT documentation is deprecated nowadays, you should be doing a YAML schema instead (like the ov8856 driver). Maxime signature.asc Description: PGP signature
Re: [PATCH] ARM: dts: sun8i: r40: bananapi-m2-ultra: Fix dcdc1 regulator
On Mon, Aug 24, 2020 at 09:36:49PM +0200, Jernej Skrabec wrote:
> DCDC1 regulator powers many different subsystems. While some of them can
> work at 3.0 V, some of them can not. For example, VCC-HDMI can only work
> between 3.24 V and 3.36 V. According to OS images provided by the board
> manufacturer this regulator should be set to 3.3 V.
>
> Set DCDC1 and DCDC1SW to 3.3 V in order to fix this.
>
> Fixes: da7ac948fa93 ("ARM: dts: sun8i: Add board dts file for Banana Pi M2
> Ultra")
> Signed-off-by: Jernej Skrabec
Applied, thanks
Maxime
signature.asc
Description: PGP signature
[PATCH 2/2] sched/topology: Move SD_DEGENERATE_GROUPS_MASK out of linux/sched/topology.h
SD_DEGENERATE_GROUPS_MASK is only useful for sched/topology.c, but still
gets defined for anyone who imports topology.h, leading to a flurry of
unused variable warnings.
Move it out of the header and place it next to the SD degeneration
functions in sched/topology.c.
Fixes: 4ee4ea443a5d ("sched/topology: Introduce SD metaflag for flags needing >
1 groups")
Reported-by: Andy Shevchenko
Signed-off-by: Valentin Schneider
---
include/linux/sched/topology.h | 7 ---
kernel/sched/topology.c| 7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
index b9b0dab4d067..9ef7bf686a9f 100644
--- a/include/linux/sched/topology.h
+++ b/include/linux/sched/topology.h
@@ -25,13 +25,6 @@ enum {
};
#undef SD_FLAG
-/* Generate a mask of SD flags with the SDF_NEEDS_GROUPS metaflag */
-#define SD_FLAG(name, mflags) (name * !!((mflags) & SDF_NEEDS_GROUPS)) |
-static const unsigned int SD_DEGENERATE_GROUPS_MASK =
-#include
-0;
-#undef SD_FLAG
-
#ifdef CONFIG_SCHED_DEBUG
struct sd_flag_debug {
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 4e1260cb4b44..da3cd60e4b78 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -154,6 +154,13 @@ static inline bool sched_debug(void)
}
#endif /* CONFIG_SCHED_DEBUG */
+/* Generate a mask of SD flags with the SDF_NEEDS_GROUPS metaflag */
+#define SD_FLAG(name, mflags) (name * !!((mflags) & SDF_NEEDS_GROUPS)) |
+static const unsigned int SD_DEGENERATE_GROUPS_MASK =
+#include
+0;
+#undef SD_FLAG
+
static int sd_degenerate(struct sched_domain *sd)
{
if (cpumask_weight(sched_domain_span(sd)) == 1)
--
2.27.0
Re: [PATCH 2/2] arm64: dts: renesas: r8a774e1: Add PWM device nodes
On Tue, Aug 25, 2020 at 12:45 PM Lad Prabhakar
wrote:
> From: Marian-Cristian Rotariu
>
> This patch adds PWM[0123456] device nodes to the RZ/G2H (a.k.a R8A774E1)
> device tree.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.10.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 1/2] sched/topology: Move sd_flag_debug out of linux/sched/topology.h
Defining an array in a header imported all over the place clearly is a daft
idea, that still didn't stop me from doing it.
Leave a declaration of sd_flag_debug in topology.h and move its definition
to sched/debug.c.
Fixes: b6e862f38672 ("sched/topology: Define and assign sched_domain flag
metadata")
Reported-by: Andy Shevchenko
Signed-off-by: Valentin Schneider
---
include/linux/sched/topology.h | 9 -
kernel/sched/debug.c | 6 ++
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
index 2d59ca77103e..b9b0dab4d067 100644
--- a/include/linux/sched/topology.h
+++ b/include/linux/sched/topology.h
@@ -33,14 +33,13 @@ static const unsigned int SD_DEGENERATE_GROUPS_MASK =
#undef SD_FLAG
#ifdef CONFIG_SCHED_DEBUG
-#define SD_FLAG(_name, mflags) [__##_name] = { .meta_flags = mflags, .name =
#_name },
-static const struct {
+
+struct sd_flag_debug {
unsigned int meta_flags;
char *name;
-} sd_flag_debug[] = {
-#include
};
-#undef SD_FLAG
+extern const struct sd_flag_debug sd_flag_debug[];
+
#endif
#ifdef CONFIG_SCHED_SMT
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 0655524700d2..0d7896d2a0b2 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -245,6 +245,12 @@ set_table_entry(struct ctl_table *entry,
entry->proc_handler = proc_handler;
}
+#define SD_FLAG(_name, mflags) [__##_name] = { .meta_flags = mflags, .name =
#_name },
+const struct sd_flag_debug sd_flag_debug[] = {
+#include
+};
+#undef SD_FLAG
+
static int sd_ctl_doflags(struct ctl_table *table, int write,
void *buffer, size_t *lenp, loff_t *ppos)
{
--
2.27.0
Re: [PATCH v5] arm64: dts: qcom: Add support for Xiaomi Poco F1 (Beryllium)
Hi Konrad,
On Sat, 22 Aug 2020 at 02:51, Konrad Dybcio wrote:
>
> Hi
>
> First of all, sorry if anybody sees this twice. I've been messing with
> Thunderbird lately.
>
>
>
> > dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r3.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += sdm845-db845c.dtb
> > +dtb-$(CONFIG_ARCH_QCOM) += sdm845-beryllium.dtb
>
> [B]eryllium should come before [C]heza, no? Also, aren't the non-development
> boards supposed to include the vendor name? i.e.
> sdm845-(xiaomi/poco)-beryllium.dtb
Ack. I didn't pay attention to that part. I'll fix that.
>
>
> > + model = "Xiaomi Technologies Inc. Beryllium";
>
> At least with Xperias, we settled on setting the model property to the
> "pretty" name, in this case Poco F1
Ack.
>
>
> > + pm8998-rpmh-regulators {
> > + compatible = "qcom,pm8998-rpmh-regulators";
> > + qcom,pmic-id = "a";
> > +
> > + vreg_l1a_0p875: ldo1 {
>
> I think you forgot to include (regulatorname)-supply properties which should
> cause havoc with all things regulators..
I didn't know that. Thanks for pointing that out. I just copied db845c
dts and started removing the nodes/properties which I didn't seem fit.
There is a very good probability that I goofed up big time.
FWIW in my limited testing so far (Booted AOSP to UI, with working
Touchscreen/BT/WiFi/Audio with out-of-tree drivers [1]), I didn't run
into issues with mainline (v5.9-rc1) or Android GKI (v5.4.58). May be
I just got lucky. I'll check up on the usage of (regulatorname)-supply
properties.
>
>
> > + vreg_l1a_0p875: ldo1 {
> > + regulator-min-microvolt = <88>;
> > + regulator-max-microvolt = <88>;
> 0p88? Unless it's a PMIC limitation.. Please also confirm names for the rest
> of the regulators.
>
> Also why are there so few regulators? And none from pmi8998? Are the rest
> WIP/coming in a followup commit, or are they disabled on this board? AFAICS
> you only include SoC/PMIC DTs which would suggest they should be there.
I intend to add more regulators and feature nodes in follow up commits.
>
>
> > +/* Reserved memory changes from downstream */
>
> Wouldn't it look better if you included that in the main {} node instead of
> reopening it in the middle of the file? I mean, it works, but let's hear what
> others have to say.
Ack. I'll fix that if necessary.
>
>
> > + * It seems that mmc_test reports errors if drive
> > + * strength is not 16 on clk, cmd, and data pins.
>
> You say that, but then you set "drive-strength = <10>;" for cmd and data,
> please confirm it's intentional.
In sync with db845c as well as downstream dts but I'll check on this as well.
>
>
> > +&ufs_mem_hc {
>
> UFS comes before USB alphabetically.
Ack. I'll add them alphabetically if that is the common norm.
Regards,
Amit Pundir
[1] https://github.com/pundiramit/linux/commits/beryllium-mainline
>
>
> > +&ufs_mem_phy
>
> Ditto
>
>
> > +&qup_uart6_default
>
> Ditto
>
>
> Konrad
Re: x86/kprobes: kretprobe fails to triggered if kprobe at function entry is not optimized (trigger by int3 breakpoint)
On Tue, Aug 25, 2020 at 10:15:55PM +0900, Masami Hiramatsu wrote: > > damn... one last problem is dangling instances.. so close. > > We can apparently unregister a kretprobe while there's still active > > kretprobe_instance's out referencing it. > > Yeah, kretprobe already provided the per-instance data (as far as > I know, only systemtap depends on it). We need to provide it for > such users. > But if we only have one lock, we can avoid checking NMI because > we can check the recursion with trylock. It is needed only if the > kretprobe uses per-instance data. Or we can just pass a dummy > instance on the stack. I think it is true in general, you can unregister a rp while tasks are preempted. Anyway,. I think I have a solution, just need to talk to paulmck for a bit. > > Ignoring that issue for the moment, the below seems to actually work. > > OK, this looks good to me too. > I'll make a series to rewrite kretprobe based on this patch, OK? Please, I'll send the fix along when I have it.
Re: [PATCH 1/2] dt-bindings: pwm: renesas,pwm-rcar: Add r8a774e1 support
On Tue, Aug 25, 2020 at 12:45 PM Lad Prabhakar
wrote:
> From: Marian-Cristian Rotariu
>
> Document RZ/G2H (R8A774E1) SoC bindings.
>
> No driver change is needed due to the fallback compatible value
> "renesas,pwm-rcar".
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/4] i2c: at91: implement i2c bus recovery
Hi Phil, yes, this thread is old but a similar issue came up again... On Fri, Oct 25, 2019 at 09:14:00AM +0800, Phil Reid wrote: > > > > > So at the beginning of a new transfer, we should check if SDA (or SCL?) > > > is low and, if it's true, only then we should try recover the bus. > > > > Yes, this is the proper time to do it. Remember, I2C does not define a > > timeout. > > > > FYI: Just a single poll at the start of the transfer, for it being low, will > cause problems with multi-master buses. > Bus recovery should be attempted after a timeout when trying to communicate, > even thou i2c doesn't define a timeout. > > I'm trying to fix the designware drivers handling of this at the moment. I wonder what you ended up with? You are right, a single poll is not enough. It only might be if one applies the new "single-master" binding for a given bus. If that is not present, my best idea so far is to poll SDA for the time defined in adapter->timeout and if it is all low, then initiate a recovery. All the best, Wolfram signature.asc Description: PGP signature
Re: [PATCH] net: clean up codestyle for net/ipv4
From: Miaohe Lin Date: Tue, 25 Aug 2020 08:32:11 -0400 > This is a pure codestyle cleanup patch. Also add a blank line after > declarations as warned by checkpatch.pl. > > Signed-off-by: Miaohe Lin Applied to net-next.
Re: [PATCH 6/7] mm: Pass pvec directly to find_get_entries
On Tue, Aug 25, 2020 at 02:33:24PM +0200, Jan Kara wrote: > On Mon 24-08-20 18:36:39, Matthew Wilcox wrote: > > We already have functions in filemap which take a pagevec, eg > > page_cache_delete_batch() and delete_from_page_cache_batch(). > > Right but those are really pretty internal helper functions so I don't > think they form or strong precedence. To be honest, I saw that as being the way forward for the page cache APIs. If we're going to use a batching mechanism, it should be pagevecs, and it should be built into the page cache interfaces rather than hanging out off on the side. > > So if we're going to merge the two functions, it seems more natural to > > have it in filemap.c and called find_get_entries(), but I'm definitely > > open to persuasion on this! > > I agree that having non-trivial xarray code in mm/swap.c isn't attractive > either. Dunno, I dislike the inconsistency between find_get_pages() and > find_get_entries() you create but they aren't completely consistent anyway > so I can live with that. Or we can just leave the pagevec_lookup_entries() > wrapper and the API will stay consistent... I was thinking about this some more [1] [2]. I think we can get to the point where find_get_pages(), find_get_entries() and find_get_pages_tag() (and all their variants) end up taking a pagevec as their last argument. Also, I was thinking that all these names are wrong. Really, they're mapping_get_pages(), mapping_get_entries() and mapping_get_marked_pages(). So maybe I should move in that direction. [1] https://lore.kernel.org/lkml/20200824214841.17132-1-wi...@infradead.org/ [2] https://lore.kernel.org/lkml/20200824183424.4222-1-wi...@infradead.org/
Re: [PATCH] MAINTAINERS: add Dafna Hirschfeld for rkisp1
Am 25.08.20 um 15:22 schrieb Helen Koike: Add Dafna Hirschfeld to rkisp1 maintainers list Signed-off-by: Helen Koike --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index deaafb617361c..3deb954b2bb5d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14858,6 +14858,7 @@ F: include/linux/hid-roccat* ROCKCHIP ISP V1 DRIVER M:Helen Koike +M: Dafna Hirschfeld L:linux-me...@vger.kernel.org S:Maintained F:drivers/staging/media/rkisp1/ Acked-by: Dafna Hirschfeld
Re: a saner API for allocating DMA addressable pages
On Tue, Aug 25, 2020 at 01:30:41PM +0200, Marek Szyprowski wrote: > I really wonder what is the difference between this new API and > alloc_pages(GFP_DMA, n). Is this API really needed? I thought that this > is legacy thing to be removed one day... The difference is that the pages returned are guranteed to be addressable by the devie. This is a very important difference that matters for a lot of use cases.
Re: [PATCH v2] pinctrl: sh-pfc: r8a7790: Add CAN pins, groups and functions
On Tue, Aug 25, 2020 at 11:55 AM Lad Prabhakar
wrote:
> Add pins, groups and functions for the CAN{0,1} interface.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Chris Paterson
> ---
> Hi All,
> This patch is part of series [1], since rest of the patches have been
> acked, I am resending patch 1/3 from the series.
>
> [1] https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=333191
>
> v1->v2
> * Added CAN clk pins
Thanks for the update!
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.10.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] net: Remove duplicated midx check against 0
From: Miaohe Lin Date: Tue, 25 Aug 2020 08:10:37 -0400 > Check midx against 0 is always equal to check midx against sk_bound_dev_if > when sk_bound_dev_if is known not equal to 0 in these case. > > Signed-off-by: Miaohe Lin Applied to net-next, thanks.
Re: INFO: rcu detected stall in smp_call_function
+Cc Paul, who was weirdly forgotten last time
And one additional question below, which made me remember this thing.
On Wed, Jul 29, 2020 at 02:58:11PM +0200, pet...@infradead.org wrote:
> > rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> > rcu:Tasks blocked on level-0 rcu_node (CPUs 0-1):
> > [ cut here ]
> > IRQs not enabled as expected
> > WARNING: CPU: 0 PID: 32297 at kernel/sched/core.c:2701
> > try_invoke_on_locked_down_task+0x18b/0x320 kernel/sched/core.c:2701
> > Kernel panic - not syncing: panic_on_warn set ...
> > CPU: 0 PID: 32297 Comm: syz-executor.2 Not tainted 5.8.0-rc7-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> >
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x1f0/0x31e lib/dump_stack.c:118
> > panic+0x264/0x7a0 kernel/panic.c:231
> > __warn+0x227/0x250 kernel/panic.c:600
> > report_bug+0x1b1/0x2e0 lib/bug.c:198
> > handle_bug+0x42/0x80 arch/x86/kernel/traps.c:235
> > exc_invalid_op+0x16/0x40 arch/x86/kernel/traps.c:255
> > asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:540
> > RIP: 0010:try_invoke_on_locked_down_task+0x18b/0x320
> > kernel/sched/core.c:2701
> > Code: 48 89 df e8 f7 35 09 00 4c 89 f7 e8 df b5 cf 06 e9 b5 00 00 00 c6 05
> > 34 82 38 08 01 48 c7 c7 8c d7 07 89 31 c0 e8 a5 a9 f5 ff <0f> 0b e9 15 ff
> > ff ff 48 c7 c1 30 71 8d 89 80 e1 07 80 c1 03 38 c1
> > RSP: 0018:c9007c50 EFLAGS: 00010046
> > RAX: 1aaa08be6903c500 RBX: 888085d16ac8 RCX: 888085d16240
> > RDX: 00010004 RSI: 00010004 RDI:
> > RBP: 888085d16b0c R08: 815dd389 R09: ed1015d041c3
> > R10: ed1015d041c3 R11: R12:
> > R13: 8880a8bac140 R14: 8880a8bac4c0 R15: dc00
> > rcu_print_task_stall kernel/rcu/tree_stall.h:269 [inline]
> > print_other_cpu_stall kernel/rcu/tree_stall.h:477 [inline]
>
> Ha, that calls it with IRQs already disabled,
>
> So I'm thinking we want something like so?
>
> ---
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 2142c6767682..3182caf14844 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2694,12 +2694,11 @@ try_to_wake_up(struct task_struct *p, unsigned int
> state, int wake_flags)
> */
> bool try_invoke_on_locked_down_task(struct task_struct *p, bool
> (*func)(struct task_struct *t, void *arg), void *arg)
> {
> - bool ret = false;
> struct rq_flags rf;
> + bool ret = false;
> struct rq *rq;
>
> - lockdep_assert_irqs_enabled();
> - raw_spin_lock_irq(&p->pi_lock);
> + raw_spin_lock_irqsave(&p->pi_lock, rf.flags);
> if (p->on_rq) {
> rq = __task_rq_lock(p, &rf);
> if (task_rq(p) == rq)
> @@ -2716,7 +2715,7 @@ bool try_invoke_on_locked_down_task(struct task_struct
> *p, bool (*func)(struct t
> ret = func(p, arg);
> }
> }
> - raw_spin_unlock_irq(&p->pi_lock);
> + raw_spin_unlock_irqrestore(&p->pi_lock, rf.flags);
> return ret;
> }
Paul, I wanted to use this function, but found it has very weird
semantics.
Why do you need it to (remotely) call @func when p is current? The user
in rcu_print_task_stall() explicitly bails in this case, and the other
in rcu_wait_for_one_reader() will attempt an IPI.
Would it be possible to change this function to:
- blocked task: call @func with p->pi_lock held
- queued, !running task: call @func with rq->lock held
- running task: fail.
?
[PATCH] MAINTAINERS: add Dafna Hirschfeld for rkisp1
Add Dafna Hirschfeld to rkisp1 maintainers list Signed-off-by: Helen Koike --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index deaafb617361c..3deb954b2bb5d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14858,6 +14858,7 @@ F: include/linux/hid-roccat* ROCKCHIP ISP V1 DRIVER M: Helen Koike +M: Dafna Hirschfeld L: linux-me...@vger.kernel.org S: Maintained F: drivers/staging/media/rkisp1/ -- 2.28.0.rc2
Re: [PATCH v2] ARM: dts: r8a7742-iwg21m: Add SPI NOR support
On Tue, Aug 25, 2020 at 10:54 AM Lad Prabhakar
wrote:
> Add support for the SPI NOR device used to boot up the system
> to the System on Module DT.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Chris Paterson
> ---
> Hi all,
>
> This patch is part of series [1], since rest of the patches have been
> acked I am just resending patch 3/3 from the series.
>
> [1] https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=333197
>
> v1->v2
> * Dropped #address-cells/#size-cells from flash node.
> * Added partitions for flash node.
Thanks for the update!
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.10.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 3/4] media: misc: introduce microchip_csi2dc driver
On 25.08.2020 15:44, Eugen Hristev - M18282 wrote: > On 14.08.2020 01:44, Sakari Ailus wrote: > >> Hi Eugen, >> >> Thanks for the patch. > > Hello Sakari, > > Thanks for reviewing. > >> >> On Fri, Jul 03, 2020 at 10:44:15AM +0300, Eugen Hristev wrote: >>> Microchip CSI2DC (CSI2 Demultiplexer Controller) is a misc bridge device >>> that converts a byte stream in IDI Synopsys format (coming from a CSI2HOST) >>> to a pixel stream that can be captured by a sensor controller. >>> >>> Signed-off-by: Eugen Hristev >>> --- >>>drivers/media/misc/Kconfig| 9 + >>>drivers/media/misc/Makefile | 1 + >>>drivers/media/misc/microchip_csi2dc.c | 705 ++ >>>3 files changed, 715 insertions(+) >>>create mode 100644 drivers/media/misc/microchip_csi2dc.c >>> >>> diff --git a/drivers/media/misc/Kconfig b/drivers/media/misc/Kconfig >>> index 206f39f86f46..86e892a41eba 100644 >>> --- a/drivers/media/misc/Kconfig >>> +++ b/drivers/media/misc/Kconfig >>> @@ -8,6 +8,15 @@ menu "Miscellaneous helper chips" >>> >>>comment "Various helper chips" >>> >>> +config VIDEO_MICROCHIP_CSI2DC >>> + tristate "Microchip CSI2 Demux Controller" >>> + depends on VIDEO_V4L2 >>> + help >>> + CSI2 Demux Controller driver. CSI2DC is a helper chip >>> + that converts IDI interface byte stream to a parallel pixel stream. >>> + It supports various RAW formats as input. >>> + Performs clock domain crossing between hardware blocks. >>> + >>>endmenu >>> >>>endif >>> diff --git a/drivers/media/misc/Makefile b/drivers/media/misc/Makefile >>> index f66554cd5c45..86477781b7af 100644 >>> --- a/drivers/media/misc/Makefile >>> +++ b/drivers/media/misc/Makefile >>> @@ -1 +1,2 @@ >>># SPDX-License-Identifier: GPL-2.0 >>> +obj-$(CONFIG_VIDEO_MICROCHIP_CSI2DC) += microchip_csi2dc.o >>> diff --git a/drivers/media/misc/microchip_csi2dc.c >>> b/drivers/media/misc/microchip_csi2dc.c >>> new file mode 100644 >>> index ..494b7c137b17 >>> --- /dev/null >>> +++ b/drivers/media/misc/microchip_csi2dc.c >>> @@ -0,0 +1,705 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +/* >>> + * Microchip CSI2 Demux Controller (CSI2DC) driver >>> + * >>> + * Copyright (C) 2018-2020 Microchip Technology, Inc. >>> + * >>> + * Author: Eugen Hristev >>> + * >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +/* Global configuration register */ >>> +#define CSI2DC_GCFG 0x0 >>> + >>> +/* MIPI sensor pixel clock is free running */ >>> +#define CSI2DC_GCFG_MIPIFRN BIT(0) >>> +/* Output waveform inter-line minimum delay */ >>> +#define CSI2DC_GCFG_HLC(v) ((v) << 4) >>> +#define CSI2DC_GCFG_HLC_MASK GENMASK(7, 4) >>> + >>> +/* Global control register */ >>> +#define CSI2DC_GCTLR 0x04 >>> +#define CSI2DC_GCTLR_SWRST BIT(0) >>> + >>> +/* Global status register */ >>> +#define CSI2DC_GS0x08 >>> + >>> +/* SSP interrupt status register */ >>> +#define CSI2DC_SSPIS 0x28 >>> +/* Pipe update register */ >>> +#define CSI2DC_PU0xC0 >>> +/* Video pipe attributes update */ >>> +#define CSI2DC_PU_VP BIT(0) >>> + >>> +/* Pipe update status register */ >>> +#define CSI2DC_PUS 0xC4 >>> + >>> +/* Video pipeline enable register */ >>> +#define CSI2DC_VPE 0xF8 >>> +#define CSI2DC_VPE_ENABLEBIT(0) >>> + >>> +/* Video pipeline configuration register */ >>> +#define CSI2DC_VPCFG 0xFC >>> +/* Data type */ >>> +#define CSI2DC_VPCFG_DT(v) ((v) << 0) >>> +#define CSI2DC_VPCFG_DT_MASK GENMASK(5, 0) >>> +/* Virtual channel identifier */ >>> +#define CSI2DC_VPCFG_VC(v) ((v) << 6) >>> +#define CSI2DC_VPCFG_VC_MASK GENMASK(7, 6) >>> +/* Decompression enable */ >>> +#define CSI2DC_VPCFG_DE BIT(8) >>> +/* Decoder mode */ >>> +#define CSI2DC_VPCFG_DM(v) ((v) << 9) >>> +#define CSI2DC_VPCFG_DM_DECODER8TO12 0 >>> +/* Decoder predictor 2 selection */ >>> +#define CSI2DC_VPCFG_DP2 BIT(12) >>> +/* Recommended memory storage */ >>> +#define CSI2DC_VPCFG_RMS BIT(13) >>> +/* Post adjustment */ >>> +#define CSI2DC_VPCFG_PA BIT(14) >>> + >>> +/* Video pipeline column register */ >>> +#define CSI2DC_VPCOL 0x100 >>> +/* Column number */ >>> +#define CSI2DC_VPCOL_COL(v) ((v) << 0) >>> +#define CSI2DC_VPCOL_COL_MASKGENMASK(15, 0) >>> + >>> +/* Video pipeline row register */ >>> +#define CSI2DC_VPROW 0x104 >>> +/* Row number */ >>> +#define CSI2DC_VPROW_ROW(v) ((v) << 0) >>> +#define CSI2DC_VPROW_ROW_MASKGENMASK(15, 0) >>> + >>> +/* Version register */ >>> +#define CSI2DC_VERSION
Re: [PATCH v3 05/11] genirq: Shutdown irq chips in suspend/resume during hibernation
On Sat, Aug 22, 2020 at 02:36:37AM +0200, Thomas Gleixner wrote: > From: Thomas Gleixner > > followed by an empty new line before the actual changelog text > starts. That way the attribution of the patch when applying it will be > correct. The way he sent it attribution will be correct as he managed to get his MTU to send out the mail claiming to be from you. But yes, it needs the second From line, _and_ the first from line needs to be fixed to be from him.
Re: [PATCH] net: Avoid unnecessary inet_addr_type() call when addr is INADDR_ANY
From: Miaohe Lin Date: Tue, 25 Aug 2020 07:40:48 -0400 > We can avoid unnecessary inet_addr_type() call by check addr against > INADDR_ANY first. > > Signed-off-by: Miaohe Lin Applied to net-next.
Re: [PATCH] net: Set ping saddr after we successfully get the ping port
From: Miaohe Lin Date: Tue, 25 Aug 2020 07:33:22 -0400 > We can defer set ping saddr until we successfully get the ping port. So we > can avoid clear saddr when failed. Since ping_clear_saddr() is not used > anymore now, remove it. > > Signed-off-by: Miaohe Lin Applied to net-next, thanks.
Re: [EXT] Re: [PATCH] edac: nxp: Add L1 and L2 error detection for A53 and A72 cores
Hi Alison, On 25/08/2020 03:31, Alison Wang wrote: >> On 09/07/2020 09:22, Alison Wang wrote: >>> Add error detection for A53 and A72 cores. Hardware error injection is >>> supported on A53. Software error injection is supported on both. >> > >> >> As we can't safely write to these registers from linux, so I think this >> means all >> the error injection and maybe SMC stuff can disappear. > I agreed with your opinion that CPUACTLR_EL1 and L2ACTLR can't be written in > Linux. Well, we can't do what the TRM tells us we must before writing to that register. > So the error injection can't be done in Linux. Do you mean the error > injection can > only be done in firmware before Linux boots up? If so, the system is running > with error > injection enabled all the time, it may be not a good idea too. Any suggestion? These registers are expected to have one value, forever. The errata document sometimes tells us to to set or clear one of these bits to workaround an issue. Because they can only be written to when the system is idle, typically during boot, this is firmware's responsibility. I expect firmware to set the bits in ACTLR_EL3, to prevent lower exception levels from touching any of these registers. I don't know how the error injection on A53 or A72 works, so I don't know if you can leave it enabled all the time. The bit you are setting is described as RES0 by the A53 and A72 TRMs. I suspect I had the wrong TRM open, as my 'L1DEIEN' comment seems to be what your CPUACTLR_EL1[6] is called on A35. (35, 53? Guess how that happened!) A35's error injection says: | While this bit is set, double-bit errors are injected on all writes to the L1 D-cache | data RAMs for the first word of each 32-byte region. You certainly can't leave this sort of thing enabled! And you can't change it at runtime, so we can't use it. I think features like this are intended to be used to check the integration, not to test the software. After I sent the original comments on this, I found Sascha's version, which has these issues resolved: https://lore.kernel.org/linux-arm-kernel/20200813075721.27981-1-s.ha...@pengutronix.de/ I think this version should work on your platform too. Thanks, James
Re: x86/kprobes: kretprobe fails to triggered if kprobe at function entry is not optimized (trigger by int3 breakpoint)
On Tue, 25 Aug 2020 14:09:11 +0200
pet...@infradead.org wrote:
> On Tue, Aug 25, 2020 at 03:15:38PM +0900, Masami Hiramatsu wrote:
>
> > From 24390dffe6eb9a3e95f7d46a528a1dcfd716dc81 Mon Sep 17 00:00:00 2001
> > From: Masami Hiramatsu
> > Date: Tue, 25 Aug 2020 01:37:00 +0900
> > Subject: [PATCH] kprobes/x86: Fixes NMI context check on x86
> >
> > Since commit 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()")
> > made int3 as one of NMI, in_nmi() in kprobe handlers always returns !0.
> > Thus the kretprobe handlers always skipped the execution on x86 if it
> > is using int3. (CONFIG_KPROBES_ON_FTRACE=n and
> > echo 0 > /proc/sys/debug/kprobe_optimization)
> >
> > To avoid this issue, introduce arch_kprobe_in_nmi() and check the
> > in_nmi() count is bigger than 1 << NMI_SHIFT on x86 if the handler
> > has been invoked from kprobe_int3_handler. By default, the
> > arch_kprobe_in_nmi() will be same as in_nmi().
>
> So I still hate all of this, it feels like it's making a bad hack worse.
>
> > Fixes: 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()")
>
> I think there's another problem, when you run this code with lockdep
> enabled it'll complain very loudly. Lockdep doesn't like using locks
> from NMI context much.
>
> Can't we take one step back. Why are we taking locks from kprobe
> context? I was under the impression that kprobes were lockless (for good
> reasons), why does kretprobe need one? And can't we fix that?
>
> Looking at the code it mucks about with with an hlist.
>
> So on pre_handler is tries and take a kretprobe_instance from a list,
> and fails when there isn't one. This looks like per-task-per-retprobe
> data. Also, all of that is only returned when the task dies.
>
> Surely we can do a lockless list for this. We have llist_add() and
> llist_del_first() to make a lockless LIFO/stack.
Ah, that's really nice!
> /me frobs code
>
>
> Oooohh, another lock :-( kretprobe_table_lock
>
> Bah bah bah, what a mess, surely we have a lockless hash-table
> somewhere? /me goes rummage around. Nope we don't.
>
> Lightbulb!
>
> That whole hash-table is nonsense, we don't need it. All it does is
> provide a per-task hlist. We can just stick a llist_head in task_struct
> itself and delete all that.
Yeah, at the first time kretprobe designed to not change the task struct,
but it seems odd restriction now. Per-task shadow stack should be implemented
as per-task.
> /me frobs more code...
>
> argh, arch/ code uses this
>
>
> damn... one last problem is dangling instances.. so close.
> We can apparently unregister a kretprobe while there's still active
> kretprobe_instance's out referencing it.
Yeah, kretprobe already provided the per-instance data (as far as
I know, only systemtap depends on it). We need to provide it for
such users.
But if we only have one lock, we can avoid checking NMI because
we can check the recursion with trylock. It is needed only if the
kretprobe uses per-instance data. Or we can just pass a dummy
instance on the stack.
>
> Ignoring that issue for the moment, the below seems to actually work.
OK, this looks good to me too.
I'll make a series to rewrite kretprobe based on this patch, OK?
Thanks,
>
> ---
> Subject: kprobe: Rewrite kretprobe to not use locks
>
> Use llist based atomic stack for rp->free_instances, and a llist based
> non-atomic stack for current->kretprobe_instances. The latter is only
> ever referenced from the task context and properly nests, so even if it
> gets interrupted, the interrupt should pop whatever it pushed on the
> stack before returning.
>
> XXX unregister_kretprobe*() vs active instances is broken.
> XXX everything !x86 is broken
>
> Not-Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/x86/kernel/kprobes/core.c | 75 ++-
> drivers/gpu/drm/i915/i915_request.c | 6 --
> include/linux/kprobes.h | 8 +-
> include/linux/llist.h | 15
> include/linux/sched.h | 4 +
> kernel/fork.c | 4 +
> kernel/kprobes.c| 145
> +---
> 7 files changed, 87 insertions(+), 170 deletions(-)
>
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> index 2ca10b770cff..311c26ef0fc2 100644
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -772,14 +772,12 @@ STACK_FRAME_NON_STANDARD(kretprobe_trampoline);
> */
> __used __visible void *trampoline_handler(struct pt_regs *regs)
> {
> - struct kretprobe_instance *ri = NULL;
> - struct hlist_head *head, empty_rp;
> - struct hlist_node *tmp;
> - unsigned long flags, orig_ret_address = 0;
> unsigned long trampoline_address = (unsigned long)&kretprobe_trampoline;
> kprobe_opcode_t *correct_ret_addr = NULL;
> + struct kretprobe_instance *ri = NULL;
> + struct llist_node *node, *first;
> + unsigned long orig_ret_address;
> void *fram
Re: [REGRESSION] omapdrm/N900 display broken
Hi Laurent, On 23/08/2020 19:26, Aaro Koskinen wrote: > Hi, > > On Tue, Aug 04, 2020 at 03:39:37PM +0300, Tomi Valkeinen wrote: >> On 04/08/2020 15:13, Tomi Valkeinen wrote: > >>> Can you try to pinpoint a bit where the hang happens? Maybe add >>> DRM/omapdrm debug prints, or perhaps sysrq works and it shows a lock >>> that's in deadlock. >> >> Also, one data point would be to disable venc, e.g. set venc status to >> "disabled" in dts. > > Disabling venc makes no difference. > > The hang happens in drm_fb_helper_initial_config(). I followed the > "HANG DEBUGGING" tips in the function comment text and enabled > fb.lockless_register_fb=1 to get more (serial) console output. > > Now I get this: > > [6.514739] omapdss_dss 4805.dss: supply vdda_video not found, using > dummy regulator > [6.566375] DSS: OMAP DSS rev 2.0 > [6.571807] omapdss_dss 4805.dss: bound 48050400.dispc (ops > dispc_component_ops) > [6.580749] omapdrm omapdrm.0: DMM not available, disable DMM support > [6.587982] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [6.626617] [ cut here ] > [6.631774] WARNING: CPU: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708 > drm_atomic_helper_commit_modeset_enables+0x134/0x268 > [6.643768] Modules linked in: > [6.647033] CPU: 0 PID: 18 Comm: kworker/0:1 Tainted: G U > 5.8.0-omap3-los_16068+-4-g2e7d4a7efefd-dirty #2 > [6.658966] Hardware name: Nokia RX-51 board > [6.663635] Workqueue: events deferred_probe_work_func > [6.669097] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [6.677429] [] (show_stack) from [] (__warn+0xbc/0xd4) > [6.684844] [] (__warn) from [] > (warn_slowpath_fmt+0x60/0xb8) > [6.692901] [] (warn_slowpath_fmt) from [] > (drm_atomic_helper_commit_modeset_enables+0x134/0x268) > [6.704254] [] (drm_atomic_helper_commit_modeset_enables) from > [] (omap_atomic_commit_tail+0xb4/0xc0) > [6.715972] [] (omap_atomic_commit_tail) from [] > (commit_tail+0x9c/0x1a8) > [6.725128] [] (commit_tail) from [] > (drm_atomic_helper_commit+0x134/0x158) > [6.734466] [] (drm_atomic_helper_commit) from [] > (drm_client_modeset_commit_atomic+0x16c/0x208) > [6.745727] [] (drm_client_modeset_commit_atomic) from > [] (drm_client_modeset_commit_locked+0x58/0x184) > [6.757629] [] (drm_client_modeset_commit_locked) from > [] (drm_client_modeset_commit+0x24/0x40) > [6.768798] [] (drm_client_modeset_commit) from [] > (__drm_fb_helper_restore_fbdev_mode_unlocked+0xa0/0xc8) > [6.780975] [] (__drm_fb_helper_restore_fbdev_mode_unlocked) > from [] (drm_fb_helper_set_par+0x38/0x64) > [6.792785] [] (drm_fb_helper_set_par) from [] > (fbcon_init+0x3d4/0x568) > [6.801757] [] (fbcon_init) from [] > (visual_init+0xb8/0xfc) > [6.809631] [] (visual_init) from [] > (do_bind_con_driver+0x1e0/0x3bc) > [6.818267] [] (do_bind_con_driver) from [] > (do_take_over_console+0x138/0x1d8) > [6.827880] [] (do_take_over_console) from [] > (do_fbcon_takeover+0x74/0xd4) > [6.837219] [] (do_fbcon_takeover) from [] > (register_framebuffer+0x204/0x2d8) > [6.846740] [] (register_framebuffer) from [] > (__drm_fb_helper_initial_config_and_unlock+0x3a4/0x554) > [6.858459] [] (__drm_fb_helper_initial_config_and_unlock) from > [] (omap_fbdev_init+0x84/0xbc) > [6.869537] [] (omap_fbdev_init) from [] > (pdev_probe+0x580/0x7d8) > [6.877807] [] (pdev_probe) from [] > (platform_drv_probe+0x48/0x98) Laurent, does this ring any bells? The WARN comes in drm_atomic_bridge_chain_enable() when drm_atomic_get_old_bridge_state() returns null for (presumably) sdi bridge. I'm not sure why the bridge state would not be there. Aaro, you can probably debug easier if you disable CONFIG_FRAMEBUFFER_CONSOLE, or even CONFIG_DRM_FBDEV_EMULATION. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] crypto: sa2ul - Reduce stack usage
On 24/08/2020 16:12, Herbert Xu wrote:
On Sun, Aug 16, 2020 at 02:56:43PM +0800, kernel test robot wrote:
drivers/crypto/sa2ul.c: In function 'sa_prepare_iopads':
drivers/crypto/sa2ul.c:432:1: warning: the frame size of 1076 bytes is larger
than 1024 bytes [-Wframe-larger-than=]
This patch tries to reduce the stack frame size in sa2ul.
---8<---
This patch reduces the stack usage in sa2ul:
1. Move the exported sha state into sa_prepare_iopads so that it
can occupy the same space as the k_pad buffer.
2. Use one buffer for ipad/opad in sa_prepare_iopads.
3. Remove ipad/opad buffer from sa_set_sc_auth.
4. Use async skcipher fallback and remove on-stack request from
sa_cipher_run.
Reported-by: kernel test robot
Fixes: d2c8ac187fc9 ("crypto: sa2ul - Add AEAD algorithm support")
Signed-off-by: Herbert Xu
This patch seems ok, I also tested it locally so:
Reviewed-by: Tero Kristo
Tested-by: Tero Kristo
diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c
index 5bc099052bd2..66629cad9531 100644
--- a/drivers/crypto/sa2ul.c
+++ b/drivers/crypto/sa2ul.c
@@ -9,8 +9,10 @@
*Tero Kristo
*/
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -356,42 +358,45 @@ static void sa_swiz_128(u8 *in, u16 len)
}
/* Prepare the ipad and opad from key as per SHA algorithm step 1*/
-static void prepare_kiopad(u8 *k_ipad, u8 *k_opad, const u8 *key, u16 key_sz)
+static void prepare_kipad(u8 *k_ipad, const u8 *key, u16 key_sz)
{
int i;
- for (i = 0; i < key_sz; i++) {
+ for (i = 0; i < key_sz; i++)
k_ipad[i] = key[i] ^ 0x36;
- k_opad[i] = key[i] ^ 0x5c;
- }
/* Instead of XOR with 0 */
- for (; i < SHA1_BLOCK_SIZE; i++) {
+ for (; i < SHA1_BLOCK_SIZE; i++)
k_ipad[i] = 0x36;
+}
+
+static void prepare_kopad(u8 *k_opad, const u8 *key, u16 key_sz)
+{
+ int i;
+
+ for (i = 0; i < key_sz; i++)
+ k_opad[i] = key[i] ^ 0x5c;
+
+ /* Instead of XOR with 0 */
+ for (; i < SHA1_BLOCK_SIZE; i++)
k_opad[i] = 0x5c;
- }
}
-static void sa_export_shash(struct shash_desc *hash, int block_size,
+static void sa_export_shash(void *state, struct shash_desc *hash,
int digest_size, __be32 *out)
{
- union {
- struct sha1_state sha1;
- struct sha256_state sha256;
- struct sha512_state sha512;
- } sha;
- void *state;
+ struct sha1_state *sha1;
+ struct sha256_state *sha256;
u32 *result;
- int i;
switch (digest_size) {
case SHA1_DIGEST_SIZE:
- state = &sha.sha1;
- result = sha.sha1.state;
+ sha1 = state;
+ result = sha1->state;
break;
case SHA256_DIGEST_SIZE:
- state = &sha.sha256;
- result = sha.sha256.state;
+ sha256 = state;
+ result = sha256->state;
break;
default:
dev_err(sa_k3_dev, "%s: bad digest_size=%d\n", __func__,
@@ -401,8 +406,7 @@ static void sa_export_shash(struct shash_desc *hash, int
block_size,
crypto_shash_export(hash, state);
- for (i = 0; i < digest_size >> 2; i++)
- out[i] = cpu_to_be32(result[i]);
+ cpu_to_be32_array(out, result, digest_size / 4);
}
static void sa_prepare_iopads(struct algo_data *data, const u8 *key,
@@ -411,24 +415,28 @@ static void sa_prepare_iopads(struct algo_data *data,
const u8 *key,
SHASH_DESC_ON_STACK(shash, data->ctx->shash);
int block_size = crypto_shash_blocksize(data->ctx->shash);
int digest_size = crypto_shash_digestsize(data->ctx->shash);
- u8 k_ipad[SHA1_BLOCK_SIZE];
- u8 k_opad[SHA1_BLOCK_SIZE];
+ union {
+ struct sha1_state sha1;
+ struct sha256_state sha256;
+ u8 k_pad[SHA1_BLOCK_SIZE];
+ } sha;
shash->tfm = data->ctx->shash;
- prepare_kiopad(k_ipad, k_opad, key, key_sz);
-
- memzero_explicit(ipad, block_size);
- memzero_explicit(opad, block_size);
+ prepare_kipad(sha.k_pad, key, key_sz);
crypto_shash_init(shash);
- crypto_shash_update(shash, k_ipad, block_size);
- sa_export_shash(shash, block_size, digest_size, ipad);
+ crypto_shash_update(shash, sha.k_pad, block_size);
+ sa_export_shash(&sha, shash, digest_size, ipad);
+
+ prepare_kopad(sha.k_pad, key, key_sz);
crypto_shash_init(shash);
- crypto_shash_update(shash, k_opad, block_size);
+ crypto_shash_update(shash, sha.k_pad, block_size);
- sa_export_shash(shash, block_size, digest_size, opad);
+ sa_export_shash(&sha, shash, digest_size, opad);
+
+ memzero_explicit(&sha, sizeof(sha));
}
/* Derive the inverse key used in AES-CBC decryption operation */
@@ -501,7 +509,8
Re: [RESEND 3/3] venus: handle use after free for iommu_map/iommu_unmap
On 8/7/20 9:24 AM, Mansur Alisha Shaik wrote:
> In concurrency usecase and reboot scenario we are trying
> to map fw.iommu_domain which is already unmapped during
> shutdown. This is causing NULL pointer dereference crash.
>
> This case is handled by adding necessary checks.
>
> Call trace:
> __iommu_map+0x4c/0x348
> iommu_map+0x5c/0x70
> venus_boot+0x184/0x230 [venus_core]
> venus_sys_error_handler+0xa0/0x14c [venus_core]
> process_one_work+0x210/0x3d0
> worker_thread+0x248/0x3f4
> kthread+0x11c/0x12c
> ret_from_fork+0x10/0x18
>
> Signed-off-by: Mansur Alisha Shaik
> ---
> drivers/media/platform/qcom/venus/firmware.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/firmware.c
> b/drivers/media/platform/qcom/venus/firmware.c
> index 8801a6a..c427e88 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -171,9 +171,14 @@ static int venus_shutdown_no_tz(struct venus_core *core)
>
> iommu = core->fw.iommu_domain;
>
> - unmapped = iommu_unmap(iommu, VENUS_FW_START_ADDR, mapped);
> - if (unmapped != mapped)
> - dev_err(dev, "failed to unmap firmware\n");
> + if (core->fw.mapped_mem_size && iommu) {
> + unmapped = iommu_unmap(iommu, VENUS_FW_START_ADDR, mapped);
> +
> + if (unmapped != mapped)
> + dev_err(dev, "failed to unmap firmware\n");
> + else
> + core->fw.mapped_mem_size = 0;
> + }
>
> return 0;
> }
> @@ -288,7 +293,11 @@ void venus_firmware_deinit(struct venus_core *core)
> iommu = core->fw.iommu_domain;
>
> iommu_detach_device(iommu, core->fw.dev);
> - iommu_domain_free(iommu);
> +
> + if (core->fw.iommu_domain) {
why not just ?
if (iommu)
> + iommu_domain_free(iommu);
> + core->fw.iommu_domain = NULL;
> + }
>
> platform_device_unregister(to_platform_device(core->fw.dev));
> }
>
--
regards,
Stan
AW: [PATCH v2] HID: roccat: add bounds checking in kone_sysfs_write_settings()
lets hope the maintainer picks that up. re, wh Von: Dan Carpenter [dan.carpen...@oracle.com] Gesendet: Dienstag, 25. August 2020 09:29 An: Walter Harms Cc: Stefan Achatz; Jiri Kosina; Benjamin Tissoires; linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org; kernel-janit...@vger.kernel.org Betreff: Re: [PATCH v2] HID: roccat: add bounds checking in kone_sysfs_write_settings() On Mon, Aug 24, 2020 at 03:35:16PM +, Walter Harms wrote: > hello Dan, > > i notice that you can shorten the line to: > (line above checks for count==sizeof(struct kone_settings)) > > difference = memcmp(settings, &kone->settings, count); > > nothing special just to shorten the line and make use of count. > > and just to save one indent level and because its readabel nicely: > if ( ! difference ) > goto unlock; > > hope that helps Yeah. I wrote that version and I wanted to send it, but then I decided not to change the style too much. I definitely agree with you, but I figured I would keep the patch less intrusive. regards, dan carpenter
Re: [PATCH V3 2/3] arm64: dts: qcom: sc7180: Add sleep pin ctrl for BT uart
On 2020-08-21 22:52, Matthias Kaehlcke wrote:
On Thu, Aug 20, 2020 at 07:21:06PM +0530, satya priya wrote:
Add sleep pin ctrl for BT uart, and also change the bias
configuration to match Bluetooth module.
Signed-off-by: satya priya
Reviewed-by: Akash Asthana
---
Changes in V2:
- This patch adds sleep state for BT UART. Newly added in V2.
Changes in V3:
- Remove "output-high" for TX from both sleep and default states
as it is not required. Configure pull-up for TX in sleep state.
arch/arm64/boot/dts/qcom/sc7180-idp.dts | 54
+++--
1 file changed, 45 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
index d8b5507..806f626 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
@@ -473,20 +473,20 @@
&qup_uart3_default {
pinconf-cts {
- /*
-* Configure a pull-down on 38 (CTS) to match the pull of
-* the Bluetooth module.
-*/
+ /* Configure no pull on 38 (CTS) to match Bluetooth module */
pins = "gpio38";
- bias-pull-down;
- output-high;
+ bias-disable;
I think it should be ok in functional terms, but I don't like the
rationale
and also doubt the change is really needed.
If the pull is removed to match the Bluetooth module, then that sounds
as
if the signal was floating on the the BT side, which I think is not the
case.
Yes, according to the datasheet there is no pull when the BT controller
is
active, but then it drives the signal actively to either high or low.
There
seems to be no merit in 'matching' the Bluetooth side in this case, if
the
signal was really floating on the BT side we would definitely not want
this.
In a reply to v2 you said:
Recently on cherokee we worked with BT team and came to an agreement
to
keep no-pull from our side in order to not conflict with their pull in
any state.
What are these conflicting pull states?
The WCN3998 datasheet has a pull-down on RTS (WCN3998 side) in reset
and
boot mode, and no pull in active mode. In reset and boot mode the host
config with a pull down would match, and no pull in active mode doesn't
conflict with the pull-down on the host UART. My understanding is that
the pinconf pulls are weak pulls, so as soon as the BT chip drives its
RTS the pull on the host side shouldn't matter.
yes, I agree with you, the pinconf pulls are weak. As this is driven by
BT SoC (pull on HOST side shouldn't matter), we are not mentioning any
bias configuration from our side and simply putting it as no-pull, just
to not conflict in any case. It seems that the rationale mentioned is a
bit confusing i will change it to clearly specify why we are configuring
no-pull.
Is this change actually related with wakeup support? I have the
impression
that multiple things are conflated in this patch. If some of the
changes
are just fixing/improving other things they should be in a separate
patch,
which could be part of this series, otherwise it's really hard to
distinguish between the pieces that are actually relevant for wakeup
and
the rest.
Independently of whether the changes are done in a single or multiple
patches, the commit log should include details on why the changes are
necessary, especially when there are not explantatory comments in the
DT/code itself (e.g. the removal of 'output-high', which seems correct
to me, but no reason is given why it is done).
This change is not related to wakeup support, I will make it a separate
patch, will also mention the details in commit text.
};
pinconf-rts {
- /* We'll drive 39 (RTS), so no pull */
+ /*
+* Configure pull-down on 39 (RTS). This is needed to avoid a
+* floating pin which could mislead Bluetooth controller
+* with UART RFR state (READY/NOT_READY).
+*/
pins = "gpio39";
drive-strength = <2>;
- bias-disable;
+ bias-pull-down;
};
[copy of my comment on v2]
I'm a bit at a loss here, about two things:
RTS is an output pin controlled by the UART. IIUC if the UART port is
active
and hardware flow control is enabled the RTS signal is either driven to
high
or low, but not floating.
Yes, RTS is either driven high or low. HW flow control is always enabled
and only turned off when RX FIFO is full. Whereas SW flow control is
controlled by upper layers(serial core), also it can be enabled/disabled
from host by calling set_mctrl.
Now lets assume I'm wrong with the above and RTS can be floating. We
only want
the BT SoC to send data when the host UART is ready to receive them,
right?
RTS is an active low signal, hence by configuring it as a pull-down the
BT
SoC can send data regardless of whether the host UART actu
[PATCH v11 4/5] powerpc/vdso: Switch VDSO to generic C implementation.
For VDSO32 on PPC64, we create a fake 32 bits config, on the same principle as MIPS architecture, in order to get the correct parts of the different asm header files. With the C VDSO, the performance is slightly lower, but it is worth it as it will ease maintenance and evolution, and also brings clocks that are not supported with the ASM VDSO. On an 8xx at 132 MHz, vdsotest with the ASM VDSO: gettimeofday:vdso: 828 nsec/call clock-getres-realtime-coarse:vdso: 391 nsec/call clock-gettime-realtime-coarse:vdso: 614 nsec/call clock-getres-realtime:vdso: 460 nsec/call clock-gettime-realtime:vdso: 876 nsec/call clock-getres-monotonic-coarse:vdso: 399 nsec/call clock-gettime-monotonic-coarse:vdso: 691 nsec/call clock-getres-monotonic:vdso: 460 nsec/call clock-gettime-monotonic:vdso: 1026 nsec/call On an 8xx at 132 MHz, vdsotest with the C VDSO: gettimeofday:vdso: 955 nsec/call clock-getres-realtime-coarse:vdso: 545 nsec/call clock-gettime-realtime-coarse:vdso: 592 nsec/call clock-getres-realtime:vdso: 545 nsec/call clock-gettime-realtime:vdso: 941 nsec/call clock-getres-monotonic-coarse:vdso: 545 nsec/call clock-gettime-monotonic-coarse:vdso: 591 nsec/call clock-getres-monotonic:vdso: 545 nsec/call clock-gettime-monotonic:vdso: 940 nsec/call It is even better for gettime with monotonic clocks. Unsupported clocks with ASM VDSO: clock-gettime-boottime:vdso: 3851 nsec/call clock-gettime-tai:vdso: 3852 nsec/call clock-gettime-monotonic-raw:vdso: 3396 nsec/call Same clocks with C VDSO: clock-gettime-tai:vdso: 941 nsec/call clock-gettime-monotonic-raw:vdso: 1001 nsec/call clock-gettime-monotonic-coarse:vdso: 591 nsec/call On an 8321E at 333 MHz, vdsotest with the ASM VDSO: gettimeofday:vdso: 220 nsec/call clock-getres-realtime-coarse:vdso: 102 nsec/call clock-gettime-realtime-coarse:vdso: 178 nsec/call clock-getres-realtime:vdso: 129 nsec/call clock-gettime-realtime:vdso: 235 nsec/call clock-getres-monotonic-coarse:vdso: 105 nsec/call clock-gettime-monotonic-coarse:vdso: 208 nsec/call clock-getres-monotonic:vdso: 129 nsec/call clock-gettime-monotonic:vdso: 274 nsec/call On an 8321E at 333 MHz, vdsotest with the C VDSO: gettimeofday:vdso: 272 nsec/call clock-getres-realtime-coarse:vdso: 160 nsec/call clock-gettime-realtime-coarse:vdso: 184 nsec/call clock-getres-realtime:vdso: 166 nsec/call clock-gettime-realtime:vdso: 281 nsec/call clock-getres-monotonic-coarse:vdso: 160 nsec/call clock-gettime-monotonic-coarse:vdso: 184 nsec/call clock-getres-monotonic:vdso: 169 nsec/call clock-gettime-monotonic:vdso: 275 nsec/call Signed-off-by: Christophe Leroy --- v9: - Rebased (Impact on arch/powerpc/kernel/vdso??/Makefile v7: - Split out preparatory changes in a new preceding patch - Added -fasynchronous-unwind-tables to CC flags. v6: - Added missing prototypes in asm/vdso/gettimeofday.h for __c_kernel_ functions. - Using STACK_FRAME_OVERHEAD instead of INT_FRAME_SIZE - Rebased on powerpc/merge as of 7 Apr 2020 - Fixed build failure with gcc 9 - Added a patch to create asm/vdso/processor.h and more cpu_relax() in it Signed-off-by: Christophe Leroy --- arch/powerpc/Kconfig | 2 + arch/powerpc/include/asm/vdso/vsyscall.h | 25 ++ arch/powerpc/include/asm/vdso_datapage.h | 40 +-- arch/powerpc/kernel/asm-offsets.c | 49 +--- arch/powerpc/kernel/time.c | 91 +-- arch/powerpc/kernel/vdso.c | 5 +- arch/powerpc/kernel/vdso32/Makefile| 32 ++- arch/powerpc/kernel/vdso32/config-fake32.h | 34 +++ arch/powerpc/kernel/vdso32/gettimeofday.S | 291 + arch/powerpc/kernel/vdso64/Makefile| 23 +- arch/powerpc/kernel/vdso64/gettimeofday.S | 242 + 11 files changed, 143 insertions(+), 691 deletions(-) create mode 100644 arch/powerpc/include/asm/vdso/vsyscall.h create mode 100644 arch/powerpc/kernel/vdso32/config-fake32.h diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 1f48bbfb3ce9..5bd22f4b38c3 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -173,6 +173,7 @@ config PPC select GENERIC_STRNCPY_FROM_USER select GENERIC_STRNLEN_USER select GENERIC_TIME_VSYSCALL + select GENERIC_GETTIMEOFDAY select HAVE_ARCH_AUDITSYSCALL select HAVE_ARCH_HUGE_VMAP if PPC_BOOK3S_64 && PPC_RADIX_MMU select HAVE_ARCH_JUMP_LABEL @@ -203,6 +204,7 @@ config PPC select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_TRACER select HAVE_GCC_PLUGINS if GCC_VERSION >= 50200 # plugin support on gcc <= 5.1 is buggy on PPC + select HAVE_GENERIC_VDSO select HAVE_HW_BREAKPOINT if PERF_EVENTS && (PPC_BOOK3S || PPC_8xx) select HAVE_IDE select HAVE_IOREMAP_PROT diff --git a/arch/powerpc/
[PATCH] clk: sunxi-ng: sun8i: r40: Use sigma delta modulation for audio PLL
Audio cores need specific clock rates which can't be simply obtained by
adjusting integer multipliers and dividers. HW for such cases supports
delta-sigma modulation which enables fractional multipliers.
Port H3 delta-sigma table to R40. They have identical audio PLLs.
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 37 ++--
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index 23bfe1d12f21..84153418453f 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -45,18 +45,29 @@ static struct ccu_nkmp pll_cpu_clk = {
* the base (2x, 4x and 8x), and one variable divider (the one true
* pll audio).
*
- * We don't have any need for the variable divider for now, so we just
- * hardcode it to match with the clock names
+ * With sigma-delta modulation for fractional-N on the audio PLL,
+ * we have to use specific dividers. This means the variable divider
+ * can no longer be used, as the audio codec requests the exact clock
+ * rates we support through this mechanism. So we now hard code the
+ * variable divider to 1. This means the clock rates will no longer
+ * match the clock names.
*/
#define SUN8I_R40_PLL_AUDIO_REG0x008
-static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
- "osc24M", 0x008,
- 8, 7,/* N */
- 0, 5,/* M */
- BIT(31), /* gate */
- BIT(28), /* lock */
- CLK_SET_RATE_UNGATE);
+static struct ccu_sdm_setting pll_audio_sdm_table[] = {
+ { .rate = 22579200, .pattern = 0xc0010d84, .m = 8, .n = 7 },
+ { .rate = 24576000, .pattern = 0xc000ac02, .m = 14, .n = 14 },
+};
+
+static SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
+ "osc24M", 0x008,
+ 8, 7,/* N */
+ 0, 5,/* M */
+ pll_audio_sdm_table, BIT(24),
+ 0x284, BIT(31),
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX(pll_video0_clk, "pll-video0",
"osc24M", 0x0010,
@@ -952,10 +963,10 @@ static const struct clk_hw *clk_parent_pll_audio[] = {
&pll_audio_base_clk.common.hw
};
-/* We hardcode the divider to 4 for now */
+/* We hardcode the divider to 1 for now */
static CLK_FIXED_FACTOR_HWS(pll_audio_clk, "pll-audio",
clk_parent_pll_audio,
- 4, 1, CLK_SET_RATE_PARENT);
+ 1, 1, CLK_SET_RATE_PARENT);
static CLK_FIXED_FACTOR_HWS(pll_audio_2x_clk, "pll-audio-2x",
clk_parent_pll_audio,
2, 1, CLK_SET_RATE_PARENT);
@@ -1307,10 +1318,10 @@ static int sun8i_r40_ccu_probe(struct platform_device
*pdev)
if (IS_ERR(reg))
return PTR_ERR(reg);
- /* Force the PLL-Audio-1x divider to 4 */
+ /* Force the PLL-Audio-1x divider to 1 */
val = readl(reg + SUN8I_R40_PLL_AUDIO_REG);
val &= ~GENMASK(19, 16);
- writel(val | (3 << 16), reg + SUN8I_R40_PLL_AUDIO_REG);
+ writel(val | (0 << 16), reg + SUN8I_R40_PLL_AUDIO_REG);
/* Force PLL-MIPI to MIPI mode */
val = readl(reg + SUN8I_R40_PLL_MIPI_REG);
--
2.28.0
[PATCH v11 3/5] powerpc/vdso: Save and restore TOC pointer on PPC64
On PPC64, the TOC pointer needs to be saved and restored. Suggested-by: Michael Ellerman Signed-off-by: Christophe Leroy --- v9: New. I'm not sure this is really needed, I can't see the VDSO C code doing anything with r2, at least on ppc64_defconfig. So I let you decide whether you take it or not. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/vdso/gettimeofday.h | 12 1 file changed, 12 insertions(+) diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h b/arch/powerpc/include/asm/vdso/gettimeofday.h index dce9d5051259..59a609a48b63 100644 --- a/arch/powerpc/include/asm/vdso/gettimeofday.h +++ b/arch/powerpc/include/asm/vdso/gettimeofday.h @@ -19,10 +19,16 @@ .cfi_register lr, r0 PPC_STLUr1, -STACK_FRAME_OVERHEAD(r1) PPC_STL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1) +#ifdef CONFIG_PPC64 + PPC_STL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1) +#endif get_datapager5, r0 addir5, r5, VDSO_DATA_OFFSET bl \funct PPC_LL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1) +#ifdef CONFIG_PPC64 + PPC_LL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1) +#endif cmpwi r3, 0 mtlrr0 .cfi_restore lr @@ -42,10 +48,16 @@ .cfi_register lr, r0 PPC_STLUr1, -STACK_FRAME_OVERHEAD(r1) PPC_STL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1) +#ifdef CONFIG_PPC64 + PPC_STL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1) +#endif get_datapager4, r0 addir4, r4, VDSO_DATA_OFFSET bl \funct PPC_LL r0, STACK_FRAME_OVERHEAD + PPC_LR_STKOFF(r1) +#ifdef CONFIG_PPC64 + PPC_LL r2, STACK_FRAME_OVERHEAD + STK_GOT(r1) +#endif crclr so mtlrr0 .cfi_restore lr -- 2.25.0
